Crowd-sourced rtt-based positioning

Abstract

In various embodiments, crowd-sourcing 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-based measurements (e.g., according to IEEE 802.11mc, 3GPP Release 16, etc.), beacon RTT capability can be crowd-sourced from UEs and maintained by a cloud-based location platform in a beacon database (or more specifically, its RTT database portion). To address the problem of determining physical antenna locations, RTT measurements can be crowd-sourced from UEs for those beacons that are RTT-capable and used by trilateration algorithms (e.g., WLS multilateration algorithms) to determine physical antenna locations, which can also be maintained in the beacon database. The accuracy of the trilateration can be enhanced by obtaining raw GNSS measurements (e.g., pseudoranges) from UEs and performing cloud-based RTK GNSS position fixes for the UEs.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to user equipment (UE) positioning, and more specifically, to crowd sourcing techniques that enable round-trip time (RTT)-based positioning of UEs. BACKGROUND

[0002] Determining UE location becomes increasingly important for tracking users, managing profiles, providing location-based services, and other tasks. Various techniques for determining UE location involve receiving signal strength (RSS) measurements. For example, trilateration of RSS measurements of signals received at a UE from multiple beacons (e.g., Wi-Fi access points (APs), cellular base stations, Bluetooth Low Energy (BLE) transmitters, etc.) can be performed, however, RSS-based techniques can struggle to determine high-precision UE locations.

[0003] By utilizing RTT measurements in the determination of UE location, improved precision is possible. Generally, RTT is the time that elapses between the transmission of an initiation signal and the reception of a corresponding response signal. The time of flight (ToF) can be obtained by subtracting the turnaround time from the RTT and dividing the result by two. From the ToF, the distance (range) between the UE and a beacon can be readily determined. Based on the distances to multiple beacons, the location of the UE can be determined, e.g., via 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, and protocols introduced in the 3rd Generation Partnership Project (3GPP) Release 16 Technical Specification (TS) series 37 and 38, enable highly precise measurement of RTT. With a Wi-Fi AP that supports the FTM protocol, the RTT can be measured from the timestamps captured at the departure and arrival of FTM frames, and their respective acknowledgements. For a cellular base station that supports 3GPP Release 16, a particular sub-type called multi-RTT can be measured.

[0005] A UE can 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. Wi-Fi APs periodically broadcast frames with advertisement frames to announce their RTT capabilities to UEs. UEs establish a peer-to-peer link to a Wi-Fi AP with a range request and use the peer-to-peer link to attempt to cause the Wi-Fi AP to measure RTT, sending a request frame and waiting to receive a burst of response frames to which the UE responds with an acknowledgement. An extended capabilities element (e.g., included in an advertisement frame or an initial response frame) can provide information about scheduling and operating details of an FTM session, such as burst duration, FTM frames per burst, bandwidth, minimum time between consecutive FTM frames, etc., with an advertisement frame or a range request. Likewise, 3GPP Release 16 provides its own mechanisms to discover which cellular base stations support RTT.

[0006] While the use of RTT can improve the accuracy of UE position determination, many obstacles have hindered the widespread deployment of RTT-based positioning. First, determining which beacons support RTT measurement is often error-prone and operationally expensive (in terms of time, processor cycles, memory space, network bandwidth, and power). Some beacons can simply lack the functionality to support RTT measurement (e.g., they only support older protocols and standards). Other beacons can include the functionality (e.g., their chipsets support the applicable protocols and standards), but they do not announce their RTT capabilities for various reasons. For example, currently only a small fraction of deployed Wi-Fi APs support the IEEE 802.11mc standard and the FTM protocol with the FTM protocol. In that fraction, some Wi-Fi APs do not announce their capability to support the FTM protocol. A UE interested in learning which Wi-Fi APs support the FTM protocol typically has two suboptimal options: they can rely on the announcements and thereby miss Wi-Fi APs that do not announce their capabilities, or they can establish a peer-to-peer link and send a request frame to every nearby Wi-Fi AP and thereby consume a large amount of time, processor cycles, memory space, network bandwidth, and power. In dense urban areas, there can be tens or even hundreds of nearby Wi-Fi APs, making it simply too operationally expensive for every UE to establish a peer-to-peer link and send a request frame to every nearby Wi-Fi AP.

[0007] Second, it can be difficult to determine physical antenna locations to the level of precision that can fully realize the benefits of RTT-based positioning. RTT-based positioning typically requires highly precise physical antenna locations (e.g., within 1 meter) to realize its full benefits. One way to obtain such physical antenna locations is through dedicated measurement. For example, a Wi-Fi measurement system or vehicle that includes high-precision hardware can drive through a site and map the physical antenna locations of Wi-Fi Aps. While the physical antenna locations determined through such a method can be precise, it is extremely time-consuming and expensive. An alternative approach is to approximate the physical antenna locations based on the coverage areas of the beacons, which can already be known from other positioning techniques. For example, the physical antenna locations of Wi-Fi Aps can be approximated as the centroids of the coverage of the Wi-Fi Aps. However, such an approach is typically not very precise. The centroid of the coverage often deviates from the physical antenna locations due to signal propagation biases, observation biases, and other factors.

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

[0009] In various embodiments, crowd-sourcing 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, BEE transmitters, etc.) support RTT-based measurements (e.g., according to IEEE 802.11mc, 3GPP Release 16, etc.), beacon RTT capabilities can be crowd-sourced from UEs and maintained by a cloud-based location platform in a beacon database (or more specifically, its RTT database portion). To address the problem of determining physical antenna locations, RTT measurements can be crowd-sourced from UEs for those beacons that are RTT-capable and used by trilateration algorithms (e.g., weighted least squares (WLS) multilateration algorithms) to determine physical antenna locations, which can also be maintained in the beacon database. The accuracy of the trilateration can be enhanced by obtaining raw global navigation satellite system (GNSS) measurements (e.g., pseudoranges) from UEs and performing cloud-based real-time kinematic (RTK) GNSS position fixes for the UEs.

[0010] In one embodiment, a positioning client on a UE is used to crowdsource beacon RTT capability. 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 positioning platform to determine whether RTT capability is known for each beacon within range. For one or more beacons that have unknown RTT capability, the UE sends a range request to attempt to have the beacon measure RTT, and based on this, assigns the beacon an RTT measurement status that indicates the beacon's RTT capability. The UE then uploads at least the RTT measurement status to the cloud-based location platform to update the beacon database. In such embodiments, the UE both consumes information from the beacon database about the RTT capability of beacons, and contributes information about the RTT capability of beacons to the beacon database.

[0011] In another embodiment, a cloud-based positioning platform is used to crowdsource beacon RTT capability. The cloud-based positioning platform provides information from a beacon database about the RTT capability of beacons to a plurality of UEs. At least one beacon initially has unknown RTT capability. The cloud-based positioning platform later receives RTT information including at least an RTT measurement status from one or more of the plurality of UEs that have attempted to measure RTT with the beacon that initially had unknown RTT capability. Based on the received RTT measurement status, the RTT capability of the beacon is determined, and the beacon database is updated to include information indicating the RTT capability of the beacon. In such embodiments, the operations allow UEs to both consume information from the beacon database about the RTT capability of beacons, and contribute information about the RTT capability of beacons to the beacon database.

[0012] In yet another embodiment, a cloud-based positioning platform determines a beacon location, or more specifically, a beacon physical antenna location, based on crowd-sourced data. The cloud-based positioning platform receives observations from a plurality of UEs that have observed a beacon, the observations including at least a determined location of the UE and an RTT measurement by the UE of the beacon. The cloud-based positioning platform uses a trilateration algorithm to determine a physical antenna location of the beacon based on the determined locations and the RTT measurements for each of the plurality of UEs. The cloud-based positioning 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 embodiments, the operations both allow UEs to contribute information used to determine the physical antenna location of the beacon to build the beacon database, and consume the physical antenna location of the beacon from the beacon database.

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

[0014] It should be appreciated that the embodiments discussed in the SUMMARY can include various other features, including other features discussed below and variations thereof. In addition, various other embodiments can be utilized, including various combinations of the features discussed herein and below and variations thereof. The SUMMARY is intended only as an overview of the reader and is not intended to suggest that the particular features mentioned therein are all or the only features of the present application. BRIEF DESCRIPTION OF DRAWINGS

[0015] The following description refers to the accompanying drawings, in which:

[0016] Figure 1 is a block diagram of an example architecture in which techniques for enabling RTT-based positioning of UEs can be deployed;

[0017] Figure 2 is a flow diagram detailing example operations for crowdsourcing beacon RTT capabilities performed under the direction of a positioning client on a UE;

[0018] Figure 3 is a flow diagram detailing example operations for crowdsourcing beacon RTT capabilities performed by a cloud-based location platform;

[0019] Figure 4 is a flow diagram detailing example operations performed by a cloud-based positioning platform for determining a beacon location, or more specifically, a beacon physical antenna location, using RTT measurements crowdsourced from UEs;

[0020] Figure 5 is a diagram illustrating an example arrangement of a UE that illustrates HPEs and their use as indicia of accuracy of location determinations;

[0021] Figure 6is a flowchart detailing example operations performed by a cloud-based positioning platform in an“off-board” implementation for determining beacon locations, or more specifically, beacon physical antenna locations, using cloud-based RTK GNSS position fixes; and

[0022] Figure 7 is a flowchart detailing example operations performed by a positioning client on a UE for implementing a hybrid RTT-based positioning algorithm to determine a UE location. DETAILED DESCRIPTION

[0023] Figure 1 is a block diagram of an example architecture 100 in which techniques for enabling RTT-based positioning of UEs can be deployed. As used herein, the term“user equipment” or“UE” refers to a mobile device operated by an end user, a machine-to-machine (M2M) device, or an Internet of Things (IoT) device. Examples of UEs 110 include smartphones, smartwatches, computers, cameras, and sensors operated by end users, among others. Likewise, as used herein, the term“beacon” refers to a device having a fixed location that exchanges signals that can be used to determine a location of a UE. Examples of beacons 140 include Wi-Fi APs, cellular base stations, BLE transmitters, and other devices. Further, as used herein, the term“RTT capable” refers to a beacon’s ability to measure RTT (or a sub-type thereof, such as multi-RTT) and provide the measured RTT to other devices. RTT capability can be according to the FTM protocol of the IEEE 802.11mc standard, 3GPP Release 16 TS series 37 and 38, or other protocols and standards. Further, as used herein, the term“RTT measurement state” refers to a beacon’s ability to perform a particular measurement RTT measurement. RTT measurement state can be according to the FTM protocol of the IEEE 802.11mc standard, 3GPP Release 16 TS series 37 and 38, or other protocols and standards.

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

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

[0026] The UE 110 can communicate with the Internet 150 and a cloud-based positioning platform 160 via Wi-Fi or cellular data communication paths. Among other functions, the positioning platform 160 typically also maintains a beacon database 170. A portion of the beacon database 170 can be designated as an RTT database 175 and relates identifiers of beacons (e.g., media access control (MAC) addresses, cellular cell identifiers (IDs), etc.) to various RTT-related information, such as RTT capability of the beacons (e.g., RTT-capable, non-RTT-capable, or with unknown RTT capability), RTT bias, beacon physical antenna locations, location uncertainty, etc. Portions (e.g., tiles) of the beacon database (including the RTT database 175) covering particular geographic areas can be downloaded by the positioning client 122 to the UE 110 for use as a local copy. Furthermore, information derived from scans performed by the UE 110 (e.g., determined locations of the UE, beacon identifications, RTT measurement status, RTT measurements, etc.) can be periodically uploaded to the cloud-based location platform 160, which uses this information to update the beacon database 170 (including the RTT database 175).

[0027] Figure 2is a flowchart detailing example operations 200 for crowdsourcing beacon RTT capability performed at the direction of the positioning client 122 on the UE 110. At 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 can be a proactive scan (e.g., in response to a current request to compute a UE position for an application executing on the UE 110) or a background scan (e.g., a background operation in the absence of any current request to determine a UE position). At step 215, for implementations that utilize a local copy of a portion (e.g., a tile) of the beacon database 170 covering a geographic region, 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 region that includes the current location of the UE 110. If not, at step 220, it downloads a local copy (e.g., a tile) from the cloud-based location platform 160. This can occur each time the UE is in a new geographic region or when a previously downloaded local copy (e.g., a tile) has aged. It will be appreciated that some implementations can not use local copies (e.g., tiles), and in such cases, steps 215-220 can be omitted.

[0028] At step 225, the positioning client 122 loops through each beacon 140 within range of the UE 110 and, at step 230, checks to determine whether the RTT capability is known. In embodiments that use a local copy (e.g., a tile), this can involve checking the identity of the beacon in the local copy (e.g., a tile). Alternatively, this can involve querying the cloud-based location platform 160. The RTT capability can have multiple states, including having RTT capability (i.e., a state indicating that some other UE has been able to cause the beacon to measure RTT in the past), not having RTT capability (i.e., a state indicating that other UEs have attempted to cause the beacon to measure RTT in the past but have not been able to cause the beacon to measure RTT), or having unknown RTT capability (i.e., a state indicating that no UE has attempted to measure RTT in the past). At step 235, for each beacon 140 within range of the UE 110 that is indicated as having RTT capability 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.)) designated for receiving range requests.

[0029] At step 240, the positioning client 122 loops through each beacon 140 on the range list and, at step 245, causes the wireless network interface 125 to 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) to attempt to cause the beacon 140 to measure RTT therewith. At step 250, the positioning client 122 assigns an RTT measurement status to the beacon 140 indicating the RTT capability of the beacon. The assigned RTT measurement status can indicate that the beacon is RTT capable (i.e., the beacon is capable of measuring and returning RTT), not RTT capable (i.e., the beacon is not capable of measuring and returning RTT), or RTT out of range (i.e., the beacon is not capable of measuring RTT, but the beacon returns an out of range indication such that the beacon can be capable of measuring and returning RTT with a smaller range).

[0030] At step 255, the positioning client 122 determines a location of the UE 110. The determination can be based on GNSS such that the determined location is a GNSS position fix. Alternatively or additionally, the determination can utilize RTT-based positioning. Such RTT-based positioning can utilize a hybrid positioning algorithm that combines an RTT-based WLS positioning algorithm and an extended Kalman positioning algorithm, as discussed in more detail below. A position confidence (e.g., a horizontal position error (HPE)) can be computed for the determined location of the UE 110.

[0031] In implementations that utilize a cache, at step 260, the positioning client 122 adds the RTT information for beacons within range to a local cache of the positioning client 122 on the UE 110. The RTT information can include the determined location of the UE (and in some cases, a location confidence), as well as, for each beacon, an identifier of the beacon (e.g., a MAC address, a cell ID, etc.), an RTT measurement status (e.g., RTT capable, not RTT capable, or RTT out of range), and an RTT measurement if available. At step 265, the positioning client 122 determines whether a cache upload trigger has been reached. The trigger can be the local cache becoming full, a certain amount of time expiring, or some other criteria being met periodically. If the trigger has been reached, at 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 to the beacon database 170 (or more specifically, its RTT database 175). It should be appreciated that some implementations can not use a cache, and in such cases, steps 260-265 can be omitted and the upload of step 270 can begin immediately when there is new RTT information for a beacon. Finally, at optional step 275, the positioning client 122 reports the determined location of the UE to other application software (e.g., if the original scan was a passive scan).

[0032] Figure 3 is a flowchart detailing example operations 300 performed by the cloud-based location platform 160 for crowdsourcing beacon RTT capabilities. The operations can aggregate information discovered by a large number of UEs 110 to build the beacon database 170 (and its RTT database 175). At step 310, the cloud-based location platform 160 batch processes RTT information received from UEs 110. As described above, the RTT information can include the determined location of the UE, as well as, for each beacon 140 within range of the EU, an identifier of the beacon (e.g., a MAC address, a cell ID, etc.), an RTT measurement status (e.g., RTT capable, not RTT capable, or RTT out of range), and an RTT measurement if available.

[0033] At step 320, in implementations that batch updates, the cloud-based location platform 160 determines that a batch processing period has been reached. The batch processing period can be a time period (e.g., once a month) or a non-time based trigger at which the RTT capabilities of the beacons 140 in the beacon database 170 are updated. It should be appreciated that some implementations can not use batch processing, in which case step 320 can be omitted and the operations begin in real-time.

[0034] At step 330, the cloud-based positioning platform 160 loops through each beacon 140 in the batch, iterating the identifier (e.g., MAC address, cell ID, etc.) and checking the aggregation of RTT information for the beacon. At step 340, the cloud-based positioning 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 the beacon 140 is RTT capable, it can be marked as RTT capable. If the RTT measurement status from all UEs 110 indicates that the beacon 140 is not RTT capable, it can be marked as not RTT capable. If the RTT measurement status from at least one UE 110 indicates that the beacon is RTT out of range (but no UE 110 RTT measurement status indicates that the UE is RTT capable), the beacon 140 can be marked as having unknown RTT capability.

[0035] At step 350, the cloud-based positioning platform 160 determines whether the RTT capability of the beacon 140 indicates that it is RTT capable. If not, a loop is performed to check the next beacon. If so, execution proceeds to step 360, where the cloud-based positioning platform 160 estimates the RTT bias of the beacon 140, which measures the expected offset / error in the RTT measurements by the beacon. The RTT bias can be estimated using various techniques. For example, the delta between the RTT-determined distance between the UE 110 and the beacon 140 and the location fix-determined distance between the UE and the beacon can be computed. If this delta is substantially the same across multiple (e.g., all) UEs 110 that have observed the beacon 140, then this delta can be used as the RTT bias for the beacon. Further, the cloud-based positioning platform 160 can determine other beacons 140 that share a common organizational identifier (e.g., an organizational unique identifier (OUI)) with the beacon. If multiple of these other beacons share substantially the same RTT bias, then this RTT bias can be assumed for the current beacon. This can allow the RTT bias to be estimated in cases where delta computation is not possible.

[0036] At step 370, the cloud-based positioning platform 160 determines whether the RTT- based computed distance (range) between the UE 110 and the beacon 140 is reasonable. For example, it can be determined whether the distance is consistent with the distance between the location of the UE 110 using other techniques (e.g., GNSS location fix) and the beacon location in the beacon database 170. If the RTT-based distance is not reasonable, the RTT capability of the beacon 140 is updated (e.g., the beacon is marked as not RTT capable).

[0037] At step 380, the cloud-based positioning platform 160 determines the physical antenna location of the beacons 140. This determination uses a trilateration algorithm (e.g., a WLS multilateration algorithm) of the RTT measurements from multiple UEs. Details of example operations to determine the physical antenna location are discussed below.

[0038] When the loop through each of the beacons completes execution, at 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. Thereafter, in implementations that utilize local replicas (e.g., shards), portions of the updated beacon database 170 can be provided back to the UEs 110 to inform them of the RTT capabilities of the beacons, so they can perform RTT-based positioning.

[0039] Figure 4 is a flowchart detailing example operations 400 performed by the cloud-based positioning platform 160 to determine beacon locations, or more specifically, beacon physical antenna locations, using crowd-sourced RTT measurements from the UEs 110. At step 410, the cloud-based positioning platform 160 receives observations of RTT-capable beacons 140 from the UEs 110. The observations can include the determined location of the UE (e.g., a GNSS position fix) and the location confidence of the determined location (e.g., the HPE of the GNSS position fix), the identifier of the beacon (e.g., a MAC address, a cell ID, etc.), and RTT information. The RTT information can include the RTT measurement, the RTT measurement uncertainty, the signal strength associated with the RTT measurement, the bandwidth associated with the RTT measurement, and other RTT-related data. At step 420, the cloud-based positioning platform 160 aggregates the observations for a given beacon 140. At step 430, the cloud-based positioning platform 160 filters the observations based on a comparison of the location confidence of the determined location of the UE (e.g., the HPE of the GNSS position fix) to a threshold. Preferably, the threshold is set to remove only observations with very poor location confidence (e.g., observations with very large HPE). Moderately confident observations can be addressed by weighting in subsequent operations.

[0040] At step 440, the cloud-based positioning platform determines the beacon locations, or more specifically, the beacon physical antenna locations, based on the aggregated observations from the UEs 110 using a trilateration algorithm. The trilateration algorithm can be a WLS multilateration algorithm, where the weights are a function of the confidence of the determined location of the UE (e.g., GNSS position fix HPE), RTT measurement uncertainty, RTT determined range (e.g., where measurements from longer ranges are considered less reliable), signal strength associated with the RTT measurements, number of RTT measurements, and bandwidth associated with the RTT measurements (e.g., where higher bandwidth is considered to have lower error). In some cases, the WLS multilateration algorithm can also consider other information (e.g., RSS, angle of arrival (AoA), etc.) applying weights to them based on uncertainty (e.g., higher weight to RSS measurements as RSS can have higher uncertainty than RTT). At step 450, the cloud-based positioning platform updates the beacon database to include the determined locations of the beacons 140, or more specifically, the determined physical antenna locations of the beacons. Thereafter, the updated portion (e.g., slice) of the beacon database 170 can be provided back to the UEs 110 so that the determined physical antenna locations of the beacons can be used for RTT-based positioning of the UEs.

[0041] The accuracy of trilateration can generally be improved by using the determined locations of UEs with very good location confidence. In the case of GNSS position fixes, very good location confidence can be measured as very low HPE. Figure 5 is a diagram of an example arrangement 500 of UEs 110 illustrating HPE and its use as an indicator of accuracy of location determination. The locations of beacons 510 can be determined by trilateration using GNSS position fixes of UEs 520-540, where each GNSS position fix has an HPE represented by a circle with a given radius. In particular, the HPE of UE 540 is somewhat large, indicating low confidence at that location. The location of UE 540 can be very inaccurate, which can impact the accuracy of the trilateration. If the accuracy of the location of UE 540 can be improved, then the accuracy of the trilateration can also be improved.

[0042] One technique for improving the accuracy of the position determination of the UEs 110 involves RTK correction services. In the traditional implementation of RTK correction, the "onboard" implementation, the GNSS receiver 130 in the UE 110 is RTK capable and interacts with a separate network of RTK base stations that provide real-time corrections applied at the UE. However, RTK capable GNSS receivers are generally quite expensive and are not typically deployed in low-cost UEs (e.g., smartphones, smartwatches, etc.). Thus, many UEs 110 cannot obtain the benefits of RTK correction if the operation is limited to "onboard."

[0043] This limitation can be addressed by a "non-onboard" implementation in which raw GNSS measurements (e.g., pseudoranges) from the UEs 110 are provided to a cloud-based positioning platform 160 that performs RTK GNSS position fixes. Figure 6 is a flowchart detailing example operations 600 performed by the cloud-based positioning platform 160 in the "non-onboard" implementation for determining beacon locations, or more specifically, beacon physical antenna locations, using cloud-based RTK GNSS position fixes. At step 610, the cloud-based positioning platform 160 receives observations of RTT-capable beacons from the UEs 110. The observations can include one or more sets of raw GNSS measurements (e.g., pseudoranges) from the GNSS receivers 130 of the UEs 110, identifiers of the beacons (e.g., MAC addresses, cell IDs, etc.), and RTT information. The RTT information can include RTT measurements, RTT measurement uncertainties, signal strengths associated with the RTT measurements, bandwidths associated with the RTT measurements, and other RTT-related data. At step 620, the cloud-based positioning platform 160 connects to an RTK correction service via the Internet 150 and obtains RTK correction information. At step 630, for each set of raw GNSS measurements, the cloud-based positioning platform 160 determines a corrected GNSS position fix for the UE 110 using the raw GNSS measurements and the RTK correction information. At step 640, the cloud-based positioning platform 160 determines the HPE of the resulting corrected GNSS position fix for each of the UEs 110. The corrected GNSS position fix generally has a much lower HPE than the GNSS position fix produced by the UE itself.

[0044] At step 650, the cloud-based positioning platform 160 aggregates the observations for the given beacon, including the cloud-based RTK GNSS position fixes of the UEs. At step 660, the cloud-based positioning platform 160 filters the observations based on a comparison of the HPEs of the GNSS position fixes to a threshold. At step 670, the cloud-based positioning platform 160 determines the beacon location, or more specifically the beacon physical antenna location, based on the aggregated observations from the UEs 110 using a trilateration algorithm. The trilateration algorithm can be a WLS multilateration algorithm with weights as described above, except using the corrected HPEs of the GNSS position fixes instead of the HPEs from the UEs 110. At step 680, the cloud-based positioning platform 160 updates the beacon database 170 to include the determined location of the beacon 140, or more specifically the determined physical antenna location of the beacon. Thereafter, portions (e.g., tiles) of the updated beacon database 170 can be provided back to the UEs.

[0045] Portions (e.g., tiles) of the updated beacon database 170 can be cached locally and used by the UEs 110 to perform RTT-based positioning. Many different RTT-based positioning algorithms can be used, which base the position determination on RTT measurements alone, or use RTT in combination with other information (e.g., RSS, AoA, etc.). In one embodiment, a hybrid RTT-based positioning algorithm is utilized that mixes a WLS positioning algorithm and an extended Kalman filter positioning algorithm.

[0046] Figure 7is a flowchart detailing example operations 700 performed by the positioning client 122 on the UE 110 for implementing a hybrid RTT-based positioning algorithm to determine a UE position. At step 710, the positioning client 122 aggregates RTT measurements by RTT-capable beacons within range of the UE 110 over a time period (e.g., a one second period). At step 720, the positioning client 122 determines a number of unique beacons 140 in the aggregation for which information (e.g., beacon position) is available in a portion (e.g., a tile) of a beacon database 170 cached locally by the UE 110. At 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 in which a UE position is determined by a WLS positioning algorithm. The weights used in the WLS positioning algorithm can be based on the number of RTT measurements, the confidence in the determined position of the beacons (e.g., HPE), RTT measurement uncertainty, and / or other factors. A WLS position uncertainty (e.g., WLS position HPE) can also be produced as part of step 740. At step 745, the positioning client 122 resets and initializes the Kalman filter state to equal the determined WLS position. Then, at step 750, the positioning client 122 reports the determined WLS position as the position of the UE 110 (e.g., to an application executing on the UE).

[0047] If the number of unique beacons is not greater than the threshold, execution proceeds to step 760, where the UE position is determined by a Kalman filter positioning algorithm. If the Kalman filter state was previously initialized to equal the determined WLS position as part of step 745, such initialization is used. If not, the Kalman filter state can be initialized to the median beacon position of the unique beacons. At step 770, the positioning client 122 determines whether the Kalman filter positioning algorithm was successful, and if so, at step 750, the positioning client 122 reports the determined Kalman position as the position of the UE 110. If the Kalman filter positioning algorithm was not successful, at step 775, the positioning client 122 determines whether there is a previous Kalman position returned within a refresh interval (e.g., 2 seconds), and if so, at step 750, the positioning client 122 reports the previous Kalman position as the position of the UE 110 (e.g., to an application executing on the UE). If there is no previous Kalman position returned within the refresh interval, at step 780, the positioning client 122 determines whether there is a previous WLS position returned within the refresh interval. If so, at step 750, the positioning client 122 resets and initializes the Kalman filter state to equal the previous WLS position at step 790, reports the previous WPS position as the position of the UE 110, and at step 750. If there is no previous WLS position returned within the refresh interval, at step 795, the positioning client 122 reports that there is no position result for the UE 110.

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

[0049] The above description details various crowdsourcing techniques for enabling RTT-based positioning of UEs 110. It will be appreciated that these techniques, and portions thereof, can be utilized together, individually, or in combination with other techniques, depending upon the implementation. Further, it will be appreciated that aspects of the techniques can be modified, added, removed, or otherwise changed according to implementa- tion. Further, while specific example hardware and software are discussed above, it will be appreciated that various different types of hardware, software, and combinations thereof can be used to implement the techniques. Such hardware can include various types of processors, memory chips, programmable logic circuits, application specific integrated circuits, and / or other types of hardware components that support software execution. Such software can include executable instructions that implement applications stored in non-transitory electronic device readable media, such as volatile or persistent memory devices, hard disks, or other data storage. Combinations of software and hardware can be adapted to suit different environments and applications. It will be appreciated that the above description is merely meant to be an example.

Claims

1. A method for enabling round-trip-time, RTT, based positioning performed by a user equipment, UE, comprising: scanning for beacons within range of the UE; accessing information from a beacon database maintained by a cloud-based location platform to determine whether RTT capability is known for each beacon within range of the UE; for at least one beacon for which RTT capability is unknown, sending a range request that attempts to cause the at least one beacon to measure RTT, and based on the range request, assigning to the at least one beacon an RTT measurement status that indicates RTT capability of the at least one beacon; and uploading at least the RTT measurement status to the cloud-based location platform to update the beacon database. the beacons are Wi-Fi access points, APs, and the RTT capability comprises support for a fine timing measurement, FTM, protocol according to an Institute of Electrical and Electronics Engineers, IEEE, 802.11mc standard.

2. The method of claim 1, wherein, the beacons are cellular base stations, the RTT capability comprises support for 3rd Generation Partnership Project, 3GPP, Release 16, and the RTT is multi-RTT.

3. The method of claim 1, wherein, the scanning is performed in response to a current request to determine a location of the UE.

4. The method of claim 1, wherein, the scanning is performed as a background process independent of any current request to determine a location of the UE.

5. The method of claim 1, wherein, 6. The method of claim 1, further comprising: downloading a local copy of a portion of the beacon database that covers a geographic area including a current location of the UE, the beacon database identifying beacons as RTT capable, not RTT capable, or having unknown RTT capability, and wherein the accessing further comprises checking against the local copy for each beacon within range of the UE.

7. 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 the sending comprises sending range requests that attempt to utilize each beacon on the range list to measure RTT. wherein 8. The method of claim 1, further comprising: determining a location of the UE using RTT based positioning.

9. The method of claim 1, further comprising: adding the RTT measurement status to a local cache, and wherein the uploading further comprises periodically sending contents of the local cache to the cloud-based location platform for inclusion in updates to a beacon database.

10. A method for enabling round-trip-time, RTT, based positioning, comprising: providing, by a cloud-based location platform, information from a beacon database regarding RTT capability of beacons to a plurality of user equipment, UEs, at least one of the beacons initially having unknown RTT capability; receiving, by the cloud-based location platform, from one or more of the UEs, RTT information including at least an RTT measurement status, the one or more UEs having attempted to utilize the at least one beacon initially having unknown RTT capability to measure RTT; determining RTT capability of the beacon based on the received RTT measurement status; ​ and updating the beacon database to include information indicating RTT capability of the at least one beacon.

11. The method of claim 10, wherein, the beacons are Wi-Fi access points, APs, and the RTT capability includes support for a Fine Timing Measurement, FTM, protocol according to an Institute of Electrical and Electronics Engineers, IEEE, 802.11mc standard.

12. The method of claim 10, wherein, the beacons are cellular base stations, the RTT capability includes support for 3rd Generation Partnership Project, 3GPP, Release 16, and the RTT is multi-RTT.

13. The method of claim 10, wherein, the determining includes: flagging the at least one beacon as RTT capable if a measurement status from at least one of the one or more UEs indicates that the UE has been able to cause the at least one beacon to measure RTT, flagging the at least one beacon as not RTT capable if a RTT measurement status from all of the one or more UEs indicates that the UEs have not been able to cause the at least one beacon to measure RTT, and flagging the at least one beacon as having unknown RTT capability if a RTT measurement status from at least one of the one or more UEs indicates that the UE is outside a range of measuring RTT and a RTT measurement status from all other of the one or more UEs indicates that the UEs have not been able to cause the at least one beacon to measure RTT.

14. The method of claim 10, further comprising: in response to the RTT capability of the at least one beacon indicating that the at least one beacon is RTT capable, estimating a RTT bias of the at least one beacon, the RTT bias measuring an expected error in a RTT measurement by the at least one beacon, and wherein the updating includes adding information to the beacon database indicating the RTT bias of the at least one beacon.

15. The method of claim 14, wherein, the estimating includes: computing an increment of distance between the UE and the at least one beacon based on RTT computation and distance between the UE and the at least one beacon based on the determined location of the UE and an estimated location of the at least one beacon, and determining the RTT bias of the at least one beacon based on the increment.

16. The method of claim 14, wherein, the estimating includes: determining one or more other beacons that share a common organizational identifier with the at least one beacon; and determining the RTT bias of the at least one beacon based on a RTT bias of the one or more other beacons.

17. The method of claim 10, further comprising: in response to the RTT capability of the at least one beacon indicating that the at least one beacon is RTT capable, determining whether a distance between a UE and the at least one beacon based on RTT computation is consistent with a determined location of the UE, and updating the RTT capability if the distance is not consistent.

18. The method of claim 10, further comprising: determining a physical antenna location of the at least one beacon by using a trilateration algorithm from RTT measurements from the plurality of UEs, and wherein the updating includes adding the physical antenna location of the at least one beacon to the beacon database.

19. The method of claim 10, wherein, The determining RTT capability and updating the beacon database are performed periodically according to a batch processing period.

20. A method for enabling round trip time (RTT)-based positioning, comprising: receiving, by a cloud-based location platform that maintains a beacon database, observations from a plurality of user equipment (UEs) that have observed a beacon, the observations including at least a determined location of the UE and an RTT measurement by the beacon of the UE; determining, by the cloud-based location platform, a physical antenna location of the beacon based on the determined location of each of the plurality of UEs and the RTT measurement using a trilateration algorithm; updating the beacon database to include the determined physical antenna location of the beacon; and providing, by the cloud-based location platform, the physical antenna location of the beacon to one or more of the plurality of UEs. The beacon is a Wi-Fi access point (AP) and the RTT capability includes support for a fine timing measurement (FTM) protocol according to an Institute of Electrical and Electronics Engineers (IEEE) 802.11mc standard.

21. The method of claim 20, wherein, The beacon is a cellular base station, the RTT capability includes support for 3rd Generation Partnership Project (3GPP) Release 16, and the RTT is multi-RTT.

22. The method of claim 20, wherein, The determined location of the UE includes a location confidence of the determined location, and the method further comprises:

23. The method of claim 20, wherein, filtering observations based on a comparison of the location confidence of the determined location of the UE to a threshold. The determining by the trilateration algorithm is further based on the location confidence of the determined location.

24. The method of claim 23, wherein, The RTT information from the plurality of UEs includes an RTT measurement uncertainty, a signal strength associated with the RTT measurement, and a bandwidth associated with the RTT measurement, and the determining by the trilateration algorithm is further based on the RTT measurement uncertainty, the signal strength of the plurality of UEs, and the bandwidth.

25. The method of claim 20, wherein, The trilateration algorithm is a weighted least squares (WLS) multilateration algorithm.

26. The method of claim 20, wherein, The information describing the location of the UE includes raw global navigation satellite system (GNSS) measurements for the UE, and the method further comprises:

27. The method of claim 20, wherein, obtaining, by the cloud-based location platform, RTK correction information for the raw GNSS measurements for each UE from a real-time kinematic (RTK) correction service; and determining, by the cloud-based location platform, a corrected GNSS position fix for each UE using the raw GNSS measurements and the RTK correction information, wherein the information describing the location and the RTT used by the trilateration algorithm includes the corrected GNSS position fix for each UE.

28. The method of claim 27, further comprising: determining a horizontal position error (HPE) for the corrected GNSS position fixes of the plurality of UEs, and wherein the determining by the trilateration algorithm is further based on the HPE for the corrected GNSS position fixes of the plurality of UEs. ​ 29. A non-transitory electronic device-readable medium having software stored thereon that, when executed on one or more processors of one or more electronic devices, is operable to: receive round trip time (RTT) measurements from a plurality of user equipment (UEs) that have attempted to measure RTT with a beacon that initially has unknown RTT capability; determine that the beacon has RTT capability and determine a location of the beacon based on the RTT measurements from the plurality of UEs; update a beacon database to include information indicating that the beacon has RTT capability and the determined location of the beacon; and provide information including an indication that the beacon has RTT capability and the determined location of the beacon to at least one UE as part of a set of beacon information that can be used to estimate a geographic area in which to locate the UE.

30. The non-transitory electronic device-readable medium of claim 29, wherein, the beacon is a Wi-Fi access point (AP) and the beacon has RTT capability when the beacon supports a fine timing measurement (FTM) protocol according to an Institute of Electrical and Electronics Engineers (IEEE) 802.11mc standard.

31. The non-transitory electronic device-readable medium of claim 29, wherein, the beacon is a cellular base station, the RTT capability includes support for 3rd Generation Partnership Project (3GPP) Release 16, and the RTT is multi-RTT.

32. The non-transitory electronic device-readable medium of claim 29, wherein, the beacon is determined to have RTT capability in response to at least one of the plurality of UEs having been able to cause the beacon to measure RTT.

33. The non-transitory electronic device readable medium of claim 29, wherein, the software is further operable to: estimate an RTT bias of the beacon that measures an expected error in RTT measurements by the beacon, and add information indicating the RTT bias for the beacon to the beacon database.

34. The non-transitory electronic device-readable medium of claim 29, wherein, the software is further operable to: determine that a distance between each UE and the beacon calculated based on RTT is consistent with a determined location of the UE.

35. The non-transitory electronic device readable medium of claim 29, wherein, the software is further operable to: determine a physical antenna location of the beacon by using a trilateration algorithm from RTT measurements by the plurality of UEs, and add the physical antenna location of the beacon to the beacon database.

36. A non-transitory electronic device-readable medium having software stored thereon that, when executed on one or more processors of one or more electronic devices, is operable to: receive information from a plurality of user equipment (UEs) that have observed a beacon, the information including at least raw global navigation satellite system (GNSS) measurements for the UEs and RTT measurements by the beacon for the UEs; obtain RTK correction information for the raw GNSS measurements for each UE from a real-time kinematic (RTK) correction service; determine a corrected GNSS position fix for each UE using the raw GNSS measurements and the RTK correction information; determine a physical antenna location of the beacon based on the corrected GNSS position fix for each of the plurality of UEs and the RTT measurements; update a beacon database to include the determined physical antenna location of the beacon; and provide the physical antenna location of the beacon to one or more of the plurality of UEs.

37. The non-transitory electronic device-readable medium of claim 36, wherein, The beacon is a Wi-Fi access point, AP, and the beacon is RTT capable when the beacon supports a fine timing measurement, FTM, protocol according to the Institute of Electrical and Electronics Engineers, IEEE, 802.11mc standard.

38. The non-transitory electronic device-readable medium of claim 36, wherein, The beacon is a cellular base station, the RTT capability includes support for 3rd Generation Partnership Project, 3GPP, Release 16, and the RTT is multi-RTT.

39. The non-transitory electronic device-readable medium of claim 36, wherein, The software is further operable when executed to: determine a horizontal positioning error, HPE, of a corrected GNSS position fix of the plurality of UEs, and wherein the position determination of the beacon uses a trilateration algorithm based at least in part on the HPE of the corrected GNSS position fix of the plurality of UEs.

40. The non-transitory electronic device-readable medium of claim 39, wherein, The trilateration algorithm is a weighted least squares, WLS, multilateration algorithm. The beacon is a Wi-Fi access point, AP, and the beacon is RTT capable when the beacon supports a fine timing measurement, FTM, protocol according to the Institute of Electrical and Electronics Engineers, IEEE, 802.11mc standard. The beacon is a cellular base station, the RTT capability includes support for 3rd Generation Partnership Project, 3GPP, Release 16, and the RTT is multi-RTT. The software is further operable when executed to: determine a horizontal positioning error, HPE, of a corrected GNSS position fix of the plurality of UEs, and wherein the position determination of the beacon uses a trilateration algorithm based at least in part on the HPE of the corrected GNSS position fix of the plurality of UEs. The trilateration algorithm is a weighted least squares, WLS, multilateration algorithm.

Images