Indoor Vehicles Geolocalization Using LoRaWAN

One of the main drawbacks of Global Navigation Satellite Sytems (GNSS) is that they do not work indoors. When inside, there is often no direct line from the satellite signals to the device and the ultra high frequency (UHF) used is blocked by thick, solid materials such as brick, metal, stone or wood. In this paper, we describe a solution based on the Long Range Wide Area Network (LoRaWAN) technology to geolocalise vehicles indoors. Through estimation of the behaviour of a LoRaWAN channel and using trilateration, the localisation of a vehicle can be obtained within a 20–30 m range. Indoor geolocation for Intelligent Transporation Systems (ITS) can be used to locate vehicles of any type in underground parkings, keep a platoon of trucks in formation or create geo-fences, that is, sending an alert if an object moves outside a defined area, like a bicycle being stolen. Routing of heavy vehicles within an industrial setting is another possibility.


Introduction
Long Range Wide Area Network (LoRaWAN) is being increasingly seen [1,2] as a complementary technology to 5G. It enables Internet-of-Things (IoT) applications for smart cities and in particular for Intelligent Transportation Systems (ITS), enabling applications for machine-to-machine (M2M), applications that typically do not need the extreme bandwidth or the ultra-low latency of 5G networks. Moreover, we must consider that LoRaWAN is available now and ready to be deployed with various available low-cost hardware and software support. This could be a transition solution allowing enterprises to develop their LoRaWAN-based solution and expand with 5G coverage when it becomes widely available.
Focusing on the application of LoRaWAN to the vehicular world there is already a large number of proposals available. For example, Li et al. [3] analyses the performance of this technology when used for Vehicle-to-Infrastructure (V2I) and Vehicle-to-Vehicle (V2V) communication. In [4], the authors propose a novel framework for architectural and communication design to effectively integrate vehicular networking clouds with IoT. The objective is to make real applications that would provide IoT services through vehicular clouds. In this article, the author specifically considers smart city applications that would be deployed, operated, and controlled through LoRaWAN-based vehicular networks. Better integration of LoRaWAN to form an all-IP based network is treated in [5], which presents a solution in the area of vehicular IoT, which allows the IPv6 end-to-end connectivity between a moving and an Internet node, by means of an adaptation mechanism performed in a Multi-Access Edge Computing (MEC) node attached to the Low Power-Wide Area Network (LP-WAN) gateway.
The growing application of LoRaWAN to the vehicular field is anyway clearly being defined and it has to do with the "monitoring" of vehicles. With the term monitoring we refer to solutions aimed at tracking or geolocating vehicles that generally allow supervision of certain parameters of the vehicles. For example, in [6], the authors detail a vehicular monitoring platform enabled by LoRaWAN that offers vehicle data retrieval by using an On-Board Diagnostics II (OBD-II) interface. Their compression with a novel IETF (Internet Engineering Task Force) compression scheme, and information visualisation through a data server hosted in the cloud.
Geolocation or geolocalization is the identification (or estimation) of the geographic position of an object, like a device, a vehicle or a person. In its basic implementation, geolocation involves the generation of a set of geographic coordinates and is closely related to the use of positioning systems. To this end Global Navigation Satellite System (GNSS) receivers, using the GPS (https://www.gps.gov/), GLONASS (https: //www.glonass-iac.ru/en/), Galileo (https://www.usegalileo.eu/) or BeiDou (http://en.beidou.gov.cn/) system, are used in many applications. GNSS systems provide high accuracy of a few meters or less but require more complex, energetically demanding and costly devices.
One of the main drawbacks of GNSS systems is that they cannot work indoors. When inside, there is often no direct line from the satellite signals to the device and the ultra high frequency (UHF) used are blocked by thick, solid materials such as brick, metal, stone or wood. A GNSS works better when the device has a clear line of sight to the sky, the more satellites that a device can access, the more accurate it is. Indoor Positioning System (IPS) technologies are being developed (e.g., Want et al. [7]) to offer pinpoint location accuracy even while users are inside. These technologies utilise different types of signals to triangulate the position of the user while indoors. Wi-Fi hot spots, Bluetooth signals and cellphone signals have all been experimented with by the various companies developing this technology.
A LoRaWAN based geolocation service can be useful for less precise localisation such as for area-based location but with the advantage of requiring fewer and cheaper devices offering long-lasting batteries. Solutions based on LoRaWAN are adequate for use cases where precise location is not needed but accessibility (hence battery life) and cost are critical. LoRaWAN networks can locate devices without GPS, using fewer radio communications signals.
Many vehicular applications can benefit from indoor geolocation. Geolocation can be used to locate vehicles of any type in underground car parks, keep a platoon of trucks in formation and track them as they move, or create geo-fences, for example, sending an alert if an object moves outside a defined area, like a bicycle being stolen. The routing of heavy vehicles within an industrial setting is another option.
In this paper, we describe our solution based on simple client devices and on the deployment of various LoRaWAN gateways. Through the estimation of the behavior of a LoRaWAN channel and using trilateration, the localisation of a vehicle can be obtained within a 20-30 m range. The main advantage of our solution is its low cost, its simplicity and clearly the possibility to operate indoors.
The paper is organised as follows: Section 2 details some related solutions available in the literature; Section 3 describes LoRaWAN and its basic characteristics; Section 4 describes the architecture proposed; Section 5 presents some preliminary results; and finally, Section 6 summarises the results obtained and outlines future work.

Related Works
A detailed overview of different indoor localisation techniques, such as Angle of Arrival (AoA), Time of Flight (ToF), Return Time of Flight (RTOF) and Received Signal Strength (RSS), is offered in [8]. Proposals based on technologies such as WiFi, Radio Frequency Identification Device (RFID), Ultra Wideband (UWB), Bluetooth and systems that have been proposed in the literature are described. The authors of [9] study the performance and prospect of LoRa in indoor localisation. The authors observed that LoRa is more stable than WiFi and Bluetooth Low Energy (BLE) and is more resilient to environmental change.
In [10], the authors present an IoT tracking system using LoRa technology designed and implemented in order to obtain some accurate results. The two algorithms that are described show that it is feasible to locate a device in a static spot with an accuracy of around 100 m. In his thesis [11], Rasmus Henriksson investigates whether the received signal strength from LoRaWAN networks can be used to determine the position of a connected end-device. The study is done by simulating a large scale network with real-world measurements to study how the number of anchor nodes impacts the positioning accuracy. Results show that the measurements vary too much to give a precise position estimation.
Sadowski and Spachos focus in [12] on comparing WiFi, BLE, Zigbee, and LoRaWAN for use in an indoor localisation system. By using three transmitting nodes broadcasting information, along with a single receiver, trilateration could be performed to determine an approximate receiver location. The most interesting results of this work are those for transmission range-LoRaWAN had the furthest transmission range when running at its maximum transmission power.
Bakkali et al. [13] address the problem of estimating the location of LoRaWAN devices from the time of arrival differences measured at gateways. An Extended Kalman Filter (EKF) based approach is considered to aggregate the measurements obtained at different time instants. Particular attention is paid to the processing of outliers. Based on experimental data obtained from field measurements conducted on a real LoRaWAN TM network and an insight into the realistic localisation accuracy of the considered localisation approach is provided. Podevijn et al. [14] analyse the performance of LoRa geolocation, although for outdoor tracking purposes. Time Difference of Arrival (TDOA) localisation accuracy, probability and update frequency were evaluated for different trajectories (walking, cycling, driving) and LoRa spreading factors. A median accuracy of 200 m was obtained and in 90% of the cases the error was less than 480 m.
Podevijn et al. [15] develop and benchmark four RSS localisation algorithms where different a priori knowledge is required. The selection of the best algorithm depends on the availability of additional information on the path loss exponent and/or transmit power. The authors perform experiments and simulations with Bluetooth Low Energy and LoRaWAN technologies and select BLE as the best technology for localisation in large open industrial environments.
In [16], the authors present an RSSI-based localisation solution that relies only on the LoRa technology. This paper mainly focuses on the design for large used car dealerships. Cars to be tracked are fitted with battery-powered tags that send each other plain LoRa messages and then report over LoRaWAN the observed RSSI to the server. The server estimates tag coordinates using multi-dimensional scaling and a novel corrective transformation based on tag clustering.
In conclusion, using TDoA for geolocalization is problematic since not all devices nor all gateways can provide a proper estimation of these values. Still, the use of the RSSI is considered a unique solution. In this sense, existing works fail to present results on the stability of the RSSI values over time and on the impact of the spreading factor on the quality of the obtained values. In our work, we particularly focus on these details using real devices.
Moreover, we think that our proposal properly fits the ITS world where various types of vehicles and even pedestrians must locate each other in any condition, and indoor conditions like car parks or city tunnels cannot be covered by GPS based solutions. Our main goal was to clearly evaluate the actual contributions and possibilities that a LoRaWAN only solution could offer. We are aware that the use of V2V communications or the integration with other systems or solutions (e.g., References [17][18][19]) could allow for better results. We left the evaluation of these alternatives as future work.

A Brief LoRaWAN Overview
LoRaWAN is a LPWAN (Low Power WAN) technology that stands between mobile (e.g., 3G, LTE) and short-range wireless (e.g., Bluetooth, WiFi or Zigbee) networks. It was designed particularly for IoT devices and applications since they typically need both low frequencies and small sizes of data transfer. LPWANs are used to create proprietary networks to connect IoT devices, such as sensors for monitoring environmental conditions.
LoRaWAN is an open standard with a certification programme to guarantee interoperability that is governed by the LoRa Alliance. Any company can buy LoRa hardware and deploy its own network without going through and paying fees to a centralised authority. However, the underlying LoRa chip needed to implement a LoRaWAN network is proprietary to a California-based semiconductor manufacturer called Semtech.
LoRa uses the sub-GHz spectrum (868 MHz in Europe, 915 MHz in the Americas and 433 MHz in Asia). It employs a spread spectrum technique to transmit data on different frequency channels and at different rates so that the gateway can adapt to changing conditions and optimise the way it exchanges data with each device. Working at sub-gigahertz frequencies it is therefore not so constrained from line-of-sight communications and from blockage from walls and other obstacles. This characteristic makes it more interesting since it implies that it requires far fewer "gateways" than cellular or other short-range wireless technologies. Figure 1 shows the basic elements that constitute a LoRaWAN system, basically the end-devices (e.g., the sensors), the gateways, and the network's servers. Networks server can be private, private with some free options for the users (e.g., LORIOT (https://www.loriot.io/)), or public (e.g., The Things Networks (https://www.thethingsnetwork.org/)).  A single gateway can communicate with several hundred thousand devices up to 20 miles away in unobstructed environments. Data rates range from 300 bps to 50 kbps depending on the spreading factor and channel bandwidth, while the maximum message length is 243 bytes and it offers effective two-way functionality. Each message is received by all the base stations in the range to improve the transmission success ratio.

The Proposed Architecture
Our proposal (see Figure 2) is based on the use of the multiple associations that a LoRaWAN node establishes with surrounding Gateways. As defined in the standard, all gateways receiving a packet coming from a LoRaWAN node forward it to the controlling network server. These multiple copies of the packet are then filtered and a unique copy is given to the accessing application. Data from the network server can be obtained using various APIs. In our case, we used Message Queuing Telemetry Transport (MQTT) to obtain the information. The network server provides in the form of metadata the various details of the data channels and the gateways where the packet got through, see Figure 3.
The only critical condition for our solution to work is that in any position inside the area under consideration a client has to have connectivity with a minimum of three gateways. The locations where the gateways are to be installed and the total number of required gateways is strongly dependent on the context in which the localisation process has to take place. The set-up and the fine-tuning of the different parameters required by the system has to be done taking into consideration factors like the actual structure of the building or the location, the size of the area that we want to cover, the number of devices to be tracked, and so on. The proper characteristics of the hardware used for the gateways, for example, can vary depending on the model used and even supposing the same model on some intrinsic details, like the proper connection of the antenna.

The Devices
Two basic devices constitute our architecture: the clients and the gateways. The client devices, also called "tags" are associated with whatever vehicle is required to be located. Their basic characteristics are (1) small size; (2) basic processing services; (3) low energy usage requirements. The latter requirement is especially critical in devices that are supposed to be used with not electrically autonomous vehicles, like a bicycle or for pedestrians. The client device does not have to perform any specific computation. It is required to periodically broadcast its associated id, (ttrack2bis as in the example in Figure 3). Frequency of this action can be varied according to the degree of mobility of the device, that is, slowly moving ones can send this beacon every 5/10 min, rapidly moving ones can send it every 10/15 s. We have to be aware of the limitation imposed by the duty-cycle which is part of the LoRaWAN standard and that can be enforced by the Networks servers. The gateways can be simple single-channel devices that do not require any special software besides the basic standard forwarding software. All gateways must head to the same network server and must be configured to be part of the same "application", according to the LoRaWAN terminology.

The Geolocalization Algorithm
Our localisation application makes use of the metadata fields provided by the networks server. As shown above, the LoRaWAN architecture directly provides complete information about the gateways that received the packet sent by the tagging client device and the strength of the signal (RSSI) with which it was received. With this information, we applied the localisation algorithm. Our solution to determine the localisation of a client is based on trilateration. Trilateration is the mechanisms used by GPS for example and it involves measuring the distances to some known reference points, the satellites in the case of GPS. Satellites simply broadcast a signal which is received by the GPS device with a specific time and distance.
Consider a single satellite that broadcasts a signal that eventually hits the GPS receiver; in this case, we will know the distance and this distance forms a circle equal in all directions. With three satellites, the true location can be determined as the point where all three circles intersect. In reality, since we are in a three-dimensional world that GPS satellites broadcast signals as a sphere, the exact result is the one given by where all spheres intersect, determining the position of the GPS receiver. In our case, the gateways that receive the broadcasted message from the client act as the satellite, and the RSSI value for each gateway perceived by the client is used to determine an estimate of the distance. The value of airtime was not used because, while testing various devices, we discovered that the actual measurement of these data was not implemented.
So the basic goal is to pass from the values of the RSSI to an estimation of the distance. This process has been widely studied in the literature and many models are available. There are also various studies in the literature specifically oriented to LoRa. Next, Section 5 will review some of this work, compared to our approach. We took as a starting assumption that we were not aiming for exact measurements and we therefore opted for a simple Log-distance model, derived from analytical and empirical methods. It can simply be defined as: where n is the called distance-power gradient. In the ideal case, n = 2; however, n is typically 4 in realistic situations. A value of n in the interval [2,6] is commonly accepted. In Section 5 we detail how we computed the used value for n.
To fit to our purposes we adapted this equation as: from which an estimator of d, indicated as δ, was obtained as: Now, supposing the use of the RSSI values from three different gateways, g 1 , g 2 , and g 3 that are located at coordinates (x g 1 , y g 1 ), (x g 2 , y g 2 ), and (x g 3 , y g 3 ). If we indicate the point to be located as (x, y) and the computed distances are d g 1 , d g 2 , and d g 3 (see Figure 4 for a graphical representation of this structure), we can state the following equations: Expanding the squares of the three: Subtracting the second equation from the first, we obtain: Doing the same, thus subtracting the third equation from the second: We obtain a system of two equations in two unknowns: which has the solution: where: This is clearly is a 2D plane. A 3D computation would take a similar approach.

Results
In this Section, we present the results obtained from our experiments. Since we are focused on indoor localisation we run several experiments in one of the underground car parks of the Universitat Politècnica de València, see Figure 5. In Figure 6 graphical representation of the localisation of the experiments with the position of the gateways and of the client is given.  The hardware used for the experiments is shown in Figure 7. As a client, we used a Whisper Node by Wisen and an Adafruit Feather 32u4. As gateways, we used LoPys by Pycom. The networks server was provided by "The Things Networks".
As indicated in the previous Section, the RSSI value for each gateway perceived by the client is used to determine an estimate of the distance. The value of airtime was not used because, while testing various devices, we discovered that the actual measurement of these data was not properly implemented. So the basic goal is to pass from the values of the RSSI to an estimation of the distance. This process has been widely studied in the literature and many models are available. Various studies are also in the literature specifically oriented to LoRa.
In [20], the authors present the experimental performance evaluation of LoRaWAN over a real environment in Bangkok, Thailand. According to their results, the LoRaWAN range is only up to 2 km in an outdoor rural area and 55-100 m in an indoor urban environment. Clearly, a strong dependency on the properties of the antennas such as antenna gain, directional and antenna height above the surrounding landscape was pointed out. Radcliffe et al. [21] present a set of measurements evaluating the performance of LoRa in a high-density urban area like the Melbourne's central business district. Their results show that loss-free communication is assured only within a radius of approximately 200 m from the base station and total loss of transmission occurs at around 600 m. Having a precise measurement is highly difficult. For example, Boano et al. [22] highlight that even temperature can have a significant impact on LoRa's communication performance, showing that an increase in temperature can be sufficient to transform a perfect LoRa link into an almost useless one. More general studies, mostly in external set-ups, can be found in [23][24][25][26]. What we wanted to analyse is the stability of the read value of the RSSI, varying the distance and the spreading factor used. The value of the Spreading Factor (SF) determines how many chips are used to represent a symbol. The higher the spreading factor, the higher the coding gain. That is, it gives better sensitivity at the expense of lower data rates. A low spreading factor requires more power to accomplish a satisfactory bit error rate. Since data rate was not a critical factor in our case since the client nodes only need to broadcast the associated tag id. Figure 8 shows how the RSSI varies as a function of the distance and of the used SF. Although the average values obtained were similar, the variance of the obtained values differed noticeably. Moreover, at 200 m, basically, the maximum distance that we could reach in our scenario, with SF12 the packet loss rate was basically 0, while with SF7, the packet loss rate was slightly higher than 50%.  Figure 9 details this behaviour at 50 m with SF7 and SF12 using the cumulative distribution of the values obtained. Both cases have a normal distribution but with SF7 the standard deviation is σ 7 = 3.96 while with SF12 the standard deviation is σ 12 = 2.11. This more stable behaviour is also evidenced by the Q-Q plot in Figure 10.
Given the above results, a fundamental step was the computation of the parameter n for Equation (3). The approach we followed was to use the mean value for the obtained RSSI at 50 m SF12 and determine n using a derived equation from Equation (2), namely: n = |RSSI| 10 * log 10 (50m) , which gives an estimated value n = 4.66. This procedure is purely empirical but this is well known in the literature since this simple parameter aggregates various factors that strongly depend on the actual characteristics of the scenario being modelled. Values in the range of [4,6] would fit almost any indoor scenario. We then proceeded to apply the trilateration algorithm described above. Figure 11 shows the distribution of the obtained position estimation; we could place the client in a circle of diameter 24 m. The localisation values got a standard deviation of σ l = 4.23. Recalling what is known as GDOP (geometric dilution of precision) or PDOP (position dilution of precision) that describe the error caused by the relative position of the positioning devices; basically, the more signals a client can see (spread apart versus close together), the more precise it can be. From the observer's point of view, if the gateways are spread apart in the locations, then the clients will have a good GDOP. If the gateways are physically close together, then we will have a GDOP, lowering the quality of the positioning.

Conclusions
In this paper, we described our solution based on simple client devices and on the deployment of various LoRaWAN gateways to provide indoor localisation for vehicular applications. Through estimation of the behaviour of a LoRaWAN channel and using trilateration, the localisation of a vehicle can be obtained within a 20-30 m range. The main advantage of this solution is its low cost and clearly the possibility of operating indoors.
We based our proposal on the use of the RSSI of the signal perceived by various surrounding gateways. The problem of using Time Difference Of Arrival (TDoA) for this goal is that not all devices nor all gateways can provide a proper estimation of these values, yet. In this sense, existing work fails to present results on the stability of the RSSI values over time and on the impact of the spreading factor on the quality of the obtained values. In this work, we particularly focus on these details using real devices.
Our proposal properly fits the ITS world where various types of vehicles and even pedestrians must locate each other in any condition and in indoor conditions, like city tunnels, which cannot be covered by a GPS based solution. For example, we consider that it could be used to locate vehicles of any type in underground car parks, keep a platoon of trucks in formation or create geo-fences, that is, sending an alert if an object moves outside a defined area, like a bicycle being stolen. The routing of heavy vehicles within an industrial setting is another possibility.
We think, therefore, that this work could be an advance in this direction, providing a useful starting point for the use of LoRaWAN for localisation in ITS. Our main goal in this paper was to clearly evaluate the actual contributions and possibilities that a LoRaWAN only solution could offer. We are anyway aware that the use of V2V communications or the integration with other systems or solutions could allow for better results. More work has to be done, since we consider that better precision can be obtained. Various parameters and factors are still to be investigated and the impact of mobility on this technique has to be thoroughly analysed. We left the evaluation of these alternatives for future work.