With the proliferation of Low Earth Orbit (LEO) satellite constellations, offering new opportunities and applications in Positioning, Navigation, and Timing (PNT), it is imperative to enhance the tools and standards that support both precise positioning solutions and means to store data for post-process analysis. At least, measurements such as pseudoranges, carrier-phases, Doppler, code biases and broadcast ephemeris —encompassing satellite orbits, clocks, ionospheric models— will have to be stored. Much in the same way as it is currently done with the Medium Earth Orbit (MEO) satellites of currently existing GNSS constellations. The current de facto standard to store such information is represented by the Receiver Independent Exchange Format (RINEX), in both its Observable and Navigation types, currently in its version 4.01.

In this blog post, we explore the potential of extending the RINEX standard to accommodate LEO PNT ephemeris data (i.e. an extension for the RINEX Navigation format), that is backward compatible with RINEX 4 Navigation files. The challenge that this extension faces is the potentially large number of space vehicles compared to current GNSS constellations: LEO PNT will be likely based on mega-constellations of around 500 satellites or even more. For instance Xona Space plans to deploy a constellation of 300 satellites. Other notable examples of these mega-constellations can be found in the communication constellations such as Starlink, with more than 4500 satellites, or OneWeb, with more than 600 satellites. Even these constellations have been explored to provide signals-of-opportunity for navigation purposes (see for instance [Humphreys et al., 2023])

RINEX Navigation extension format for LEO PNT

As per the navigation format, this proposal takes advantage of the fact that the navigation blocks are preceded by a header (starting with ">"), which allows certain flexibility in the satellite ID length. Moreover, since the satellite ID is included in the header, it does not then need to be added in the actual navigation block (as done for MEO GNSS satellites). This helps to maintain the lengths of subsequent fields of the EPOCH / SV CLOCK line.

The proposal for the extension is as follows (following the same format description used in the RINEX format): 

TYPE / SV           - New Record identifier: '>'                A1
                    - Navigation Data Record Type – 'EPH'       1X,A3
                    - LEO constellation type                    1X,A1
                    - LEO satellite id                          I5

EPOCH / SV CLK      - Void spaces (Sat ID already in header)    3X
                    - year (4 digits)                           1X,I4
                    - month, day, hour, minute, second          5(1X,I2)
                    - SV clock bias; a_f0 (seconds)             D19.12
                    - SV clock drift; a_f1 (sec/sec)            D19.12
                    - SV clock drift rate; a_f2 (sec/sec2)      D19.12

ORBIT - 1           - A DOT (meters/sec)                        4X,4D19.12
                    - C_rs (meters)
                    - Delta n0 (radians/sec)
                    - M0 (radians)

ORBIT - 2           - C_uc (radians)                            4X,4D19.12
                    - e Eccentricity
                    - C_us (radians)
                    - sqrt(A) (sqrt(m))

ORBIT - 3           - reserved                                  4X,4D19.12
                    - C_ic (radians)
                    - OMEGA0 (radians)
                    - C_is (radians)

ORBIT - 4           - i0 (radians)                              4X,4D19.12
                    - C_rc (meters)
                    - omega (radians)
                    - OMEGA DOT (radians/sec)

ORBIT - 5           - IDOT (radians/sec)                        4X,4D19.12
                    - Delta n0 dot (radians/sec^2)
                    - reserved
                    - reserved

An example of a navigation block for a Starlink LEO satellite 2434 is shown below. This example has been built transforming the TLE elements of the Starlink satellite found at Celestrak and assuming no orbit perturbations. 

> EPH Z02434
    2023 11 02 11 10 24 0.000000000000e+00 0.000000000000e+00 0.000000000000e+00
     0.000000000000e+00 0.000000000000e+00 1.989675347274e-09 4.642884733583e+00
     0.000000000000e+00 1.811000000000e-04 0.000000000000e+00 2.835776281159e+03
     0.000000000000e+00 0.000000000000e+00 5.882354736496e+00 0.000000000000e+00
     9.288031413876e-01 0.000000000000e+00 1.642393223370e+00 0.000000000000e+00
     0.000000000000e+00 0.000000000000e+00 0.000000000000e+00 0.000000000000e+00

Albeit the TLE elements are built specifically for the SGP4 propagation model and in principle a one-to-one mapping to orbital parameters should be avoided (see for instance [Harding, 2019]), this approach has been used as a first approximation for the orbital elements that could be published in a broadcast ephemeris file.

Some additional specifications and notes on the format:

  • The one-character LEO constellation type, would be specific to each constellation. Obviously, an "official" list of constellation types would have to be agreed upon. A tentative list of constellations are considered
Generic LEO constellation 'L'
Xona                      'X'
Geely                     'Y'
Starlink                  'Z'
Oneweb                    'O'
Spire                     'V'
  • The LEO satellite ID field (5 digits) will identify the Space Vehicle (or PRN number, if applicable). Similarly to the constellation type, the list of the IDs will have to be agreed upon as well. In the example provided, the ID has been extracted from the first field of the TLE entry for this Starlink satellites.
  • The rest of the parameters match the ones specified by the MEO GNSS constellations. Some of the parameters will likely require revision by experts in orbital mechanics to account for the specifics of the LEO orbit. It is clear that, being in a much lower orbit, the atmospheric drag will play an important role. Works such as [Guo et al., 2022] propose extending the set of harmonic coefficients up to third order and even adding additional ones for the e.g. variation of the right ascension of the ascending node (Ω). These parameters could be stored in the fields marked above as reserved (currently filled with 0.0). Alternatively, [Wang et al., 2020] propose the increase of the update rate to 10 or 20 minutes (instead of the 2h used in GNSS) to be able to maintain centimetric accuracies in the orbit representation.

Next steps

The extension of the RINEX Navigation format for LEO PNT satellites has been proposed as a necessary step to provide with tools that will be required in the near future to store data that can be used for scenario simulation as well as post-processing analysis. The choice of RINEX has been made in order to ease the way to use a single file format for positioning engines that hybridize GNSS and LEO satellites.

A necessary next step of this RINEX extension proposal will consist in an extension of the RINEX Observation file in a way that (a) maintains the backward compatibility of RINEX 4 and (b) keeps the consistency of satellite ID between Navigation and Observation files. At this point, the limitation of 2-digit for the satellite ID in the Observation file is a major blocking point unless a breaking change is introduced. In order not to do so, a possible way forward would be to use, in the measurement lines, the satellite ID notation based on 2 digits as specified in the RINEX standard and using L to indicate LEO PNT satellites (or the appropriate LEO constellation) preceded by a header information event (of type SAT ID ASSIGNEMENT, like so: 

> 2006 12 20 12  1  0.0000000  4 1
Z95 = Z43012                                               SAT ID ASSIGNEMENT
> 2022 12 20 12  1  4.6030000  0 30                     
G23  24718012.436   129894024.173    24718009.543   101216196.673                  
Z95    732793.036      732794.384

The 2-digit limitation for the LEO satellite ID could then be overcome with this event information, valid only within each RINEX Observation file, that establishes a temporary link between the 2-digit number and the actual satellite ID provided by the constellation agency. This hack assumes, however, that the receiver will not be able to track more than 100 different LEO satellites on each constellation in the same navigation session, which may be a challenge considering the fast dynamics of the LEO orbit.

All in all, while acknowledging certain caveats that require attention, this extension could be potentially considered as a foundation for having a standardized LEO-PNT data storage for research and development activities within the positioning domain.

References

[Guo et al., 2022] Guo, Xueli, Lei Wang, Wenju Fu, Yingbo  Suo, Ruizhi Chen, and Hongxing Sun. "An optimal design of the broadcast  ephemeris for LEO navigation augmentation systems." Geo-Spatial Information Science 25, no. 1 (2022): 34-46. Available at https://www.tandfonline.com/doi/abs/10.1080/10095020.2021.2017760

[Harding, 2019] Harding, David, "Converting TLEs to Keplerian Elements", Satellite Engineering blog, July 16h 2019. https://blog.hardinglabs.com/tle-to-kep.html. Accessed in Nov 5th, 2023.

[Humphreys et al., 2023] Humphreys, Todd E., Peter A. Iannucci, Zacharias M. Komodromos, and Andrew M. Graff. "Signal structure of the  starlink ku-band downlink." IEEE Transactions on Aerospace and Electronic Systems (2023). Available at: https://arxiv.org/pdf/2210.11578.pdf

[Wang et al., 2020] Wang, Kan, and Ahmed El-Mowafy. "Proposed orbital products for positioning using mega-constellation LEO satellites." Sensors 20, no. 20 (2020): 5806. Available at https://www.mdpi.com/1424-8220/20/20/5806