LoRaWAN Coverage Analysis in the Transportation Sector: A Real-World Approach ^†

Abstract

In this paper, the LoRaWAN network coverage provided by many gateways across Germany is evaluated mainly concerning the transportation sector (German rail routes). For this purpose, related works are first analyzed. Based on this, the objective of the measurement is concretized, and a microcontroller measurement module is prototypically developed and built. Along a previously defined route, the measurement module continuously attempts to send GNSS data via LoRaWAN. The received data will be stored and evaluated, including metadata such as RSSI. The evaluation is not only concerned with network coverage, but also with some considerations of possible use cases in the transportation sector.

1. Introduction

The Internet of Things (IoT) offers many possibilities for digitalization in companies, among other things through sensors or wireless networks [1]. For example, GNSS data, acceleration, or speed can be recorded and evaluated [2] (p. 47). One option for sending this data is the long-range wide-area network (LoRaWAN) [3] (p. 9).

LoRaWAN was defined by the LoRa Alliance and includes a network architecture and other higher layers that build on the physical long-range (LoRa) layer [4] (p. 1). It operates on sub-gigahertz frequency bands, which are not licensed [5] (p. 16). It features a spread spectrum modulation scheme derived from chirp spread spectrum modulation [5] (p. 16). In this work, the LoRaWAN network coverage of two networks will be evaluated: The Things Network/-Industries (TTN/TTI) and The People’s Network (TPN).

The coverage of these networks is already illustrated on different websites [6,7]. However, it is not clear how these data were collected or whether they are still up to date. Therefore, to investigate what coverage is given, an own measurement is made.

2. Related Work

Petajajarvi et al. conducted a network coverage measurement in the summer of 2015 [8]. The goal of the measurement was to record the range of LoRaWAN endnotes using a single gateway [8]. Therefore, the measurements were all performed in one city [8]. Additionally, the measurements took place with the highest possible spreading factor and effective radiated power [8]. The measurements found that the packet loss at 10–15 km was more than twice as high (74%) as at 5–10 km when measurements were made by car [8]. In contrast, when measurements were made by the ship, the loss rate increased only slightly from 31% (5–15 km distance) to 38% (15–30 km distance) [8]. Among the reasons given for the packet loss were line-of-sight blockages [8].

In another scenario, Terleev et al. evaluated the network coverage of a single gateway with a similar technique [9]. Based on the results, they calculated that a LoRaWAN coverage of Sankt Petersburg needs around 400 and complete coverage of the region of Leningrad needs around 84,000 gateways [9].

A different approach was evaluated by Del Campo et al. [10]. Although they also examined the network coverage by a single LoRaWAN gateway, they measured with different spreading factors [10]. This showed that the spreading factor is one of the most important factors influencing the drop rate of packages, especially if the range is greater than 1.5 km [10]. In that case, the drop rate raises from 1.2% (SF12) to about 42.3% (SF7) in a range of up to two kilometers [10]. Other influencing factors include vegetation where the drop rate increased by 18% [10]. However, the most important influence factor was the line-of-sight, which resulted in a 100% dropout rate when interrupted [10].

Vejlgaard et al. evaluated the network coverage of different LPWANs through existing base stations of a cellular provider on an area of 8000 square kilometers [11]. In a simulation, they measured coverage of 99% outdoors and minimal coverage of 76% indoors at a maximum attenuation of 30 dB [11].

Last, as mentioned in the introduction, websites that illustrate coverage, such as https://ttnmapper.org (accessed on 22 August 2022) [6] (TTN) or https://coveragemap.net (accessed on 22 August 2022) [7] (TPN) could be an entry point for network coverage analysis.

In summary, these works evaluated the network coverage of a single gateway [8,9,10], in some measurements with the highest spreading factor [8] which may result in larger transmission times [12] (p. 2). Furthermore, the introduced websites provide a map of network coverage [6,7], but it is not known how this data was collected. The line-of-sight was the deciding factor here when it comes to a high packet dropout rate [8,10]. Other factors such as vegetation or buildings and, above a certain range, the end node configuration, are also very influential [10]. In contrast, here the approach of a wide-area measurement is pursued, which includes urban and rural regions and uses many gateways.

3. Materials and Methods

The basic aim of the following analysis is to determine at which point of a German railroad line LoRaWAN can be received. To achieve a real-world approach, instead of using a dedicated LoRaWAN field tester, a microcontroller measurement module is prototypically designed and built. This is meant to recreate a prototyping scenario. Additionally, the price point has had an impact on this decision since the self-build module costs only half of a field tester.

3.1. Measurement Methods

To achieve such a coverage measurement, three main points are considered: the parts of the measurement module, the way this module measures coverage, and the route that should be measured.

The module itself should include various sensors: a global navigation satellite system (GNSS) sensor so that the current position is detected, a LoRaWAN sender and receiver module, and an accelerometer to capture possible crashes of the module. Furthermore, an SD card slot is mandatory, so that any data can also be stored locally. A display is used for better visualization throughout the measurement itself.

To measure coverage, the module shall continuously attempt to send GNSS data via LoRaWAN at short intervals during the measurement itself to a software backend stack that stores the sent data. The measurement route itself is chosen to cover a major part of the German Intercity Express (ICE) train network [13]. In this way, it can be ensured that the requirements of long-distance transportation are also considered.

3.2. Microcontroller-Measurement Modules

Regarding the solution to be designed, the first decision was that of the framework used. Due to previous knowledge, the Arduino framework was chosen. However, there were other criteria that influenced the parts selection (e.g., number of in- and outputs, applicability with LoRaWAN module, price). Based on these criteria, two microcontrollers were shortlisted and compared: the Seeeduino XIAO incl. expansion board [14,15] and the Arduino MKR WAN 1310 [16]. Since the assembly is easier due to the Grove system with the Seeeduino XIAO at the same price point, the XIAO Microcontroller was chosen. In addition, an SD card slot is already integrated in the expansion board [15].

In the course of the work, two modules (module A and B, see Figure 1a,b) were developed for the measurements, with module B representing an improvement of module A. These were made because a need for optimization was identified during initial test measurements with module A, since, for example, a GNSS reallocation failed. In module A, only components from the Grove system were used, whereas in module B, other components also had to be used. Thus, the GNSS sensor and the LoRaWAN module were replaced. The final sensor components used are a ublox SAM-M8Q GNSS sensor, a Grove LIS3DHTR accelerometer, and the Seeedstudio Wio-E5 development kit, which uses a STM32WLE5JC LoRaWAN chip. An external LCD was also used. The final module was verified with an Adeunis field tester for LoRaWAN transmission.

3.3. Coverage Measurement Methods

As described above, the measuring module should send data continuously at a certain interval. The interval here is based on the maximum permissible duty cycle of 1% specified by the European Commission [17] (p. L 212/64). In addition to the GNSS data (latitude, longitude, and speed) sent by the microcontroller via LoRaWAN, the received-signal-strength-indicator (RSSI) and the signal-to-noise ratio (SNR) from the receiving gateway should also be recorded.

As a spreading factor during the measurements, the factor 10 was chosen, because this represents a compromise between range and airtime of the data, as Del Campo et al. shows [10]. The data to be sent results in a length of 13 bytes in hexadecimal format. Spreading factor, payload length, and the used bandwidth of 125 kHz combined result in an approximate time on air of 411 ms. Therefore, to comply with the 1% duty cycle limit [17] (p. L 212/64), a transmission interval of 1 min was selected. The measurement module itself stores, in addition to that, the acceleration data on the SD card as well. The firmware, representing these settings, was verified after each startup of the setup.

As mentioned above, the measurement itself takes place in two different LoRaWAN networks: TTN/TTI and TPN. In some cases, however, different route sections are measured for each network. The measurements were carried out from coach transition areas in the trains (e.g., ICE or regional trains).

4. Results

In order to evaluate the collected data, data validation was first carried out to filter out erroneous data as best as possible. During the measurements, two main reasons for invalid data showed up. On the one hand, the GNSS signal was lost sometimes, especially in route sections with tunnels; on the other hand, the firmware verification resulted in invalid data, since this is not part of the measurement.

Each measuring point was therefore considered individually and evaluated according to two criteria. Firstly, the measurement point had to have a latitude greater than the value zero; furthermore, the measurement value was only validated if two consecutive measurement values did not show the same value, since this behavior was a strong indication of loss of the GNSS signal.

As a result, 504 valid points were measured in TTN/TTI and 154 valid points in TPN. The coverage of TTN/TTI can be seen in Figure 2a. Figure 2b shows the coverage of TPN. The different colors of the measuring points represent the reception field strength, where red represents very good and dark blue very poor reception. An exact classification of the colors can be seen on the scale. The classification of the TTN-mapper [6] served as a template here. The blue line approximately symbolizes the traveled route. Another evaluation shows the number of existing measuring points according to minimum speed. It can be found in

Table 1. LoRaWAN measurement points by minimum speed (km/h).

Min. Speed (km/h)	Measuring pt. TTN	% From 504	Measuring pt. TPN	% From 154
0	504	100.00%	154	100.00%
1	201	39.88%	115	74.68%
10	55	10.91%	68	44.16%
100	14	2.78%	43	27.92%
120	9	1.79%	30	19.48%
150	8	1.59%	10	6.49%
160	6	1.19%	8	5.19%
200	1	0.2%	3	1.95%

.

5. Discussion

A striking feature of the results is that network coverage in both networks is found almost exclusively in urban areas. Only in some regions did TPN perform slightly better than TTN/TTI. This is the case, for example, in the Nuremberg/Bamberg region and in Halle. There was a larger coverage in the TTN/TTI mainly in the Cologne–Düsseldorf–Essen area. Coverage with several measuring points along a railroad line has only been measured on the line between Cologne and Hagen. In TPN, greater coverage was found upstream and downstream of urban regions.

As shown in Table 1, there is a significantly stronger drop at low speeds in the TTN/TTI network. However, this could be related to more transfers and waiting times at platforms due to the longer test duration. Likewise, the larger drop between one and ten km/h minimum speed could be explained in this way, since more distances were covered on foot. Despite all this, the absolute measured values also show better coverage in the TPN at higher speeds, despite the shorter measurement duration.

The better coverage in the TPN may also be related to the number of active gateways. According to TTN, 2896 gateways are active for the network in Germany [18]. According to Helium, 2761 gateways are active for TPN in Berlin alone [19], and over 54,000 in Germany [20]. According to Terleev et al. as well, many gateways are needed for continuous coverage [9]. For the entire series of measurements, however, it must be noted that the measurements were taken from a moving train, which according to Vejlgaard et al. corresponds to a signal attenuation of 10 to 20 dBm [11].

As a result of the measurements, the following statements can be made:

• Live monitoring for long-distance transport is not possible with the current network coverage;
• Live monitoring should only be used in urban regions with stationary devices;
• The results also suggest that use cases in rural regions in general will most likely have to be served with their own infrastructure;
• Campus (delineated, regional area) supply would be a good option here;
• For transportation, one approach would be to limit the transmission range of sensors by geofencing them so that they transmit only in covered regions;
• A combination of geofencing and campus coverage could be a cost-effective way to deploy sensors with LoRaWAN.

5.1. Limitations

Problems with the measurement module occurred both during the test runs for the TTN/TTI network and for the TPN. The main problems in the TTN/TTI network were mainly related to transmitted data, which was not received despite coverage. First, the firmware was slightly adjusted so that response messages were no longer requested. However, in most cases this problem could only be solved by reinstalling the firmware. After this step, the measuring module functioned correctly for the most part. Nevertheless, response messages were sent by the network server. This could possibly be related to an incorrect configuration of the network parameters, which were specified when setting up the device in the TTN/TTI network, since different specifications were found for this. These problems did not occur with the same LoRaWAN module in TPN. However, no network parameters can be configured there either. In this series of measurements, however, a total failure of the measurements was found on the route between Frankfurt and Nuremberg. The device worked perfectly again on the subsequent trip from Nuremberg to Berlin.

Finally, incorrect data may still be present despite validation of the data. This can be the case, among other things, if the GNSS signal was lost and later exactly one measured value was recorded with the now incorrect GNSS data point, since a reallocation could take longer, especially on route sections with many tunnels. For the future, a direct invalidation of the data points on the measuring device itself is recommended here. In addition, spreading factor 10 was used throughout the transmission. However, this can lead to a higher packet loss rate, especially in regions with poor coverage, as Del Campo et al. [10] shows. Otherwise, the measurement density would have had to be restricted due to the limited transmission time [17] (p. L 212/64).

5.2. Conclusions

In summary, this paper records the network coverage of LoRaWAN along some railroad lines in Germany in two different networks using a prototypically developed measurement module. It also lists any problems in the design and use of such a measurement module. For specific projects, the work can therefore be mainly seen as an entry point. Further evaluation of the use cases beyond this work in other projects is therefore recommended. Furthermore, differences between the LoRaWAN networks are discussed. First evaluations already show some differences. A more in-depth evaluation based on the data collected could further illustrate this and is therefore planned.