Deployment of a LoRaWAN network and evaluation of tracking devices in the context of smart cities

Abstract

Recent public cooperation between the Federal University of Technology – Parana (UTFPR) and the Toledo Municipality plans to implement the concept of smart cities in this city. In this context, one of the applications under development intends to track the recyclable garbage collector trucks in real time over the Internet. Actually, fleet vehicle tracking is one of the main applications for smart cities. LoRaWAN stands out among network technologies for smart cities due to operating in an open frequency range, covering long distances with low power consumption and low equipment cost. However, the coverage and performance of LoRaWAN is directly affected by both the environment and configuration parameters. In addition, tracking devices must be able to send its coordinates to the Internet even when the vehicle goes through zones where there are obstacles for electromagnetic waves such as elevated buildings or valleys. In this paper we perform experimental investigations to evaluate four LoRaWAN tracking devices, two available out of the box and two assembled and programmed. The behavior of each tracking device is analyzed when moving at a constant speed through three representative urban areas totaling 10.71 km². The two most efficient tracking devices are analyzed in a stretch of 3.5 km with speeds ranging from 0 to 30 km/h, 0 to 50 km/h and 0 to 100 km/h. Results include a quantitative and qualitative aspects, including the received signal strength indication (RSSI), signal-to-noise ratio (SNR), packet delivery ratio (PDR), and spreading factor (SF) for the received geographic coordinates. As the devices depend on the quality of the signal offered by the network, we also present the results of the development and evaluation of the LoRaWAN network, by planning its coverage throughout the city.

1 Introduction

Despite the fact that there is still no consensus on what characteristics or requirements define smart cities, some definitions are technology-based [1]. In this sense, the combination of sensing technologies, long-range wireless networks, and computational infrastructure for processing large volumes of heterogeneous data enables the development of intelligent and scalable solutions to deal with the challenges of large urban centers [2].

A fundamental requirement for any smart city application is the ability to transmit its data through a communication network [3]. In a smart city, a data communication network is not exclusively used to connect people, but also any object [4]. The Internet of Things (IoT) concept is used to define objects connected to the Internet, which are capable of generating useful data and being represented in the virtual world [5]. Such objects have particular characteristics regarding the use of a network: (i) they send small amounts of data periodically; (ii) connect directly to the Internet or to each other typically, but not exclusively, via a wireless link; (iii) are powered by batteries and/or solar panels; (iv) may be spread over areas of difficult access and (v) are fixed or moving, i.e., on a utility pole or in a moving vehicle. In this scenario, Low Power Wide Area Network (LPWAN) is a class of networks characterized by low power consumption and coverage of large areas designed to provide connectivity for the IoT objects, particularly for typical smart city applications [6–8].

Among the main LPWAN technologies and protocols are: NB-IoT (Narrowband IoT) [9], SigFox [10] and LoRaWAN (LoRa Wide Area Network) [11]. Although they share several similarities, the main difference is in the cost of licensing use. The NB-IoT network is based on the licensed LTE (Long Term Evolution) network, also known as 4G, and already existing among cellular service carriers. SigFox acts as a conventional telecommunication carrier, deploying the necessary infrastructure to operate the network, but charging the customer for its use. On the other hand, the open standard LoRaWAN operates on wireless technology LoRa (Long Range) [12]. Despite LoRa is a proprietary technology of Semtech, LoRaWAN is open and it does not require paying any fee for the use of the network. However, it is the user’s responsibility to deploy and maintain the LoRaWAN infrastructure.

Recently, the Federal University of Technology - Parana (UTFPR) and the Municipality of Toledo entered into an agreement to develop the concept of smart cities. LoRaWAN is the network chosen to support the smart cities initiative in Toledo, mainly because it is possible to install and expand the network whenever necessary with a relatively low investment. One of the applications under development is fleet vehicle tracking [13]. The municipality would like a system to track the recyclable garbage collector trucks. Through a GPS (Global Positioning System) device attached to the vehicle, it is possible to track it within the city and make its route available in the cloud in real time. Additionally, applications running in the cloud can estimate vehicle speed and also emit alerts when it approaches or moves away from an origin or deviates from a predefined route.

However, the success of the tracking application depends directly on its ability to send the coordinates to the Internet, even when the vehicle goes through zones where there are obstacles for electromagnetic waves such as elevated buildings, trees, flatlands, or valleys. The obstacles and the irregular terrain profile attenuate the signal, reduce communication distance, and can even interrupt communication. Even though the physical layer of LoRaWAN is supposed to reach a range of 5 km in urban areas, and it is robust against a high degree of interference, in addition to multi-path and Doppler effects [8, 14], we need to know how LoRaWAN performs in the field, including its real range, with moving objects in order to perform possible optimizations and properly configure the network and applications, thus aiming its implementation in a real scenario. On the other hand, the IoT market currently offers several end devices with GPS and LoRa transmitters, with the promise of real-time tracking [15–17]. Therefore, it is essential to check whether these devices can in fact be adopted in a real scenario.

In this paper, we perform experimental investigations to evaluate commercial and assembled LoRaWAN tracker devices aiming to understand the behaviour of such devices in order to select the most suitable one to be installed in the recycling garbage trucks in the future. Although the literature presents important investigations on how to correctly configure the LoRa parameters in different environments [14, 18–20], including when there are mobile nodes, as far as we know, there are no practical evaluations comparing commercial and non-commercial LoRaWAN tracking. Furthermore, each environment presents a particular set of characteristics that make it unique and challenging for radio propagation, such as vegetation, climate, Line of Sight (LoS), etc.

We assessed four tracking devices, two of-the-shelf commercial devices, and two assembled and programmed devices. Both commercial devices are projected for tracking on LoRaWAN networks. The third device has a built-in GPS and a LoRa transmitter, being the LoRaWAN layer programmed using the LMIC library [21]. The fourth device was assembled using an Arduino Uno, a GPS transmitter, and a commercial LoRaWAN transmitter. We perform two experiments. In the first experiment, all four devices were attached to a vehicle moving at a constant speed, simulating the recyclable garbage collector truck. The evaluation took place in three areas around the university campus, with approximate sizes of 0.34 km², 0.77 km² and 9.6 km². The results show the packet delivery ratio (PDR) as the efficiency of each device in the three areas. PDR is the ratio of the number of packets delivered in full to the total number of packets sent from a device to the LoRaWAN gateway. There is also a qualitative evaluation, which considers the received signal strength indicator (RSSI), the signal-to-noise ratio (SNR), and the spreading factor (SF) for the geographic coordinates received.

From the results of the first experiment, we select the two most efficient devices and perform a new experiment. The objective of this new experiment is twofold: assess the efficiency of the devices at different speeds and verify if there is a significant difference between them when the vehicle accelerates. We evaluate the devices varying the velocity from 0 to 30 km/h, 0 to 50 km/h, and 0 to 100 km/h in a 3.5 km stretch. In this experiment, results include PDR and the SF used for the devices. With the results in hand, we also presented the cost-benefit of each device.

The evaluation of tracking devices is strictly linked to the signal quality offered by the LoRaWAN network. Therefore, we deployed the LoRaWAN network on the rooftop of a building in our campus with an SX1301 LoRa gateway, and have conducted simulations and practical experiments to evaluate both RSSI and SNR inside the campus surroundings and also in some more distant city locations. In Toledo, there is no study on radio frequency propagation in the 915 MHz spectrum, so the data obtained are compared with a network coverage model obtained by the CloudRF tool [22]. In this sense, UTFPR is located in a privileged region, which allows for the evaluation of the network signals in both rural and urban areas. With the results, both the network and tracking devices in hand, we also present in this work the network expansion plan to cover the municipality.

The main contributions and results of our work can be summarized as follows:

• To the best of our knowledge, this work is the first to evaluate commercial and non-commercial tracking devices. The results indicate that the assembled and programmed devices present superior efficiency in the performed experiments.

• We found that a possible reason for the better efficiency of the non-commercial devices evaluated is due to the fact that they vary the SF at runtime while the vehicle moves. Similar works generally fix the SF to carry out their experiments.

• The results also demonstrate that there is no impact of the Doppler effect for the evaluated scenario when varying the speed. Previous work also fixed the SF when evaluating the Doppler effect for different speeds.

• We present the evaluation of the LoRaWAN network deployed at our university campus and the network expansion plan to cover the municipality. Evaluation results obtained in the field corroborated the simulation results obtained from the online service used to model the RF propagation signal.

The remainder of this paper is organized as follows: Section 2 summarizes the main LPWAN standards with emphasis on LoRa and LoRaWAN. Section 3 presents a review of the main related works. Section 4 describes the deployment of the LoRaWAN network, the assessed tracking devices, and the evaluation methodology in the context of this network. Section 5 presents and discusses the obtained results. Finally, Section 6 presents the conclusion and future work.

2 LPWAN networks

LPWAN is a class of wireless standard that has become a promising technology for supporting the growth of the Internet of Things paradigm, mainly because of its low power, long range, and low-cost communication characteristics [8, 23, 24]. Among the main LPWAN technologies are NB-IoT (Narrowband Internet of Things) [9], SigFox [10], and LoRaWAN [11], described next.

The working group 3GPP (3rd Generation Partnership Project) started to work on the specifications for NB-IoT in 2014 and completed the standardization in June 2016 [25]. The network can coexist with the current cellular phone carriers’ network infrastructure (e.g., LTE or GSM) under licensed frequency bands. NB-IoT occupies a frequency bandwidth of 200 KHz, which corresponds to one resource block in GSM and LTE transmission. The modulation employed is the quadrature phase-shift keying modulation (QPSK) and the data rate is limited to 200 kbps for the downlink and to 20 kbps for the uplink. The maximum payload size is 1600 bytes for each message. The range is estimated at 1 km for urban areas and 10 km for rural areas. One of the great advantages of the standard is that network infrastructure services are provided by carriers, enabling the rapid deployment of IoT systems. In Brazil, the TIM carrier implemented in June 2018 a pilot NB-IoT network in the city of Santa Rita do Sapucaí, state of Minas Gerais [26].

Sigfox is a French global network carrier, founded in 2010, that offers an end-to-end IoT connectivity solution based on its patented technologies. In that standard, the customer acquires a license to use the network. SigFox deploys its base stations equipped with cognitive software-defined radios. Base stations are connected to servers by the use of an IP-based network. The end devices are connected to the SigFox base stations using binary phase-shift keying (BPSK) modulation in an ultra-narrow band (100 Hz) sub-GHz ISM band carrier. The carrier allows a range from 3 km to 10 km in urban areas and from 30 km to 50 km in rural areas. It has a data rate of 100 bps carrying up to 12 bytes of uplink, limited to sending 140 messages per day and 8 bytes of downlink with 8 messages per day. WND Brasil is the Sigfox carrier for Brazil [27]. Currently, there is no SigFox network installed in Toledo, a city with a population close to 140,000 inhabitants, located in the western region of the state of Parana, Brazil.

NB-IoT and SigFox require an infrastructure provided by carriers through the payment of periodic subscriptions and licenses. On the other hand, LoRaWAN does not require any payment and allows anyone to install the infrastructure needed for its operation. Next, we detail LoRa and LoRaWAN technologies.

2.1 LoRa and LoRaWAN

LoRa is a physical layer technology for bidirectional wireless communication developed and patented by Semtech [28]. The technology modulates the signal in the sub-GHz frequency range using chirp spread spectrum (CSS), which allows it to cover long distances with low levels of interference. A LoRa message can be of two types: uplink or downlink. The message structure is similar in both cases, however, only the uplink message adds a verification code (CRC) to ensure the integrity of the payload (PHYPayload).

LoRa uses unlicensed ISM (Industrial, Scientific and Medical) bands, i.e., 868 MHz in Europe, 915 MHz in Australia and North America, and 433 MHz in Asia [8]. In Brazil, LoRa uses the 915 MHz band, ranging from 902 MHz to 907.5 MHz and from 915 MHz to 928 MHz. In 2018, the Brazil National Telecommunications Agency (ANATEL) published the act n^o 6 506, which approves the procedures to assess the conformity of radiocommunication equipment with restricted radiation, allowing the operation of LoRa devices in the national territory [29]. Although it is possible to use two transmission bands, the American and the Australian bands [11], the latter has been adopted in Brazil. The Australian standard has 72 channels for uplink and 8 for downlink. The uplink channels range from 0 to 63 and use a bandwidth of 125 kHz with a coding rate of 4/5, starting at 915.2 MHz with a linear increment from 200 kHz to 927.8 MHz. On the other hand, the channels from 64 to 71 have a bandwidth of 500 kHz, starting at 915.9 MHz, increasing linearly from 1.6 MHz to 927.1 MHz. The downlink channels range from 0 to 7 and have a bandwidth of 500 kHz, starting at 923.3 MHz with linear increment from 600 kHz to 927.5 MHz.

There are four configuration parameters for the LoRa physical layer that determine the power consumption, transmission range and noise resilience [30, 31], which are:

• Carrier Frequency (CF): this is the frequency used for the transmission band and it is defined according to the operation area of the equipment;

• Code Rate (CR): the CR is the degree of redundancy implemented by the forward error correction (FEC) used to detect errors and correct them. This rate is fixed at 4/5 for the LoRaWAN protocol;

• Spreading Factor (SF): it determines the number of chirps required to represent a symbol (one or more bits of data). LoRa defines six different values for the SF parameter (SF7-SF12). The larger the spreading factor, the farther the signal will be able to be received. In the same channel, packets using different spreading factors are orthogonal, i.e., they do not interfere with each other;

• Bandwidth: this is the range of frequencies used in the transmission band and can assume three determined values, 125 kHz, 250 kHz or 500 kHz, suffering a displacement of up to 20%, which will not influence the decoding.

The LoRa physical layer may be used with any MAC layer. However, LoRaWAN is the currently proposed MAC, which operates a network in a simple star or star-of-star topology. LoRaWAN is an open communication protocol for LoRa networks managed by the open and non-profit entity LoRa Alliance, which brings together more than 500 members around the world. An overview of the architecture of a LoRaWAN network is shown in Fig. 1. A gateway connects the devices on the LoRaWAN network to the Internet through the network server, which manages the communication of the devices with the application server. The end nodes are objects equipped with sensors and/or actuators. The application server provides the information from the devices to the end user [11].

Fig. 1

A general overview of the LoRaWAN architecture [11]

An important feature of the LoRa technology, called adaptive data rate (ADR), resides in the network server. ADR allows adapting and optimizing the data rate for the static end devices. For mobile end devices, data rate should be fixed, once the mobility can cause significant temporal variations for the radio channel characteristics [14].

The MAC layer of LoRaWAN defines pure ALOHA for medium access. In this layer, end devices can take one of three configurations. Class A is the mandatory configuration in all classes. In this class, the end device initiates communication with the gateway, making a transmission and opening two windows to receive data from the gateway. In class B, the process is similar to that of class A. The class B device also opens two reception windows after performing a transmission. However, in addition, class B devices open reception windows with scheduled times, configured through beacon messages sent by the gateway. In class C, the end device performs a data transmission, opens two reception windows and keeps one window open until the next transmission, making the final device require a constant source of energy.

In terms of security, LoRaWAN relies on the standardized AES cryptographic algorithm and offers two levels of cryptography. The first is located in the network layer to guarantee the authenticity of the end device. The second is located in the application layer in order to guarantee the confidentialily and integrity between the end device and the application server. There are two types of authentication: OTAA (Over The Air Activation) and ABP (Activation By Personalization). The first is more secure because it is the device itself that manages its activation.

3 Related Work

In this section we present some related work that implement geolocation and tracking applications based on the LoRaWAN technology.

In [32, 33], two practical works are proposed. James and Nair [32] proposed an alternative to conventional public transport tracking systems, normally based on GPS. The proposed model uses LoRa wireless transmission to communicate between bus stops and a base station. Communication between buses and the stops takes place via RF transmitters. Whenever a bus approaches a stop, the data is directly transmitted to the gateway, which in turn makes the bus geolocation available to users. Among the advantages of the adopted solution are the low cost of the installation, since it does not use GPS, and the low energy consumption. However, the solution requires predefined routes and a fixed point to collect vehicle data, in order to estimate its geolocation.

Hattarge, Kekre and Kothari [33] state that deploying traditional GPS trackers can significantly reduce the maintenance cost by using LoRaWAN instead of GSM/GPRS modules. They provide a GPS localizing system based on LoRaWAN technology combined with an Android application for a smart public transport system. A prototype was built and tested using Arduino Uno as a transmitter and NEO-6M as a GPS module. Works described in [34, 35] also propose tracking systems based on LoRa, GPS and Arduino to estimate the speed and geolocation of tourist boats in a protected park in Malaysia and tracking troops in Thailand, respectively.

Geolocation in LoRa with the absence of a GPS is studied in [36, 37]. Podevijn et al. [36] propose a solution where Time Difference of Arrival (TDoA) is processed at network level in a public LoRa network. The work provides experimental quantification of the TDoA geolocation performance. The authors also investigate and determine the best LoRa spreading factor to use with respect to updating frequency and positioning accuracy. According to the authors, the median accuracy of 200 m was obtained for the raw TDoA output data. Fargas and Martin [37] also propose a system where geolocation is calculated applying a multilateration algorithm on the gateways timestamps from received packages. Despite the fact that their solution was shown to be able to locate a static spot with an accuracy of around 100 meters, it did not present good results for real-time tracking application.

Experimental works, including mobility, are developed in [14, 18, 19]. Petäjäjärvi et al. carry out experimental validations of various performance metrics of LoRa through different configurations and scenarios in Finland [14, 38, 39]. Regarding mobility [14], LoRa’s performance in the presence of the Doppler effect is analyzed experimentally. Results show that for an SF=12 (which allows greater distances to be reached) and when the relative speed exceeds 40 km/h, the communication performance deteriorates. On the other hand, with the same SF and lower speeds, below 25 km/h, communication is still sufficiently reliable. The conclusion is that LoRa can be used in monitoring or tracking applications. The authors also state that smaller SFs should be less affected by the Doppler effect and thus more suitable for mobile scenarios.

The work of Liando et al. [19] perform measurements to evaluate LoRa, including the Doppler effect in mobile nodes. They employed a mobile LoRa gateway by the roadside and attached an end device to a car used as a moving transmitter. The speed of the car varied from 50 to 80 km/h. In the experiment, they fixed SF=12 and ensured LoS between the end device and the gateway during the experiment. In this scenario, they conclude that more than 85% of sent messages were received taking in account all speeds. Other studies about LoRa, including mobility, were conducted in Romania [20] and Singapure [19].

In Brazil, Ferreira et al. [18] study the propagation of LoRa signals in forest, urban, and suburban vehicular environments. One of the goals is to understand how LoRa could be used for alternative applications such as geolocation of hikers in a natural park. They build LoRa prototype nodes using Arduino Uno R3, LoRa transmitter and receiver, and GPS receiver. The authors do not employed LoRaWAN because the work focuses on propagation and device-to-device communication. The scenario with a mobile transmitter takes places in both suburban and rural zones where a mobile device is moving at a speed of approximately 90 km/h. As in [14], they also conclude that LoRa devices configured with an SF=12 and moving at a moderate speed (around 40 km/h) do not disrupt LoRa communications, while a device at a high speed (around 90 km/h), increases the probability of disrupting the link. Other works found in Brazil study the application of LoRaWAN for smart grids [40, 41] and deployment of LoRaWAN in rural areas [42].

Unlike [14, 18, 19], in our work the SF was not previously defined in the tracking devices. During the experiments we recorded the SF of each message sent from all tracking devices to the gateway. Results obtained from SFs are analyzed in Section 5.2.2 where we perform a quantitative analysis. Additionally, in Section 5.2.3 we conduct an experiment varying the speed of the devices. It’s important to note that, unlike [18], we focus on LoRaWAN and communication device-to-gateway. As far as we know this is the first study to evaluate and compare both commercial and assembled tracking devices in a LoRaWAN network.

4 Methodology

In this section, we present the methodological approach used in this work to deploy the LoRaWAN network and evaluate the tracking devices.

The smart cities project in Toledo/Brazil aims to develop applications in typical smart city domains such as environmental monitoring [43, 44], public transport [32], and fleet vehicle tracking [13]. As the first step, we deployed the LoRaWAN network at the UTFPR-Toledo campus. Then, a theoretical coverage model of the network signal was defined using a simulation tool and taking into account the deployment characteristics and hardware features. After that, an empirical evaluation of the theoretical network coverage model was conducted for a set of n predefined places. The results obtained were the input for defining the areas where the tracking devices were evaluated. Each device was evaluated through an analyses that envolved both quantitative and qualitative work. The results helped us understand the behavior of the LoRa signal within the previous defined area and the behaviou of each device inside the area. We detail each step next.

4.1 The LoRaWAN network deployment

Firstly, the gateway was installed on the fourth floor of one of the UTFPR buildings (denoted as “Building E” in the following figures), and a 6 dBi omnidirectional antenna was positioned about 20 meters high on the top of this building. The gateway is made up of a Raspberry Pi 2 and one LoRaWAN hub which uses a digital baseband chip Semtech SX1301. This gateway communicates with The Things Network (TTN) LoRaWAN network server [45] and with the TagoIO application server [46].

4.2 Network coverage estimation and evaluation

Once the network was installed, Google Earth was employed to make an evaluation scenario aiming to assess the network’s coverage considering the radio-frequency (RF) propagation using 915 MHz range. Associated with Google Earth, the CloudRF [22] online service was used to model the RF propagation signal into the interior area of interest. Table 1 lists the parameters and respective values used such as the LoRa frequency, gateway geolocation, and antenna specificities. The propagation model adopted was the Irregular Terrain Model (ITM), also known as the “Longley Rice” model, with 90 meters of terrain resolution within a 40 km radius.

Table 1 CloudRF configuration parameters

Figure 2 shows the simulation of propagation based on relief using CloudRF. CloudRF does not take into account obstacles such as buildings, trees and others. The heatmap (colored layer on the map) shows which areas have the dB coverage as indicated by the color schema on the left. For the sake of the readers’ understanding, the limiting circles and respective evaluating points were overlaid to the covered area predicted by the simulation model.

Fig. 2

Heatmap showing the signal coverage simulated using CloudRF

It’s worth mentioning that the location of the building where the LoRaWAN gateway was installed is strategic, as it allows assessing both the urban and rural areas. This particularity can be seen in Fig. 3. A maximum radius of three kilometers from the gateway was defined (the outer circle in red), covering an area of approximately 28.4 km ², elevation varying between 428 and 567 meters above sea level. A set of n predefined places called evaluation points P_i, where 0<i≤n, were scored every 600 meters from the gateway. The spatial distribution of the evaluation points can be seen in Fig. 3. Obstacles that could possibly hamper the communication were identified to be considered in the analysis.

Fig. 3

Evaluation area

An end device equipped with a LoRa transmitter Semtech SX1276 was used, aiming to empirically validate the theoretical model presented in Fig. 2.

Table 2 shows the parameters setup for the LoRa transmitter. This device was attached to an IoT-USB base module adding a USB interface that when connected to a laptop allowed sending messages to a LoRaWAN application. Basically, the message is a tuple containing the geographic coordinate of the place associated with the label of the evaluated place, e.g., “P1”, “P2”, etc. Upon receiving the message, the gateway calculates the signal strength and the signal-to-noise ratio of the received message. At each point in the test area, 5 messages were sent. The most distant evaluation points (P₃₉ – P₄₆) had 10 messages sent. Such distant points are located between 10 km and 30 km from the gateway, far from the most outer circle, and therefore, they are not shown in Fig. 3. The messages were stored on the TagoIO application server indicating the communication of the final device with the gateway and with the network and application servers.

Table 2 Radioenge LoRa transmitter parameters

4.3 Tracking devices evaluation

4.3.1 Tracking devices description

The four devices evaluated in this work are described in Table 3. Rak5205 and Rak7200 are commercially-available tracking devices. The former is commonly used to make rapid prototyping of LoRa-based IoT solutions and has several different sensors, e.g., temperature and humidity. The latter is commercialized as a general-purpose tracking device, and by being small it could be fixed in a person’s belt, for instance. Both allow to set configurable parameters, but are not programmable. On the other hand, the tracking device TTGO T-Beam is an end device made up of a PCB using a dual-core ESP32 chip and LoRa and GPS extra modules. As a microcontrolled device, it’s necessary to program the T-Beam modules to perform the desired functions. Arduino is an open platform for the prototyping of electronics. It is extensible using proper small PCBs (named as shields) and software libraries. In this work, both the GPS and LoRa shields were used. Similarly to the T-Beam, the Arduino was coded using open-source libraries. Considering the cost, the Rak5205 is the most expensive of the devices used, possibly due to their inclued additional sensors. Those unnecessary sensors were disabled for the experiments. Finally, the T-Beam is cheaper, but has more memory capacity and processing power when compared to the others.

Table 3 Details of the evaluated devices

We employed the LMIC library [21], modified by the MCCI Corporation to program the T-Beam’s LoRa module. This library implements a hardware abstraction working as a state machine and it is responsible for the communication between the LoRa physical layer and the other gateway devices. The NEO-6M module was programmed using the TinyGPS++ library [47] which performs the data flow control based on NMEA (National Marine Electronics Association) – a common communication standard used by many electronic tracking devices, including the GPS receivers. Arduino was codded using the TinyGPS++ library, SD library for the SD card and TimeLib for providing the time. The communication between the Arduino and the LoRaWAN transmitter ocurrs through a software serial port and AT commands (Hayes command set).

4.3.2 Tracking devices evaluation scenario

With the results of the network simulation and the empirical evaluation of Figs. 6 and 7 (detailed in Section 5.1) in hand, the next step was to evaluate the custom-programmed devices in relation to the commercial devices. We defined three different assessment regions named “Area 1”, “Area 2”, and “Area 3”. The red polygon shown in Fig. 4a corresponds to Area 1, covering about 0.34km². Area 2 extends Area 1 to about 0.77km² and it is limited by the magenta polygon highlighted in Fig. 4b. The red circle that could be seen in both Figures is Area 3 which covers about 9.6km². Despite presenting overlapped regions, each area was evaluated separately. The data were collected during three strides in distinct days using the four devices described in Table 3. All devices were put together to go through the paths and to transmit their coordinate in real time. That is, the devices faced the same environmental conditions during the experiments. The vehicle was driven at an average velocity of 20 km/h. Such velocity was chosen to simulate the velocity of the real vehicles following the established route for the recyclable garbage collector truck. The option for constant velocity – instead of simulating all the possible stops inherent to the collection process – is explained by the tendency of the movement to affect the signal quality due to the well known Doppler effect. Actually, the results obtained from the four tracking devices also contribute to evaluate the LoRa network coverage.

Fig. 4

Evaluation areas. The red circle limits Area 3

The devices were set up to send their geolocation data every 10 seconds creating a measuring point every 5.6 meters. Thus, it is also possible to evaluate the eventual interference of buildings on the transmission process, such as the university’s own buildings, as well as the residential and commercial buildings. Considering the different precision between the four tracking devices, there could exist discrepancies in the geolocations data for the same registered point.

The devices were evaluated considering the following criteria:

• (a) Signal quality: based on the Received Signal Strength Indication (RSSI), and the Signal-to-Noise Ratio (SNR), both measured for each geolocation point using the TTN Mapper tool. RSSI is a value measured in dBm indicating the received signal power in milliwatts. In a typical LoRa network, an RSSI of -30 dBm indicates a strong signal, while an RSSI of -120 dBm represents a weak signal, being -120 dBm the minimum RSSI. The closer the RSSI is to zero, the better the signal. SNR is defined as the ratio between the received power signal and the noise floor power level. The noise floor is the sum of interfering signals and different noises which potentially can corrupt the transmitted signal, causing retransmissions. An SNR >0 indicates that the received signal operates above the noise floor, and an SNR <0 denotes the received signal operating below the noise floor. Typical LoRa SNR values range from -20 dB to +10 dB. A received signal presenting an SNR value closer to +10 dB means the received signal is less corrupted.

• (b) Sending measurement capacity: also named PDR which is obtained comparing the expected sending point to the geolocation effectively received from the devices. Besides, we have also analyzed possible reasons that have interfered in the device communication, such as buildings or natural obstacles.

• (c) Cost-benefit: the balance between the equipment’s financial cost and the quality metrics achieved by the device were considered.

In order to evaluate a potential influence of the node velocity, after executing the experiments in Areas 1, 2, and 3, we selected the two best devices in this initial experiment to perform a new trial varying the vehicle’s speed. In this experiment we present the behavior of the two most efficient device with speeds ranging from 0 to 30 km/h, 0 to 50 km/h and 0 to 100 km/h in a 3.5 km stretch in Fig. 5. Our analysis was focused on PDR and SF values because we aim to investigate if packets were lost due to different velocities.

Fig. 5

Stretch of 3.5 km from the Maripa Avenue

5 Results and discussion

We present results of the evaluation of the LoRaWAN network installed on the UTFPR campus and the results of the evaluation of the devices are in Sections 5.1 and Sections 5.2, respectively.

5.1 LoRaWAN signal evaluation

Figures 6 and 7 present the minimum and maximum values of RSSI and SNR, respectively. Such metrics were obtained from the empirical tests at the points described in Fig. 3. Points P₁ to P₁₁ are located in the urban area, which has several buildings. Despite the way these points are distributed in relation to the distance from the UTFPR gateway, there are points that are farther but with higher RSSI. This is caused by variations in the altitude of the location of the points. For instance, points P₅ to P₇ are placed behind a terrain elevation, as shown in the black rectangle in Fig. 8. That is, those points present no LoS. Also, points P₉ – P₁₁ are placed in a lower area, which results in packets not being received by the gateway.

Fig. 6

Minimum and maximum RSSI values obtained at each test point

Fig. 7

Minimum and maximum SNR values obtained at each test point

Fig. 8

Topographic map of the city Toledo, Brazil

Similar behavior can be observed for points P₁₂ – P₂₀, despite the fact that those points are located in a region with fewer buildings when compared to the region of points P₁ to P₁₁. There is an elevation from points P₁₂ to P₁₅, but from P₁₆ to P₂₀ there is a constant decrease in altitude, obstructing the LoS and reducing both RSSI and SNR. Furthermore, there is an elevation in the path of the points, as depicted by the magenta rectangle in Fig. 8. That’s why the communication failed from points P₁₈ to P₂₀.

Once the points from P₂₁ to P₂₇ are located in a rural area, the propagation scenario is analogous to open field communications. The RSSI from the points presents low variations, and most of the points also present low SNR variation. Despite the decrise in altitude from P₂₁ to P₂₇, these points are not behind an elevated point, as occurs with points P₁ to P₁₁ and P₁₂ to P₂₀, resulting in better coverage and no outage of those points.

From points P₂₈ to P₃₃, there is a mix of rural and urban areas, indicated by different variations of RSSI and SNR. From points P₃₄ to P₃₆, the propagation is mainly in rural areas, resulting in a low SNR variation (except for P₃₅). Points P₃₇ and P₃₈ are able to overcome the obstacles presented encountered by points P₁₂ to P₂₀. For points P₃₉ to P₄₆, which are further away, the RSSI and SNR variations are lower (except the SNR variation for P₄₅), and despite the higher distance, they were able to communicate with the gateway. The results showed that the points located in an area with good network coverage had 100% of their messages received by the gateway. In contrast, the points located in an area without coverage, e.g., P₉ to P₁₁ and P₁₈ to P₂₀, did not even receive a message.

In essence, these results corroborate that the relief of the installation area and the environment are key factors of the LoRaWAN network deployment, as concluded in [14, 19]. It was possible to reach a distance greater than 30 km in the rural area, according to points P₃₉ to P₄₆, so that neighboring municipalities could be reached as well. In the urban area, the maximum range varied between 2 km and 2.5 km, according to points P₈ and P₁₇ to the east and north (Fig. 3), respectively. However, still in the urban area, point P₃₃ is more than 3 km away. Unlike other furthest points in the urban area, P₃₃ presents clear LoS, that is, like [19] we highlight the importance of a clear LoS between the aplication and the gateway. Although the simulation performed with CloudRF does not contain obstacles, the results of the practical assessment corroborated the simulation results regarding the signal coverage. More antennas, or antennas located at higher places, could improve the signal propagation and achieve a good coverage for the city area. This inherent requirement is taken into account for planning the future network expansion, discussed in Section 5.3.

5.2 Tracking devices evaluation

Initially, in this section we present a qualitative and quantitative analysis considering the vehicle at a constant speed. The quantitative analysis (5.2.1) presents the device capacity to send a coordinate (geolocation) while moving through the areas. For each device, the TTN Mapper tool was used to get the number of coordinates received by the gateway. Secondly, to assess the signal quality, the qualitative analysis (5.2.2) took into account the noise and the spreading factor (SF) present in the received coordinates. Finally, an experiment was conducted to evaluate the influence of different speeds of the vehicle. This experiment and the respective results are presented in 5.2.3.

5.2.1 Quantitative analysis

As stated in Section 4.3, an interval of 10 seconds for each device to send its geolocation is defined. However, both the T-Beam and the commercial RAK devices did not manage to operate with this interval. Arduino was the only one that actually managed to send a coordinate every 10 or 11 seconds. Such behavior of T-Beam can be explained because it is configured to use class A, so it is ready to transmit only after sending a packet to the gateway what opens two receive data windows of about 1 to 3 seconds. Therefore, the T-Beam interval for each data transmission is approximately 13 seconds. For RAKs devices, the first step is to search for the GPS signal and the second step is sending data to the network. As consequence, an interval greater than 10 seconds is always required to send each coordinate. In addition, RAKs takes about 120 seconds to search for the satellite in the first transmission followed by a latency of 2–10 seconds to obtain a coordinate from satellites. Thus, the total time both RAKs take to send a geographic coordinate, actually was 24 seconds, on average.

Tables 4 and 5 present the efficiency of each device in the three evaluated areas considering the amount of geographic coordinates received by the gateway, i.e., the PDR. The “SD card” entry refers to the data stored by Arduino in the external storage card. That device stores the coordinate into its memory card before sending it to the gateway. That makes it possible to know the number of unsent coordinates by Arduino.

Table 4 Behavior of the evaluated devices in Areas 1 and 2

Table 5 Area 3 segmented into three distinct routes

Table 4 shows the data obtained from Areas 1 and 2. The “coordinates” column shows the number of coordinates stored on the SD card and received by the gateway from the Arduino, T-Beam, RAK5205 and RAK7200 devices. For example, the SD card stored 250 coordinates for Area 1 and 503 coordinates for Area 2. However, the gateway only received 212 coordinates for Area 1 and 457 coordinates for Area 2 from Arduino. That is, 38 and 46 geographic coordinates for Areas 1 and 2, respectively, have not been successfully sent by the Arduino device. The “average time ” column presents the average time in seconds the gateway took to receive a geographic coordinate. For example, a coordinate was recorded every 12 seconds by the Arduino and every 33 seconds by the RAK7200 for Area 1, according to the TTN Mapper tool. As we describe previously, RAK7200 can only send a new coordinate every 24 seconds. For Area 2, Arduino successfully sent a coordinate every 11 seconds. RAK7200 sent a coordinate every 37 seconds, which means that many packets were lost.

The “expected coordinates” column considers the time expected to receive a geographic coordinate from each device, that is, 10 seconds for the Arduino, 13 seconds for the T-Beam and 24 seconds for the RAKs. From the time expected and the total time of the experiment, it is possible to calculate the number of coordinates that should actually be received by the gateway and stored on the SD card. Considering Area 1, for example, 254 coordinates should be stored on the Arduino’s memory card and 253 coordinates should have been received by the gateway from Arduino. For T-Beam, 195 coordinates should have actually been sent to the gateway. The RAK5205 and RAK7200 devices should have sent 105 and 106 coordinates, respectively.

The efficiency of each device is a ratio between the obtained coordinates and the expected coordinates. The SD card did not show an efficiency of 100% because a coordinate was stored between 10 and 11 seconds (and not 10, as expected). For Areas 1 and 2, the T-Beam presented the best efficiency, although it sent less cofordinates to the gateway when compared to Arduino. In this work, we defined efficiency as the device’s ability to successfully send as many of its expected coordinates as possible. For Area 1, Arduino achieved an efficiency close to that of RAK5205. RAK7200 had the worst efficiency, 71.73%. In Area 2, Arduino was more efficient than the RAKs. In turn, the RAK5205 and RAK7200 devices had an efficiency of 68.08% and 64.97%, respectively. For Area 1, the efficiency of the devices was above 70%, possibly because it is close to the gateway. As for Area 2, which contains a zone further away from the gateway, we observe particularly for the RAKs a lower efficiency compared to Area 1.

Table 5 presents data from Area 3. This area was segmented into three routes, called Route 1, 2 and 3, due to its large size. For Area 3, we present only the geographic coordinates received by the gateway and the efficiency of each device on each route, including data stored on the Arduino’s SD Card. Route 2 is the closest to the gateway. Route 1 is further north and Route 3 is further east in relation to the gateway. However both Routes 1 and 3 are far from the gateway. We noticed that the devices presented different efficiencies depending on the route. In general, T-Beam was the most efficient. Arduino oscillated between 25% efficiency for Routes 1 and 3, and 70% efficiency for Route 2. That is, the data show that the Arduino did better near the gateway. The RAKs had the worst efficiency for Area 3.

5.2.2 Qualitative analysis

Figures 9, 10, 11, 12 were obtained through the TTN Mapper tool from the geographical coordinates received by the gateway. As Area 1 is contained in Area 2, the results of Fig. 11 can be used together with those of Fig. 9 to analyze Area 1. The color of the points in Figs. 9.(a), 11 and 12.(a) refers to the received signal strength, including both RSSI and SNR. Based on quantitative results that demonstrated the lower efficiency of the RAKs, analysis of RSSI and SNR are performed only for the T-Beam and Arduino devices. In Figs. 13 and 14 the devices are evaluated considering the SF. Figures 15 and 16 present the CDF (Cumulative Distribution Function) for SNR and RSSI, respectively.

Fig. 9

Data from Area 1 collected using TTN Mapper

Fig. 10

Signal coverage simulation for Area 1, obtained using CloudRF

Fig. 11

Data from Areas 1 and 2 collected using TTN Mapper

Fig. 12

Data from Area 3 collected using TTN Mapper

Fig. 13

TTGO T-Beam Spreading factor (SF) analysis

Fig. 14

Arduino Spreading factor (SF) analysis

Fig. 15

Empirical probability distribution curve for SNR

Fig. 16

Empirical probability distribution curve for RSSI

Arduino and T-Beam successfully sent 212 and 186 coordinates for Area 1, respectively, as shown in Fig. 9a, details (L) and (R). However, Arduino was not able to send its coordinates when transversing the upper left corner of this area. This does not happen in Fig. 11 where Arduino was able to send its data from the same zone. This result may indicate that Arduino gets a weak network signal from that specific zone. Figure 10 presents the CloudRF simulation for Area 1. Note that blue shades are indicating a weaker signal, although this region is close to the gateway. Another explanation is that Arduino has an antenna with a slightly lower gain (2.15 dbi versus 2.5 dbi for T-Beam).

As the Arduino saves all the coordinates captured by the GPS on a memory card, it is possible to check which of them are not received by the gateway. The result is shown in Fig. 9b : black dots represent coordinates not received by the gateway, and the magenta dots represent the coordinates received by the gateway. The upper left corner zone has several geographic coordinates that have not been received. However, T-Beam was able to send coordinates from that zone - not necessarily the same amount of coordinates than Arduino, since the GPS sampling intervals are different for the two devices. That is, compared to Arduino, T-Beam sends data from that zone even with a weak network signal.

Figure 11 presents the qualitative analyzes for Area 2. Results from quantitative analysis show Arduino and T-Beam sent 457 and 347 coordinates, respectively, i.e., a satisfactory performance even in more distant areas. The south zone of Area 2 (at the bottom of the Figure) is far from the gateway, but it has few homes and buildings with a clear line of sight (LoS) in relation to the gateway. In turn, the upper right area has few buildings as well, being dominated by small residential buildings.

Area 3 is presented in Fig. 12. In this area we find the most interesting results. As show in Table 5, T-Beam has an efficiency of 68.31% and 69.04% against 25.07% and 25.90% of the Arduino for Route 1 and Route 3. However, Arduino’s efficiency for Route 2 was superior (70.40% against 67.37%). When we analyze Fig. 12, both devices present quite similar behavior in some particular small zones (the central and southern zones in relation to the gateway). However, T-Beam is far superior. With the help of Fig. 12, we highlighted that there is a large amount of coordinates sent from Arduino, but not received by the gateway. The analysis of topographic maps showed that some of these zones are located after an elevation of relief, in addition to being more inhabited and densely built. However, the comparison between the devices shows that T-Beam was able to send its data, even though RAKs devices proved to be quite limited in these regions. Note when comparing Fig. 12 with the data collected from Arduino in Fig. 12 that there is a zone in the upper left area, which was not covered by T-Beam either.

One explanation for the failure of devices to send coordinates from some zones is due to the current elevation of the gateway, installed on top of a four-floor UTFPR building. To mitigate this limitation, the University and the City Hall are considering installing the new gateways in higher places as presented in Section 5.3. The feasibility study for such sites is going to be conducted in the future.

In order to understand why T-Beam had an advantage over Arduino, we analyze the packets received by the gateway. One of the parameters recorded by the TTN Mapper is the Spreading Factor (SF) used by each device to send its coordinates, together with the chosen bandwidth. Smaller bandwidths combined with higher SFs are useful in order to achieve a more reliable data transmission despite the penalty of reducing the data rate. Figures 13 and 14 show the SF chosen by the T-Beam and Arduino devices to send their coordinates to the gateway in Area 3. The geographic coordinates were plotted according to their latitude and longitude. Arduino (Fig. 14) mostly adopted SF 7, which is one of the shortest factors, while the T-Beam (Fig. 13) adopted SF values ranging from 7 to 12. In areas with few coordinates received from Arduino, mainly in the upper right zone, T-Beam adopted SF values between 10 and 12, which helped it to have more received coordinates. The RAK5205 device behaved similarly to the Arduino, operating with factors between 7 and 9, while the RAK7200 used SFs between 7 and 12, but most of them used SFs between 7 and 10.

What explains a possible advantage of the T-Beam device is the use of the LMIC library. LMIC provides internal SF adjustment mechanisms even with Adaptive Data Rate (ADR) deactivated. We follow the LMIC documentation that recommends not using ADR on mobile nodes [21]. Thus, the presence of an adjustment mode without ADR has made the T-Beam better adapted to different environments and covering an area greater than that covered by Arduino and RAK devices.

Although studies, such as [14, 18, 19], have carried out evaluations with mobile nodes in the LoRaWAN network, all of them have fixed the SF=12. Our result indicates that the best coverage of the T-Beam is due to the SF variation and not only due to its superior hardware. Regarding the hardware, what could give the T-Beam an advantage over the others is its antenna and the SX1276 transmitter. SX1276 offers slightly better receiving sensitivity than SX1272 [48]. However, RAKs also have an SX1276 transmitter.

Finally, Figs. 15 and 16 show the empirical probability distributions (CDF) for SNR and RSSI, respectively. Note that the T-Beam SNR curve presents lower SNR values, since it was able to collect more distant points. The same occurs with the RSSI curve. The SNR can vary in points of the same RSSI, which justifies by observing the two curves. It is also noticed that the curve of the RAK7200 has more points in low SNR (remembering that each one collected a number of different points). One of the causes that can contribute to this behavior is the use of an internal LoRa antenna, while the others devices use external antennas. In terms of RSSI, the devices are quite balanced, with T-Beam receiving more points with less RSSI, and Arduino receiving more points with greater RSSI (in proportion to the respective points).

5.2.3 Tracking devices at different speeds

The objective of this experiment is to know the efficiency of the devices at different speeds and to verify if there is a significant difference between them when varying the speed. RAK devices were not considered due to their lower efficiency when compared to Arduino and T-Beam. Table 6 presents the behavior of the Arduino and T-Beam end devices with speeds ranging from 0 to 30 km/h, 0 to 50 km/h and 0 to 100 km/h in a 3.5 km stretch from Maripá Avenue, shown in Fig. 17.

Fig. 17

Stretch of 3.5 km from the Maripa Avenue

Table 6 Behavior of T-Beam and Arduino devices at different speeds

It is worthy to mention that this avenue passes next to the UTFPR University where the LoRaWAN gateway is located. The stretch where the experiment was carried out was chosen because it is in both rural and urban areas, containing buildings along the route, LoS and NLoS (Non-Line of Sight). Since the avenue has intense urban vehicle traffic, it was not possible to maintain a constant speed during the experiment, so we say the speed varied from 0 to 30 km/h, for example. During the experiments, we keep the maximum speed whenever possible. Different from the experiments from Section 5.2.2, the data was stored locally both on the Arduino memory card and on the internal memory of the T-Beam (local memory column in Table 6). For each speed, three complete laps were performed. According to the data, the Arduino stored more data locally as it records and sends its coordinates every 10 seconds. T-Beam records and sends its coordinates approximately 13 seconds as stated in Section 4.3. The T-Beam has shown superior efficiency to the Arduino at all speeds: 65.35% against 42.47% with the speed varying from 0 to 30 km/h, 60.58% against 56.59% for the speed from 0 to 50 km/h and 69.23% against 45.75% for the speed of 0 to 100 km/h. The experiment also demonstrated that the speed variation did not impact the efficiency of the devices.

We noticed during the experiments that the devices presented similar behavior for speeds 0–50 km/h and 0–100 km/h. A possible reason for this result is that there is an area without the network coverage on this avenue of about 1.5 km, as shown in Fig. 17. As the vehicle speeds up, fewer coordinates are recorded, which can cause the vehicle with higher speeds to lose fewer packets in the area without coverage. It is also important to note that in the urban area it was not possible to maintain the maximum speed at 100 km/h for reasons of safety and traffic laws.

Therefore, for the evaluated speeds we do not realize the impact of the Doppler effect. The speeds considered in the experiment are compatible with the application tracking application of recycling garbage trucks since the trucks should not exceed 100 km/h. It is important to highlight that unlike the works in [14, 18, 19], the SF was not fixed during the experiment. The device itself chose an SF at runtime. The Arduino varied the SF between 7 and 12 during the experiments. The T-Beam used SF=10 for the 0-100 km/h experiment and SF=8 for the 0-30 km/h and 0-50 km/h experiments.

5.3 Future network expansion

Figure 18 presents the network expansion plan to cover the entire urban area totaling six LoRaWAN gateways. For the best radio signal performance, studies are being conducted to select public municipality buildings that offer minimal infrastructure and which located in elevated terrain, thus avoiding obstacles in the Fresnel zone [49]. Finally, considering the experimental results of this work, it is expected that each gateway covers a minimum radius of 2.5 km. Thus, the densest urban central-region will be covered by the interception of at least 4 antennas.

Fig. 18

LoRaWAN expansion plan

In the context of the vehicle tracking application, the next step is to evaluate the T-Beam and Arduino devices on the recycling garbage trucks. Both devices will be installed on the truck to store their routes in local memory, since the network is not yet available in the entire urban area. As the truck faces many stops and has regular speed, coordinates will be recorded every 30 seconds. We studied placing an accelerometer on each device to estimate the speed and thus record each coordinate according to the vehicle’s speed. The devices will be automatically activated as soon as the vehicle is started, being connected directly from the truck battery. The simple fact of knowing the truck route will help the city to make improvements in the route.

After assessing the capacity of devices to locally store their coordinates during the journey, the next step will be to assess communication with the network when the expansion plan is completed. The network will maintain the star topology and use The Things Network (TTN) network servers while undergoing evaluation. During the experiments, we found that a disadvantage of the T-Beam is that it does not have a built-in memory card, as its local memory is small and does not allow storing too many coordinates. To include a memory card in the T-Beam it is necessary an additional circuit, which will increase its cost. In this sense, the advantage of the Arduino is that the memory card is easily installed.

6 Final considerations

This work presented the deployment of a LoRaWAN network, along with an analysis of four tracking devices, two of-the-shelf commercial devices, and two assembled and programmed devices, that communicate using a LoRaWAN network to send their geolocations at constant and varying velocities.

The evaluation of the LoRaWAN network deployed on our campus, showed us that although the simulation carried out with CloudRF does not contain obstacles, the results of the practical assessment corroborate the results of the simulation regarding signal coverage. In order to evaluate the four devices we performed two experiments. The first experiment evaluated the four devices moving at a constant speed in three areas which together totaling 10.71 km². This experiment showed that Arduino and T-Beam devices are more efficient than the commercial devices. The second experiment aimed to evaluate the Arduino and T-Beam devices when they move at variable speeds. The experiment presented that the speed variation does not interfere with the devices’ ability to send their coordinates to the gateway. In addition, we found that there is no significant difference between them when the speed varies. In both experiments, the T-Beam showed the best efficiency, being the device with the best cost benefit.

This two-fold analysis was helpful for the following: (a) to understand the behavior of each tracking device under the LoRaWAN network, (b) to evaluate how the intrinsic network characteristics can influence the mobile data acquisition, and (c) to subsidize the development of a truck tracking solution for selective waste collection in the Municipality of Toledo. The qualitative analysis indicated that the T-Beam was able to vary the spreading factor while moving and it may have contributed to a better performance of this device.

Different from [14, 18, 19], we do not set a fixed spread factor. Thus, the T-Beam programmed using the LMIC library presented the best cost-benefit between the assessed devices. Based on the study conducted in this work, we agree with [14], which describes the LoRaWAN technology as a viable option that can be used to subsidize applications like monitoring and tracking. In our experiments, the relative speed was 20 km/h at constant speed. When we carried out the experiment varying the velocity, we do not confirm the the statements in [14, 18] that when the relative speed exceeds 40 km/h the performance of the communication deteriorates. One of the possible reasons is that the speed did not remain at maximum during the whole stretch. However, for the application of tracking recycling garbage trucks, monitoring using the LoRaWAN network is promising since the truck varies its speed and must not exceed the maximum speed of 100 km/h.

The results have mainly highlighted that the LoRaWAN technology can achieve a good long-range covering and this signal coverage could be extended avoiding obstacles. Furthermore, more broad coverage was obtained by programmable devices. In this aspect, the commercial solutions were limited, possibly due to their respective firmware. As future work, the following possibilities are underlined: a) evaluate the energy consumption of the devices considering different configuration scenarios; b) determine an ideal spreading factor that may optimize the reduction in energy consumption, by maximizing the signal strength and coverage area; c) implement a strategy allowing devices to send their geolocation just when a good network signal is detected, and d) plan a structure of gateways to satisfactorily cover the entire municipality of Toledo.