Introduction

Wi-Fi based positioning is widely used nowadays for indoor applications using the fingerprinting technology, that consists in using a map of Received Signal Strength (RSS) measurements to match the ones measured by the user device (see for instance [1]). However, the RSS measurements are highly dependent on the environment and are susceptible to obstructions, walls or furniture. Positioning methods that use a propagation model to derive range from RSS have to deal with range errors as high as 5 meters with large variability (see for instance [2]). The revision of the 802.11mc protocol published in 2016 allows to measure the Round Trip Time (RTT), also known as Fine Time Measurements (FTT), between the access point and the user device. These measurements, being time-based measurements, are less susceptible to the environment (compared to RSS) and open up the possibility of providing meter level indoor positioning ( [3], [4]). In fact, using RTT measurements for positioning brings Wi-Fi closer to GNSS: both systems use range measurements to estimate the user device position and thus access points become pseudolites that can be used in combination of GNSS measurements once the position of these access points are known. The main difference between GNSS and Wi-Fi RTT is that, while GNSS is a broadcast-based system and the whole system needs to be synchronized (hence the user device requires the computation of its clock deviation relative to each GNSS system clock), Wi-Fi is a bistatic system and thus there is no synchronization error, but hardware biases in the measurements are present and need to be somehow accounted for (see for instance [4]). In fact, for a Wi-Fi RTT system, both access point location and hardware biases need to be provided to the positioning engine of the user device ( [5]), similarly to the GNSS case in which satellite orbits and clocks need to be provided.

This paper does not focus on Wi-Fi as a standalone positioning system for indoor application, which has been already researched in the past (see for instance [4] or [6]), but rather in the benefits that can be obtained when using Wi-Fi as complement to GNSS in urban scenarios to reduce the impact of buildings, structures and narrow streets found in cities, which dramatically degrade the performance of satellite-based navigation systems due to lack of visibility and multipath. Therefore, this paper proposes the usage of Wi-Fi RTT ranges to mitigate the errors of GNSS in urban environments, when the receiver is able to track Wi-Fi RTT measurements served by access points that are visible from the streets (e.g. near windows). In this context, this paper is organized as follows: the first section includes a brief description of the processing model, followed by the details of the data campaign that has been used for testing and, finally, a discussion and conclusion section wraps this paper.

Processing model

The processing model employed in this work is based on tightly coupling the GNSS raw measurements (pseudoranges) with the RTT measurements obtained from 802.11mc compatible Wi-Fi devices. The ranges of GNSS can be modelled using the following simplified model as:

R sat G = ρ sat + c • (dt EU − dt sat ) + ε,(1)

where R sat G is the observed range between the user equipment (U E) and the satellite (sat) (called also pseudorange as it contains not only geometric range but other error terms), ρ sat is the geometric range (i.e. Euclidean distance) between the user equipment and the satellite, dt EU and dt sat are the clock offsets for U E and sat respectively and ε contains the rest of the GNSS pseudorange terms (ionospheric delay, tropospheric error, relativity, multipath and thermal noise). A full description of the GNSS data model is outside the scope of this paper but can be found in extensive literature (see for instance [7]).

On the other hand, for the Wi-Fi case, the range can be modelled according to the following expression:

R AP W = ρ AP + b AP + b U E ,(2)

where R AP W is the observed range between U E and the access point (AP ) (also pseudorange because it contains error terms as well), ρ AP is the geometric (Euclidean) distance between AP and the user equipment that, similarly to the GNSS case, needs to be linearized using Taylor expansion, and finally, b AP and b U E are the hardware biases for the access point and user equipment respectively (see for instance [8]). Note that in the same way that GNSS satellite orbits and clocks are required to model the GNSS range, in Wi-Fi both the AP location and hardware biases are also required. In fact, the quality of WAP position and biases will ultimately determine the accuracy of the Wi-Fi based positioning and the potential improvement in the GNSS+Wi-Fi hybridization. For this work, the WAP products (position and biases) have been surveyed, thus reaching errors in those products on the range of few centimeters. However, works such as [5] indicate that meter-level accuracies can be reached in an operational system that uses data from 802.11mc compliant smartphones to automatically compute those WAP products, without the need of dedicated surveying campaign.

The ranges for both GNSS and Wi-Fi are then fused in a Kalman filter in a measurement update characterized with the following matrix:

⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ R sat1 G − R sat1 G,0 . . . R satN G − R satN G,0 R bssid1 W − R bssid1 W,0 . . . R bssidN W − R bssidN W,0 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ = ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ p sat1 x p sat1 y p sat1 z 1 0 . . . p satN x p satN y p satN z 1 0 p AP 1 x p AP 1 y p AP 1 z 0 1 . . . p AP N x p AP N y p AP N z 0 1 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ • ⎡ ⎢ ⎢ ⎢ ⎢ ⎣ ∆x ∆y ∆z dt U E b U E ⎤ ⎥ ⎥ ⎥ ⎥ ⎦ (3)

where p c is the partial for the c component (i.e. x, y or z), defined as:

p tx c = c 0 − c tx ρ tx 0 ,(4)

and

ρ tx 0 = √︁ (x 0 − x tx ) 2 + (y 0 − y tx ) 2 + (z 0 − z tx ) 2

is the geometric range considering the apriori position for the user receiver and a given transmitter (tx), that can be either a GNSS satellite (sat) or Wi-Fi access point (AP ). The parameters to be estimated correspond to the position deltas (relative to the position apriori), ∆x, ∆y, ∆z as well as the GNSS receiver clock (dt U E ) and the receiver Wi-Fi bias (b U E ). The measurement updates can be solved in a purely kinematic way by simply applying a Least Mean Squares strategy on every incoming batch of measurements or apply a Kalman filter that allows to define certain dynamics for the user equipment. In the case of this work, the latter has been adopted, and it has been assumed that the UE behaves as a moving device and thus its dynamics are modelled as a random walk with a generous dynamic (100 m / s), which should cover gently the dynamics of a pedestrian. In fact, this setting can be tuned in real operations with an estimation of the velocity. For this work, the wide dynamics stated above have been chosen so that the effective smoothing of a tighter setting would not mask the improvement due to the combination between GNSS and Wi-Fi (i.e. the rationale being that if the solution is improved with this wider setting, it would also benefit a tighter dynamic setting).

Data campaign

In order to assess the potential improvement that can be achieved with the proposed fusion approach, a harsh environment in terms of GNSS has been selected, with multipath and limited satellite visibility. The test setup has been conducted in Barcelona, in the patio of the Glòries incubator center, where Rokubun offices are located (approx coordinates 41°24'23.39"N 2°11'32.58"E), see Fig. 1.

The most relevant characteristic of the proposed test setup is its complexity in terms of GNSS signal. As it can be appreciated, the patio in which the test has been performed is surrounded by tall buildings and structures. This environment is considered harsh in terms of GNSS: the surrounding buildings and structures block multitude of GNSS satellites and increases the noise due to multipath. In fact, it is optimal for the purpose of this work in The list of equipment used in the execution of the test campaign is collated in Table 1. In particular, the Rokubun MEDEA navigation computer, based on the u-blox ZED-F9P chipset, has been modified to incorporate a Wi-Fi capable module in order to record both GNSS and Wi-Fi measurements (see Fig. 2). In addition, a smartphone compliant with the 802.11mc protocol has been used. The list of access points used for the campaign are also included in the table. The table shows also the test points at which the equipment was placed during the campaign.

Results and discussion

The data collected for both the Rokubun MEDEA navigation computer and the Google Pixel 4 has been processed with the model described in earlier section of this paper. The processing model for GNSS that has been adopted attempts to reproduce the conditions of a mass-market device, namely: pseudorange only processing and correcting the ionospheric delay with the Klobuchar model (broadcast in the GNSS ephemeris, see [9]) and using the Saastamoinen model for the tropospheric delay (see [10]). Given the conditions of the scenario, a high elevation mask of 15 • has been adopted. The coordinates generated by the positioning engine have been then compared against the reference position (surveyed point at which the devices have been placed) in order to obtain the horizontal deviation (Easting and northing deviation) as well as the vertical deviation. The results for the different strategies considered (GNSS only, Wi-Fi only and GNSS+Wi-Fi hybrid solution) are shown for Rokubun MEDEA navigation computer (see Fig. 3) as well as for Google Pixel 4 (see Fig. 4). The scatter plots of these figures have been generated using a data set of 32 minutes with a sampling rate of 1 second for the Google Pixel 4 and 20 minutes with a sampling rate of 1 second for MEDEA. As expected, the positioning errors are very large, specially for the smartphone case. Similar performance in positioning has been obtained using third party tools such as RTKlib (see [11]). All the error values, expressed as bias and standard deviation (σ) for all devices, components and strategies are collated in Table 2. In all cases, there is a clear benefit in combining GNSS with Wi-Fi both in bias and standard deviation, which is also evidenced in the figures shown above. This improvement, mostly in the horizontal dimension, is due to the fact that Wi-Fi is much less impacted than GNSS in this particular scenario. Note however that the improvement is much lower in the case of MEDEA than Google Pixel 4. This is due to the fact that the quality of the GNSS solution for MEDEA is much higher than the smartphone (due to the dedicated GNSS chipset as well as much better antenna), thus leaving less room for improvement. Therefore, when using more complex GNSS processing strategies (such as e.g. Precise Point Positioning or Real Time Kinematics), the relative weighting between GNSS and Wi-Fi ranges may have to be reviewed. However, considering the typical use case of the proposed algorithm (i.e. mobile devices whose GNSS chipset and antenna offer observables with higher noise, but integrate additional data sources for navigation such as Wi-Fi and Ultra-wideband), the adoption of the proposed algorithm is deemed beneficial.

Regarding the accuracy that can be achieved with Wi-Fi only data, naïve positioning strategies such as centroid computation (i.e. weighted average position of the WAPs seen by the receiver) yields higher error values. For the case of Google Pixel 4 (whose Wi-Fi only solution yields 1.6 meter of horizontal error), discrepancies of 3.9 m, 2.6 m and 5.1 m are obtained respectively for the unweighted average (raw average of WAP positions), weighting based on RSS and weighting based on the inverse of the RTT measurements. The latter one yields worse results due to the presence of the hardware biases. These error figures are highly dependent on the geometry and disposition of the WAPs (in this case the WAPs were surrounding the receiver in all directions), and can increase if the WAPs positions have a bad geometry relative the receiver (e.g. all in one side). However, a naïve location based on weighted average can be used as an apriori position to linearize the navigation equations. Actually, this approach might provide more accurate apriori positions than the Bancroft method typically used in GNSS, which will reduce the convergence time of the positioning engine.

Another point worth noticing from the figures shown above (Fig. 3) and Fig. 4) is the linear shape for the Wi-Fi horizontal errors. The reason behind this shape is due to the disposition of the access points. From the lower panel shown in Fig. 1, the reader might have noticed that the routers where placed, approximately in the North West to South East direction. Since the user equipment where placed in the middle, there is an ambiguity in the South West to North East direction (i.e. the algorithm cannot properly determine the correct position along this direction), thus leading to this shape. This problem, due to the Dilution of Precision (DOP), also exists in GNSS and in fact worsens in Wi-Fi because the relative distances of the ranges and user dynamics is much shorter than in the case of GNSS.

Conclusions

The present paper showed to what extent Wi-Fi RTT measurements can benefit and complement GNSS systems when challenged by multipath in urban scenarios. This benefit applies to urban outdoor GNSS receivers that are able to track Wi-Fi RTT measurements (from e.g. access points placed near windows or visible from the street). A clear application field of this technique is for certain Android smartphones, where GNSS raw measurements are available to the developer since Android 7 (Nougat, API 24) and Wi-Fi RTT ranging since Android 9 (Pie, API 28 [12]).

The results shown in the paper indicate a clear improvement of at least 1 to 2 meters in bias and standard deviation, albeit this depends on the device: for a premium-mass-market receiver such as the Rokubun MEDEA navigation computer (with a dedicated multifrequency antenna), there is still improvement, but is less noticeable than in the case of the smartphone. Similarly, benefits are still present when GNSS is working at its full capability (open sky, with no multipath or problems in terms of visibility), but are much smaller than the case proposed (reduction of errors less than 1 m).

From the results shown above, Wi-Fi only solution is better than the combined one with GNSS in a multipath-rich scenario, but might not be the case in a mixed environment (nominal GNSS visibility and irregular Wi-Fi RTT availability), albeit still benefit from the hybridization. In this scenario, the number of available Wi-Fi RTT measurements was plenty, which allowed for a robust position estimation with Wi-Fi (this could be in fact the typical case in indoors). In a more generic case, in order to achieve the best possible geolocation solution, the hybridization strategy will likely have to be properly weighted between GNSS and Wi-Fi taking into account different factors such as number of available Wi-Fi measurements, potential GNSS multipath indicators (C/N0, variation of the C/N0), etc.

Unfortunately, the number of Commercial Off The Shelf platforms (both access points and smartphones) that are fully 802.11mc compatible are rather scarce. Apple, for instance, has no support for 802.11mc to the best of the author's knowledge. However, the technique proposed in this work can be easily applied as well to similar short range location technologies such as Ultra-wideband (UWB). In fact, smartphone manufacturers are already supporting UWB and additional systems such as Bluetooth or 5G-based ranging may be supported in the near future.

"Data availability" The GNSS raw measurements as well as Wi-Fi RTT ranges from smartphone data are available to the reader upon request to the authors.