Patent Application
20240241263
The present disclosure relates generally to the field of satellite-based positioning.
Global Navigation Satellite Systems (GNSS) positioning of mobile devices (e.g., consumer electronics, vehicles, assets, drones, etc.) can provide accurate positioning of a GNSS receiver in open sky scenarios. However, because GNSS satellites are distant compared with other satellites, their signals are relatively weak, and they move relatively slowly across the sky. This can make GNSS-based positioning more susceptible to degradation due to blockage if large parts of the sky are obstructed. They may also be more susceptible to spoofing, where a false signal may be stronger than the relatively weak GNSS signal. Solutions for using Low-Earth Orbit (LEO) satellites for positioning thus far have often required additional hardware on the LEO satellites.
Embodiments described herein provide for determining Position, Velocity, and Time (PVT) information of a LEO satellite by leveraging a known position of a mobile device comprising a terrestrial satellite receiver of the LEO satellite and using ranging measurements (e.g., range and/or range rate) of the LEO satellite taken at the mobile device. According to some embodiments, this PVT information can be shared by the mobile device with the server and/or other mobile devices, and information from multiple mobile devices can be crowdsourced to determine robust PVT information for a LEO satellite. Once the PVT information is determined, it can be used to subsequently for positioning of the mobile device and/or other mobile devices.
An example method of determining Position, Velocity, and Time (PVT) information of a Low-Earth Orbit (LEO) satellite for LEO-based positioning, according to this disclosure, comprises obtaining a known position of a mobile device comprising a LEO receiver. The method also comprises obtaining range information indicative of a range between the mobile device and the LEO satellite, the range information obtained from one or more measurements of a radio frequency (RF) signal transmitted by the LEO satellite and received by the LEO receiver of the mobile device. The method also comprises determining the PVT information of the LEO satellite based at least in part on the known position of the mobile device and the range information.
An example device for determining Position, Velocity, and Time (PVT) information of a Low-Earth Orbit (LEO) satellite for LEO-based positioning, according to this disclosure, comprises a transceiver, a memory, one or more processors communicatively coupled with the transceiver and the memory, wherein the one or more processors are configured to obtain a known position of a mobile device comprising a LEO receiver. The one or more processing units are further configured to obtain range information indicative of a range between the mobile device and the LEO satellite, the range information obtained from one or more measurements of a radio frequency (RF) signal transmitted by the LEO satellite and received by the LEO receiver of the mobile device. The one or more processing units are further configured to determine the PVT information of the LEO satellite based at least in part on the known position of the mobile device and the range information.
An example apparatus for determining Position, Velocity, and Time (PVT) information of a Low-Earth Orbit (LEO) satellite for LEO-based positioning, according to this disclosure, comprises means for obtaining a known position of a mobile device comprising a LEO receiver. The apparatus further comprises means for obtaining range information indicative of a range between the mobile device and the LEO satellite, the range information obtained from one or more measurements of a radio frequency (RF) signal transmitted by the LEO satellite and received by the LEO receiver of the mobile device. The apparatus further comprises means for determining the PVT information of the LEO satellite based at least in part on the known position of the mobile device and the range information.
According to this disclosure, an example non-transitory computer-readable medium stores instructions for determining Position, Velocity, and Time (PVT) information of a Low-Earth Orbit (LEO) satellite for LEO-based positioning, the instructions comprising code for obtaining a known position of a mobile device comprising a LEO receiver. The instructions further comprise code for obtaining range information indicative of a range between the mobile device and the LEO satellite, the range information obtained from one or more measurements of a radio frequency (RF) signal transmitted by the LEO satellite and received by the LEO receiver of the mobile device. The instructions further comprise code for determining the PVT information of the LEO satellite based at least in part on the known position of the mobile device and the range information.
This summary is neither intended to identify key or essential features of the claimed subject matter, nor is it intended to be used in isolation to determine the scope of the claimed subject matter. The subject matter should be understood by reference to appropriate portions of the entire specification of this disclosure, any or all drawings, and each claim. The foregoing, together with other features and examples, will be described in more detail below in the following specification, claims, and accompanying drawings.
Like reference symbols in the various drawings indicate like elements, in accordance with certain example implementations. In addition, multiple instances of an element may be indicated by following a first number for the element with a letter or a hyphen and a second number. For example, multiple instances of an element 110 may be indicated as 110-1, 110-2, 110-3 etc. or as 110a, 110b, 110c, etc. When referring to such an element using only the first number, any instance of the element is to be understood (e.g., element 110 in the previous example would refer to elements 110-1, 110-2, and 110-3 or to elements 110a, 110b, and 110c).
Several illustrative embodiments will now be described with respect to the accompanying drawings, which form a part hereof. While particular embodiments, in which one or more aspects of the disclosure may be implemented, are described below, other embodiments may be used, and various modifications may be made without departing from the scope of the disclosure or the spirit of the appended claims.
As described herein, a satellite receiver, such as a Global Navigation Satellite Systems (GNSS) and/or Low-Earth Orbit (LEO) satellite receiver, may be integrated into a mobile device comprising an electronic device or system. Such a mobile device can include, for example, consumer, industrial, and/or commercial electronics, vehicles, assets, vessels, and the like. As described herein, a location estimate of the satellite receiver or mobile device into which the satellite receiver is integrated may be referred to as a location, location estimate, location fix, fix, position, position estimate, or position fix of the satellite receiver or mobile device. Moreover, the location estimate may be geodetic, thus providing location coordinates for the mobile device (e.g., latitude and longitude) which may or may not include an altitude component (e.g., height above sea level, height above or depth below ground level, floor level, or basement level). In some embodiments, a location of the satellite receiver and/or mobile device comprising the satellite receiver may also be expressed as an area or volume (defined either geodetically or in civic form) within which the satellite receiver is expected to be located with some probability or confidence level (e.g., 67%, 95%, etc.). In the description contained herein, the use of the term location may comprise any of these variants unless indicated otherwise. When computing the location of a satellite receiver, such computations may solve for local X, Y, and possibly Z coordinates and then, if needed, convert the coordinates from one coordinate frame to another.
As noted, embodiments described herein provide for determining Position, Velocity, and Time (PVT) information of a LEO satellite by leveraging a known position of a mobile device comprising a terrestrial satellite receiver of the LEO satellite and using ranging measurements (e.g., range and/or range rate) of the LEO satellite taken at the mobile device. According to some embodiments, this PVT information can be shared by the mobile device with the server and/or other mobile devices, and information from multiple mobile devices can be crowdsourced to determine robust PVT information for a LEO satellite. Once the PVT information is determined, it can be used to subsequently for positioning of the mobile device and/or other mobile devices. Additional details will follow after an initial description of relevant systems and technologies.
It will be understood that the diagram provided in
GNSS positioning is based on trilateration, which is a method of determining position by measuring distances to points at known coordinates. In general, the determination of the position of a GNSS receiver 110 in three dimensions may rely on a determination of the distance between the GNSS receiver 110 and four or more satellites 130. As illustrated, 3D coordinates may be based on a coordinate system (e.g., XYZ coordinates; latitude, longitude, and altitude; etc.) centered at the earth's center of mass. A distance between each satellite 130 and the GNSS receiver 110 may be determined using precise measurements made by the GNSS receiver 110 of a difference in time from when a radio frequency (RF) signal is transmitted from the respective satellite 130 and when it is received at the GNSS receiver 110. To help ensure accuracy, not only does the GNSS receiver 110 need to make an accurate determination of when the respective signal from each satellite 130 is received, but many additional factors need to be considered and accounted for. These factors include, for example, clock differences at the GNSS receiver 110 and satellite 130 (e.g., clock bias), a precise location of each satellite 130 at the time of transmission (e.g., as determined by the broadcast ephemeris), the impact of atmospheric distortion (e.g., ionospheric and tropospheric delays), and the like.
To perform a traditional GNSS position fix, the GNSS receiver 110 can use code-based positioning to determine its distance to each satellite 130 based on a determined delay in a generated pseudorandom binary sequence received in the RF signals received from each satellite, in consideration of the additional factors and error sources previously noted. With the distance and location information of the satellites 130, the GNSS receiver 110 can then determine a position fix for its location. This position fix may be determined, for example, by a Standalone Positioning Engine (SPE) executed by one or more processors of the GNSS receiver 110. However, code-based positioning is relatively inaccurate and, without error correction, and is subject to many of the previously described errors. Even so, code-based GNSS positioning can provide an positioning accuracy for the GNSS receiver 110 on the order of meters.
More accurate carrier-based range estimation is based on a carrier wave of the RF signals from satellites and may use measurements at a base or reference station (not shown) to perform error correction to help reduce errors from the previously noted error sources. More specifically, errors (e.g., atmospheric errors sources) in the carrier-based range estimate of satellites 130 observed by the GNSS receiver 110 can be mitigated or canceled based on similar carrier-based range estimation of the satellites 130 using a highly accurate GNSS receiver at the base station at a known location. These measurements and the base station's location can be provided to the GNSS receiver 110 for error correction. This position fix may be determined, for example, by a Precise Positioning Engine (PPE) executed by one or more processors of the GNSS receiver 110. More specifically, in addition to the information provided to an SPE, the PPE may use base station GNSS measurement information, and additional correction information, such as troposphere and ionosphere, to provide a high accuracy, carrier-based position fix. Several GNSS techniques can be adopted in PPE, such as Differential GNSS (DGNSS), Real Time Kinematic (RTK), and Precise Point Positioning (PPP), and may provide a sub-meter accuracy (e.g., on the order of centimeters).
While positioning provided by GNSS satellites using these techniques often can be accurate and reliable, it may have its drawbacks relative to LEO satellites. Additional detail regarding GNSS satellites and LEO satellites is provided with regard to
Generally put, orbital distance 220 of GNSS systems are approximately 20,000 km. More specifically, the satellite orbits of GNSS systems range between 19130 km (GLONASS orbit 230) and 23222 km (Galileo orbit 240). At this altitude, satellites orbit the earth 210 on the order of approximately 11 to 14 hours, and atmospheric effects on satellite orbit are typically negligible.
The LEO orbital distance 250 of an LEO satellite in LEO orbit 260, on the other hand, is roughly 10 times closer. That is, LEO orbital distance 250 is below approximately 2,000 km. At this altitude, satellites may orbit the earth 210 in fewer than 128 minutes. In addition to the International space Station (ISS), Hubble space telescope, and other satellites supported by militaries, governments, national agencies, and/or international agencies, LEO satellites may also comprise commercial satellites. These commercial satellites may, for example, support telecom applications (e.g., satellite-based Internet and radio), imaging, and the like.
Although GNSS satellites are typically used for positioning, LEO satellites may offer some advantages over traditional GNSS positioning. Given the proximity of LEO satellites, they may be capable of sending much stronger signals (e.g., 30 dB stronger than GNSS), which may allow for easier detection of signals by satellite receivers, and less vulnerability to spoofing and jamming. The speed at which LEO satellites orbit the earth 210 also provides for faster changing geometry (approximately 15 times faster), which can lead to more resistance to multipath errors and can be beneficial in integer carrier phase ambiguity resolution.
Despite those advantages, there are drawbacks for using LEO satellites for positioning. For example, satellite position information for LEO satellites, such as ephemerides (meter-level accurate satellite position and clock) typically are not available. This is because LEO satellites are typically not designed for positioning, thus, an accurate timing source (e.g., an atomic clock) is unnecessary, and there may be no ground control segment (GCS) needed to provide ephemeris and almanac. Thus, without accurate PVT information of LEO satellites, it can be difficult to perform positioning of terrestrial-based devices (e.g., mobile devices) using measurements of signals from LEO satellites with an accuracy or robustness similar to GNSS positioning.
Some solutions may comprise equipping an LEO satellite with the GNSS receiver, enabling the LEO satellite to determine its location using GNSS signals from GNSS satellites. But this, too, has its drawbacks. For example, this solution would necessarily exclude any existing LEO satellites that do not already have GNSS receivers. Further, equipping new LEO satellites with GNSS receivers mean additional payload and power consumption, which can be especially impactful for smaller LEO satellites.
Embodiments herein address these and other issues by determining accurate PVT information of an LEO satellite using a terrestrial satellite receiver at a known position. In particular, a terrestrial device, such as a mobile device, may be able to determine its position using positioning techniques such as GNSS, network-based positioning techniques (e.g., positioning performance by mobile broadband and/or wireless local area network (WLAN) networks), or the like. The terrestrial satellite receiver can then measure signals from the LEO satellite to determine a range and trajectory of the LEO satellite, and derived PVT information of the LEO satellite based on the measurements and the known position of the terrestrial satellite receiver. The PVT information may then be shared with other devices (e.g., other mobile devices, a server, etc.), and used for positioning of mobile devices.
It can be noted that although a single mobile device 310 and single LEO satellite 320 are illustrated in
Further, in the example illustrated in
To determine the PVT information of the LEO satellite 320, the mobile device 310 can have (1) capability of determining its position, and (2) capability of performing measurements to determine the range 330. As previously noted, the position of the mobile device 310 can be determined via one or more techniques including GNSS positioning (e.g., if the mobile device is equipped with a GNSS receiver), wireless network-based positioning (e.g., if the mobile device is equipped with an LTE, NR, and/or similar mobile communication receiver), sensor-based positioning, dead reckoning, or the like. As for determining range 330, any of a variety of techniques may be performed for generating pseudo-range between the LEO satellite 320 and mobile device 310. These techniques may be dependent, for example, on modulation and/or other properties of signals transmitted by the LEO satellite 320 and received by a mobile device 310. Additionally, range rates, or rates at which the range 330 changes over time, also may be determined from the frequency offset between the nominal frequency and the actual track frequency.
For example, according to some embodiments, an LEO satellite 320 may comprise a dedicated Positioning, Navigation, and Timing (PNT) service to facilitate range determination. This can include, for example, communications providing Satellite Time and Location (STL), which is deployed on Iridium and Iridium NEXT satellites. The process of generating pseudorange is similar to generating pseudo-range in GPS. In particular, the quadrature phase-shift keying (QPSK) transmission scheme used by such satellites can facilitate precision measurements by providing QPSK data at the beginning of an STL burst that may be manipulated to form a continuous wave (CW) marker used for burst detection and coarse measurement. The remaining QPSK data in the STL burst may then be organized into pseudorandom sequences. This can reduce the effective information data rate while providing a mechanism for precise measurement via correlation with locally generated sequences.
Embodiments may require very little to implement pseudo-range determination using this technique. Little or no additional hardware may be needed on the LEO satellite 320 to implement the STL communications to provide the PNT service, and a modernized GNSS receiver of the mobile device 310 may only need minor modification to generate pseudorange measurements from the LEO satellite signal.
Additionally or alternatively, measurements of the range 330 may be performed without a PNT service provided by the LEO satellite 320. For example, if the LEO satellite 320 transmits Code-division multiple access (CDMA) signals, or any other form of Direct-Sequence Spectrum Spread (DS-SS), a mobile device 310 may be able capture a pseudo-random-noise code (PRN code) and generate pseudoranges, as may be performed in GNSS to get high timing (ranging accuracy). The challenge is some modifications to the downlink protocol may be required to provide precise timing of the downlink signals. For example, “seconds in a week” (SOW) in a GPS sub-frame is the timing information embedded in GPS signals. An example modification to an LEO protocol may comprise adding a time stamp to a message transmitted by an LEO satellite (e.g., LEO satellite 320) in the downlink signals to a receiver (e.g., at mobile device 310) to provide something similar to SOW in GPS. Instead of SOW, the time stamp could be “milliseconds in an hour,” from which a receiver can easily derive the absolute full time. Other embodiments may use additional or alternative types of timestamps, depending on desired functionality.
PVT information of the LEO satellite 320 can be determined at the mobile device 310 (or, as explained below, a server or other device) using a positioning engine. In particular, a positioning engine comprising a Extended Kalman Filter (EKF) or Weighted Least Squares (WLS) algorithm can use information from the range measurements to determine PVT information of the LEO satellite 320. According to some embodiments, a course position of the LEO satellite 320 may be obtained from an almanac and used as a starting point for the positioning engine. Range measurements, including ranges and (if available) range rates), as well as the known position of the mobile device 310, can then be provided to the EKF/WLS algorithm to determine PVT information of the LEO satellite 320. (Additional details regarding a specific technique are provided hereafter.) According to some embodiments, 8-12 states may be needed to estimate PVT information of the LEO satellite 320, and thus PVT information can be determined in 12 epochs (measurement/estimation periods), or fewer if range rates are available. Similar to many GNSS applications, each epoch may be one second, thus a solution for the PVT information of the LEO satellite 320 may take as little as 6-12 seconds. That said, if more data is available (e.g., from other satellite receivers, as described in more detail below) PVT information may be determined in less time. On the other hand, more data may be collected over a longer period of time, according to some embodiments, to help ensure a robust determination of the PVT information. Determining PVT information of an LEO satellite 320 in this manner can often have an accuracy within a few meters. This can be input into a gravitational model, as explained in more detail below, to provide sufficient ephemeris for subsequent position determination based on the PVT information.
As previously indicated, range measurements and/or PVT information of the LEO satellite 320 may be used by the mobile device 310 and/or shared among other devices to enable subsequent positioning of the mobile device 310 and/or other devices using the LEO satellite 320. In a stand-alone mode, the mobile device 310 may determine PVT information of the LEO satellite 320 at a time during which the location of the mobile device 310 is known or can be determined using means other than the LEO satellite 320. For example, in a “GNSS benign” environment where GNSS positioning of the mobile device 310 is available, the mobile device 310 may determine its location and make range measurements (across 6-12 epochs, if needed, as previously described) to determine PVT information of the LEO satellite 320 at time T0. At a subsequent time, TK, in a GNSS denied or degraded environment when GNSS positioning is unavailable, the mobile device 310 can use a gravitational model (an example of which is described hereafter) and the previously-determined PVT information of the LEO satellite 320 to determine current PVT information for time TK. Together with new range of the LEO satellite 320 by the mobile device 310, the current PVT information of the LEO satellite 320 can be used to determine the position of the mobile device 310 at time TK.
In a crowdsourcing mode, the mobile device 310 may share location information regarding the LEO satellite 320 with one or more devices. Examples of how this can be done are illustrated in
As previously noted, 8-12 states may be needed to estimate PVT information of an LEO satellite 320. Although these states can be determined by a single mobile device 310 taking range measurements 410 across multiple epochs, the states may additionally or alternatively be determined by range measurements 410 taken by multiple mobile devices 310. Because multiple devices may take multiple range measurements 410 of an LEO satellite 320 in a single epoch, fewer epochs may be needed to estimate PVT information of the LEO satellite 320. A configuration in which 100 mobile devices (m=100) collectively take 100 measurements of a particular LEO satellite (e.g., LEO satellite 320-1) can result in enough information to determine the PVT information of the particular LEO satellite and a single epoch. As noted, a single mobile device 310 may take range measurements 410 of multiple LEO satellites 320 in parallel. Thus, as illustrated in
The satellite information 420 shared between mobile devices 310 may vary, depending on desired functionality, and may be shared in a variety of ways. The information itself may comprise one or more measurements and/or PVT information derived from the one or more measurements. The satellite information 420 may also include timestamp information. For example, for satellite information 420 comprising one or more measurements, it may also include one or more respective timestamps indicative of when the one or more measurements were taken. For satellite information 420 comprising PVT information, such as a model describing the PVT of the LEO satellite, the satellite information 420 can include a timestamp indicating when the PVT information was determined, a duration of time during which the PVT information is valid, and/or a time at which the PVT information expires. Because the timestamps for satellite information 420 are not used themselves for the determination of the mobile device location, they do not need to be in precise synchronization (e.g., between mobile device 310 and LEO satellite 320) for accurate position determination. Instead, because timestamps are used to determine when information is valid (which, as described herein, can span seconds, minutes, or longer), synchronization on the order of tens of nanoseconds or greater may be sufficient to utilize the satellite information 420.
In the ad-hoc or P2P environment of
It can be noted that other configurations different from those illustrated in
The sharing of satellite information 420 using either or both of the configurations illustrated in
The sharing of satellite information 420 (including range measurements 410 and/or information derived therefrom) may be performed in different ways. This may include a “push” or “pull” method, in which satellite information can be “pushed” out to other devices without a request, or “pulled” from other devices in response to a request.
For example, according to some embodiments, satellite information 420 may be broadcast. As previously noted, it may be broadcast by the LEO satellite 320 itself. According to some embodiments, for example, a LEO satellite 320 may broadcast satellite information 420 for itself (and/or possibly other LEO satellites 320) periodically (e.g., every few seconds, minutes, etc.). Additionally or alternatively, mobile devices 310 may broadcast this information to nearby devices. According to some embodiments, satellite information 420 may be broadcast by certain network entities (e.g., access points, base stations, etc.) of a wireless network. According to some embodiments, such broadcasts may be encrypted to help ensure security of the information.
According to some embodiments, the sharing of satellite information 420 may be conducted on demand. For example, a first mobile device 310-1 may send satellite information 420 to a second mobile device 310-2 or server 430 in response to a request for the satellite information 420 from the second mobile device 310-2 or server 430. Where uplink communication to an LEO satellite 320 is possible, a mobile device 310 may request satellite information 420 from an LEO satellite 320. In some embodiments, this may be executed by the mobile device 310 sending a request to the server 430, which can (via an uplink to the LEO satellite 320) relay the request to the LEO satellite 320. Embodiments that use on-demand sharing in this manner can utilize bandwidth more efficiently, providing satellite information 420 only in certain circumstances (e.g., when a mobile device 310 is in a GNSS degraded/denied environment).
According to some embodiments, to further preserve or reduce bandwidth utilized by sharing satellite information 420, and reduce the processing load of receiving devices for decoding shared satellite information 420, the satellite information 420 requested by the requesting mobile device 310 may comprise satellite information 420 only for LEO satellites 320 visible to the requesting mobile device 310. This can include, for example, an indication of the LEO satellites 320 visible to the requesting mobile device 310 (e.g., based on RF signals of the LEO satellites 320 received by the requesting mobile device 310). Additionally or alternatively, this can include an indication of an approximate position of the requesting mobile device 310, in which case the responding device or server that receives the request can determine, based on almanac or other information, which LEO satellites 320 should be visible to the requesting mobile device 310.
As noted, PVT information for an LEO satellite can be determined from range measurements and may be represented in different ways. As previously mentioned, PVT information may be obtained using 8-12 states, for example. An 8-state example may include three satellite position components, three satellite velocity components, and two clock components (e.g., clock bias and clock drift). The overall clock error, then, may be described as a first order polynomial:
Clock error=Clock bias+Clock drift*ΔT, (1)
where ΔT is a time period over which the clock drift occurs.
The way in which the position and velocity (PV) information is represented may vary and may further impact the length of time for which the PVT information is valid. For example, according to some embodiments, PV information of an LEO satellite may be represented using a Keplerian model. A Keplerian model, which is traditionally used to model Geosynchronous Equatorial Orbit (GEO) and Medium Earth Orbit (MEO) satellites, can be used for LEO satellites as well. It offers efficient compression, for example, and can be used for an extended period of time (e.g., 1-4 hours). As a person of ordinary skill in the art will appreciate, a Keplerian model can contain 6-20 parameters or more, depending on its validity period and expected accuracy. For example GPS has 16-parameter Keplerian model. The simplest Keplerian model can only have 6 parameters, e.g. semi-major, eccentricity, inclination, etc. The advantages of using a Keplerian model may be weighed against disadvantages for using a Keplerian model for LEO satellite, such as the relatively computationally heavy calculations (e.g., large amount of trigonometric calculations) versus other representations. Further, Keplerian modeling, while accurate for MEO and LEO satellite orbits may be less accurate for LEO satellites, which experience relatively more complicated gravitational perturbations and atmospheric drag.
According to some embodiments, a direct Position and Velocity (PV) may offer some additional advantages. While a direct PV representation may be valid for a shorter time than a Keplerian representation (e.g., on the order of seconds to minutes, rather than hours), it can offer a relatively lighter computational load using numerical integration with fewer parameters. This can be beneficial for certain types of devices, such as connected mobile devices, which may benefit from a lighter computational load (e.g., from a power consumption and/or processing resource perspective) and are capable of receiving updated PV information on the order of seconds to minutes.
According to some embodiments, PVT information of an LEO satellite can be modeled based on position and velocity information measured by a mobile device. In an example 3D measurements of position (x, y, z) and velocity (Vx, Vy, Vz) may be obtained by a mobile device at time T0. Changes to position of the LEO satellite in each dimension (x, y, z) over time can then be modeled as:
Further, changes to velocity of the LEO satellite over time can then be modeled as:
Where μ is the gravitational constant, @ is the Earth rotation rate, α is the semi-major axis of Earth, and J is second zonal harmonic geopotential. These equations (2) and (3) offer a gravitational model of the LEO satellite that can offer sufficient accuracy for many circumstances. According to some embodiments, the validity provided by these equations may extend over tens of seconds because integration errors are usually negligible over this amount of time. According to some embodiments, an acceleration adjustment term may be added to one or more of the equations (3) (e.g., modeling gravitational perturbation and/or atmospheric drag) to help extend this validity. According to some embodiments, a server-based environment (e.g., as shown in
At block 510, the functionality comprises obtaining a known position of a mobile device comprising an LEO receiver. As previously described (e.g., with reference to
Means for performing the functionality at block 510 may therefore comprise bus 605, processing unit(s) 610, wireless communication interface 630, sensor(s) 640, memory 660, satellite receiver unit 680, and/or other components of a mobile device, as illustrated in
At block 520, the functionality comprises obtaining range information indicative of a range between the mobile device and the LEO satellite, the range information obtained from one or more measurements of a RF signal transmitted by the LEO satellite and received by the LEO receiver of the mobile device. As previously indicated, range information may include measurements of the range and (optionally) range rates between the mobile device and LEO satellite. According to some embodiments, measurements of a range rate may be based on a determination of a frequency offset, and measurement of a range may comprise pseudo-range measurements based on measuring the receipt of a pseudorandom sequence in a manner similar to GPS and other GNSS-based solutions.
Means for performing the functionality at block 520 may therefore comprise bus 605, processing unit(s) 610, wireless communication interface 630, sensor(s) 640, memory 660, satellite receiver unit 680, and/or other components of a mobile device, as illustrated in
At block 530, the functionality comprises determining the PVT information of the LEO satellite based at least in part on the known position of the mobile device and the range information. As noted, the determination may be performed by the server or a mobile device. For example, according to some embodiments of the method 500, determining the PVT information of the LEO satellite maybe performed by a server communicatively linked to the mobile device, obtaining the known position of the mobile device may comprise receiving the known position at the server from the mobile device, and obtaining the range information may comprise receiving the range information at the server from the mobile device. In such embodiments, determining the PVT information of the LEO satellite additionally may be based on one or more additional known position of one or more additional mobile devices and, for each of the one or more additional mobile devices, information indicative of a range between the respective mobile device and the LEO satellite. Further, according to some embodiments, the method 500 may comprise sending the PVT information of the LEO satellite to the mobile device, at least one of the one or more additional mobile devices, or a combination thereof.
The functionality may be different if the determination of the PVT information is performed by the mobile device. For example, according to some of the method 500 determining the PVT information of the LEO satellite may be performed by the mobile device, and obtaining the range information may comprise taking the one or more measurements at the mobile device. As noted, these measurements may be indicative of a range and (optionally) range rate between the mobile device and LEO satellite. Moreover, as noted in relation to
As noted, determining PVT information at a mobile device can be beneficial during periods of time in which other positioning methods may be unavailable, such as during periods of time in which the mobile device is in GNSS degraded or denied environments. According to some embodiments, determining the PVT information of the LEO satellite may be performed by the mobile device at a first time, and the method 500 may further comprise determining a position of the mobile device at a second time, subsequent to the first time, based at least in part on the PVT information.
As noted, a mobile device may share PVT and/or range information to one or more other devices. As such, according to some embodiments, the method 500 may further comprise sending the PVT information of the LEO satellite, the range information, or both to a second mobile device. According to some embodiments, the sending of the PVT information of the LEO satellite, the range information, or both may be responsive to a request from the second mobile device. According to some embodiments, the sending of the PVT information of the LEO satellite, the range information, or both may be responsive to a determination that the LEO satellite is visible to the second mobile device. As noted, the mobile device may determine what is visible to the second mobile device based on, for example, a location (e.g., approximately location) of the second mobile device and an almanac, database, or other source of information indicative of satellite orbital information. According to some embodiments, the PVT information of the LEO satellite comprises a 3D position and velocity of the LEO satellite at a point in time.
Means for performing the functionality at block 530 may comprise bus 605, processing unit(s) 610, wireless communication interface 630, sensor(s) 640, memory 660, and/or other components of a mobile device, as illustrated in
The mobile device 600 is shown comprising hardware elements that can be electrically coupled via a bus 605 (or may otherwise be in communication, as appropriate). The hardware elements may include a processing unit(s) 610 which can include without limitation one or more general-purpose processors, one or more special-purpose processors (such as digital signal processor (DSP) chips, graphics acceleration processors, application specific integrated circuits (ASICs), and/or the like), and/or other processing structures or means. As shown in
The mobile device 600 may also include a wireless communication interface 630, which may comprise without limitation a modem, a network card, an infrared communication device, a wireless communication device, and/or a chipset (such as a Bluetooth® device, an IEEE 802.11 device, an IEEE 802.15.4 device, a Wi-Fi device, a WiMAX device, a WAN device, and/or various cellular devices, etc.), and/or the like, which may enable the mobile device 600 to communicate with other devices as described in the embodiments above. The wireless communication interface 630 may permit data and signaling to be communicated (e.g., transmitted and received) with base stations or Transmission Reception Points (TRPs) of a network, for example, via eNBs, gNBs, ng-eNBs, access points, various base stations and/or other access node types, and/or other network components, computer systems, and/or any other electronic devices communicatively coupled with the network. The communication can be carried out via one or more wireless communication antenna(s) 632 that send and/or receive wireless signals 634. According to some embodiments, the wireless communication antenna(s) 632 may comprise a plurality of discrete antennas, antenna arrays, or any combination thereof. The antenna(s) 632 may be capable of transmitting and receiving wireless signals using beams (e.g., Tx beams and Rx beams). Beam formation may be performed using digital and/or analog beam formation techniques, with respective digital and/or analog circuitry. The wireless communication interface 630 may include such circuitry.
Depending on desired functionality, the wireless communication interface 630 may comprise a separate receiver and transmitter, or any combination of transceivers, transmitters, and/or receivers to communicate with base stations (e.g., ng-eNBs and gNBs) and other terrestrial transceivers, such as wireless devices and access points. The mobile device 600 may communicate with different data networks that may comprise various network types. For example, a Wireless Wide Area Network (WWAN) may be a CDMA network, a Time Division Multiple Access (TDMA) network, a Frequency Division Multiple Access (FDMA) network, an Orthogonal Frequency Division Multiple Access (OFDMA) network, a Single-Carrier Frequency Division Multiple Access (SC-FDMA) network, a WiMAX (IEEE 802.16) network, and so on. A CDMA network may implement one or more RATs such as CDMA2000®, Wideband Code Division Multiple Access (WCDMA), and so on. CDMA2000® includes IS-95, IS-2000 and/or IS-856 standards. A TDMA network may implement GSM, Digital Advanced Mobile Phone System (D-AMPS), or some other RAT. An OFDMA network may employ LTE, LTE Advanced, 5G NR, and so on. 5G NR, LTE, LTE Advanced, GSM, and WCDMA are described in documents from 3GPP. CDMA2000® is described in documents from a consortium named “3rd Generation Partnership Project 2” (3GPP2). 3GPP and 3GPP2 documents are publicly available. A WLAN may also be an IEEE 802.11x network, and a wireless personal area network (WPAN) may be a Bluetooth network, an IEEE 802.15x, or some other type of network. The techniques described herein may also be used for any combination of WWAN, WLAN and/or WPAN.
The mobile device 600 can further include sensor(s) 640. Sensor(s) 640 may comprise, without limitation, one or more inertial sensors and/or other sensors (e.g., accelerometer(s), gyroscope(s), camera(s), magnetometer(s), altimeter(s), microphone(s), proximity sensor(s), light sensor(s), barometer(s), and the like), some of which may be used to obtain position-related measurements and/or other information.
Embodiments of the mobile device 600 may also include a satellite receiver unit 680 capable of receiving signals 684 from one or more satellites using an antenna 682 (which could be the same as antenna 632). In particular, the satellite receiver unit 680 may comprise an LEO receiver 686 and the GNSS receiver 687, as described herein. It can be noted that the LEO receiver 686 and GNSS receiver 687 may share components such as the antenna 682 and/or may have separate (e.g., specialized) components for processing signals from LEO or GNSS satellites. This may include, for example, processors and/or other circuitry capable of executing positioning engines (e.g., an EKF-based or WLS-based SPE and/or PPE) used to determine the positions of the mobile device and one or more LEO satellites. In some embodiments LEO receiver 686 and the GNSS receiver 687 may be separate components (e.g., not part of a larger satellite receiver unit 680).
As noted, positioning based on GNSS signal measurement can be utilized to complement and/or incorporate the techniques described herein. The GNSS receiver 687 can extract a position of the mobile device 600, using conventional techniques, from GNSS satellites X110 of a GNSS system, such as Global Positioning System (GPS), Galileo, GLONASS, Quasi-Zenith Satellite System (QZSS) over Japan, IRNSS over India, BeiDou Navigation Satellite System (BDS) over China, and/or the like. Moreover, the GNSS receiver 687 can be used with various augmentation systems (e.g., a Satellite Based Augmentation System (SBAS)) that may be associated with or otherwise enabled for use with one or more global and/or regional navigation satellite systems, such as, e.g., Wide Area Augmentation System (WAAS), European Geostationary Navigation Overlay Service (EGNOS), Multi-functional Satellite Augmentation System (MSAS), and Geo Augmented Navigation system (GAGAN), and/or the like.
It can be noted that, although satellite receiver unit 680 is illustrated in
The mobile device 600 may further include and/or be in communication with a memory 660. The memory 660 can include, without limitation, local and/or network accessible storage, a disk drive, a drive array, an optical storage device, a solid-state storage device, such as a random access memory (RAM), and/or a read-only memory (ROM), which can be programmable, flash-updateable, and/or the like. Such storage devices may be configured to implement any appropriate data stores, including without limitation, various file systems, database structures, and/or the like.
The memory 660 of the mobile device 600 also can comprise software elements (not shown in
The computer system 700 is shown comprising hardware elements that can be electrically coupled via a bus 705 (or may otherwise be in communication, as appropriate). The hardware elements may include processing unit(s) 710, which may comprise without limitation one or more general-purpose processors, one or more special-purpose processors (such as digital signal processing chips, graphics acceleration processors, and/or the like), and/or other processing structure, which can be configured to perform one or more of the methods described herein. The computer system 700 also may comprise one or more input devices 715, which may comprise without limitation a mouse, a keyboard, a camera, a microphone, and/or the like; and one or more output devices 720, which may comprise without limitation a display device, a printer, and/or the like.
The computer system 700 may further include (and/or be in communication with) one or more non-transitory storage devices 725, which can comprise, without limitation, local and/or network accessible storage, and/or may comprise, without limitation, a disk drive, a drive array, an optical storage device, a solid-state storage device, such as a RAM and/or ROM, which can be programmable, flash-updateable, and/or the like. Such storage devices may be configured to implement any appropriate data stores, including without limitation, various file systems, database structures, and/or the like. Such data stores may include database(s) and/or other data structures used store and administer messages and/or other information to be sent to one or more devices via hubs, as described herein.
The computer system 700 may also include a communications subsystem 730, which may comprise wireless communication technologies managed and controlled by a wireless communication interface 733, as well as wired technologies (such as Ethernet, coaxial communications, universal serial bus (USB), and the like). The wireless communication interface 733 may comprise one or more wireless transceivers may send and receive wireless signals 755 (e.g., signals according to 5G NR, LTE, or Wi-Fi) via wireless antenna(s) 750. Thus the communications subsystem 730 may comprise a modem, a network card (wireless or wired), an infrared communication device, a wireless communication device, and/or a chipset, and/or the like, which may enable the computer system 700 to communicate on any or all of the communication networks described herein to any device on the respective network, including a User Equipment (UE), base stations and/or other TRPs, and/or any other electronic devices described herein. Hence, the communications subsystem 730 may be used to receive and send data as described in the embodiments herein.
In many embodiments, the computer system 700 will further comprise a working memory 735, which may comprise a RAM or ROM device, as described above. Software elements, shown as being located within the working memory 735, may comprise an operating system 740, device drivers, executable libraries, and/or other code, such as one or more applications 745, which may comprise computer programs provided by various embodiments, and/or may be designed to implement methods, and/or configure systems, provided by other embodiments, as described herein. Merely by way of example, one or more procedures described with respect to the method(s) discussed above might be implemented as code and/or instructions executable by a computer (and/or a processing unit within a computer); in an aspect, then, such code and/or instructions can be used to configure and/or adapt a general purpose computer (or other device) to perform one or more operations in accordance with the described methods.
A set of these instructions and/or code might be stored on a non-transitory computer-readable storage medium, such as the storage device(s) 725 described above. In some cases, the storage medium might be incorporated within a computer system, such as computer system 700. In other embodiments, the storage medium might be separate from a computer system (e.g., a removable medium, such as an optical disc), and/or provided in an installation package, such that the storage medium can be used to program, configure, and/or adapt a general purpose computer with the instructions/code stored thereon. These instructions might take the form of executable code, which is executable by the computer system 700 and/or might take the form of source and/or installable code, which, upon compilation and/or installation on the computer system 700 (e.g., using any of a variety of generally available compilers, installation programs, compression/decompression utilities, etc.), then takes the form of executable code.
It will be apparent to those skilled in the art that substantial variations may be made in accordance with specific requirements. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets, etc.), or both. Further, connection to other computing devices such as network input/output devices may be employed.
With reference to the appended figures, components that can include memory can include non-transitory machine-readable media. The term “machine-readable medium” and “computer-readable medium” as used herein, refer to any storage medium that participates in providing data that causes a machine to operate in a specific fashion. In embodiments provided hereinabove, various machine-readable media might be involved in providing instructions/code to processing units and/or other device(s) for execution. Additionally or alternatively, the machine-readable media might be used to store and/or carry such instructions/code. In many implementations, a computer-readable medium is a physical and/or tangible storage medium. Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. Common forms of computer-readable media include, for example, magnetic and/or optical media, any other physical medium with patterns of holes, a RAM, a programmable ROM (PROM), erasable PROM (EPROM), a FLASH-EPROM, any other memory chip or cartridge, or any other medium from which a computer can read instructions and/or code.
The methods, systems, and devices discussed herein are examples. Various embodiments may omit, substitute, or add various procedures or components as appropriate. For instance, features described with respect to certain embodiments may be combined in various other embodiments. Different aspects and elements of the embodiments may be combined in a similar manner. The various components of the figures provided herein can be embodied in hardware and/or software. Also, technology evolves and, thus many of the elements are examples that do not limit the scope of the disclosure to those specific examples.
It has proven convenient at times, principally for reasons of common usage, to refer to such signals as bits, information, values, elements, symbols, characters, variables, terms, numbers, numerals, or the like. It should be understood, however, that all of these or similar terms are to be associated with appropriate physical quantities and are merely convenient labels. Unless specifically stated otherwise, as is apparent from the discussion above, it is appreciated that throughout this Specification discussion utilizing terms such as “processing,” “computing,” “calculating,” “determining,” “ascertaining,” “identifying,” “associating,” “measuring,” “performing,” or the like refer to actions or processes of a specific apparatus, such as a special purpose computer or a similar special purpose electronic computing device. In the context of this Specification, therefore, a special purpose computer or a similar special purpose electronic computing device is capable of manipulating or transforming signals, typically represented as physical electronic, electrical, or magnetic quantities within memories, registers, or other information storage devices, transmission devices, or display devices of the special purpose computer or similar special purpose electronic computing device.
Terms, “and” and “or” as used herein, may include a variety of meanings that also is expected to depend, at least in part, upon the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B, or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B, or C, here used in the exclusive sense. In addition, the term “one or more” as used herein may be used to describe any feature, structure, or characteristic in the singular or may be used to describe some combination of features, structures, or characteristics. However, it should be noted that this is merely an illustrative example and claimed subject matter is not limited to this example. Furthermore, the term “at least one of” if used to associate a list, such as A, B, or C, can be interpreted to mean any combination of A, B, and/or C, such as A, AB, AA, AAB, AABBCCC, etc.
Having described several embodiments, various modifications, alternative constructions, and equivalents may be used without departing from the scope of the disclosure. For example, the above elements may merely be a component of a larger system, wherein other rules may take precedence over or otherwise modify the application of the various embodiments. Also, a number of steps may be undertaken before, during, or after the above elements are considered. Accordingly, the above description does not limit the scope of the disclosure.
In view of this description embodiments may include different combinations of features. Implementation examples are described in the following numbered clauses:
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/CN2021/106419 | 7/15/2021 | WO |
