Crowdsourced RTT-based positioning

Abstract

In various embodiments, crowdsourcing techniques are provided to enable RTT-based positioning of UEs. To address the problem of discovering which beacons (e.g., Wi-Fi APs, cellular base stations, BLE transmitters, etc.) support RTT measurements (e.g., according to IEEE 802.11mc, 3GPP Release 16, etc.), beacon RTT capabilities may be crowdsourced from UEs and maintained by a cloud-based location platform in a beacon database (or more specifically, an RTT database portion thereof). To address the problem of determining physical antenna locations, RTT measurements may be crowdsourced from UEs for those beacons that are RTT-enabled and used by a trilateration algorithm (e.g., a WLS multilateration algorithm) to determine physical antenna locations, which may also be maintained in the beacon database. The accuracy of the trilateration may be enhanced by obtaining raw GNSS measurements (e.g., pseudoranges) from the UE and performing a cloud-based RTK GNSS position fix for the UE.

Description

[Technical field]

[0001] The present disclosure relates generally to user equipment (UE) positioning, and more particularly to crowdsourcing techniques that enable round trip time (RTT) based positioning of a UE. [Background technology]

[0002] Determining UE location is becoming increasingly important for tracking users, managing profiles, providing location-based services, and other tasks. Some techniques for determining UE location include received signal strength (RSS) measurements. For example, triangulation of RSS measurements of signals received at the UE from multiple beacons (e.g., Wi-Fi access points (APs), cellular base stations, Bluetooth low energy (BLE) transmitters, etc.) may be performed. However, RSS-based techniques may have difficulty determining UE location with high accuracy.

[0003] Improved accuracy may be possible by utilizing RTT measurements in determining the UE location. In general, the RTT is the time that elapses between the transmission of an initiation signal and the receipt of a corresponding response signal. By subtracting the turnaround time from the RTT and dividing the result by two, the Time-of-flight (ToF) can be obtained. From the ToF, the distance (range) between the UE and the beacon can be easily determined. Based on the distances to multiple beacons, the location of the UE can be determined, for example, by trilateration.

[0004] Various new protocols, such as the Fine Timing Measurement (FTM) protocol introduced in the Institute of Electrical and Electronics Engineers (IEEE) 802.11mc standard, as well as protocols introduced in the 3rd Generation Partnership Project (3GPP®) Release 16 Technical Specifications (TS) Series 37 and 38, allow for highly accurate measurement of RTT. With a Wi-Fi AP supporting the FTM protocol, RTT can be measured from timestamps captured at the departure and arrival of FTM frames and their respective acknowledgments. With a cellular base station supporting 3GPP® Release 16, a specific subtype of RTT called multi-RTT can be measured.

[0005] A UE may use various mechanisms to discover which beacons support RTT measurement. For example, the FTM protocol provides two mechanisms for discovering which Wi-Fi APs support RTT measurement: advertisement frames and range requests. With advertisement frames, a Wi-Fi AP periodically broadcasts frames to advertise its RTT capabilities to the UE. With range requests, a UE attempts to establish a peer link to a Wi-Fi AP and have it measure RTT by sending a request frame and waiting to receive a burst of response frames, which it responds to with an acknowledgment. In either the advertisement frame or range request, an extended capability element (e.g., included in the advertisement frame or initial response frame) may provide information about the scheduling and operation details of the FTM session, such as burst duration, FTM frames per burst, bandwidth, minimum time between consecutive FTM frames, etc. Similarly, 3GPP Release 16 provides its own mechanisms for discovering which cellular base stations support RTT.

[0006] Although using RTT has the potential to improve the accuracy of UE positioning, several obstacles prevent widespread deployment of RTT-based positioning. First, determining which beacons support RTT measurements is often error-prone and operationally expensive (in terms of time, processor cycles, memory space, network bandwidth, and power). Some beacons may simply not have the capability to support RTT measurements (e.g., they only support older protocols and standards). Other beacons may include the capability (e.g., their chipsets support applicable protocols and standards), but they do not advertise their RTT capabilities for various reasons. For example, with the FTM protocol, only a small minority of deployed Wi-Fi APs currently support the IEEE 802.11mc standard and the FTM protocol. Of that small minority, some Wi-Fi APs do not advertise their capability to support the FTM protocol. A UE interested in knowing which Wi-Fi APs support the FTM protocol generally has two suboptimal options: the UE can rely on advertisements and thus miss Wi-Fi APs that do not advertise their capabilities, or the UE can establish peer links and send request frames to each neighboring Wi-Fi AP, thus consuming significant time, processor cycles, memory space, network bandwidth, and power. In a dense urban area, there may be dozens or even hundreds of neighboring Wi-Fi APs, and having every UE establish peer links and send request frames to every neighboring Wi-Fi AP is simply too operationally expensive and impractical.

[0007] Second, it may be difficult to determine the physical antenna location to a level of accuracy that can fully realize the benefits for RTT-based positioning. RTT-based positioning generally requires highly accurate physical antenna locations (e.g., within one meter) to fully realize its benefits. One way to obtain such physical antenna locations is by dedicated surveying. For example, a Wi-Fi surveying system or vehicle that includes high-precision hardware may traverse a location and create a map of the physical antenna locations of Wi-Fi APs. Although the physical antenna locations determined by such an approach may be accurate, it is extremely time-consuming and expensive. An alternative approach is to approximate the physical antenna location based on the coverage area of ​​a beacon, which may already be known from other positioning techniques. For example, the physical antenna location of a Wi-Fi AP may be approximated as the centroid of the coverage of the Wi-Fi AP. However, such an approach is generally not very accurate. The centroid of the coverage often deviates from the physical antenna location due to signal propagation bias, observation bias, and other factors. Summary of the Invention [Problem to be solved by the invention]

[0008] Thus, there is a need for improved techniques that can address these and / or other issues that have hindered widespread deployment of RTT-based positioning of UEs. [Means for solving the problem]

[0009] In various embodiments, crowdsourcing techniques are provided to enable RTT-based positioning of UEs. To address the problem of discovering which beacons (e.g., Wi-Fi APs, cellular base stations, BLE transmitters, etc.) support RTT measurements (e.g., according to IEEE 802.11mc, 3GPP Release 16, etc.), beacon RTT capabilities may be crowdsourced from UEs and maintained in a beacon database (or more specifically, the RTT database portion thereof) by a cloud-based location platform. To address the problem of determining physical antenna locations, RTT measurements may be crowdsourced from UEs for beacons that are RTT-enabled and used by a trilateration algorithm (e.g., a weighted least squares (WLS) multilateration algorithm) to determine physical antenna locations, which may also be maintained in the beacon database. The accuracy of the trilateration may be increased by obtaining raw Global Navigation Satellite System (GNSS) measurements (e.g., pseudoranges) from the UE and performing a cloud-based real-time kinematic (RTK) GNSS position fix for the UE.

[0010] In one embodiment, a positioning client on the UE is used to crowdsource beacon RTT capabilities. The UE uses a wireless network interface to scan for beacons within range of the UE. The UE accesses information from a beacon database maintained by a cloud-based location platform to determine whether the RTT capabilities are known for each beacon within range. For one or more beacons with unknown RTT capabilities, the UE sends a range request to attempt to have the beacon measure the RTT, and based thereon assigns the beacon an RTT measurement status indicating the beacon's RTT capabilities. The UE then uploads at least the RTT measurement status to the cloud-based location platform to update the beacon database. In such an embodiment, the UE both consumes information about the beacon's RTT capabilities from the beacon database and provides information about the beacon's RTT capabilities to the beacon database.

[0011] In another embodiment, a cloud-based location platform is used to crowdsource the beacon RTT capabilities. The cloud-based location platform provides information regarding the RTT capabilities of the beacons from a beacon database to a plurality of UEs. At least one of the beacons initially has an unknown RTT capability. The cloud-based location platform later receives RTT information including at least an RTT measurement status from one or more of the plurality of UEs that attempted to measure the RTT on the beacon with the initially unknown RTT capability. The RTT capabilities of the beacons are determined based on the received RTT measurement status, and the beacon database is updated to include information indicative of the RTT capabilities of the beacons. In such an embodiment, this operation allows the UEs to both consume information regarding the RTT capabilities of the beacons from the beacon database and to provide information regarding the RTT capabilities of the beacons to the beacon database.

[0012] In yet another embodiment, a cloud-based location platform determines the beacon location, or more specifically the physical antenna location of the beacon, based on crowdsourced data. The cloud-based location platform receives observations from a plurality of UEs that have observed the beacon, the observations including at least the determined location of the UE and an RTT measurement for the UE due to the beacon. The cloud-based location platform uses a trilateration algorithm to determine the physical antenna location of the beacon based on the determined location and the RTT measurement for each of the plurality of UEs. The cloud-based location platform updates a beacon database to include the determined physical antenna location of the beacon and provides the physical antenna location of the beacon to one or more of the plurality of UEs. In such an embodiment, this operation allows the UE to both contribute information used to determine the physical antenna location of the beacon to build a beacon database and to consume the physical antenna location of the beacon from the beacon database.

[0013] In yet another embodiment, a cloud-based location platform determines a beacon location, or more specifically, a physical antenna location of the beacon, based on crowdsourced data, and the accuracy of such determination is improved using a cloud-based RTK GNSS position fix for the UE location. The cloud-based location platform receives information from a plurality of UEs that have observed the beacon, including at least raw GNSS measurements for the UE and RTT measurements for the UE. The cloud-based location platform also obtains RTK correction information from a correction service for the raw GNSS measurements. The cloud-based location platform determines a corrected GNSS position fix for each UE using the raw GNSS measurements and the RTK correction information. Thus, the cloud-based location platform uses a trilateration algorithm to determine the location of the beacon based on the corrected GNSS position fix and the RTT measurements, and updates the beacon database to include the determined physical antenna location of the beacon. The cloud-based location platform then provides the physical antenna location of the beacon to one or more of the plurality of UEs.

[0014] It should be understood that the embodiments described in this Summary of the Invention may include various other features, including other features described below, and variations thereof. Furthermore, various other embodiments may be utilized including various combinations of the features described herein and below, and variations thereof. The Summary of the Invention is intended merely to provide a brief introduction to the reader, and is not intended to imply that any particular feature referred to herein is all or essential to the invention.

[0015] The following description refers to the accompanying drawings. [Brief description of the drawings]

[0016] [Figure 1]FIG. 1 is a block diagram of an example architecture in which techniques for enabling RTT-based positioning of a UE may be deployed. [Diagram 2] 11 is a flow diagram detailing example operations performed under the control of a positioning client on a UE to crowdsource beacon RTT capabilities. [Diagram 3] 11 is a flow diagram detailing example operations performed by a cloud-based location platform to crowdsource beacon RTT capabilities. [Figure 4] 11 is a flow diagram detailing example operations performed by a cloud-based location platform to determine beacon locations, or more specifically, physical antenna locations of beacons, using crowdsourced RTT measurements from UEs. [Diagram 5] 1 is a diagram of an example deployment of a UE illustrating HPE and its use as an indication of position determination accuracy. [Figure 6] 1 is a flow diagram detailing example operations performed by a cloud-based location platform in an “off-board” implementation to determine a beacon position, or more specifically, a beacon's physical antenna position, using a cloud-based RTK GNSS position fix. [Figure 7] 4 is a flow diagram detailing example operations performed by a positioning client on a UE to implement a hybrid RTT-based positioning algorithm to determine a UE position. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] FIG. 1 is a block diagram of an example architecture 100 in which techniques for enabling RTT-based positioning of a UE may be deployed. As used herein, the term "user equipment" or "UE" refers to a mobile device, a machine-to-machine (M2M) device, or an Internet of Things (IoT) device operated by an end user. Examples of UE 110 include smartphones, smart watches, computers, cameras, and sensors operated by end users, among others. Similarly, as used herein, the term "beacon" refers to a device having a fixed location that exchanges signals that may be used to determine the location of a UE. Examples of beacons 140 include Wi-Fi APs, cellular base stations, and BLE transmitters, among other devices. Furthermore, as used herein, the term "RTT capability" refers generally to the capability of a beacon to measure RTT (or a subtype thereof, such as multi-RTT) and provide the measured RTT to other devices. The RTT capability may be in accordance with the FTM protocol of the IEEE 802.11mc standard, 3GPP Release 16 TS Series 37 and 38, or other protocols and standards. Still further, as used herein, the term "RTT measurement status" refers to the capability of a beacon to make a particular RTT measurement. The RTT measurement status may be in accordance with the FTM protocol of the IEEE 802.11mc standard, 3GPP Release 16 TS Series 37 and 38, or other protocols and standards.

[0018] The UE 110 generally includes, among other components, a central processing unit (CPU) 115, storage 120 (e.g., volatile and non-volatile memory) that maintains application software including a positioning client 122, one or more wireless network interfaces 125 (e.g., a Wi-Fi interface operating in accordance with the IEEE 802.11 standard, a cellular radio operating in accordance with 3GPP Release 16 TS Series 37 and 38, and / or another type of wireless interface), and a GNSS receiver 130 that receives satellite signals.

[0019] The positioning client 122 typically utilizes a wireless network interface to scan for and determine characteristics of beacons 140 (e.g., Wi-Fi APs, cellular base stations, BLE transmitters, etc.) within range of the UE 110. These characteristics may be used in conjunction with a local copy of the beacon information to determine the location of the UE 110. Similarly, the positioning client 122 may utilize the GNSS receiver 130 to acquire raw GNSS measurements (e.g., pseudoranges) from satellites. The raw GNSS measurements may also be used to determine the location of the UE (i.e., a GNSS position fix).

[0020] The UE 110 may communicate over the Internet 150 and a Wi-Fi or cellular data path to a cloud-based location platform 160. Among other functions, the location platform 160 typically maintains a beacon database 170. A portion of the beacon database 170 may be designated as an RTT database 175, which may relate a beacon's identifier (e.g., media access control (MAC) address, cell identifier (ID), etc.) to various RTT-related information, such as the beacon's RTT capability (e.g., RTT-capable, RTT-incapable, or having unknown RTT capability), RTT bias, the beacon's physical antenna location, location uncertainty, etc. A portion of the beacon database (including the RTT database 175) covering a particular geographic area (e.g., a tile) may be downloaded by the positioning client 122 to the UE 110 for use as a local copy. Additionally, information derived from scans performed by the UE 110 (e.g., the UE's determined location, beacon identification information, RTT measurement status, RTT measurement values, etc.) may be periodically uploaded to a cloud-based location platform 160 that uses the information to update the beacon database 170 (which includes the RTT database 175).

[0021] 2 is a flow diagram detailing example operations 200 performed under the direction of the positioning client 122 on the UE 110 to crowdsource beacon RTT capabilities. In step 210, the positioning client 122 uses the wireless network interface 125 of the UE 110 to perform a scan to discover beacons 140 within range of the UE. The scan may be an active scan (e.g., in response to a current request to calculate a UE position for an application running on the UE 110) or a background scan (e.g., background operation with no current request to determine the UE's position). In step 215, for implementations utilizing a local copy of a portion of the beacon database 170 covering a geographic area (e.g., a tile), the positioning client 122 checks whether the UE 110 stores a local copy of a portion (e.g., a tile) of the beacon database 170 covering a geographic area that includes the current location of the UE 110. If not, in step 220, the positioning client 122 downloads a local copy (e.g., tile) from the cloud-based location platform 160. This may occur each time the UE enters a new geographic area or when a previously downloaded local copy (e.g., tile) becomes stale. It should be understood that some implementations may not use a local copy (e.g., tile), in which case steps 215-220 may be omitted.

[0022] In step 225, the positioning client 122 loops through each beacon 140 within range of the UE 110 and checks in step 230 to determine if the RTT capability is already known. In an embodiment using a local copy (e.g., a tile), this may include checking the identity of the beacon in the local copy (e.g., a tile). Alternatively, this may include querying the cloud-based location platform 160. The RTT capability may have several states, including RTT-capable (i.e., a state indicating that some other UEs have been able to have the beacon measure the RTT in the past), RTT-incapable (i.e., a state indicating that other UEs have tried to have the beacon measure the RTT in the past but none have been able to), or having unknown RTT capability (i.e., a state indicating that no UEs have attempted to measure the RTT in the past). In step 235, for each beacon 140 within range of the UE 110 indicated as being RTT-capable or having unknown RTT capability, the positioning client 122 adds the beacon to a range list (i.e., a list of identifiers (e.g., MAC addresses, cell IDs, etc.)) indicated to receive range requests.

[0023] In step 240, the positioning client 122 loops through each beacon 140 on the range list and in step 245 has the wireless network interface 125 send a range request (e.g., an FTM protocol range request according to the IEEE 802.11mc standard, or a request according to another standard) with which it attempts to have the beacon 140 measure the RTT. In step 250, the positioning client 122 assigns the beacon 140 an RTT measurement status indicating the beacon's RTT capabilities. The assigned RTT measurement status may indicate that the beacon is RTT-capable (i.e., the beacon was able to measure and return the RTT), RTT-incapable (i.e., the beacon was not able to measure and return the RTT), or out of RTT range (i.e., the beacon was not able to measure the RTT, but the beacon returned an out of range indication, and if the range is smaller, the beacon may be able to measure and return the RTT).

[0024] In step 255, the positioning client 122 determines a position of the UE 110. The determination may be based on GNSS, such that the determined position is a GNSS position fix. Alternatively or additionally, the determination may utilize RTT-based positioning. Such RTT-based positioning may utilize a hybrid positioning algorithm that combines an RTT-based WLS positioning algorithm with an Extended Kalman positioning algorithm, as described in more detail below. A position confidence (e.g., estimated horizontal position error (HPE)) may be calculated for the determined position of the UE 110.

[0025] In step 260, in an implementation utilizing caching, the positioning client 122 adds RTT information for beacons within range to a local cache of the positioning client 122 on the UE 110. The RTT information may include the UE's determined location (and possibly location confidence), and for each beacon, the beacon's identifier (e.g., MAC address, cell ID, etc.), RTT measurement status (e.g., RTT capable, RTT not capable, or out of RTT range), and, if available, the RTT measurement value. In step 265, the positioning client 122 determines whether a cache upload trigger has been reached. The trigger may be the local cache filling up, a certain amount of time expiring, or some other criteria that is periodically met. If the trigger is reached, in step 270, the positioning client 122 uploads the contents of the local cache to the cloud-based location platform 160 for inclusion in an update of the beacon database 170 (or, more specifically, its RTT database 175). It should be understood that some implementations may not use caching, in which case steps 260-265 may be omitted and the upload of step 270 begins as soon as there is new RTT information for the beacon. Finally, in optional step 275, the positioning client 122 reports the determined location of the UE to other application software (e.g., if the initial scan was an active scan).

[0026] 3 is a flow diagram detailing example operations 300 performed by cloud-based location platform 160 to crowdsource beacon RTT capabilities. This operation may aggregate information discovered by multiple UEs 110 to build beacon database 170 (and its RTT database 175). At step 310, cloud-based location platform 160 batches received RTT information from UEs 110.

[0027] As described above, the RTT information may include, for the UE's determined location and each beacon 140 within range of the UE, the beacon's identifier (e.g., MAC address, cell ID, etc.), the RTT measurement status (e.g., RTT capable, RTT not capable, or out of RTT range), and, if available, the RTT measurement value.

[0028] In step 320, in a batch updating implementation, the cloud-based location platform 160 determines that a batch period has been reached. The batch period may be a period of time (e.g., once a month) during which the RTT capabilities of the beacons 140 are updated in the beacon database 170, or a non-time-based trigger. It should be understood that some implementations may not use batch processing, in which case step 320 may be omitted and operations commence in real time.

[0029] In step 330, the cloud-based location platform 160 loops through each beacon 140 in the batch, iterating through the identifiers (e.g., MAC addresses, cell IDs, etc.) and looking up an aggregate of the RTT information for the beacons. In step 340, the cloud-based location platform 160 determines the RTT capability of the beacon 140 based on the RTT measurement status in the RTT information for the beacon. If the RTT measurement status from at least one UE 110 indicates that it is RTT-capable, the beacon 140 may be marked as RTT-capable. If the RTT measurement status from all of the UEs 110 indicates that it is RTT-non-capable, the beacon 140 may be marked as RTT-non-capable. If the RTT measurement status from at least one UE 110 indicates that the beacon is out of RTT range (but the RTT measurement status of the UE 110 indicates that the UE is RTT-capable), the beacon 140 may be marked as having unknown RTT capability.

[0030] In step 350, the cloud-based location platform 160 determines whether the RTT capabilities of the beacon 140 indicate that it is RTT-capable. If not, execution loops to examine the next beacon. If so, execution proceeds to step 360, where the cloud-based location platform 160 estimates an RTT bias for the beacon 140, which measures the expected offset / error in the RTT measurement by the beacon. The RTT bias may be estimated using various techniques. For example, a delta may be calculated between the RTT-determined distance between the UE 110 and the beacon 140 and the position fix-determined distance between the UE and the beacon. If the delta is substantially the same across several (e.g., all) UEs 110 that have observed the beacon 140, the delta may be used as the RTT bias of the beacon. The cloud-based location platform 160 may also determine other beacons 140 that share a common organizational identifier (e.g., organizational unique identifier (OUI)) with the beacon. If some of these other beacons share substantially the same RTT bias, then this RTT bias may be assumed for the current beacon, which may allow for estimation of the RTT bias in situations where delta calculations are not possible.

[0031] In step 370, the cloud-based location platform 160 determines whether the distance (range) between the UE 110 and the beacon 140 calculated based on the RTT is valid. For example, it may be determined whether the distance is consistent with the distance between the location of the UE 110 using other techniques (e.g., GNSS position fixes) and the beacon location in the beacon database 170. If the RTT-based distance is not valid, the RTT capability of the beacon 140 is updated (e.g., to mark the beacon as RTT-incapable).

[0032] In step 380, the cloud-based location platform 160 determines the physical antenna location of the beacon 140. The determination uses a trilateration algorithm (e.g., a WLS multilateration algorithm) that makes RTT measurements from multiple UEs. Exemplary operations for determining the physical antenna location are described in detail below.

[0033] As the loop through each of the beacons is performed in step 390, the cloud-based location platform 160 updates the beacon database 170 (or more specifically, its RTT database 175) to include the new RTT capabilities. In implementations that utilize local copies (e.g., tiles), the updated portions of the beacon database 170 may then be provided back to the UE 110 to inform the UE 110 of the RTT capabilities of the beacons so that the UE 110 can perform RTT-based positioning.

[0034] FIG. 4 is a flow diagram detailing an example operation 400 performed by the cloud-based location platform 160 to determine a beacon location, or more specifically, a physical antenna location of a beacon, using crowdsourced RTT measurements from the UE 110. In step 410, the cloud-based location platform 160 receives observations from the UE 110 of an RTT-enabled beacon 140. The observations may include the UE's determined location (e.g., GNSS position fix), a location confidence of the determined location (e.g., HPE of the GNSS position fix), an identifier of the beacon (e.g., MAC address, cell ID, etc.), and RTT information. The RTT information may include the RTT measurement, the RTT measurement uncertainty, a signal strength associated with the RTT measurement, a bandwidth associated with the RTT measurement, as well as other RTT-related data. In step 420, the cloud-based location platform 160 aggregates the observations of a given beacon 140. In step 430, the cloud-based location platform 160 filters the observations based on a comparison of the position confidence of the UE's determined position (e.g., HPE of the GNSS position fix) to a threshold. Preferably, the threshold is set to remove only observations with very poor position confidence (e.g., observations with a very large HPE). Subsequent weighting in operations may accommodate moderately reliable observations.

[0035] In step 440, the cloud-based location platform uses a trilateration algorithm to determine the beacon location, or more specifically the physical antenna location of the beacon, based on the aggregated observations from the UE 110. The trilateration algorithm may be a WLS multilateration algorithm, in which the weights are a function of the confidence of the UE's determined location (e.g., HPE of the GNSS position fix), the RTT measurement uncertainty, the range at which the RTT was determined (e.g., measurements from longer ranges are considered less reliable), the signal strength associated with the RTT measurement, the number of RTT measurements, and the bandwidth associated with the RTT measurement (e.g., higher bandwidths are considered to have smaller errors). In some cases, the WLS multilateration algorithm may also consider other information (e.g., RSS, angle of arrival (AoA), etc.) and apply weights to them based on the uncertainty (e.g., apply a higher weight to the RSS measurement since RSS may have a higher uncertainty than RTT). In step 450, the cloud-based location platform updates the beacon database to include the determined positions of the beacons 140, or more specifically, the determined physical antenna locations of the beacons. A portion (e.g., a tile) of the updated beacon database 170 may then be provided back to the UE 110, allowing the determined physical antenna locations of the beacons to be used in the UE's RTT-based positioning.

[0036] The accuracy of trilateration can often be improved by using a determined position of a UE with very good position confidence. If the determined position is a GNSS position fix, very good position confidence may be measured as a very low HPE. FIG. 5 is a diagram of an example deployment 500 of a UE 110 illustrating the HPE and its use as an indication of the accuracy of the position determination. The position of a beacon 510 may be determined by trilateration using the GNSS position fixes of UEs 520-540, each of which has an HPE represented by a circle with a given radius. Specifically, the HPE of UE 540 is somewhat large, indicating low confidence in this position. The position of UE 540 may be very inaccurate, which may affect the accuracy of the trilateration. If the accuracy of the position of UE 540 can be improved, the accuracy of the trilateration may also likely be improved.

[0037] One technique for improving the accuracy of position determination for the UE 110 includes RTK correction services. In a conventional implementation, an "on-board" implementation of RTK corrections, the GNSS receiver 130 in the UE 110 is RTK-enabled and interacts with an independent network of RTK base stations that provide real-time corrections to be applied at the UE. However, RTK-enabled GNSS receivers are typically quite expensive and are not typically deployed in low-cost UEs (e.g., smartphones, smart watches, etc.). Thus, many UEs 110 cannot benefit from RTK corrections if their operation is restricted to be "on-board".

[0038] This limitation may be addressed by an “off-board” implementation in which raw GNSS measurements (e.g., pseudoranges) from the UE 110 are provided to a cloud-based location platform 160 that performs a RTK GNSS position fix. FIG. 6 is a flow diagram detailing an example operation 600 performed by the cloud-based location platform 160 in an “off-board” implementation to determine a beacon position, or more specifically, a physical antenna position of a beacon, using a cloud-based RTK GNSS position fix. In step 610, the cloud-based location platform 160 receives observations from the UE 110 of an RTT-enabled beacon. The observations may include one or more sets of raw GNSS measurements (e.g., pseudoranges) from the GNSS receiver 130 of the UE 110, an identifier of the beacon (e.g., MAC address, cell ID, etc.), and RTT information. The RTT information may include an RTT measurement, an RTT measurement uncertainty, a signal strength associated with the RTT measurement, a bandwidth associated with the RTT measurement, as well as other RTT-related data. In step 620, cloud-based location platform 160 connects to the RTK correction service via Internet 150 to obtain RTK correction information. In step 630, for each set of raw GNSS measurements, cloud-based location platform 160 uses the raw GNSS measurements and the RTK correction information to determine a corrected GNSS position fix for UE 110. In step 640, cloud-based location platform 160 determines the HPE of the resulting corrected GNSS position fix for each of UEs 110. This corrected GNSS position fix will generally have a much smaller HPE than a GNSS position fix generated by the UE itself.

[0039] In step 650, cloud-based location platform 160 aggregates observations, including a cloud-based RTK GNSS position fix of the UE, for a given beacon. In step 660, cloud-based location platform 160 filters the observations based on a comparison of the GNSS position fix to a threshold of HPE. In step 670, cloud-based location platform 160 uses a trilateration algorithm to determine a beacon position, or more specifically, a physical antenna position of the beacon, based on the aggregated observations from UE 110. The trilateration algorithm may be a WLS multilateration algorithm with weights as described above, except that the HPE of the corrected GNSS position fix is ​​used instead of the HPE from UE 110. In step 680, cloud-based location platform 160 updates beacon database 170 to include the determined position of beacon 140, or more specifically, the determined physical antenna position of the beacon. The updated portion (e.g., a tile) of beacon database 170 may then be provided back to the UE.

[0040] Portions (e.g., tiles) of the updated beacon database 170 may be cached locally and used by the UE 110 to perform RTT-based positioning. A number of different RTT-based positioning algorithms may be used that base position determination solely on RTT measurements or that use RTT in combination with other information (e.g., RSS, AoA, etc.). In one embodiment, a hybrid RTT-based positioning algorithm is utilized that blends the WLS positioning algorithm and the extended Kalman filter positioning algorithm.

[0041] FIG. 7 is a flow diagram detailing example operations 700 performed by the positioning client 122 on the UE 110 to implement a hybrid RTT-based positioning algorithm to determine a UE position. In step 710, the positioning client 122 aggregates RTT measurements from RTT-enabled beacons within range of the UE 110 over a period of time (e.g., a one-second period). In step 720, the positioning client 122 determines a number of unique beacons 140 in the aggregate for which information (e.g., beacon positions) is available in a portion (e.g., a tile) of the beacon database 170 cached locally by the UE 110. In step 730, the positioning client 122 determines whether the number of unique beacons is greater than a threshold (e.g., one beacon). If the number of unique beacons is greater than the threshold, execution proceeds to step 740, where the UE position is determined by the WLS positioning algorithm. The weights used in the WLS positioning algorithm may be based on the number of RTT measurements, the confidence of the beacon's determined position (e.g., HPE), the RTT measurement uncertainty, and / or other factors. The WLS positioning uncertainty (e.g., WLS Position HPE) may be generated as part of step 740. In step 745, the positioning client 122 resets and initializes the Kalman filter state to be equal to the determined WLS position. Then, in step 750, the positioning client 122 reports the determined WLS position as the position of the UE 110 (e.g., to an application running on the UE).

[0042] If the number of unique beacons is not greater than the threshold, execution proceeds to step 760, where the UE location is determined by a Kalman filter positioning algorithm. If the Kalman filter state was already initialized to be equal to the WLS location determined as part of step 745, such initialization is used. Otherwise, the Kalman filter state may be initialized to the median beacon location of the unique beacons. In step 770, the positioning client 122 determines whether the Kalman filter positioning algorithm was successful, and if so, in step 750, the positioning client 122 reports the determined Kalman location as the location of the UE 110. If the Kalman filter positioning algorithm was not successful, in step 775, the positioning client 122 determines whether there was a previous Kalman location returned within a freshness interval (e.g., 2 seconds), and if so, in step 750, the positioning client 122 reports the previous Kalman location as the location of the UE 110 (e.g., to an application running on the UE). If the previous Kalman position was not returned within the freshness interval, then in step 780 the positioning client 122 determines whether there was a previous WLS position returned within the freshness interval. If so, in step 750 the positioning client 122 resets and initializes the Kalman filter state to be equal to the previous WLS position in step 790 and reports the previous WPS position as the position of the UE 110 in step 750. If there was not a previous WLS position returned within the freshness interval, then in step 795 the positioning client 122 does not report a position result to the UE 110.

[0043] It should be appreciated that in addition to basing position determination solely on RTT measurements, a positioning algorithm may use RTT in combination with other information (e.g., RSS, AoA, etc.) to determine position. In some cases, RTT measurements may be used to improve the accuracy of techniques that primarily utilize another form of beacon data (e.g., RSS). For example, a positioning algorithm may use multiple RSS measurements for beacons in a weighted trilateration to estimate a UE position. RTT measurements may be used to adjust the RSS measurements, filter potentially erroneous RSS measurements, adjust weights assigned to beacons in a weighted trilateration, and / or otherwise improve the accuracy of the RSS positioning.

[0044] The above description details various crowdsourcing techniques that enable RTT-based positioning of UE 110. It should be understood that the techniques and portions thereof may be utilized together, individually, or in combination with other techniques depending on the implementation. Furthermore, it should be understood that aspects of the techniques may be modified, added, removed, or in some cases changed depending on the implementation. Furthermore, while certain exemplary hardware and software are described above, it should be understood that the techniques may be implemented using a variety of different types of hardware, software, and combinations thereof. Such hardware may include various types of processors, memory chips, programmable logic circuits, application specific integrated circuits, and / or other types of hardware components that support the execution of software. Such software may include executable instructions that implement an application stored on a non-transitory electronic device readable medium, such as a volatile or persistent memory device, a hard disk, or other data store. Combinations of software and hardware may be configured to suit different environments and applications. It should be understood, among other things, that the above description is intended to be taken merely as an example. [Explanation of symbols]

[0045] 100 Exemplary Architectures 110UE 115 Central Processing Unit (CPU) 120 Storage 122 Positioning Client 125 Wireless Network Interface 130 GNSS receiver 140 Beacon 150 Internet 160 Cloud-Based Location Platform 170 Beacon Database 175 RTT database

Claims

1. A method for enabling round trip time (RTT) based positioning of a user equipment (UE), comprising: scanning, by a wireless network interface of a user equipment (UE), for beacons within range of the UE; accessing information from a beacon database maintained by a cloud-based location platform to determine whether an RTT capability is known for each beacon within range of the UE; sending range requests to one or more beacons having unknown RTT capabilities determined based on the accessed information to attempt to have the beacons measure RTT, and based thereon, assigning an RTT measurement status to the beacons indicative of the beacon's RTT capabilities, the RTT measurement status including the beacon's ability to perform RTT measurements; uploading at least the RTT measurement status to the cloud-based location platform for updating the beacon database; A method comprising:

2. 2. The method of claim 1, wherein the beacon is a Wi-Fi access point (AP) and the RTT capabilities include support for a fine timing measurement (FTM) protocol in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.11mc standard.

3. 2. The method of claim 1, wherein the beacon is a cellular base station, the RTT capabilities include support for 3rd Generation Partnership Project (3GPP) Release 16, and the RTT is multi-RTT.

4. The method of claim 1 , wherein the scanning step is performed in response to a current request for a determination of the UE's location.

5. The method of claim 1 , wherein the scanning step occurs as a background process independent of any current request for a determination of the UE's location.

6. downloading a local copy of a portion of the beacon database covering a geographic area that includes a current location of the UE, the beacon database identifying beacons as RTT-capable, RTT-incapable, or having unknown RTT capabilities; Further comprising: The method of claim 1 , wherein the accessing step further comprises checking each beacon within range of the UE against the local copy.

7. 6. The method of claim 5, further comprising adding each beacon within range of the UE that is RTT capable or has unknown RTT capability to a range list, and wherein the sending step sends a range request to attempt to measure RTT at each beacon on the range list.

8. A method for enabling round trip time (RTT) based positioning of a user equipment (UE), comprising: providing, by a cloud-based location platform, to a plurality of user equipments (UEs) information regarding RTT capabilities of beacons from a beacon database, where at least one of the beacons has an initially unknown RTT capability; receiving, by the cloud-based location platform, RTT information including at least an RTT measurement status from one or more of the plurality of UEs that initially attempted to measure RTT on a beacon of the beacons having unknown RTT capabilities, the RTT measurement status including a beacon's capability to perform RTT measurements; determining the RTT capability of the beacon based on the received RTT measurement status; updating the beacon database to include information indicative of the RTT capabilities of the beacons; A method comprising:

9. 9. The method of claim 8, wherein the beacon is a Wi-Fi access point (AP) and the RTT capabilities include support for a Fine Timing Measurement (FTM) protocol in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.11mc standard.

10. 9. The method of claim 8, wherein the beacon is a cellular base station, the RTT capabilities include support for 3rd Generation Partnership Project (3GPP) Release 16, and the RTT is multi-RTT.

11. The determining step further comprises: deeming the beacon RTT-capable if the RTT measurement status from at least one of the one or more UEs indicates that the UE was able to have the beacon measure RTT, deeming the beacon RTT-incapable if the RTT measurement status from all of the one or more UEs indicates that the UE was not able to have the beacon measure RTT, and deeming the beacon to have unknown RTT capability if the RTT measurement status from at least one of the one or more UEs indicates that the UE was out of range to measure RTT and the RTT measurement status from all others of the one or more UEs indicates that the UE was not able to have the beacon measure RTT.

9. The method of claim 8, comprising:

12. estimating an RTT bias for the beacon measuring an expected error in an RTT measurement by the beacon as a function of the RTT capability of the beacon indicating that the beacon is RTT-capable. Further comprising: The method of claim 8 , wherein the updating step comprises adding information indicative of the RTT bias for the beacon to the beacon database.

13. The estimating step comprises: calculating a delta for a distance between the UE and the beacon calculated based on an RTT and a distance between the UE and the beacon calculated based on a determined location of the UE and an estimated location of the beacon, and determining the RTT bias of the beacon based on the delta.

13. The method of claim 12, comprising:

14. The estimating step comprises: determining one or more other beacons that share a common organizational identifier with the beacon; determining the RTT bias of the beacon based on the RTT biases of the one or more other beacons; 13. The method of claim 12, comprising:

15. determining whether a distance between the UE and the beacon calculated based on RTT is consistent with a determined location of the UE, in response to the RTT capability of the beacon indicating that the beacon is RTT-capable, and updating the RTT capability if the distance is not consistent.

9. The method of claim 8, further comprising:

Images