Method and medium for enabling RTT based positioning

Abstract

Methods and media for enabling RTT-based positioning are provided. The method includes receiving, by a cloud-based location platform maintaining a beacon database, observations from a plurality of UEs that have observed beacons, the observations including at least a determined location of each UE and RTT measurements of each UE by the beacons; determining, by the cloud-based location platform, the physical antenna location of the beacon based at least on the determined location of each UE and the RTT measurement of each UE using a WLS multilateral measurement algorithm in which the weight is a function of the location confidence of the determined location of each of the plurality of UEs; updating the beacon database to include the determined physical antenna position of the beacon; and providing, by the cloud-based location platform, the physical antenna locations of the beacons to the one or more UEs such that the one or more UEs both contribute information to determine the physical antenna locations of the beacons to construct a beacon database and consume the physical antenna locations from the beacons in the beacon database.

Description

[0001] This application is a divisional application of the invention patent application filed on March 30, 2021, with application number 202180061140.8 and invention title "Location Based on Crowdsourcing RTT". Technical Field

[0002] This disclosure generally relates to user equipment (UE) positioning, and more specifically, to crowdsourcing techniques for enabling UE positioning based on round-trip time (RTT). Background Technology

[0003] Determining the location of a UE is becoming increasingly important for tasks such as tracking users, managing profiles, providing location-based services, and other purposes. Various techniques used to determine UE location involve received signal strength (RSS) measurements. For example, triangulation can be performed on the 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.). However, RSS-based techniques may struggle to determine highly accurate UE locations.

[0004] Improved accuracy is possible by utilizing RTT measurements in UE location determination. Typically, RTT is the time elapsed between sending an initiation signal and receiving the corresponding response signal. Time of Flight (ToF) can be obtained by subtracting the turnaround time from the RTT and dividing the result by two. Based on the ToF, the distance (range) between the UE and a beacon can be easily determined. Based on the distances to multiple beacons, the UE's location can be determined, for example, via trilateration.

[0005] Various new protocols, such as the Fine Timing Measurement (FTM) protocol introduced in the IEEE 802.11mc standard and the protocols introduced in 3GPP Release 16 Technical Specifications (TS) Series 37 and 38, enable highly accurate measurement of RTT. Using a Wi-Fi AP that supports the FTM protocol, RTT can be measured from the timestamps captured at the departure and arrival of FTM frames, along with their respective acknowledgments. For cellular base stations supporting 3GPP Release 16, specific subtypes known as multi-RTT can be measured.

[0006] UEs 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: announcement frames and range requests. Wi-Fi APs periodically broadcast frames using announcement frames to advertise their RTT capabilities to the UE. The UE uses range requests to establish a peering link to the Wi-Fi AP and attempts to have the Wi-Fi AP measure RTT using that link, sending request frames and waiting for a burst of response frames, which the UE responds with acknowledgments. Extended capability elements (e.g., included in announcement frames or initial response frames) can provide information about the scheduling and operational details of the FTM session using announcement frames or range requests, such as burst duration, FTM frames per burst, bandwidth, minimum time between consecutive FTM frames, etc. Similarly, 3GPP Release 16 provides its own mechanism for discovering which cellular base stations support RTT.

[0007] While using RTT can improve the accuracy of UE location determination, several obstacles have hindered the 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 lack the functionality to support RTT measurements (e.g., they only support older protocols and standards). Other beacons may include functionality (e.g., their chipset supports applicable protocols and standards) but do not advertise their RTT capabilities for various reasons. For example, currently only a small fraction of deployed Wi-Fi APs utilize the FTM protocol to support the IEEE 802.11mc standard and the FTM protocol. Within this segment, some Wi-Fi APs do not advertise their support for the FTM protocol. UEs interested in learning which Wi-Fi APs support the FTM protocol typically have two suboptimal options: they can rely on announcements, thus missing Wi-Fi APs that do not advertise their capabilities, or they can establish peer-to-peer links and send request frames to each nearby Wi-Fi AP, thus consuming significant time, processor cycles, memory space, network bandwidth, and power. In dense urban areas, there may be dozens or even hundreds of nearby Wi-Fi APs, making it simply too expensive and impractical to have each UE establish a peer-to-peer link and send request frames to each nearby Wi-Fi AP.

[0008] Secondly, it can be difficult to determine the physical antenna location at a level of accuracy that fully realizes the benefits of RTT-based positioning. RTT-based positioning typically requires highly accurate physical antenna locations (e.g., within 1 meter) to achieve its full benefits. One way to obtain such physical antenna locations is through specialized measurements. For example, a Wi-Fi measurement system or vehicle, including high-precision hardware, can traverse the field and map the physical antenna locations of the Wi-Fi AP. While the physical antenna locations determined by such methods can be accurate, it is extremely time-consuming and expensive. An alternative approach is to approximate the physical antenna location based on the beacon's coverage area, which may already be known from other positioning techniques. For example, the physical antenna location of a Wi-Fi AP can be approximated as the centroid of the Wi-Fi AP's coverage. However, such methods are generally not very accurate. The centroid of coverage often deviates from the physical antenna location due to signal propagation bias, observation bias, and other factors.

[0009] Therefore, there is a need for improved technologies that can address these and / or other issues that hinder the widespread deployment of RTT-based positioning for UEs. Summary of the Invention

[0010] In various embodiments, crowdsourcing techniques are provided to enable RTT-based positioning for the UE. To address the problem of discovering which beacons (e.g., Wi-Fi APs, cellular base stations, BEE transmitters, etc.) support RTT measurements (e.g., according to IEEE 802.11mc, 3GPP Release 16, etc.), beacon RTT capabilities can be crowdsourced from the UE 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 crowdsourced from the UE for those beacons with RTT capabilities and used by a trilateration algorithm (e.g., a weighted least squares (WLS) multilateral measurement algorithm) to determine the physical antenna locations, which can also be maintained in the beacon database. The accuracy of the trilaterations can be enhanced by obtaining raw Global Navigation Satellite System (GNSS) measurements (e.g., pseudorange) from the UE and performing cloud-based real-time dynamic (RTK) GNSS position fixing for the UE.

[0011] In one embodiment, a location client on the UE is used to crowdsource beacon RTT capabilities. The UE uses a wireless network interface to scan for beacons within its range. The UE accesses information from a beacon database maintained by a cloud-based location platform to determine whether the RTT capability is 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 its RTT, and based on this, assigns an RTT measurement state indicating the beacon's RTT capability to the beacon. The UE then uploads at least the RTT measurement state to the cloud-based location platform to update the beacon database. In this type of embodiment, the UE both consumes information about the beacon's RTT capability from the beacon database and contributes information about the beacon's RTT capability to the beacon database.

[0012] In another embodiment, a cloud-based positioning platform is used for crowdsourcing beacon RTT capabilities. The cloud-based positioning platform provides multiple UEs with information about the RTT capabilities of beacons from a beacon database. At least one beacon initially has an unknown RTT capability. The cloud-based positioning platform later receives RTT information from one or more of the multiple UEs, including at least the RTT measurement state, which has attempted to measure the RTT using the beacon initially with an unknown RTT capability. The RTT capability of the beacon is determined based on the received RTT measurement state, and the beacon database is updated to include information indicating the beacon's RTT capability. In this embodiment, operation allows UEs to consume information about the beacon's RTT capability from the beacon database and contribute information about the beacon's RTT capability to the beacon database.

[0013] In yet another embodiment, the cloud-based positioning platform determines beacon locations, or more specifically, beacon physical antenna locations, based on crowdsourced data. The cloud-based positioning platform receives observations from multiple UEs that have observed the beacon; these observations include at least the determined location of the UE and the RTT measurement for the UE from the beacon. The cloud-based positioning platform uses a trilateration algorithm to determine the beacon's physical antenna location based on the determined location and the RTT measurement for each of the multiple UEs. The cloud-based positioning platform updates the beacon database to include the determined physical antenna locations of the beacons and provides the physical antenna locations of the beacons to one or more of the multiple UEs. In this type of embodiment, operation both allows UEs to contribute information for determining the physical antenna locations of the beacons to build the beacon database and to consume the physical antenna locations of the beacons from the beacon database.

[0014] In another embodiment, the cloud-based positioning platform determines beacon locations, or more specifically, beacon physical antenna locations, based on crowdsourced data, wherein cloud-based RTK GNSS location fixing for UE locations is used to improve the accuracy of such determination. The cloud-based positioning platform receives information from multiple UEs that have observed the beacon, including at least the raw GNSS measurements and RTT measurements for that UE. It also obtains RTK correction information from a correction service used for the raw GNSS measurements. The cloud-based positioning platform uses the raw GNSS measurements and the RTK correction information to determine a calibrated GNSS location fixing for each UE. Subsequently, the cloud-based positioning platform uses a trilateration algorithm to determine the beacon location based on the calibrated GNSS location fixing and RTT measurements, and updates the beacon database to include the determined physical antenna locations of the beacons. It then provides the physical antenna locations of the beacons to one or more of the multiple UEs.

[0015] It should be understood that the embodiments discussed in this invention summary may include various other features, including those discussed below and variations thereof. Furthermore, various other embodiments may be utilized, including various combinations and variations of the features discussed herein and below. This invention summary is intended only as a brief overview for the reader and is not intended to imply that any specific features mentioned herein are all or necessary features of the invention. Attached Figure Description

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

[0017] Figure 1 This is a block diagram of an example architecture for deploying RTT-based positioning technologies to enable UEs;

[0018] Figure 2 This is a flowchart detailing exemplary operations performed under the guidance of a positioning client on the UE for crowdsourced beacon RTT capabilities;

[0019] Figure 3 This is a flowchart detailing exemplary operations performed by a cloud-based location platform for crowdsourced beacon RTT capabilities;

[0020] Figure 4 This is a flowchart detailing an example operation performed by a cloud-based positioning platform to determine the location of a beacon, or more specifically, the location of the physical antenna of a beacon, using RTT measurements crowdsourced from the UE.

[0021] Figure 5 This is a diagram illustrating an example arrangement of the HPE and its use as an indicia for determining the accuracy of location;

[0022] Figure 6This is a flowchart detailing example operations performed by a cloud-based positioning platform in an "off-board" implementation to determine beacon location, or more specifically, the location of the beacon's physical antenna, using cloud-based RTK GNSS location fixing; and

[0023] Figure 7 This is a flowchart detailing an example operation performed by a positioning client on the UE to implement a hybrid RTT-based positioning algorithm to determine the UE's location. Detailed Implementation

[0024] Figure 1 This is a block diagram of an example architecture 100 for deploying technologies that enable RTT-based positioning for UEs. As used herein, the term "User Equipment" or "UE" refers to a mobile device, machine-to-machine (M2M) device, or Internet of Things (IoT) device operated by an end user. Examples of UE 110 include smartphones, smartwatches, computers, cameras, and sensors operated by the end user. Similarly, as used herein, the term "beacon" refers to a device with a fixed location that can be used to determine the location of a UE. Examples of beacon 140 include Wi-Fi APs, cellular base stations, BLE transmitters, and other devices. Furthermore, as used herein, the term "RTT capability" refers to the beacon's ability to measure RTT (or its subtypes, such as multi-RTT) and provide the measured RTT to other devices. RTT capability can be based on the IEEE 802.11mc standard, 3GPP Release 16 TS Series 37 and 38, or other protocols and standards' FTM protocols. Furthermore, as used herein, the term "RTT measurement status" refers to the beacon's ability to perform a specific RTT measurement. RTT measurement status can be based on the IEEE 802.11mc standard, 3GPP Release 16 TS Series 37 and 38, or other protocols and standards' FTM protocols.

[0025] UE 110 typically includes a central processing unit (CPU) 115, a memory 120 (e.g., volatile and non-volatile memory) storing application software, which includes a location 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 for receiving satellite signals, and many other components.

[0026] The positioning client 122 typically uses the wireless network interface to scan for beacons 140 (e.g., Wi-Fi APs, cellular base stations, BLE transmitters, etc.) within the range of the UE 110 and determine their characteristics. These characteristics can be combined with a local copy of the beacon information to determine the location of the UE 110. Similarly, the positioning client 122 can utilize the GNSS receiver 130 to capture raw GNSS measurements from satellites (e.g., pseudo-range). Raw GNSS measurements can also be used to determine the UE's location (i.e., GNSS location is fixed).

[0027] UE 110 can communicate with the Internet 150 and the cloud-based positioning platform 160 via Wi-Fi or cellular data communication paths. Among other functions, the positioning platform 160 typically maintains a beacon database 170. A portion of the beacon database 170 can be designated as an RTT database 175, and it associates beacon identifiers (e.g., Media Access Control (MAC) addresses, Cell Identifiers (IDs), etc.) with various RTT-related information, such as the beacon's RTT capability (e.g., having RTT capability, not having RTT capability, or having unknown RTT capability), RTT offset, beacon physical antenna location, location uncertainty, etc. A portion (e.g., tiles) of the beacon database (including RTT database 175) covering a specific geographic area can be downloaded to UE 110 by the positioning client 122 for use as a local copy. In addition, information derived from scans performed by UE 110 (e.g., the UE’s determined location, beacon identifier, RTT measurement status, RTT measurement, etc.) can be periodically uploaded to a cloud-based location platform 160, which uses this information to update the beacon database 170 (including the RTT database 175).

[0028] Figure 2This is a flowchart detailing an example operation 200 performed under the guidance of a location client 122 on UE 110 for crowdsourced beacon RTT capabilities. In step 210, the location client 122 uses the UE 110's wireless network interface 125 to perform a scan to discover beacons 140 within the UE's range. The scan can be an active scan (e.g., in response to a current request to calculate the UE's location for an application running on UE 110) or a background scan (e.g., in the background where there is no current request to determine the UE's location). In step 215, for an implementation utilizing a local copy of a portion (e.g., a slice) of a beacon database 170 covering a geographic area, the location client 122 checks whether UE 110 stores a local copy of a portion (e.g., a slice) of the beacon database 170 covering the geographic area including UE 110's current location. If not, in step 220, it downloads the local copy (e.g., the slice) from a cloud-based location platform 160. This can occur each time the UE is in a new geographic area or when a previously downloaded local copy (e.g., the slice) has aged. It should be understood that some implementations may not use local copies (e.g., shards), and in such cases, steps 215-220 may be omitted.

[0029] In step 225, the location client 122 cycles through each beacon 140 within the range of UE 110, and in step 230, checks to determine whether RTT capability is known. In embodiments using local copies (e.g., slices), this may involve checking the identity of the beacon in the local copy (e.g., slice). Alternatively, this may involve querying the cloud-based location platform 160. RTT capability may have multiple states, including having RTT capability (i.e., indicating a state where another UE has been able to enable the beacon to measure RTT in the past), not having RTT capability (i.e., indicating a state where another UE has attempted to enable the beacon to measure RTT in the past but has not yet been able to), or having unknown RTT capability (i.e., indicating a state where no UE has attempted to measure RTT in the past). In step 235, for each beacon 140 within the range of UE 110 indicated as having RTT capability or having unknown RTT capability, the location client 122 adds the beacon to a range list (i.e., a list of identifiers (e.g., MAC address, cell ID, etc.)) designated for receiving range requests.

[0030] In step 240, the positioning client 122 cycles through each beacon 140 on the range list, and in step 245, causes the wireless network interface 125 to send a range request (e.g., a range request according to the FTM protocol of the IEEE 802.11mc standard, or a request according to another standard) to attempt to enable beacon 140 to use it to measure RTT. In step 250, the positioning client 122 assigns an RTT measurement state to beacon 140 indicating the beacon's RTT capability. The assigned RTT measurement state can indicate that the beacon has RTT capability (i.e., the beacon can measure and return RTT), does not have RTT capability (i.e., the beacon cannot measure and return RTT), or is out of range (i.e., the beacon cannot measure RTT, but the beacon returns an out-of-range indication, allowing the beacon to measure and return RTT with a smaller range).

[0031] In step 255, the positioning client 122 determines the location of the UE 110. This determination may be based on GNSS, such that the determined location is a GNSS location fixed. Alternatively or additionally, this determination may utilize RTT-based positioning. Such RTT-based positioning may 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. Location confidence (e.g., estimated horizontal position error (HPE)) can be calculated for the determined location of the UE 110.

[0032] In step 260, in the cache-based implementation, the location client 122 adds the RTT information of beacons within range to its local cache on the UE 110. The RTT information may include the UE's determined location (and, in some cases, location confidence), the beacon identifier for each beacon (e.g., MAC address, cell ID, etc.), the RTT measurement status (e.g., RTT capability enabled, RTT incapable, or RTT out of range), and the RTT measurement (if available). In step 265, the location client 122 determines whether a cache upload trigger has been reached. The trigger may be a local cache becoming full, a specific time interval expiring, or some other criterion being periodically met. If a trigger has been reached, in step 270, the location client 122 uploads the contents of its local cache to the cloud-based location platform 160 for inclusion in updates to the beacon database 170 (or more specifically, its RTT database 175). It should be understood that some implementations may not use a cache, and in such cases, steps 260-265 may be omitted, and the upload in step 270 may begin immediately when new RTT information for the beacon is available. Finally, in 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 an active scan).

[0033] Figure 3 This is a flowchart detailing an example operation 300 performed by a cloud-based location platform 160 for crowdsourced beacon RTT capabilities. The operation may aggregate information discovered by a large number of UEs 110 to construct a beacon database 170 (and its RTT database 175). In step 310, the cloud-based location platform 160 batches the RTT information received from the UEs 110. As described above, the RTT information may include the UE's determined location, and the beacon identifier (e.g., MAC address, cell ID, etc.) for each beacon 140 within the EU range, the RTT measurement status (e.g., RTT capability enabled, RTT capability disabled, or RTT out of range), and the RTT measurement (if available).

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

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

[0036] In step 350, the cloud-based positioning platform 160 determines whether the RTT capability of beacon 140 indicates that it possesses RTT capability. If not, a loop is executed to check the next beacon. If yes, execution proceeds to step 360, where the cloud-based positioning platform 160 estimates the RTT deviation of beacon 140, which is measured by the expected offset / error in the beacon's RTT measurement. The RTT deviation can be estimated using various techniques. For example, the increment between the RTT-determined distance between UE 110 and beacon 140 and the location-fixed distance between UE and beacon can be calculated. If this increment is substantially the same on multiple (e.g., all) UEs 110 that have observed beacon 140, then this increment can be used as the beacon's RTT deviation. Furthermore, the cloud-based positioning platform 160 can identify other beacons 140 that share a common organization identifier (e.g., organization unique identifier (OUI)) with the beacon. If multiple of these other beacons share substantially the same RTT deviation, then that RTT deviation can be assumed for the current beacon. This allows for estimating RTT bias when incremental calculations are not possible.

[0037] In step 370, the cloud-based positioning platform 160 determines whether the distance (range) between the UE 110 and the beacon 140 calculated based on RTT is reasonable. For example, it may determine whether this distance is consistent with the distance between the location of the UE 110 using other technologies (e.g., GNSS location fixing) and the beacon location in the beacon database 170. If the RTT-based distance is unreasonable, the RTT capability of the beacon 140 is updated (e.g., the beacon is marked as not having RTT capability).

[0038] In step 380, the cloud-based positioning platform 160 determines the physical antenna location of the beacon 140. This determination uses a trilateration algorithm (e.g., WLS multi-lateral measurement algorithm) based on RTT measurements from multiple UEs. Details of an example operation for determining the physical antenna location are discussed below.

[0039] As the loop completes execution for each of the beacons, 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. Subsequently, in an implementation utilizing local copies (e.g., slices), a portion of the updated beacon database 170 can be provided back to the UEs 110 to inform them of the beacon's RTT capabilities, thus enabling them to perform RTT-based positioning.

[0040] Figure 4 This is a flowchart detailing an instance operation 400 performed by a cloud-based positioning platform 160 to determine a beacon location, or more specifically, the physical antenna location of a beacon, using crowdsourced RTT measurements from a UE 110. In step 410, the cloud-based positioning platform 160 receives observations from the UE 110 of an RTT-capable beacon 140. The observations may include the UE's determined location (e.g., GNSS location fixed) and the location confidence of that location (e.g., HPE for GNSS location fixed), the beacon's identifier (e.g., MAC address, cell ID, etc.), and RTT information. The RTT information may include the RTT measurement, RTT measurement uncertainty, signal strength associated with the RTT measurement, bandwidth associated with the RTT measurement, and other RTT-related data. In step 420, the cloud-based positioning platform 160 aggregates the observations for a given beacon 140. In step 430, the cloud-based positioning platform 160 filters the observations based on a comparison of the UE's determined location confidence (e.g., HPE for GNSS location fixed) with a threshold. Preferably, the threshold is set to remove only observations with very poor location confidence (e.g., observations with very high HPE). Observations with moderate confidence can be addressed by weighting in subsequent operations.

[0041] In step 440, the cloud-based positioning platform uses a trilateration algorithm to determine the beacon location, or more specifically, the beacon's physical antenna location, based on aggregated observations from UE 110. The trilateration algorithm can be a WLS multi-lateral measurement algorithm, where the weights are functions of the confidence level of the UE's determined location (e.g., HPE for GNSS location fixed), RTT measurement uncertainty, the range of the determined RTT (e.g., where measurements from a longer range 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., where higher bandwidth is considered to have lower error). In some cases, the WLS multi-lateral measurement algorithm may also consider other information (e.g., RSS, angle of arrival (AoA), etc.), applying weights based on uncertainty (e.g., higher weights for RSS measurements, since RSS can have higher uncertainty than RTT). In step 450, the cloud-based positioning platform updates the beacon database to include the determined location of beacon 140, or more specifically, the determined physical antenna location of the beacon. Subsequently, a portion (e.g., a slice) of the updated beacon database 170 can be provided back to the UE 110, so that the determined physical antenna location of the beacon can be used for the UE's RTT-based positioning.

[0042] The accuracy of trilateration can typically be improved by using the UE's definitive location with very high location confidence. When the definitive location is a fixed GNSS position, very good location confidence can be measured, resulting in very low HPE. Figure 5 This is a diagram of an example arrangement 500 of UE 110, illustrating the use of the HPE and its role as a marker for the accuracy of location determination. The location of beacon 510 can be determined using trilateration of GNSS location fixes of UEs 520-540, where each GNSS location fix has an HPE represented by a circle with a given radius. Specifically, the HPE of UE 540 is somewhat large, indicating a low confidence level at that location. The location of UE 540 may be very inaccurate, which could affect the accuracy of the trilateration. If the accuracy of the location of UE 540 can be improved, the accuracy of the trilateration may also be improved.

[0043] One technique for improving the accuracy of location determination in UE 110 involves RTK correction services. In the conventional “airborne” implementation of RTK correction, the GNSS receiver 130 in UE 110 is RTK-capable and interacts with an independent network of RTK base stations, which provides real-time correction applied at the UE. However, RTK-capable GNSS receivers are typically quite expensive and are not usually deployed in low-cost UEs (e.g., smartphones, smartwatches, etc.). Therefore, many UEs 110 cannot benefit from RTK correction if operation is restricted to “airborne”.

[0044] This limitation can be addressed through a “non-airborne” implementation, in which raw GNSS measurements (e.g., pseudorange) from UE 110 are provided to a cloud-based positioning platform 160 that performs RTK GNSS location fixing. Figure 6 This is a flowchart detailing an example operation 600 performed by a cloud-based positioning platform 160 in a "non-airborne" implementation to determine a beacon location, or more specifically, the physical antenna location of a beacon, using cloud-based RTK GNSS location fixing. In step 610, the cloud-based positioning platform 160 receives observations of an RTT-capable beacon from the UE 110. The observations may include one or more sets of raw GNSS measurements (e.g., pseudorange) from the UE 110's GNSS receiver 130, beacon identifiers (e.g., MAC address, cell ID, etc.), and RTT information. The RTT information may include RTT measurements, RTT measurement uncertainties, signal strength associated with the RTT measurements, bandwidth associated with the RTT measurements, and other RTT-related data. In step 620, the cloud-based positioning platform 160 connects to an RTK correction service via the Internet 150 and obtains RTK correction information. In step 630, for each set of raw GNSS measurements, the cloud-based positioning platform 160 uses the raw GNSS measurements and RTK correction information to determine the corrected GNSS position fix for the UE 110. In step 640, the cloud-based positioning platform 160 determines the HPE of the obtained corrected GNSS position fix for each of the UEs 110. This corrected GNSS position fix typically has a much lower HPE than the GNSS position fix generated by the UE itself.

[0045] In step 650, the cloud-based positioning platform 160 aggregates observations for a given beacon, including the UE's cloud-based RTK GNSS location fixation. In step 660, the cloud-based positioning platform 160 filters the observations based on a comparison of the GNSS location fixation HPE with a threshold. In step 670, the cloud-based positioning platform 160 uses a trilateration algorithm to determine the beacon location, or more specifically, the beacon physical antenna location, based on the aggregated observations from the UE 110. The trilateration algorithm may be a WLS multilateral measurement algorithm with the weights described above, except that it uses a corrected GNSS location fixation HPE instead of the HPE from the UE 110. In 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. A portion (e.g., a slice) of the updated beacon database 170 may then be provided back to the UE.

[0046] A portion (e.g., a slice) of the updated beacon database 170 can be cached locally and used by UE 110 to perform RTT-based localization. Many different RTT-based localization algorithms can be used, which make location determination based solely on RTT measurements, or combine RTT with other information (e.g., RSS, AoA, etc.). In one embodiment, a hybrid RTT-based localization algorithm that combines the WLS localization algorithm and the extended Kalman filter localization algorithm is utilized.

[0047] Figure 7This is a flowchart detailing example operation 700 performed by a positioning client 122 on UE 110 to implement a hybrid RTT-based positioning algorithm for determining the UE's location. In step 710, the positioning client 122 aggregates RTT measurements by identifying RTT-capable beacons within the range of UE 110 over a time period (e.g., a one-second interval). In step 720, the positioning client 122 determines the number of unique beacons 140 in the aggregation, for which information (e.g., beacon location) is available in a portion (e.g., a slice) of a beacon database 170 cached locally by 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's location is determined using a WLS positioning algorithm. The weights used in the WLS positioning algorithm may be based on the number of RTT measurements, the confidence level of the determined beacon location (e.g., HPE), RTT measurement uncertainty, and / or other factors. As part of step 740, a WLS location uncertainty (e.g., WLS location HPE) may also be generated. In step 745, the positioning client 122 resets and initializes the Kalman filter state to be equal to the determined WLS location. Then, in step 750, the positioning client 122 reports the determined WLS location as the location of the UE 110 (e.g., to an application running on the UE).

[0048] If the number of unique beacons is not greater than a threshold, execution proceeds to step 760, where the UE location is determined by the Kalman filter localization algorithm. If, as part of step 745, the Kalman filter state was previously initialized to be equal to the determined WLS location, this initialization is used. Otherwise, the Kalman filter state can be initialized to the median beacon location of the unique beacons. In step 770, the localization client 122 determines whether the Kalman filter localization algorithm was successful, and if successful, in step 750, the localization client 122 reports the determined Kalman location as the location of the UE 110. If the Kalman filter localization algorithm is unsuccessful, in step 775, the localization client 122 determines whether a previous Kalman location was returned within a refresh interval (e.g., 2 seconds), and if so, in step 750, the localization client 122 reports the previous Kalman location as the location of the UE 110 (e.g., to an application running on the UE). If no previous Kalman location was returned within the refresh interval, in step 780, the localization client 122 determines whether a previous WLS location was returned within the refresh interval. If so, then 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, reports the previous WPS position as the position of UE 110, and in step 750. If the previous WLS position is not returned within the refresh interval, then in step 795, the positioning client 122 reports that UE 110 has no position result.

[0049] It should be understood that, in addition to determining location solely based on RTT measurements, positioning algorithms can also use RTT in combination with other information (e.g., RSS, AoA, etc.) to determine location. 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 beacons in a weighted trilateration to estimate the UE's location. RTT measurements can be used to adjust RSS measurements, filter potentially erroneous RSS measurements, adjust the weights assigned to beacons in the weighted trilateration, and / or otherwise improve the accuracy of RSS positioning.

[0050] The above description details various crowdsourcing techniques for enabling RTT-based positioning for UE 110. It should be understood that, depending on the implementation, these techniques and parts thereof can be used together, individually, or in combination with other techniques. Furthermore, it should be understood that aspects of the techniques can be modified, added to, removed from, or otherwise altered depending on the implementation. Moreover, while specific example hardware and software have been discussed above, it should be understood that various types of hardware, software, and combinations thereof can be used to implement these techniques. 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 software execution. Such software may include executable instructions that implement an application stored on a non-transitory electronically readable medium, 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. First, it should be understood that the above description is intended only as an example.

Claims

1. A method for enabling location based on round-trip time (RTT), comprising: The cloud-based location platform that maintains the beacon database receives observation results from multiple user equipment (UEs) that have observed the beacons. The observation results include at least the determined location of each of the multiple UEs and the RTT measurement of each of the multiple UEs by the beacon. The cloud-based location platform uses a trilateration algorithm to determine the physical antenna location of the beacon based at least on the determined location of each of the plurality of UEs and the RTT measurement of each of the plurality of UEs, wherein the trilateration algorithm is a weighted least squares (WLS) multilateral measurement algorithm, in which the weights are a function of the location confidence of the determined location of each of the plurality of UEs; Update the beacon database to include the determined physical antenna locations of the beacons; and The cloud-based location platform provides the physical antenna location of the beacon to one or more of the plurality of UEs. This allows the one or more UEs to both contribute information 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.

2. The method according to claim 1, wherein, The determined location of each of the plurality of UEs includes a location confidence level for the determined location, and the method further includes: The observation results are filtered out based on the comparison between the location confidence score of the determined location of the UE and a threshold.

3. The method according to claim 1, wherein, The determination by the trilateration algorithm is also based on the position confidence of the determined position of each of the plurality of UEs.

4. The method according to claim 3, wherein, The determined position of each of the plurality of UEs includes a Global Navigation Satellite System (GNSS) position fixed, and the position confidence includes the horizontal positioning error (HPE) of the GNSS position fixed.

5. The method according to claim 1, wherein, The RTT measurement from each of the plurality of UEs includes an RTT measurement uncertainty or an RTT determination range, and the determination by the trilateration algorithm is also based on the RTT measurement uncertainty or the RTT determination range from each of the plurality of UEs.

6. The method according to claim 1, wherein, The RTT measurement from each of the plurality of UEs includes the signal strength associated with the RTT measurement, and the determination by the trilateration algorithm is also based on the signal strength of each of the plurality of UEs.

7. The method according to claim 1, wherein, The RTT measurement from each of the plurality of UEs includes the bandwidth associated with the RTT measurement, and the determination by the trilateration algorithm is also based on the bandwidth of each of the plurality of UEs.

8. The method according to claim 1, wherein, The RTT measurement from each of the plurality of UEs is one or more RTT measurements from each of the plurality of UEs, and the determination by the trilateration algorithm is also based on the number of RTT measurements in one or more RTT measurements from each of the plurality of UEs.

9. The method according to claim 1, wherein, The beacon is a Wi-Fi access point (AP) operating according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11mc standard.

10. The method according to claim 1, wherein, The beacon is a cellular base station operating under the 3rd Generation Partnership Project (3GPP) Release 16.

11. The method according to claim 1, wherein, The observations include Global Navigation Satellite System (GNSS) measurements for each of the plurality of UEs, and the method further includes: The cloud-based location platform obtains correction information for the raw GNSS measurements of each of the multiple UEs; and The cloud-based location platform uses the raw GNSS measurements and the correction information to determine the corrected GNSS position of each of the plurality of UEs. Wherein, the determined position of each of the plurality of UEs used by the trilateration algorithm is the corrected GNSS position fixed for each of the plurality of UEs.

12. A method for enabling location based on round-trip time (RTT), comprising: The cloud-based location platform that maintains the beacon database receives observation results from multiple user equipment (UEs) that have observed the beacons, the observation results including RTT measurements of each of the multiple UEs by the beacons; The physical antenna location of the beacon is determined by the cloud-based location platform using a weighted least squares (WLS) multilateral measurement algorithm, which calculates the physical antenna location based on the determined location and RTT measurements of each of the plurality of UEs weighted by the location confidence of the determined location. Update the beacon database to include the physical antenna locations of identified beacons; as well as The cloud-based location platform provides the physical antenna location of the beacon to one or more of the plurality of UEs. This allows the one or more UEs to both contribute information 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.

13. The method according to claim 12, wherein, The observation results also include the determined location of each of the plurality of UEs and the location confidence of the determined location, the physical antenna location using a trilateration algorithm, and the trilateration algorithm determining the physical antenna location of the beacon based on the determined location, the location confidence of the determined location, and the RTT measurement of each of the plurality of UEs.

14. The method according to claim 13, wherein, The determined position of each of the plurality of UEs includes a Global Navigation Satellite System (GNSS) fixed position, and the position confidence includes the horizontal positioning error (HPE) of the GNSS fixed position.

15. A non-transitory computer-readable medium storing computer-executable instructions, which, when executed by a cloud-based location platform, cause the cloud-based location platform to: Receive observation results from multiple user equipment (UEs) that have observed the beacon, the observation results including at least the determined location of each of the multiple UEs, the location confidence of the determined location of each of the multiple UEs, and the round-trip time (RTT) measurement of each of the multiple UEs by the beacon; The physical antenna location of the beacon is determined using a weighted least squares (WLS) multilateral measurement algorithm, which calculates the physical antenna location based on the determined location and RTT measurements of each of the plurality of UEs weighted by the location confidence of the determined location. Update the beacon database to include the physical antenna locations of the identified beacons; as well as The physical antenna location of the beacon is provided to one or more of the plurality of UEs.

16. The non-transitory computer-readable medium of claim 15, further comprising computer-executable instructions, which, when executed by the cloud-based location platform, cause the cloud-based location platform to: The observation results are filtered out based on a comparison between the location confidence score of each of the plurality of UEs at the determined location and a threshold.

17. The non-transitory computer-readable medium according to claim 15, wherein, The determined position of each of the plurality of UEs includes a Global Navigation Satellite System (GNSS) position fixed, and the position confidence includes the horizontal positioning error (HPE) of the GNSS position fixed.

18. The non-transitory computer-readable medium according to claim 15, wherein, The beacon is a Wi-Fi access point (AP) operating according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11mc standard.

19. The non-transitory computer-readable medium according to claim 15, wherein, The beacon is a cellular base station operating under the 3rd Generation Partnership Project (3GPP) Release 16.

Images