Crowdsourced beacon altitude for 3d positioning

Abstract

In various embodiments, crowd-sourcing techniques are provided for determining beacon altitude, which can then be used for 3D positioning of UEs. Some techniques can crowd-source beacon altitude based on global navigation satellite system (GNSS) position fixes obtained by UEs. Other techniques can crowd-source beacon altitude based on uncalibrated pressure measurements obtained by UEs. Still other techniques can combine beacon altitude crowd-sourcing and pressure sensor calibration on UEs. Such techniques can make inferences based on line-of-sight (LOS) between UEs and beacons, which is determined using signal strength, connection state, and / or timing measurements. These techniques can be implemented individually, or as part of a combined system that determines beacon altitude in different ways. Once the beacon altitude is known, it can be used to determine 3D position of UEs (e.g., through trilateration, multilateration, or other positioning techniques).

Description

Technical Field

[0001] This disclosure generally relates to user equipment (UE) positioning, and more specifically, to three-dimensional (3D) positioning of the UE. Background Technology

[0002] Determining 3D UE location is becoming increasingly important for providing emergency services, providing location-based non-emergency services, managing user profiles, tracking device location, and other tasks. 3D location is typically provided as a 2D location on the Earth's surface (e.g., expressed in latitude and longitude) and altitude (e.g., expressed as height above sea level, land level, etc.). Incorporating altitude data can: enable emergency responders to reach the correct address; provide more accurate information for location-based non-emergency services; update user profiles more accurately; and provide many other benefits.

[0003] Various existing positioning technologies have some ability to estimate altitude. For example, Global Navigation Satellite System (GNSS) positioning (e.g., Global Positioning System (GPS) positioning) can estimate the UE's altitude by using trilateration with four or more satellites. However, many existing technologies suffer from low accuracy. For instance, with GPS, the vertical error is typically about three times the horizontal error. Therefore, a single altitude determined using GPS may only be accurate to about 35-70 feet. This may be insufficient for many use cases, such as emergency positioning services.

[0004] Another common method for estimating altitude is to calculate it directly using uncompensated barometric pressure (UBP) measurements. Some UEs include pressure sensors that measure ambient air pressure. The resulting UBP can then be used to calculate altitude (e.g., using a barometric equation). However, to provide the accuracy required for many use cases, it is often necessary to perform a dedicated calibration of the pressure sensor for each UE. Some UEs may not support such calibration, or performing it using existing calibration techniques may be cumbersome. Furthermore, ambient air pressure depends on weather conditions and varies over time. These variations in weather conditions can introduce errors into the altitude calculated directly from UBP measurements.

[0005] Due to the limitations and problems associated with existing technologies, improved technologies are needed to achieve 3D positioning for UEs. Summary of the Invention

[0006] In various embodiments, crowdsourcing techniques are provided for determining beacon altitude, which can then be used for 3D positioning of the UE. Some techniques can crowdsource beacon altitude based on GNSS location obtained by the UE. Other techniques can crowdsource beacon altitude based on uncalibrated pressure measurements obtained by the UE. Still other techniques can combine beacon altitude crowdsourcing with pressure sensor calibration on the UE. These techniques can infer based on the line-of-sight (LOS) between the UE and the beacon, which is determined using signal strength, connectivity status, and / or timing measurements. These techniques can be implemented individually or as part of a combined system that determines beacon altitude in different ways. Once the beacon altitude is known, it can be used to determine the UE's 3D position (e.g., via trilateration, polygonation, or other positioning techniques).

[0007] In one embodiment, for each of a plurality of UEs, the UE's altitude at a given time is estimated based on one or more GNSS-based location methods of the UE. One or more beacons having a LOS (Loss of Orientation) with the UE at that time are determined based on the UE's observations of the beacons. The UE's altitude is bound to each of the one or more beacons having a LOS at that time. Subsequently, for one or more beacons, the beacon altitude is determined based on a set of bound altitudes for the respective beacon, and the beacon database is updated with the determined beacon altitudes. At least a portion of the beacon database is provided to the UE to enable the UE to calculate its 3D position (e.g., via trilateration, polygonation, or other positioning techniques).

[0008] In another embodiment, for each of a plurality of UEs, the UE's altitude at a given time is estimated based on a reference point measured by the UE (e.g., reference pressure such as a reference UBP and reference altitude) and a tracked altitude change measured by the UE (e.g., pressure change such as a UBP change). One or more beacons having a LOS with the UE at that time are determined based on the UE's observations of the beacons. The UE's altitude is bound to each of the one or more beacons having a LOS at that time. Subsequently, for one or more beacons, the beacon altitude is determined based on a set of bound altitudes for the corresponding beacon, and the beacon database is updated with the determined beacon altitudes. At least a portion of the beacon database is provided to the UE to enable the UE to calculate its 3D position (e.g., via trilateration, polygonation, or other positioning techniques).

[0009] In another embodiment, for each of a plurality of calibration points, the UE's altitude at a given time is calculated based on UBP measurements. The UE's altitude at that time is estimated based on the UE's GNSS-based positioning. Individual biases are calculated by comparing the UBP-calculated altitude with the GNSS-estimated altitude. Multiple individual biases are combined to produce a final bias, which is returned to the UE for calibration of the UE's pressure sensors. Additionally, for one or more beacons, the beacon altitude is determined based on multiple UBP-calculated altitudes from the calibration points, and the beacon database is updated with the determined beacon altitudes. At least a portion of the beacon database is provided to the UE to enable the UE to calculate its 3D position (e.g., via trilateration, polygonation, or other positioning techniques), thus providing an alternative to or supplement to altitude determination based on calibrated sensors.

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

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

[0012] Figure 1 This is a block diagram of an example architecture for crowdsourced beacon elevation for 3D positioning of a UE;

[0013] Figure 2 This is a flowchart of an example sequence of steps for GNSS-based beacon altitude crowdsourcing;

[0014] Figure 3A This is a flowchart of an example sequence of steps for crowdsourcing beacon altitude based on uncalibrated pressure;

[0015] Figure 3B This is an illustration illustrating an example of uncalibrated altitude determination that can be used for beacon altitude crowdsourcing; and

[0016] Figure 4 This is a flowchart of an example sequence of steps for a hybrid technology used for beacon altitude crowdsourcing and pressure sensor calibration. Detailed Implementation

[0017] Figure 1This is a block diagram of an example architecture 100 for crowdsourced beacon altitude measurement for UE 3D positioning. As used herein, the term "user equipment" or "UE" refers to a mobile device, wearable device, customer premises equipment (CPE), drone, or Internet of Things (IoT) device operated or used by an end user. Examples of UEs include smartphones, smartwatches, 4G / 5G cellular routers, drones (UAVs), and sensors. Similarly, as used herein, the term "beacon" refers to a device with a fixed location that exchanges signals that can be used to determine the location of a UE. Examples of beacons include Wi-Fi APs, Bluetooth Low Energy (BLE) transmitters (e.g.,... Proximity beacon Proximity beacons, AltBeacon TM Devices such as proximity beacons and indoor small cells. Furthermore, the terms “location” and “location” as used herein are interchangeable and should be considered to have the same meaning when used alone or as part of a longer phrase.

[0018] Although Figure 1 A single example UE 110 is shown, but it should be understood that typical architectures will include a large number of UEs (e.g., thousands, hundreds of thousands, millions, etc.) and crowdsourcing can leverage these numbers. UE 110 typically includes a central processing unit (CPU) 115 and a storage device 120 (e.g., volatile and non-volatile memory). The storage device 120 maintains software, which includes an operating system (OS) 122, a native positioning engine 124 (which may be part of OS 122), a 3D positioning client 126, and third-party applications 128. The operating system 122 may be a commercially available OS (e.g., The local positioning engine 124 provides a positioning application programming interface (API) for accessing the functions of the local positioning engine 124. The local positioning engine 124 can interoperate with pressure sensor 132 (e.g., a microelectromechanical system (MEMS) pressure sensor) to collect UBP measurements, with wireless network interface 134 (e.g., a Wi-Fi interface operating according to the IEEE 802.11 standard, a Bluetooth interface, etc.) to perform beacon scanning within a certain range, with GNSS receiver 136 to generate GNSS location positioning (e.g., 3D positioning including altitude), and with cellular modem 138 to collect measurements of the serving cell and neighboring cells, as well as various other functions. Beacons within the scanning range can indicate their identity (e.g., Media Access Control (MAC) address, Bluetooth device address, etc.), signal strength (e.g., Received Signal Strength Indication (RSSI)), connection status (e.g., "connected" flag), timing (e.g., Timing Advance (TA), Round Trip Time (RTT), etc.), and / or other characteristics. The 3D positioning client 126 can work with the native positioning engine 124 to serve 3D positioning requests issued by third-party applications 128, thereby providing them with 3D location (e.g., for location-based non-emergency services, profile generation, etc.). The 3D positioning client 126 can also work with the native positioning engine 124 to provide 3D location (e.g., for emergency services, tracking device location, etc.) to remote applications (e.g., those executed on a carrier core 152 accessible via a 2G / 3G / 4G / 5G backhaul network 150). 3D location typically includes 2D location on the Earth's surface (e.g., represented by latitude and longitude or another measure in the xy plane of a geographic coordinate system) and altitude (e.g., represented by the 1984 World Geodetic System (WGS84) ellipsoid, mean sea level, altitude above the ground plane, or another measure along the z-axis).

[0019] The 3D positioning client 126 and / or the native positioning engine 124 can communicate with a cloud-based 3D positioning platform 140 that maintains the beacon database 142. The beacon database 142 may include crowdsourced features of the beacons, including crowdsourced 3D locations of the beacons. A portion (e.g., a block) of the beacon database 142 covering a specific geographic area can be downloaded to the UE 110 and cached as a local copy. This local copy can be used by the 3D positioning client 126 and / or the native positioning engine 124 (e.g., via trilateration, polygonal measurement, or other positioning techniques) to determine the UE's location (e.g., 3D location). Furthermore, information derived through scanning or otherwise collected by components 132-138 of the UE 110 (e.g., beacon identity, signal strength, signal timing, UBP, user activity, etc.) can be periodically (or dynamically in response to triggers) uploaded to the 3D positioning platform 140, which uses this information to update and expand the beacon database 142. To this end, the 3D positioning platform 140 may include a hybrid 2D positioning server 144 and a z-axis positioning server 146. The hybrid 2D positioning server 144 is capable, among other capabilities, of determining (e.g., estimating) the 2D location of the beacon based on crowdsourced information, and the z-axis positioning server 146 is capable, among other capabilities, of determining (e.g., estimating) the altitude of the beacon based on crowdsourced information and, in some cases, additional data from other data sources (e.g., pressure and weather data from the pressure and weather station network 160).

[0020] In the first embodiment, the 3D positioning client 126 on the UE 110 and the z-axis positioning server 146 of the 3D positioning platform 140 implement GNSS-based crowdsourcing technology to determine the beacon altitude, which can then be used for the 3D positioning of the UE 110. Figure 2 This is a flowchart of an example sequence of steps 200 for crowdsourcing beacon altitude using GNSS. Steps 210-220 can be executed in parallel for each of a large number of UEs 110 to crowdsource information. Steps 230-280 can be executed on a 3D positioning platform 140 in the cloud to aggregate the crowdsourced information.

[0021] In step 210, on each UE 110, the 3D positioning client 126 obtains the UE's GNSS-based location determined by the native positioning engine 124 working in conjunction with the GNSS receiver 136. The GNSS-based location can be obtained periodically, in response to a request from a third-party application 128, in response to a request from the 3D positioning client 126, and / or in response to other triggers. In one implementation, the GNSS-based location can be fused location provided by the native positioning engine 124 (e.g., The location-based positioning can be either fused location provider (FLP) positioning or another hybrid positioning calculated using multiple positioning technologies. This fused location positioning combines GNSS location positioning generated using GNSS receiver 136 with location estimates generated using Wi-Fi or cellular data. In another embodiment, GNSS-based location positioning can be pure GNSS location positioning, which is based solely on GNSS measurements without being combined with any other type of measurement. The GNSS-based location positioning, along with a timestamp, can be stored in the local cache of the 3D positioning client 126.

[0022] Simultaneously with step 210, in step 220, on each UE, the 3D positioning client 126 observes beacons within range of the UE 110, including their identity and signal strength (e.g., RSSI), connection status (e.g., “connected” flag), and / or timing measurements (e.g., TA, RTT, etc.), and / or other characteristics. This observation may be the result of a scan performed using the native positioning engine 124 and the wireless network interface 134. The observed beacon characteristics, along with timestamps, may be stored in the local cache of the 3D positioning client 126.

[0023] Periodically, or in response to dynamic triggers (e.g., receiving a user opt-in, detecting an emergency call, etc.), the contents of each UE's local cache can be uploaded in batches to the 3D positioning platform 140 in the cloud. For each UE 110 provided in a batch, in step 230, the z-axis positioning server 146 of the 3D positioning platform 140 estimates the UE's altitude at least in part based on available GNSS-based location positioning (e.g., fused location positioning or pure GNSS location positioning). Such estimation may simply involve extracting the z-axis component from each available GNSS-based location positioning. Alternatively, more complex operations may be performed. As part of this step, one or more altitude quality indicators may be determined for each altitude. In one embodiment, the indicator may be the vertical uncertainty (VPE). The lower the VPE, the better the altitude estimation. In further processing, altitudes with VPEs above a given threshold may be ignored. In another embodiment, the indicator may be the UE's velocity when GNSS-positioned. The lower the velocity, the greater the likelihood that the UE is stationary, and therefore the more suitable its altitude is for determining the beacon altitude. In further processing, altitudes with GNSS positioning velocities above a given threshold can be ignored. The result of this step can be a high-quality list of GNSS-based altitudes and timestamps, which can be used in conjunction with features of observed beacons and timestamps provided as part of a batch.

[0024] In step 240, the z-axis positioning server 146 of the 3D positioning platform 140 establishes a time window (e.g., a 5-second time window) and checks the altitude of the UE 110 and the observed beacon within each time window.

[0025] In step 250, the z-axis positioning server 146 determines whether a LOS exists for each beacon observed in each time window. LOS refers to a straight signal path between two entities that is substantially unobstructed by interfering objects. It can be assumed that in most deployments, LOS will only exist if the UE 110 and the beacon are at substantially the same altitude. For example, considering intermediate floor decking, the UE 110 and the beacon located on different floors (e.g., different floors) of a building typically will not have LOS. While there may be openings between floors that could potentially provide LOS, such as staircases, atriums, etc., the probability that the UE 110 and the beacon are in the same room on the same floor is much higher if LOS exists.

[0026] In some implementations, the Level of Service (LOS) can be determined by comparing a signal strength indicator (e.g., RSSI) with a threshold (e.g., an empirically determined threshold), as high signal strength typically indicates the presence of LOS. The signal strength indicator and threshold used can vary depending on the radio frequency (RF) band / channel, beacon type, model of a beacon type, manufacturer of a beacon type, or other criteria. For example, different signal strength indicators and thresholds can be provided for the 2.4 GHz Wi-Fi band and the 5 GHz Wi-Fi band. Similarly, different signal strength indicators and thresholds can be provided for Wi-Fi APs, Proximity beacon Proximity beacons and AltBeacon TM Proximity beacons provide different signal strength indicators and thresholds. Similarly, different signal strength indicators and thresholds can be provided for one model of Wi-Fi AP compared to another model, or for one Wi-Fi AP manufacturer compared to another manufacturer. Furthermore, multiple different signal strength indicators can be examined and combined in various ways, such as based on radio frequency (RF) bands / channels, beacon type, model of a particular beacon type, manufacturer of a particular beacon type, or other standards.

[0027] Table 1 is a list of different example signal strength indicators and thresholds that can be used to determine LOS in one implementation.

[0028]

[0029]

[0030] In other implementations, the LOS can be determined by checking the connection status (e.g., a connected flag). The UE will typically connect to a beacon with good signal strength, and the formation of such a connection can indicate the presence of a LOS.

[0031] In some other implementations, LOS can be determined by analyzing timing measurements (e.g., TA value, RTT, etc.). A single low timing measurement may not necessarily indicate the presence of LOS. However, when considering multipathing, a signal that has both a low timing measurement (compared to a threshold) and a higher signal strength compared to other relevant signals can be assumed to have LOS. For example, consider multiple signals between UE 110 and a given beacon due to multipathing. If a signal measurement has a low timing measurement and a higher signal strength than other signal measurements, such a signal measurement can be assumed to represent a direct path with LOS. Conversely, if a signal measurement has a low timing measurement but also a lower signal strength than other signal measurements, an obstacle (e.g., a wall, floor, etc.) can be assumed to be present, and therefore such a signal measurement represents a path without LOS.

[0032] It should be understood that signal strength (e.g., RSSI), connectivity status (e.g., connected flag), and timing measurements (e.g., TA value, RTT, etc.) can be combined in various ways to determine the LOS. Furthermore, various other characteristics can be combined with signal strength, connectivity status (e.g., connected flag), and / or timing measurements during this determination process. These combinations may be based at least in part on statistical data measured empirically. In step 260, the z-axis positioning server 146 binds the altitude of the UE 110 to each beacon with an LOS within the corresponding time window. When a single altitude exists within the time window, that altitude can be bound to each beacon. When multiple altitudes exist within the time window, one altitude can be selected. In one implementation, the altitude that is closest in time to the center of the time window can be selected and used. Alternatively, the altitudes can be combined (e.g., averaged), and the result bound to each beacon.

[0033] After performing steps 230-260 for a group of UEs 110 (e.g., a large number of UEs), for each beacon, in step 270, the z-axis positioning server 146 determines the beacon altitude of that beacon based on a set of bound altitudes. The beacon altitude can be determined as a combination (e.g., an average) of the altitudes bound to that beacon. GNSS-based location positioning may individually have significant uncertainties; however, for a sufficiently large set, the average error may be small. Alternatively, the beacon altitude can be based on a previously determined altitude of one or more beacons already in the beacon database 142, which are inferred to be at the same altitude as the beacon based on the bound altitude (e.g., the same floor of a building). For example, if the beacon and a beacon with a previously determined altitude are repeatedly bound to substantially the same altitude, it can be assumed that the two beacons are at the same altitude, and the previously determined altitude can also be assigned to the beacon. Such inference can allow for higher accuracy of altitude propagation between beacons.

[0034] In step 280, the 3D z-axis positioning server 146 updates the beacon database 142 to assign the determined altitude to the beacon. Steps 270-280 can then be repeated for other beacons. Afterward, the updated portion (e.g., a block) of the beacon database 142 can be downloaded to the UE 110 and used by the 3D positioning client 126 to determine the 3D position of the UE 110 (e.g., via trilateration, polygonation, or other positioning techniques).

[0035] In the second embodiment, the 3D positioning client 126 on the UE 110 and the z-axis positioning server 146 of the 3D positioning platform 140 in the cloud implement crowdsourcing technology based on uncalibrated pressure to determine the beacon altitude, which can then be used for the 3D positioning of the UE 110. Figure 3A This is a flowchart of example step sequence 300 for crowdsourcing beacon altitude based on uncalibrated pressure. For better understanding... Figure 3A The steps 300 also referenced Figure 3B , Figure 3B Figure 385 illustrates an example of uncalibrated altitude determination that can be used in a crowdsourced beacon altitude calculation. Steps 310-320 can be performed in parallel for each of the large number of UEs 110 to gather crowdsourced information. Steps 330-380 can be performed on a 3D positioning platform 140 in the cloud to aggregate the crowdsourced information.

[0036] In step 310, on each UE 110, the 3D positioning client 126 establishes a reference point including a reference pressure and a reference altitude. The reference pressure can be UBP (or the average of UBP over a period of time). The reference altitude can be ground altitude (i.e., altitude above ground (AGL) = 0) or another known altitude (e.g., a previously determined altitude of a beacon already in the beacon database 142).

[0037] For example, refer to Figure 3B In this example, the reference point could be a ground elevation of 387.

[0038] Ground altitude or another known elevation can be assumed by examining various markers, which can vary depending on the type of UE 110. For example, for a UE 110 that is a mobile device (e.g., a smartphone) or an IoT device (e.g., a sensor), the marker for ground altitude could be that the UE is in a moving car. The 3D positioning client 126 can monitor the speed of the UE 110 (e.g., as determined by the native positioning engine 124), and if the speed is within a given range consistent with car travel (e.g., between a high threshold and a low threshold), it is concluded that the UE is in a moving car. Since cars typically travel at ground altitude, a reference pressure corresponding to AGL=0 can be established. Similarly, for a UE 110 that is a mobile device (e.g., a smartphone) or a wearable device (e.g., a smartwatch), the marker for ground altitude could be that the UE is located in an area known to have few (or no) buildings. The presence of buildings can be determined based on maps or clustering data. The lack of buildings near the UE can indicate that the UE is likely at ground altitude, and thus a reference pressure corresponding to AGL=0 can be established. Furthermore, for a UE 110 that is a drone (e.g., a UAV), the ground altitude marker could be that the UE is powered on. The 3D positioning client 126 can monitor the UE's power state. Since drones are typically on the ground before they take off, a reference pressure corresponding to AGL=0 can be established. Further, for a UE 110 that is a wearable device (e.g., a smartwatch), the ground altitude marker could be that the UE user is walking or running. The 3D positioning client 126 can monitor the UE 110's speed (e.g., as determined by the native positioning engine 124), and if the speed is within a given range consistent with walking or running (e.g., between a high threshold and a low threshold), and the GNSS-based location is changing (indicating the user is unlikely to be on a treadmill), then the conclusion is drawn that the UE is walking or running. Since users typically walk or run on the ground, a reference pressure corresponding to AGL=0 can be established. Furthermore, for any type of UE 110, the previously determined beacon height marker of a beacon already in the beacon database 142 can be used to determine the LOS to that beacon using any of the techniques described herein. It should be understood that a wide variety of other markers or combinations of markers may be used alternatively.

[0039] In step 312, on each UE 110, the 3D positioning client 126 determines whether the weather conditions have changed relative to a reference point. In one embodiment, it may be assumed that the weather conditions remain substantially unchanged over a period of time (e.g., 1 hour (hr)), and this determination is implemented as a timer (e.g., a 1-hour timer). Alternatively, the weather conditions may be determined based on weather data accessible from other data sources (e.g., the pressure and weather station network 160), information from sensors on the UE, etc.

[0040] If the weather conditions have changed, execution can loop back to step 310, where the positioning client 126 establishes a new reference point. If they have not changed, execution proceeds to step 314, where the 3D positioning client 126 tracks changes in relative altitude relative to the reference point. Tracking may include collecting UBP measurements, collecting markers of user activity, and / or other types of data. UBP measurements can be obtained via an uncalibrated pressure sensor 132. Markers of user activity can be markers indicating known changes in altitude. For example, a marker indicating a user changing floors in a building (e.g., moving up or down a flight of stairs) could be equivalent to a change in altitude of one floor (approximately 3 meters (m)). Markers of user activity can be based on velocity, acceleration, position changes, and / or other types of data collected by components 132-138 of the UE 110, or derived from information collected by components 132-138 of the UE 110. Relative altitude changes (e.g., UBP, user activity markers, etc.) along with timestamps can be stored in a local cache of the 3D positioning client 126.

[0041] For example, refer to Figure 3B The UE can initially move to location 1 on the first floor 392 of building 390 (e.g., an office building), while still essentially on the ground. The 3D positioning client 126 can collect the UBP for location 1 and store it along with a timestamp. The UE can then move to location 3 on the third floor 394 of building 390. The 3D positioning client 126 can collect the UBP for location 3 and store it along with a timestamp.

[0042] Simultaneously with steps 310-314, in step 320, on each UE, the 3D positioning client 126 observes beacons within the UE's range, including their identity, signal strength (e.g., RSSI), connection status (e.g., "connected" flag), timing measurements (e.g., TA, RTT, etc.), and / or other characteristics. This observation may be the result of a scan performed using the native positioning engine 124 and the wireless network interface 134. The observed beacon characteristics, along with timestamps, may be stored in the local cache of the 3D positioning client 126.

[0043] For example, refer to Figure 3B When UE 110 is in position 1, the 3D positioning client 126 can observe beacon 396 on the first floor 392 and beacon 398 on the third floor 394 of building 390, and store their characteristics along with timestamps. Subsequently, when UE 110 is in position 2, the positioning client 126 can again observe beacon 396 on the first floor 392 and beacon 398 on the third floor of building 390, but their characteristics may have changed. The positioning client 126 can store their new characteristics along with timestamps.

[0044] Periodically, or in response to dynamic triggers (e.g., receiving a user opt-in, detecting an emergency call, etc.), the contents of each UE's local cache are uploaded in batches to the cloud-based 3D positioning platform 140. For each UE 110 provided in a batch, in step 330, the z-axis positioning server 146 of the cloud-based 3D positioning platform 140 calculates the UE's altitude based on a reference point and any tracked altitude changes. For example, the z-axis positioning server 146 can use barometric pressure formulas, such as:

[0045]

[0046] Where T is temperature in degrees Celsius (which can be measured by the UE or set as a constant), P0 is the reference pressure, and P is the average of the UBP measurement over a time interval (e.g., 1 second). Similarly, the 3D positioning client 126 can determine altitude changes based on markers of user activity. For example, if user activity indicates climbing a flight of stairs, this can be assumed to correspond to a change of one floor (e.g., 3m). Initially, the z-axis positioning server 146 can simply add the change to the reference altitude. Afterward, the z-axis positioning server 146 can add the change to the previously calculated altitude to produce an updated quantity. As part of step 330, one or more altitude quality indicators can be determined for each altitude. In one embodiment, the indicator can be the VPE, and in further processing, altitudes with VPEs above a given threshold can be ignored. In another embodiment, the indicator can be the velocity of the VPE. In further processing, altitudes with velocities above a given threshold can be ignored. The result of this step can be a high-quality list of absolute altitudes and timestamps based on uncalibrated pressure, which can be used in conjunction with features of observed beacons and timestamps provided as part of a batch.

[0047] For example, refer to Figure 3BIn this example, the 3D positioning platform 140 can calculate that the altitude of the UE at location 1 is still essentially on the ground, based on the relative invariance of UBP. The 3D positioning platform 140 can calculate that the altitude of the UE at location 2 has increased by two floors, based on the relative change in UBP. These altitudes, along with the observed beacons 396 and 398 and the timestamp, can be provided as part of a batch. In step 340, the z-axis positioning server 146 of the 3D positioning platform 140 establishes a time window (e.g., a 5-second time window) and checks the altitude of the UE 110 and the observed beacons within each time window.

[0048] In step 350, the z-axis positioning server 146 determines whether a LOS exists for each beacon observed in each time window. Similar to the embodiments discussed above, the LOS can be determined based on signal strength (e.g., RSSI), connectivity status (e.g., “connected” flag), timing measurements (e.g., TA value, RTT, etc.) and / or other characteristics.

[0049] For example, refer to Figure 3B The z-axis positioning server 146 can determine that although the UE has a LOS with beacon 396 at position 1, it does not have a LOS with beacon 398. The z-axis positioning server 146 can determine that after the UE moves to position 2, it has a LOS with beacon 398, but not with beacon 396.

[0050] In step 360, the z-axis positioning server 146 binds the altitude of the UE 110 to each beacon with a LOS within the corresponding time window. When a single altitude exists within the time window, that altitude can be bound to each beacon. When multiple altitudes exist within the time window, one altitude can be selected. In one implementation, the altitude that is closest in time to the center of the time window can be selected and used. Alternatively, the altitudes can be combined (e.g., averaged) and the result bound to each beacon.

[0051] For example, refer to Figure 3B The z-axis positioning server 146 can determine to bind the ground elevation to beacon 396 and bind the elevations of the two higher floors to beacon 398.

[0052] After performing steps 330-360 for a set of UEs 110 (e.g., a large number of UEs), for each beacon, in step 370, the z-axis positioning server 146 determines the beacon altitude based on a set of bound altitudes. The beacon altitude can be determined as a combination (e.g., an average) of the heights bound to the beacon. Absolute altitudes based on uncalibrated pressures may each have significant uncertainty. However, for a sufficiently large set, the average error may be small. Alternatively, the beacon altitude can be based on previously determined altitudes of one or more beacons already in the beacon database 142, which are inferred to be at the same altitude (e.g., a floor in a building) based on the bound altitudes. For example, if the beacon and a beacon with a previously determined altitude are repeatedly bound to substantially the same altitude, it can be assumed that the two beacons are at the same altitude, and the previously determined altitude can also be assigned to the beacon. Such inference can allow for higher accuracy altitude propagation between beacons at the same floor.

[0053] In step 380, the 3D z-axis positioning server 146 updates the beacon database 142 to assign the determined altitude to the beacon. Steps 370-380 can then be repeated for other beacons. Afterwards, the updated portion (e.g., a block) of the beacon database 142 can be downloaded to the UE and used by the 3D positioning client 126 to determine the UE's 3D position (e.g., via trilateration, polygonation, or other positioning techniques).

[0054] In the third embodiment, the 3D positioning client 126 on the UE 110 and the z-axis positioning server 146 of the cloud-based 3D positioning platform 140 implement a combination of beacon altitude crowdsourcing and pressure sensor calibration techniques. This technique allows beacon altitude to be obtained for 3D positioning (e.g., via trilateration, polygonation, or other positioning techniques), while 3D positioning can also be performed using calibrated pressure measurements. Figure 4 This is a flowchart of an example sequence of steps 400 for a combined technique of beacon altitude crowdsourcing and pressure sensor calibration. Steps 410-420 can be performed in parallel for each of a large number of UEs 110 to crowdsource information. Steps 430-494 can be performed on a 3D positioning platform 140 in the cloud to aggregate the crowdsourced information.

[0055] In step 410, on each UE 110, the 3D positioning client 126 obtains the UE's GNSS-based location determined by the native positioning engine 124 working in conjunction with the GNSS receiver 136. The GNSS-based location can be obtained periodically, in response to a request from a third-party application 128, in response to a request from the 3D positioning client 126, and / or in response to other triggers. In one implementation, the GNSS-based location can be fused location provided by the native positioning engine 124 (e.g., The location-based positioning (FLP) method combines GNSS location data generated using GNSS receiver 136 with location estimates generated using radio or cellular data. In another embodiment, GNSS-based location positioning can be pure GNSS location positioning, which is based on GNSS measurements without being combined with any other type of measurement. The GNSS-based location data, along with a timestamp, can be stored in the local cache of the 3D positioning client 126.

[0056] In step 420, on each UE 110, essentially simultaneously with obtaining GNSS-based positioning, the 3D positioning client 126 collects UBP measurements. UBP measurements can be obtained via an uncalibrated pressure sensor 132 (e.g., an uncalibrated MEMS sensor). GNSS-based positioning and UBP can be collectively referred to as “calibration points.” Steps 410-420 can be repeated to generate a number of calibration points, and each calibration point, along with a timestamp, is stored in the local cache of the 3D positioning client 126.

[0057] In parallel with steps 410-420, on each UE, in step 430, the 3D positioning client 126 observes beacons within range of the UE 110 and their characteristics, including their identity, signal strength (e.g., RSSI), connection status (e.g., “connected” flag), beacon timing (e.g., TA, RTT, etc.), and / or other characteristics. This observation may be the result of a scan performed using the native positioning engine 124 and the wireless network interface 134. The observed beacon characteristics, along with their timestamps, may be stored in the local cache of the 3D positioning client 126.

[0058] Periodically, or in response to dynamic triggers, the contents of each UE's local cache can be uploaded in batches to the cloud-based 3D positioning platform 140. For each calibration point, in step 440, the z-axis positioning server 146 of the 3D positioning platform 140 calculates the altitude of the UE 110 based on UBP measurements, for example, using the barometric pressure formula adjusted for the final deviation (calculated below) discussed above. In the first iteration, the final deviation can be set to zero. In some implementations, the calculation may also include, for example, weather data (e.g., barometric pressure correction) from the pressure and weather station network 160. Such weather data may be based on measurements collected simultaneously with the UBP measurements, or on historical measurements indicating trends or patterns.

[0059] In step 450, the z-axis positioning server 146 estimates the altitude of the UE 110 based on GNSS-based location positioning, for example by extracting the z-axis component from the GNSS-based location positioning.

[0060] In step 460, the z-axis positioning server 146 compares the elevation calculated by UBP with the elevation estimated by GNSS and calculates the individual bias (e.g., as a difference). This individual bias is combined with previous individual biases (e.g., averaged) to produce a final bias. The individual bias can also be used as an indicator of the quality of the associated UBP-calculated elevation. If the UBP-calculated elevation has at least a predetermined quality (e.g., associated with an individual bias less than a threshold), the UBP-calculated elevation is retained for use as the crowdsourced beacon elevation. Otherwise, the UBP-calculated elevation may be ignored in further processing.

[0061] After repeating steps 450-460 for each calibration point, in step 462, the final deviation is returned to UE 110 for calibrating the pressure sensor, thereby enabling UE altitude determination based on the calibrated pressure.

[0062] In addition, the high-quality UBP-calculated altitude and observed beacons are used to crowdsource beacon altitudes to update the beacon database 142. In step 470, the z-axis positioning server 146 of the cloud-based 3D positioning platform 140 establishes a time window (e.g., a 5-second time window) and checks the UBP-calculated altitude of the UE 110 from the above calibration operation and the observed beacons falling within the time window.

[0063] In step 480, the z-axis positioning server 146 determines whether a LOS exists for each beacon observed in each time window. Similar to the embodiments discussed above, the LOS can be determined based on signal strength (e.g., RSSI), connectivity status (e.g., “connected” flag), timing measurements (e.g., TA value, RTT, etc.), and / or other characteristics.

[0064] In step 490, the z-axis positioning server 146 binds the altitude of the UE 110 to each beacon with a LOS. When a single UBP-calculated altitude exists within a time window, that altitude can be bound to each beacon. When multiple UBP-calculated altitudes exist within a time window, one altitude can be selected. In one implementation, the UBP-calculated altitude closest in time to the center of the time window can be selected and used. Alternatively, the altitudes calculated by the individual UBPs can be combined (e.g., averaged) and the result bound to each beacon. As described above, the altitude of the UE 110 can be corrected, for example, based on weather data from the pressure and weather station network 160. Other corrections based on real-time or historical data obtained from this or other sources can also be applied at this stage.

[0065] After performing steps 470-490 for a group of UEs 110 (e.g., a large number of UEs), for each beacon, in step 492, the z-axis positioning server 146 determines the beacon altitude based on a set of bound altitudes. Alternatively, the beacon altitude may be based on previously determined altitudes of one or more beacons already in the beacon database 142, which are inferred to be at the same altitude (e.g., a floor in a building) based on their bound altitudes.

[0066] In step 494, the 3D z-axis positioning server 146 updates the beacon database 142 to assign the determined altitude to the beacon. Steps 492-494 can then be repeated for other beacons. The updated portion (e.g., a block) of the beacon database 142 can then be downloaded to the UE 110 and used by the 3D positioning client 126 to determine the UE's 3D position (e.g., via trilateration, polygonation, or other positioning techniques).

[0067] The above description details various crowdsourcing techniques for determining beacon altitude, which can then be used for 3D positioning of the UE. It should be understood that these techniques, and parts thereof, may be used together, individually, or in combination with other techniques, depending on the implementation. Furthermore, it should be understood that aspects of these techniques may be modified, added to, removed from, or otherwise altered depending on the implementation. For example, while some of the above description may suggest that determining LOS is a binary decision, it should be understood that LOS is not necessarily binary but can be determined probabilistically. Multiple beacons at different altitudes may have corresponding probabilities of having LOS with UE 110 at a given time, and their altitudes may be weighted or otherwise combined to derive the UE's altitude.

[0068] Similarly, while some of the descriptions above may imply that certain operations can be performed by the 3D positioning client 126 of the UE 110 or the 3D positioning platform in the cloud, it should be understood that these operations can be performed in various ways at different locations, split between the UE 110, the cloud, or elsewhere.

[0069] Furthermore, while some of the descriptions above may suggest that operations can occur in real time, periodically, or in response to dynamic triggers, it should be understood that operations can occur at any of a variety of different times and in response to any of a variety of different standards. For example, GNSS-based location, UBP measurements, observed beacon characteristics, etc., can be stored along with timestamps (e.g., cached on UE 110 or maintained in the cloud) for subsequent processing. When processed, the stored information can be combined with weather data (e.g., from the pressure and weather station network 160) with similar timestamps to calibrate the data used for UE altitude determination and / or improve the accuracy of beacon altitude determination.

[0070] In general, while specific examples of hardware and software have been discussed above, it should be understood that these technologies can be implemented using a wide variety of hardware, software, and combinations thereof. Such hardware may include various types of processors, memory chips, programmable logic circuits, application-specific integrated circuits, and / or other types of hardware components that enable software execution. Such software may include executable instructions stored on a non-transitory electronic device readable medium, such as volatile or persistent storage devices, hard drives, or other data storage. Combinations of software and hardware can be adapted to different environments and applications. Most importantly, it should be understood that the above descriptions are for illustrative purposes only.

Claims

1. A method for crowdsourcing beacon altitude for three-dimensional 3D positioning of a user equipment (UE), comprising: For each of the multiple UEs The altitude of the UE at a given time is estimated by software executing on one or more electronic devices based on one or more GNSS-based location data of the UE. The software determines, based on the UE's observations of the beacons, that one or more beacons have a LOS with the UE at that time, and The altitude of the UE is bound to each of the one or more beacons that have a time of loss (LOS) at the time, wherein the time is a time window, and the binding binds the altitude of the UE when it is closest to the center of the time window to each beacon. For one or more beacons, The beacon altitude is determined based on a set of bound altitudes for the corresponding beacon, and The beacon database is updated using the determined beacon altitude, and the beacon database can be used to calculate the 3D position of the UE.

2. The method of claim 1, further comprising: The software provides at least a portion of the beacon database to the UE so that the UE can calculate their 3D positions.

3. The method as described in claim 1, wherein the GNSS-based location positioning is fused location positioning.

4. The method of claim 1, wherein the GNSS-based positioning is based solely on GNSS measurements.

5. The method of claim 1, further comprising: The GNSS-based location of the UE is obtained based on the signal received by the UE's GNSS receiver; as well as Based on the signal received by the UE's wireless network interface, one or more beacons within the UE's range are observed.

6. The method of claim 1, wherein determining that one or more beacons have a LOS further comprises: Compare the signal strength indicator of each of the one or more beacons with a threshold; as well as It is determined that the signal strength indicator exceeds the threshold.

7. The method of claim 6, wherein at least one of the signal strength indicator or the threshold is based on a radio frequency (RF) band / channel, a beacon type, a model of the beacon type, or a manufacturer of the beacon type.

8. The method of claim 1, wherein determining that one or more beacons have a LOS further comprises: Check the connection status of the UE with each of the one or more beacons; as well as The connection status indicates that the UE is connected.

9. The method of claim 1, wherein determining that one or more beacons have a LOS further comprises: Compare timing measurements and signal strengths of multiple signal measurements for the beacon; as well as The signal measurement whose timing measurement value is less than a threshold is determined to have a signal strength greater than that of the other signal measurements among the plurality of signal measurements.

10. The method of claim 1, wherein determining the beacon altitude based on the set of bound altitudes further comprises: The average altitude of the set of bound altitudes is calculated.

11. The method of claim 1, wherein determining the beacon altitude based on the set of bound altitudes further comprises: It is determined that the beacon and another beacon with a previously determined altitude are bound to the same altitude; as well as The previously determined altitude of the other beacon is assigned to the beacon.

12. A method for crowdsourcing beacon altitude for three-dimensional 3D positioning of a user equipment (UE), comprising: For each of the multiple UEs Software executed on one or more electronic devices estimates the altitude of the UE at a given time based on a reference point measured by the UE and the tracked altitude change measured by the UE. The software determines, based on the UE's observations of the beacons, that one or more beacons have a LOS with the UE at that time, and The altitude of the UE is bound to each of the one or more beacons that have a time of loss (LOS) at the time, wherein the time is a time window, and the binding binds the altitude of the UE when it is closest to the center of the time window to each beacon. For one or more beacons, The beacon altitude is determined based on a set of bound altitudes for the corresponding beacon, and The beacon database is updated using the determined beacon altitude, and the beacon database can be used to calculate the 3D position of the UE.

13. The method of claim 12, further comprising: The software provides at least a portion of the beacon database to the UE so that the UE can calculate their 3D positions.

14. The method of claim 12, wherein the reference point includes a reference pressure and a reference altitude, the tracked altitude change includes uncompensated barometric pressure (UBP) measured by the UE, and estimating the altitude of the UE at the time further includes: The barometric pressure formula is applied to the reference pressure and the UBP to calculate the altitude change from the reference altitude.

15. The method of claim 12, wherein the reference point includes a reference altitude, the tracked altitude change includes markers of user activity relating to altitude changes, and estimating the altitude of the UE at the time further includes: The reference altitude is adjusted based on the altitude changes indicated by the user activity.

16. The method of claim 12, wherein the reference point includes a reference altitude, and the method further comprises: The reference point is established for the UE based on the uncompensated air pressure UBP measured by the UE's pressure sensor; as well as Based on the signal received by the UE's wireless network interface, one or more beacons within the UE's range are observed.

17. The method of claim 16, wherein the reference point further comprises a reference elevation at ground level, and establishing the reference point further comprises: The UE is assumed to be at ground level based on a tag associated with its type, wherein two or more different types of UEs have different tags indicating that they are at ground level.

18. The method of claim 12, wherein, Determining that one or more beacons have a LOS further includes: Compare the signal strength indicator of each of the one or more beacons with a threshold; and It is determined that the signal strength indicator exceeds the threshold.

19. The method of claim 18, wherein at least one of the signal strength indicator or the threshold is based on a radio frequency (RF) band / channel, a beacon type, a model of the beacon type, or a manufacturer of the beacon type.

20. The method of claim 12, wherein, Determining that one or more beacons have a LOS further includes: Check the connection status of the UE with each of the one or more beacons; and The connection status indicates that the UE is connected.

21. The method of claim 12, wherein, Determining that one or more beacons have a LOS further includes: Compare timing measurements and signal strength of multiple signal measurements for the beacon; and The signal measurement whose timing measurement value is less than a threshold is determined to have a signal strength greater than that of the other signal measurements among the plurality of signal measurements.

22. The method of claim 12, wherein determining the beacon altitude based on the set of bound altitudes further comprises: The average altitude of the set of bound altitudes is calculated.

23. The method of claim 12, wherein determining the beacon altitude based on the set of bound altitudes further comprises: It is determined that the beacon and another beacon with a previously determined altitude are bound to the same altitude; as well as The previously determined altitude of the other beacon is assigned to the beacon.

24. A method for crowdsourcing beacon altitude for three-dimensional 3D positioning of a user equipment (UE), comprising: For each of the multiple calibration points The software executing on one or more electronic devices calculates the UE's altitude at a given time based on uncompensated barometric pressure (UBP) measurements; Software executing on one or more electronic devices estimates the altitude of the UE at a given time based on the UE's GNSS-based positioning. Individual bias is calculated by comparing the altitude calculated by UBP with the altitude estimated by GNSS. Multiple individual deviations are combined to produce a final deviation, which is returned to the UE to calibrate the UE's pressure sensor; For one or more beacons, The beacon altitude is determined based on altitude calculations from multiple UBPs at calibration points. The beacon database is updated using the determined beacon altitude, and this beacon database can be used to calculate the UE's 3D position. The determination of beacon altitude based on the altitude calculated from the multiple UBPs includes: The software determines, based on the UE's observations of the beacons, that one or more beacons have a LOS with the UE at that time, and The altitude calculated by the UE's UBP is bound to each of the one or more beacons that have a LOS at the time, wherein the time is a time window, and the binding binds the altitude of the UE when it is closest to the center of the time window to each beacon. The beacon altitude is determined based on a set of tethered altitudes for the corresponding beacon.

25. The method of claim 24, further comprising: The software provides at least a portion of the beacon database to the UE so that the UE can calculate their 3D positions.

26. The method of claim 24, wherein, Determining that one or more beacons have a LOS further includes: Compare the signal strength indicator of each of the one or more beacons with a threshold; and It is determined that the signal strength indicator exceeds the threshold.

27. The method of claim 26, wherein at least one of the signal strength indicator or the threshold is based on a radio frequency (RF) band / channel, a beacon type, a model of the beacon type, or a manufacturer of the beacon type.

28. The method of claim 24, wherein, Determining that one or more beacons have a LOS further includes: Compare timing measurements and signal strength of multiple signal measurements for the beacon; and The signal measurement whose timing measurement value is less than a threshold is determined to have a signal strength greater than that of other signal measurements among the plurality of signal measurements.

29. The method of claim 24, further comprising: The GNSS-based location of the UE is obtained based on the signals received by the UE's GNSS receiver; UBP is measured by the pressure sensor of the UE; as well as Based on the signal received by the UE's wireless network interface, one or more beacons within the UE's range are observed.

Images