There are interesting tradeoffs to consider in placing navigation satellites at various orbital heights, including signal power, availability, cost, orbit prediction, receiver computational load and manufacturer motivation.
In early July the communications company OneWeb, owner of a low-Earth orbit (LEO) satellite constellation, was rescued from bankruptcy by a UK government-led consortium. This triggered speculation OneWeb will form part or all of the UK government’s plans for its own GNSS following the completion of Brexit at the beginning of 2021, tentatively at a fraction of the costs initially set aside for such sovereign capability. Or so it seems. Here we look into the potential of using the OneWeb constellation for the provision of PNT services.
All current GNSS operate typically in medium-Earth Orbit (MEO) 20,000 kilometers above our heads, but all have their roots in pioneering early satellites like Sputnik and TRANSIT. Those flew in LEO, just 1,000 kilometers or so above us. LEO has recently become popular for new commercial ventures. This region of space will soon be very crowded, potentially containing tens of thousands of small satellites, including the recently proposed LEO PNT constellation being developed by Silicon Valley startup Xona Space.
MEO versus LEO
There are interesting tradeoffs to consider in placing navigation satellites at various orbital heights.
In LEO, satellites are much closer to Earth than at MEO. So given the same transmission power, receivers on the Earth tracking LEO satellites will enjoy far higher signal strengths (e.g. 1000x greater). This translates into better indoor availability and improved protection from jamming. That comes at a cost.
Operating much closer to the Earth’s surface enforces a much-reduced signal footprint, and hence lower availability per satellite. Therefore, many more LEO satellites are required compared to MEO to achieve the same levels of both global coverage and a high number of satellites simultaneously in view. The high level of performance in current day GNSS is due in part to the system diversity and interoperability: over one hundred MEO satellites available, all broadcasting in a similar frequency band.
Due to their lower orbits, LEO satellites are easier and cheaper to launch and replace. However, LEO satellites need to be replaced much more often than those at MEO due to increased atmospheric drag, meaning that their station-keeping maneuvers burn through fuel at a much higher rate.
The more complicated dynamics in LEO bring in another problem. GNSS positioning accuracy relies intrinsically upon the accuracy of the predicted orbit and clock behavior of the satellites. Orbit prediction at the decimeter level is readily achievable at MEO as the forces acting on the satellites are reasonably well understood, and the orbit prediction process is supported by the high visibility of the satellites to ground tracking stations.
The same cannot be said in LEO. Atmospheric density prediction is still a hard problem, and the LEO satellites are visible to fewer ground stations. Of course, one could simply boost the number of tracking stations, but that would be a very expensive solution. Modelling clock behavior usually requires solving for the orbit first. So if the orbit is compromised at some level, so is the clock predictor.
Clock modelling relies also upon a robust time scale, usually derived from an ensemble of both ground and space-borne clocks. All these problems are more easily resolved with a MEO constellation. It is no coincidence all four operational GNSS fly the backbone of their systems at that altitude.
LEOs move very rapidly across the sky, which helps to whiten multipath interference, reducing its impact on PNT fixes. However, at best a OneWeb satellite would be visible to a ground-based receiver for a maximum of sixteen minutes versus a few hours for MEO satellites. This means the LEO satellites rise and set far more frequently, and their Doppler shift changes rapidly during a pass.
This in turn places additional computational burdens on the tracking device, with attendant demands on the processor and hits to the power budget. Chipset manufacturers may be wary of committing to developing front ends that can handle much greater ranges in Doppler shift, and reducing the battery life of a device. Indeed, given they already have four perfectly well functioning and interoperable systems, what motivation exists for them to bother?
OneWeb satellites will provide the Internet to receivers on the ground using an adaptation of the 4G cellular signal employed today for terrestrial smartphone communications. OneWeb satellites will transmit 4G type signals in the 14GHz (Ku) radio band. This is of course a vastly different frequency than the L-Band GNSS signals at around 1.5GHz. The OneWeb broadcast frequencies are dramatically different from those used by standard GNSS receivers, the provision of PNT alongside communication signals was absent from the original design strategy for OneWeb, and the OneWeb satellites have very small payloads compared to MEO GNSS satellites.
For all these reasons, we believe that it is not feasible to adapt the existing OneWeb satellites to jointly broadcast communications and PNT signals that can be easily used by existing or future GNSS receivers. Other options appear much more likely: either new PNT-dedicated satellites would be inserted into the constellation (making it larger), or a subset of satellites in the existing constellation plan would be swapped out for dedicated PNT satellites (reducing the availability and capacity of the original communications system).
Feasibility of OneWeb for Positioning
There is a rich and successful history in using communications signals for determining position: the use of Wi-Fi and Bluetooth for positioning is commonplace in smartphones for example. Recent work by researchers at the University of California, Irvine (see “Opportunity Comes Knocking,” Inside Unmanned Systems, June/July 2020) demonstrated the feasibility of using LEO communication signals as part of a positioning system. There are certainly some key and fundamental positive aspects of the OneWeb signal, for example an extremely high channel bandwidth, which would manifest as submeter resolution in a ranging estimate. However, there are some serious issues which render the direct use of the OneWeb signals for a standalone GNSS as impractical and even implausible.
Firstly, the existing four main GNSS all use L-band signals, which means that an existing multi-system receiver only requires one antenna and one L-band radio front end. This has led to very low-cost, very compact, multi-system receivers. If UK GNSS receivers required multiple antennas and radio front ends, this would significantly impact their adoption and market share. A designed-for-purpose UK GNSS would undoubtedly center its signals on the existing L1, L2 and L5 frequencies, something that current Ku-band OneWeb satellites cannot do.
Secondly the OneWeb constellation has been designed for communications purposes, and there is always a critical difference between how you lay out your transmitters for communications versus positioning. Good signal geometry and high signal availability are required for positioning. It is well known that at least 4 satellites must be visible for a GPS fix, and as a simple rule of thumb, at least double that number are required for confident and accurate positioning with less than 10 meters of error.
In contrast, for communication purposes minimal signal availability is preferred from a business bottom-line point of view: the optimal communications system from the financial perspective provides visibility of just one transmitter to any receiver at any time. Due to the selected orbits, number of satellites, and the coverage area on the ground of each OneWeb satellite, the OneWeb constellation in its planned configuration cannot provide enough transmitter diversity to allow standalone position fixes.
Thirdly, the OneWeb system currently depends upon GNSS receivers installed within the OneWeb communication receivers. The OneWeb receivers use the GNSS PNT solution to determine the current exact location and time and then use models of the OneWeb orbits to correctly set the correct radio frequency and frequency rate required by the receiver to acquire and lock onto the current serving OneWeb satellite as it whizzes across the sky with significant Doppler shift.
It was a sensible design choice to use GNSS to allow a simple acquisition of the communications signal rather than to design more expensive and computationally expensive unassisted OneWeb receivers. The OneWeb receivers are therefore unlikely to be able to use their own signals to calculate PNT if accurate PNT from GNSS is first required to acquire those OneWeb signals.
A further challenge in using OneWeb for positioning is the need for the signals to be locked to a high-stability timing reference, and for them to be broadcast from a well-known location. OneWeb satellites do not currently contain atomic clocks, and they are too small to carry the multiple large space-quality atomic clocks that are deployed in MEO GNSS satellites. An alternative source of stable time would be required, and the OneWeb orbits would need to be tracked to a very high accuracy and broadcast to receivers.
Unsurprisingly, we can conclude that it is not trivial to take a LEO communications system and convert it into a joint communication and positioning system without having designed this capability from the very beginning. However, since the constellation is still not even 50% completed yet, and its LEO satellites will be replaced every few years, there is scope for providing some enhanced capabilities to the system over time. A proposed solution combining the new OneWeb opportunity for the UK Government, and its desire for an enhanced and sovereign GNSS capability runs as follows:
It is sensible to develop OneWeb PNT satellites that are actually dependent on the open signals of the other GNSS satellites in MEO above them to provide the OneWeb satellites with their own orbital and clock data via an onboard GNSS receiver. This will dramatically reduce the overall cost and complexity of the system. This dependency will not be a problem in practice as the main threat to GNSS availability is local jamming and spoofing near receivers on the Earth, not a catastrophic failure of the space segment.
Historically when one GNSS has suffered a failure in the space segment (as has happened in the past for GPS, Galileo and GLONASS), the other GNSS constellations have remained entirely unaffected due to their independence. So designing UK GNSS to be dependent on the signals from any of the existing 4 independent GNSS can actually provide some resilience if one or even two of the existing GNSS were to fail at the same time. It is a departure from the traditional desire for a fully independent system but one that will be required for a OneWeb PNT system to be practical within a sensible budget.
Some subset of the full OneWeb constellation could be switched over to a dedicated PNT payload, but it is difficult to see how a joint communications and PNT payload could be squeezed onto every satellite. They are simply too small and targeting too low a unit cost. Dedicated OneWeb PNT satellites would preferentially form a new constellation with dedicated orbits separate from the current OneWeb communication satellite orbital planes.
The simplest OneWeb PNT system would simply be an encrypted authentication service for the open signals from other GNSS in order to provide spoofing protections. The OneWeb signals in this approach would not just broadcast ranging signals used for PNT but would also contain an encrypted message that can be used to confirm that the data content of the other open signals from existing GNSSs were valid. For example, a rebroadcasting of the recent unpredictable bits from the GPS satellites overhead, and other established forms of navigation message authentication. It will certainly be easier to provide an overlay authentication service to the existing open GNSS signals with OneWeb than to provide an entire standalone UK GNSS using OneWeb. OneWeb satellites offer a way forward to augment and strengthen global PNT services.
But as a standalone alternative GNSS, the odds are not good. The UK government would be ill-advised to put all its PNT eggs in a LEO basket.