Real-Time LEO Satellite Clocks Based on Near-Real-Time Clock Determination with Ultra-Short-Term Prediction

Abstract

The utilization of Low Earth Orbit (LEO) satellites is anticipated to augment various aspects of traditional GNSS-based Positioning, Navigation, and Timing (PNT) services. While the LEO satellite orbital products can nowadays be produced with rather high accuracy in real-time of a few centimeters, the precision of the LEO satellite clock products that can be achieved in real-time is less studied. The latter, however, plays an essential role in the LEO-augmented positioning and timing performances. In real-time, the users eventually use the predicted LEO satellite clocks, with their precision determined by both the near-real-time clock precision and the prediction time needed to match the time window for real-time applications, i.e., the precision loss during the prediction phase. In this study, a real-time LEO satellite clock determination method, consisting of near-real-time clock determination with ultra-short-term clock prediction is proposed and implemented. The principles and strategies of this method are discussed in detail. The proposed method utilized Kalman-filter-based processing, but supports restarts at pre-defined times, thus hampering continuous bias propagation and accumulation from ancient epochs. Based on the method, using Sentinel-3B GNSS observations and the real-time GNSS products from the National Center for Space Studies (CNES) in France, the near-real-time LEO satellite clocks can reach a precision of 0.2 to 0.3 ns, and the precision loss during the prediction phase is within 0.07 ns for a prediction time window from 30 to 90 s. This results in a total error budget in the real-time LEO satellite clocks of about 0.3 ns.

1. Introduction

With the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS) in Russia, the BeiDou Navigation Satellite System (BDS), and the Galileo now providing global services, the Global Navigation Satellite System (GNSS) development has entered a new era. However, due to the inherent characteristics of GNSS, it still faces the challenge of being unable to address all the service requirements using a specific navigation technology. As a result, the navigation systems of countries are targeting higher service accuracy, more diverse functionalities, and more reliable services, initiating the planning and construction of the next generation of navigation systems [1].

In recent years, due to the unique advantages of orbital characteristics and signal strength, augmentation with Low Earth Orbit (LEO) satellites has gained attention and favor in the global satellite navigation field, promising to be an incremental development in the next generation of satellite navigation systems. Worldwide, there is the active implementation and deployment of LEO satellite constellation plans, such as Musk’s Starlink [2], the OneWeb [3], the Iridium [4], the Xona’s Pulsar of the United States [5], the Kepler system of Germany [6], and the Centispace [7], Hongyan and Hongyun [8] of China, involving tens of thousands of LEO satellites. Some of these constellations have the capability to actively broadcast navigation signals, such as Xona’s Pulsar and the Centispace [7], aiming to augment the performance of GNSS, providing users with high-precision, fast convergence, low-cost, and highly reliable satellite Positioning, Navigation and Timing (PNT) services [9]. The LEO-augmented positioning results using real LEO satellite navigation signals have, e.g., been achieved with the CentiSpace satellites [7].

For cm-level high-accuracy LEO-augmented PNT services, high-precision real-time LEO satellite clock products are indispensable. Therefore, in addition to the LEO satellite real-time orbital products that have been intensively studied over the past decade [10,11,12,13], high-precision LEO satellite clock products are a prerequisite for integrating the LEO navigation augmentation system with GNSS to provide high-performance PNT services. Their contributions to the LEO satellite Signal-In-Space-Ranging-Error (SISRE) to ground users are unignorable.

In contrast to GNSS satellites that are predominantly positioned in Medium Earth Orbits (MEOs), LEO satellites have an altitude ranging from a few hundred kilometers to approximately 1500 km. This results in significantly smaller footprints compared to that of GNSS satellites [14]. When employing the same clock determination strategy as that for the GNSS satellite clocks using a network of ground stations, frequent reinitializations and discontinuous estimation cannot be avoided due to the difficulties in building dense network stations in remote areas and oceans [11,14]. Luckily, LEO satellites serve as users of GNSS satellite signals and can perform continuous clock determination, treating the clock bias as a time-independent white noise estimation parameter [15]. When processing LEO satellite clocks using batch least-squares adjustment in reduced-dynamic mode, a high precision of about 0.15 ns can be achieved in near-real-time when using high-quality GNSS real-time products [16]. This, however, implies a processing time of about 5 min for 24 h processing with a sampling interval of 30 s, even with a powerful processing unit [12]. Considering a time interval between subsequent processing rounds of, e.g., another 5 min, a clock prediction of 10 min is needed to catch up with the real-time applications.

The mid-term LEO satellite clock prediction turns out to be a more challenging task for LEO satellite clocks compared to that for the GNSS satellite clocks. The estimable LEO satellite clocks exhibit diverse systematic effects, which contain complicated relativistic effects, temperature-related hardware biases, influences caused by the South Atlantic Anomaly, and some other reasons that are not yet fully clarified [17,18]. Wang et al. utilized real data from GRACE-FO and Sentinel-3B to identify the factors impacting the stability of LEO satellite clocks and introduced a prediction model that takes into account the systematic effects [18]. A substantial reduction was demonstrated in the prediction errors compared to polynomial fitting, however, with a precision loss of approximately 0.4 to 0.5 ns at a 10 min prediction time. Wu et al. attempted to remove the complicated relativistic effects on LEO satellite clocks for a better clock prediction, leading to a precision loss of about 0.3 to 0.5 ns at a prediction time point of 10 min [19]. Ge et al. proposed to perform the LEO satellite clock prediction with least-squares harmonic estimation and obtained a precision loss of about 0.3 ns within prediction arcs of 15 min [20]. In short, LEO satellite clock prediction over more than 10 min already leads to significant precision loss. This urges the employment of more efficient LEO satellite clock determination methods with ultra-short-term prediction for real-time applications.

Processing the LEO satellite clocks in a filter-based manner delivers more efficient but less precise clock solutions. Lots of previous studies have discussed the filter-based LEO satellite Precise Orbit Determination (POD), with the clocks automatically produced as byproducts [11,21]. The focus, however, was mostly put on the POD accuracy due to the requirements of other applications instead of navigation. Using simulation data, a real-time estimation approach for the LEO satellite clock based on ground tracking stations was proposed for the first time [22]. Yang et al. introduced a method to estimate the LEO satellite clocks by integrating ground observations from specific regions with onboard observations from LEO satellites. Without using a ground network, the kinematic clock estimation achieved a precision of over 0.3 ns using GNSS products, while incorporating a simulated ground network improved the clock precision to 0.15 ns [23].

In this contribution, using solely the GNSS observations tracked onboard LEO satellite, a real-time clock estimation strategy is introduced containing filter-based near-real-time clock estimation and ultra-short-term clock prediction. The filter-based processing is proposed to be restarted at pre-defined times to hamper bias propagation and accumulation from ancient epochs, allowing also for convergence through processing arcs that are long enough. Using real data from Sentinel-3B, the effects of using different processing arc lengths and time intervals between adjacent processing sessions are discussed, and the total error budget consisting of the near-real-time clock estimation, ultra-short-term clock prediction and the total real-time clock precision achieved under different cases are analyzed.

The study begins with an overview of the LEO satellite real-time clock determination method, containing the near-real-time clock determination and the ultra-short-term clock prediction. The near-real-time clock determination is elaborately discussed, particularly emphasizing the selection and utilization of the GNSS real-time products. Afterward, the processing strategy for real-time clock determination is introduced with near-real-time clock precision and efficiency achieved with processing arc lengths discussed. Subsequently, the total error budget of the real-time LEO satellite clock precision is assessed for the near-real-time estimation part, the ultra-short-term prediction part, and then combined. The conclusions and discussions are given at the end.

2. Method

In this study, the real-time LEO satellite clocks are proposed to be determined and provided to users with the following steps:

(1)

Set a timer and loop through the steps (2)–(4);

(2)

Use real-time GNSS orbits, clocks and LEO satellite on-board GNSS observation to determine the near-real-time LEO satellite clocks based on the kinematic model, including GNSS product selection and the clock re-referencing;

(3)

Predict the LEO satellite clocks in the ultra-short term, ensuring that users obtain LEO satellite clock products in real time;

(4)

Broadcast the low-order polynomial parameters to users at regular intervals.

The flowchart of real-time clock determination is illustrated in Figure 1. The principles of the steps are described briefly in the following subsections.

2.1. LEO Satellite Clock Determination in Near-Real-Time

LEO satellite clock determination can be realized through a reduced-dynamic POD model or a kinematic POD model. The reduced-dynamic model provides higher accuracy in both the POD and the clock determination [12], while the kinematic model combined with, e.g., Kalman-filtering, achieves higher computational efficiency and better flexibility during, e.g., orbital maneuvers. The foundation for both models is the GNSS raw observation equations, with the differences of combining and not combining dynamic models. Therefore, this sub-section starts with GNSS raw observation equations, which can be formulated as:

$$P_i^s={\rho }_i^s+c\left(d{t}_r-d{t}_s\right)+I_i^s+d_i^s-d_{r,i}+{\epsilon }_{i,p}$$

(1)

$$L_i^s={\rho }_i^s+c\left(d{t}_r-d{t}_s\right)+{\lambda }_i(N_i^s+b_{r,i}-b_i^s)-I_i^s+{\epsilon }_{i,L}$$

(2)

where $P_i^s$ and $L_i^s$ represent the pseudorange and phase observations, respectively. $i$ indicates the frequency, and $s$ indicates the GNSS satellite. $c$ is the speed of light. $d{t}_r$ and $d{t}_s$ are the LEO satellite clock bias and the GNSS satellite clock bias, respectively. $I_i^s$ is the slant ionospheric delay. $d_i^s$ and $d_{r,i}$ represent the pseudorange hardware delays of the GNSS satellite and the LEO satellite, respectively. ${\lambda }_i$ is the wavelength of the frequency $i$, and $N_i^s$ is the carrier phase ambiguity. $b_{r,i}$ and $b_i^s$ denote the carrier phase hardware delays of the LEO satellite and the GNSS satellite, respectively. ${\epsilon }_{i,p}$ and ${\epsilon }_{i,L}$ are the measurement noise and multipath effects of the pseudorange and carrier phase observations, respectively. Other correctable error terms such as tidal effects, phase center offsets and variations, etc., are not specifically described in Equations (1) and (2).

The kinematic model determines the orbit and clocks of LEO satellites using only the GNSS observational data and related real-time GNSS products, without introducing any dynamic models. The kinematic model has the advantages of simplicity, low computational requirements, short processing time, and the ability to maintain good precision. Determining the LEO satellite clocks and orbit using the kinematic model is similar to the PPP (Precise Point Positioning) principle. However, compared to PPP, the GNSS observations received by LEO satellites are not affected by the tropospheric delays.

In this study, the kinematic model is implemented using the Ionosphere-Free (IF) pseudorange and carrier phase observations. The Observed-Minus-Computed (O-C) terms can be expressed as:

$$P_{IF}=A_x\mathsf{\Delta }{r}_K+c\times d{\bar{t}}_r+{\epsilon }_{P_{IF}}$$

(3)

$$L_{IF}=A_x\mathsf{\Delta }{r}_K+c\times d{\bar{t}}_r+\lambda {\overline{N}}_{IF}+{\epsilon }_{L_{IF}}$$

(4)

with

$$d{\bar{t}}_r=d{t}_r+\frac{d_{r,IF}}{c}+d_{rel}$$

(5)

$$\mathsf{\Delta }{r}_K=\left[\mathsf{\Delta }{r}_x,\mathsf{\Delta }{r}_y,\mathsf{\Delta }{r}_z\right]$$

(6)

$${\lambda }_{IF}=\frac{c}{f_1+f_2}$$

(7)

$${\bar{N}}_{IF}=\frac{f_1^2}{f_1^2-f_2^2}{N}_1-\frac{f_2^2}{f_1^2-f_2^2}{N}_2+b_{r,IF}-b_{IF}^s+\frac{-d_{r,IF}}{{\lambda }_{IF}}$$

(8)

where the pseudorange and phase observations O-C terms for the IF combinations are represented by $P_{IF}$ and $L_{IF}$, respectively. $f_1$ and $f_2$ correspond to the first and the second frequencies used, respectively. $A_x$ is the design matrix containing partial derivatives of the observations with respect to the orbital coordinates. $\mathsf{\Delta }{r}_K$ is the orbital correction vector based on the initial orbits, with $\mathsf{\Delta }{r}_x,$ $\mathsf{\Delta }{r}_y$ and $\mathsf{\Delta }{r}_z$ representing the increments of the LEO satellite position in the $X$, $Y$ and $Z$ directions of the Earth-Centered Earth-Fixed (ECEF) system, respectively. $d{\bar{t}}_r$ represents the estimable receiver clocks with the inclusion of the IF receiver code bias $d_{r,IF}$ and the relativistic effects $d_{rel}$. Recall that $d{t}_r$ denotes the LEO satellite clock bias. It is assumed here that the IF code hardware delay of the GNSS satellite is already included in the GNSS satellite clock products. Depending on the specific type of pseudorange dual-frequency observations used, Differential Code Bias (DCB) corrections may be applied. For multi-GNSS processing, Inter-System Biases (ISBs) need to be additionally considered [13,17].

The Kalman filter is a commonly used parameter estimation method in the field of satellite navigation. It first requires the establishment of a linearized kinematic observation model and a state-transition model for filtering. Subsequently, by recursion, the parameters to be estimated are determined. For detailed information, see [24]. In this study, ambiguity parameters are constrained as constants if there is no cycle slip.

This study aims to determine LEO satellite clocks timely, which involves firstly the near-real-time clock determination as introduced above. Therefore, the choice of real-time GNSS products needs to be carefully considered. Currently, many analysis centers of the International GNSS Service (IGS) and other analysis systems like the International GNSS Monitoring and Assessment System (iGMAS) provide rich real-time GNSS orbit and clocks products [25,26,27,28,29], such as those offered by the National Centre for Space Studies (CNES) in France [30], The Federal Agency for Cartography and Geodes (BKG) in Germany [31], the GMV Aerospace and Defense (GMV) in Spain [32], the Wuhan University in China [33] and the GeoForschungsZentrum (GFZ) in Germany [34]. In this study, the selection of real-time GNSS products is based on the following steps:

(1)

Analyze the availability and continuity of each real-time product over a past period.

(2)

Analyze the accuracy of GNSS satellite orbits, the precision of the GNSS satellite clocks, and their Signal-In-Space Range Error (SISRE) over a past period through comparison with the final GNSS products of, e.g., the Center for Orbit Determination in Europe (CODE) [35,36].

(3)

Based on the results of the first two steps, identify a set of optional real-time GNSS products and establish an initial ranking. The ranking list is updated on a daily basis.

(4)

Upon each processing round, conduct an assessment of the availability/continuity of the real-time products of GNSS satellites in the corresponding processing period. For those passing the pre-defined thresholds for availability and continuity, select the real-time GNSS products according to the ranking list, so that real-time GNSS products with both good completeness and precision can be used for the real-time determination of LEO satellite clocks.

Figure 2 shows, e.g., the precision of real-time GPS satellite clocks from the BKG, CNE, GMV, GFZ, and WHU on Day of Year (DOY) 358 to 364, 2023 with a sampling interval of 10 s. It can be seen that the average clock precision from all the analysis centers is better than 0.2 ns, with BKG and WHU exhibiting the best performances during the test period, approximately at 0.12 ns.

Using the above-mentioned selection strategy for real-time GNSS products, the estimated LEO satellite clocks determined may face two issues:

(1)

Inconsistent time references for LEO satellite clocks are determined in each session. This is caused by the different time references of different real-time GNSS satellite clocks provided by different analysis centers.

(2)

Poor stability of the real-time LEO satellite clock time reference due to the poor stability of the time reference of the real-time GNSS satellite clocks, as shown in Figure 3 (red). In Figure 3, the real-time time reference is calculated as the epoch mean difference between all the usable real-time GPS satellite clocks from the CNES and the CODE final GPS satellite clocks [18].

With inconsistent and unstable time references for LEO satellite clocks determined during different sessions, jumps between sessions and degraded clock prediction results can occur. To solve these issues, the LEO satellite clock estimates need to be re-referenced to a stable time reference directly after the near-real-time clock determination in each session. In real-time, the time reference is proposed to be aligned to a selected satellite clock in the corresponding GNSS with good stability and completeness, avoiding at least jumps (red) in Figure 3. After aligning to a stable GPS satellite clock, as shown in the blue line in Figure 3, the standard deviation (STD) of the time reference is reduced from above 10 ns to 1.5 ns, with all the large jumps removed (blue).

Figure 4 shows the Sentinel-3B satellite clocks determined using the CNES real-time clock products. It can be observed that when using the original real-time CNES clock products, the LEO satellite clocks (red) exhibit significant fluctuations. This is attributed to the unstable reference of real-time CNES clocks as shown in Figure 3. Aligning the CNES real-time clocks to a stable GPS satellite clock and then using it to determine the Sentinel-3B satellite clocks (blue), results in a substantial improvement in stability. The improvement in the stability of the time reference does not affect the clock estimation precision but will influence the LEO satellite clock prediction [18].

2.2. LEO Satellite Clock Prediction in Ultra-Short-Term

As described in [19,37], different LEO satellite clock prediction algorithms do not lead to significant differences in ultra-short-term prediction, i.e., a few minutes or shorter. In this contribution, the LEO satellite clocks are predicted with periodic terms and polynomials, expressed as [18,19]:

$$\widehat{C}lk\left(t_p-t_0\right)={\widehat{a}}_0+{\widehat{a}}_1\left(t_p-t_0\right)+\cdots +{\widehat{a}}_m{(t}_p-t_0{)}^m+\sum _{j=1}^k{\widehat{A}}_j\mathrm{s}\mathrm{i}\mathrm{n}\left(\frac{2\pi }{{\widehat{T}}_j}\left(t_p-t_0\right)+{\widehat{\phi }}_j\right)$$

(9)

where $\widehat{C}lk$ denotes the predicted clocks, $t_p$ denotes prediction epoch, $t_0$ is the initial epoch, ${\widehat{a}}_i(i=1,\dots ,m)$ is the polynomial fitting coefficient, $k$ denotes the number of periodic terms, ${\widehat{T}}_j$, ${\widehat{A}}_j$ and ${\widehat{\phi }}_j$ denotes the period, the amplitude and the phase of the periodic terms, respectively. The determination of the coefficients can be referred to [19].

2.3. LEO Satellite Clock Broadcasting for Real-Time Applications

The GNSS satellite clocks are typically broadcast as low-order polynomial coefficients to users either in navigation messages with a low frequency via satellite links, or in real-time streams with high frequency via Internet links [12]. Like the clocks of GNSS satellites, predicted LEO satellite clocks (see Section 2.2) can be fitted with low-order polynomials and provided to users. Due to the bad LEO satellite clock prediction behaviors over the mid- to long-term [38,39], broadcasting clock coefficients over low-frequency navigation messages like GNSS is not a good option for LEO satellites. It is suggested to either significantly increase the update rate of the broadcast clock messages, or transfer the clocks via real-time streams with the Internet. An update interval of a few seconds can be considered.

3. Processing Strategies

Figure 5 depicts a processing timeline of the real-time LEO satellite clock determination based on near-real-time clock determination and ultra-short-term clock prediction. The entire processing flow is initiated on a scheduled basis. The time interval between the launching of two subsequent processing sessions is represented as $∆T$.

In Figure 5, the black line corresponds to the near-real-time clock determination part of LEO satellite clocks, while the red line represents the ultra-short-term clock prediction part. The initial time of the entire process is $T_0$, the processing arc length of the GNSS observations is $T_{obs}$, and the prediction period is $T_{pre}.$ $B$ is the end of $T_{obs}$. $C$ represents the time point when the near-real-time clock determination is completed, $D$ represents the time point when the clock prediction is completed, and $E$ represents the end epoch of the predicted clocks. The total processing time for the entire workflow is denoted as $T_{process}$ ($BD$), while $T_{process}$ is mainly the time taken to determine the near-real-time LEO satellite clocks due to the very short time needed for clock prediction, i.e., typically less than 1 s. According to Figure 5, users can use real-time clock products within the interval [$D,E$], and when the products from the next session are available, [$D+∆T,E+∆T$].

In general, $T_{pre}$ ($BE$) must be longer than the sum of $T_{process}$ ($BD$) and $∆T$ to provide users with real-time LEO satellite clocks; $T_{process}$ is typically shorter than $∆T$ to avoid overlapped processing and to save computational resources; $T_{pre}$ needs to be determined according to $∆T$ and $T_{process}$. When updating the clock products in each session regularly, as shown in Figure 5, the clock products within the interval [$D,D+∆T$] are used by real-time users, with the precision representing the real-time LEO satellite clock precision available to users. To achieve a high real-time clock precision, one needs to, on the one side, obtain high-precision near-real-time clocks as the basis for good prediction and on the other side, attempt to suppress $T_{process}$ ($BD$) to shorten the prediction time window, here mainly shorten the BC part for the near-real-time clock determination.

As a representative example, the LEO satellite Sentinel-3B flying at about 810 km [40] is used to show the relationships between the length of the processing arcs and the processing time for the near-real-time clock estimation (the $BC$ part) within $T_{process}$. Using its 30 s GPS L1/L2 observations, the processing is performed in 288 sessions with the starting time on DOY 228, 2018, shifted by 5 min in each round. The averaged processing time required for the near-real-time clock determination ($BC$ in Figure 5) is shown in

Table 1. The average processing time ($T_{process}$) and the precision (STD) of the near-real-time clock estimates using different processing arc lengths ($T_{obs}$). (K denotes Kalman-filter-based daily solution using the kinematic model and the CNES real-time products, RD denotes the batch least-squares reduced-dynamic solutions using the CODE final products).

${\mathit{T}}_{\mathit{o}\mathit{b}\mathit{s}}$ (h)	${\mathit{T}}_{\mathit{p}\mathit{r}\mathit{o}\mathit{c}\mathit{e}\mathit{s}\mathit{s}}$ (s)	STD (vs. K) (ns)	STD (vs. R) (ns)
24	24	---	---
12	21	0.015	0.19
8	19	0.015	0.19
6	18	0.015	0.20
4	17	0.018	0.20
2	17	0.048	0.22

. For a conservative assessment, a relatively poor processing unit with an operating frequency of the server of 2.1 GHz was used for this test.

From Table 1 it can be observed that reducing the processing arc ($T_{obs}$) from 24 to 6 h, the processing time is shortened from 24 to 17 s, i.e., with a shortening of almost 30%. Comparing the Kalman-filter-based kinematic solutions employing real-time products from the CNES with the batch least-squares reduced-dynamic clock solutions using the CODE final products (denoted as R), reducing the $T_{obs}$ from 24 to 4 h leads to almost no changes in the near-real-time clock determination. Further reducing $T_{obs}$ can slightly reduce the processing time, but could lead to a degradation in the clock precision. Considering the similar processing time and resulting clock precision between $T_{obs}$ of 4 h and 6 h, in this study, $T_{obs}$ is set to the longer processing arc of 6 h for safety reasons, with $T_{process}$ (including the determination and the prediction) equal to 18 to 20 s using a processing unit described above. When calculating the STDs, a 4.42-sigma outlier exclusion was performed.

In addition to $T_{obs}$ and $T_{process}$, other time points in Figure 5 are also important. $∆T$, for example, can be set to 60 to 300 s depending on the real-time precision needed. A short $∆T$ leads to a short prediction time needed to match the real-time window [$D,D+∆T$], and delivers a higher precision of the real-time clocks of the LEO satellite.

In summary, the real-time determination process of LEO satellite clocks in this study is as follows:

(1)

At the current time point $T$, acquire observational data in [$T-T_{obs},T$], and obtain real-time GNSS products selected according to Section 2.1;

(2)

Based on the strategies outlined in

Table 2. Processing strategy.

Type	Parameters	Processing Strategies
Near-real-time clock determination	Observations	Undifferenced IF code and carrier phase combination (GPS: L1/L2)
	Sampling	30 s
	Elevation cut-off angle	3°
	GNSS orbits and clocks	Selected (Section 2.1)
	GNSS satellite antenna PCO/PCVs	igs20.atx
	LEO satellite antenna PCO/PCVs	Operator supplied
	Phase wind-up	Corrected
	Estimatior	Kalman filter, Kinematic
	$T_{obs}$	6 h
Clock Prediction	$T_{pre}$	Longer than $T_{process}+∆T$
	$∆T$	60/120/180/240/300 s
	Broadcast interval	Optional

, determine the LEO satellite clocks in near-real-time;

(3)

According to the prediction method detailed in Section 2.2, predict the LEO satellite clocks over $T_{pre}$.

(4)

Perform a second-order polynomial fitting using the predicted clocks, and broadcast the fitted polynomial coefficients to users;

4. Test Results

Real-time LEO satellite clocks determined based on near-real-time clock determination and ultra-short-term clock prediction are tested and analyzed in this section. Firstly, near-real-time LEO satellite clocks are assessed. Based on the clock predictions tested for different periods, the real-time clocks are then analyzed with their total error budget. GPS L1/L2 observations with a sampling interval of 30 s from Sentinel-3B on DOY 227–229, 2018 are used for the processing.

4.1. Near-Real-Time LEO Satellite Clocks

Using the CNES real-time GNSS satellite orbital and clock products, with the processing arc length $T_{obs}$ set to 6 h, and the time interval $∆T$ between subsequent processing sessions tested for 60, 120, 180, 240, and 300 s as explained in Section 3, near-real-time Sentinel-3B satellite clocks are determined.

The blue lines in Figure 6 connect the near-real-time Sentinel-3B satellite clocks during the last $∆T$ period over each processing arc, i.e., the most recently updated near-real-time satellite clocks to be used for prediction. The Kalman-filter-based daily clocks based on the kinematic model utilizing the real-time products provided by the CNES (red line), and the daily clocks based on the batch least-squares reduced-dynamic model using the CODE final products (yellow line) are given for comparison. The LEO satellite clocks are re-referenced to the same time reference, i.e., that of the CODE final clocks, for a fair comparison with:

$$\Delta t_p^{ref}={\sum }_{s=1}^{m_p}\frac{(t_p^{s_1}-t_p^{s_2})}{m_p}$$

(10)

$$\mathsf{\Delta }\nabla t_p^{s,leo}=t_p^{s,leo}-t_{0p}^{s,leo}-t_p^{ref}$$

(11)

where $\mathsf{\Delta }{t}_p^{ref}$ is the epoch mean difference between the real-time and the CODE final GPS clocks at epoch $p$, and $m_p$ is the number of the compared GPS satellites at epoch $p$. $t_p^{s_1}$ and $t_p^{s_2}$ are satellite clock biases from the real-time and the CODE final products at epoch $p$, respectively, and $t_p^{s,leo}$ and $t_{0p}^{s,leo}$ are the LEO satellite clocks determined based on real-time and the CODE final products at epoch $p$, respectively. $\mathsf{\Delta }\nabla t_p^s$ represents the re-referenced clock difference at epoch $p$.

As depicted in Figure 6, the trends of the connected near-real-time Sentinel-3B satellite clocks determined during the last $∆T$ period of different arcs are generally consistent with the two types of daily solutions. Compared to the daily solutions based on the Kalman-filter-based kinematic model using the CNES products (yellow), the connected near-real-time Sentinel-3B clocks (blue) have fewer outliers. When using the 6 h arcs, the near-real-time clocks determined during the last $∆T$ period are fully converged. The connected clocks determined from the different sessions do not exhibit obvious jumps at boundaries either, since $∆T$ is much shorter than the processing arc length of 6 h, and shifting the observation arc by $∆T$ each time does not lead to significant solution differences at the ending period of the processing arc.

Figure 7 shows the differences between the connected near-real-time Sentinel-3B clocks (blue lines in Figure 6) and the daily clock solutions using the reduced-dynamic model with the CODE final products (yellow lines in Figure 6) over the test period. The results are shifted by $N=\left(∆T⁄60-1\right)\times 2$ ns for each shifted $∆T$ for a better demonstration. As presented in Figure 7, it is noticeable that the trend of the clock errors is highly consistent for different $∆T$. As $∆T$ increases, the STDs of the clock errors are slightly improved.

Table 3. Daily STDs between the connected near-real-time clocks for different $∆T$ and different daily clocks (K denotes Kalman-filter-based daily kinematic clocks using the CNES real-time products, R denotes the batch least-squares reduced-dynamic daily clocks using the CODE final products).

DOY	STD (K vs. R) (ns)	$∆\mathit{T}$ (s)	STD (vs. K) (ns)	STD (vs. R) (ns)
227	0.211	60	0.025	0.218
		120	0.021	0.218
		180	0.018	0.218
		240	0.015	0.215
		300	0.015	0.201
228	0.297	60	0.025	0.304
		120	0.021	0.300
		180	0.018	0.300
		240	0.014	0.299
		300	0.025	0.301
229	0.237	60	0.028	0.246
		120	0.024	0.245
		180	0.020	0.245
		240	0.017	0.241
		300	0.028	0.230

lists the daily precision of the connected near-real-time clocks for different $∆T$. From Table 3, it can first be observed that the connected near-real-time clocks over $∆T$ based on 6 h Kalman-filter-based processing exhibit very similar precision to the daily kinematic clocks using the same CNES real-time products, i.e., with STD of the differences at 0.01 to 0.03 ns. Secondly, compared with the clocks determined by reduced-dynamic with CODE final products serving as the “true” clocks in this study, the STD of connected near-real-time clocks is about 0.2 to 0.3 ns. Having a look at the last column of Table 3, increasing the $∆T$ can slightly improve the connected near-real-time clock precision, i.e., with an improvement within 0.02 ns when increasing $∆T$ from 30 to 300 s. To reduce the required prediction period for real-time applications, a short $∆T$ of 1 to 2 min should be a good choice.

Figure 8 shows the Modified Allan Deviations (MDEVs) [41] of the connected near-real-time clock errors using different $∆T$. As shown in Figure 8, when the averaging time $\tau$ is between the range of [100, 300], MDEV decreases with increasing $∆T$. This corresponds to the conclusions from Table 3, i.e., a large $∆T$ is beneficial for the continuity of the clock solutions, especially over the short term, due to fewer connections of the results. For a $∆T$ of 300 s, the MDEV is slightly increased due to the disturbance of gross errors, which is consistent with its slightly larger STD as shown in Figure 7.

4.2. Real-Time LEO Satellite Clocks

As shown in Figure 5, the interval [$D,D+∆T$] represents the actual time window when the predicted LEO satellite clocks need to be used by users in real time. In other words, the real-time clocks of interest to users are those within the prediction period [$T_{process}$, $T_{process}+∆T$]. This implies that the prediction time $T_{pre}$ needs to be at least longer than $T_{process}+∆T$. As mentioned before, $T_{obs}$ in Figure 5 is set to 6 h, and $T_{process}$ amounts to about 18–20 s. For possible delays in the GNSS real-time products and transmission of the LEO onboard GNSS observations, $T_{process}$ is set to 30 s in this study. In this sub-section, $∆T$ is tested for 60, 120, 180, 240 and 300 s, and $T_{pre}$ is consequently set to 90, 150, 210, 270, and 330 s.

Using the connected near-real-time clocks determined based on different $∆T$ in Section 4.1, and according to the corresponding $T_{pre}$, predictions are performed based on Equation (9) to obtain the real-time Sentinel-3B satellite clocks. The fitting time is tested from 90 to 1800 s with a step of 30 s. The most suitable one, as shown in

Table 4. The daily STDs of the connected real-time clocks according to different $∆T$ (R denotes the daily reduced-dynamic clocks based on batch least-squares adjustment using the CODE final products).

DOY	$∆\mathit{T}$ (s)	${\mathit{T}}_{\mathit{p}\mathit{r}\mathit{e}}$ (s)	Fitting Time (s)	STD of Near-Real-Time Clocks Used for Fitting (ns)	Precision Loss (ns)	STD (vs. R) (ns)
227	60	90	120	0.219	0.064	0.229
	120	150	180	0.219	0.084	0.246
	180	210	180	0.222	0.106	0.247
	240	270	270	0.211	0.127	0.264
	300	330	300	0.223	0.156	0.297
228	60	90	120	0.304	0.069	0.311
	120	150	180	0.301	0.092	0.326
	180	210	180	0.301	0.115	0.329
	240	270	270	0.299	0.138	0.341
	300	330	300	0.303	0.169	0.342
229	60	90	120	0.247	0.068	0.266
	120	150	180	0.245	0.090	0.279
	180	210	180	0.246	0.127	0.295
	240	270	270	0.243	0.136	0.312
	300	330	300	0.228	0.173	0.327

, is the one delivering the smallest STD in prediction errors. The clocks determined based on the batch least-squares reduced-dynamic model with the final CODE products are taken as the reference.

The daily precision of the predicted and then connected real-time clocks within [$T_{process}$, $T_{process}+∆T$] is listed in Table 4. The precision of the near-real-time clocks is about 0.2 to 0.3 ns. As the $T_{pre}$ increases from 90 to 330 s, the precision loss due to prediction is from about 0.06 to 0.17 ns, with the total error budget of the real-time clocks amounting to 0.2 to 0.35 ns. As $T_{pre}$ increases, the precision of real-time clocks gradually decreases due to the slightly increasing prediction errors. As shown in Figure 9, the STD of the near-real time clocks decreases slightly with the increasing $∆T$ (blue bars), while the precision loss due to prediction increases substantially when increasing the $∆T$ (red bars). Therefore, it can be inferred that the total error budget of real-time LEO satellite clocks (yellow bars) based on near-real-time determination and ultra-short-term prediction mainly comes from the prediction, and a small $∆T$ is preferred if possible.

In summary, there are several key factors affecting the final error budget of the real-time LEO satellite clocks:

(1)

The processing time $T_{process}$ is mainly dependent on the processing arc length $T_{obs}$. For the very similar $T_{process}$, it is preferable to have a longer $T_{obs}$ to enhance the short-term stability of the near-real-time clocks. The time interval between subsequent processing sessions ($∆T$) is independent of the precision of the near-real-time clocks but directly determines the prediction time $T_{pre}$ and the usable prediction window [$T_{process}$, $T_{process}+∆T$] for real-time applications. The latter is directly related to the predicted clock precision, i.e., the precision of real-time LEO satellite clocks.

(2)

The precision of the connected near-real-time LEO satellite clocks of the last $∆T$ period within the 6 h processing arcs is similar to the kinematic daily solutions. The major differences in the real-time clocks for different $∆T$ come from the clock prediction, more concretely, from the different prediction times. Further research is needed to improve the ultra-short-term prediction of LEO satellite clocks, i.e., within 5 min.

(3)

When setting $∆T$ to 60 s, a real-time clock precision around or lower than 0.3 ns can be achieved.

5. Discussion and Conclusions

The utilization of LEO satellites is anticipated to enhance various aspects of traditional GNSS-based PNT services. These enhancements include improvements in coverage, signal strength, reliability, initialization time, and landing power. The improved performance of LEO satellites positions them as valuable assets for future real-time high-precision PNT users, particularly in applications like autonomous driving and unmanned aerial vehicles. However, in practical applications, LEO satellites also face some challenges. For instance, the determination of real-time LEO satellite clocks still awaits further investigation due to challenges in mid- to long-term LEO satellite clock prediction.

To address this need, this study introduces real-time LEO satellite clock determination based on efficient high-precision near-real-time clock determination and ultra-short-term clock prediction. The method connects the most updated clock estimates from different rounds of Kalman-filter-based solutions and performs ultra-short-term prediction using the clock estimates of the last few minutes, hampering unnecessary bias propagation and accumulations of ancient epochs.

Using Sentinel-3B GPS L1/L2 observations and the CNES real-time GNSS products, near-real-time satellite clocks were determined and assessed. The results showed that the precision of the near-real-time LEO satellite clocks is generally at 0.2 to 0.3 ns. A processing arc of 6 h can be selected considering the efficiency and the precision. The time interval $∆T$ between subsequent processing sessions affects the prediction time windows needed for real-time applications. When setting the time interval to 60 s, it is possible to obtain real-time LEO satellites with a precision of about 0.3 ns, with a precision loss within 0.07 ns during a prediction time of 90 s. A longer $∆T$ induces larger prediction errors due to the longer prediction time needed.

Although notable precision is achieved in estimating LEO satellite clocks in this study, there are still challenges in real-world applications. For instance, the timely acquisition of observation data and GNSS real-time products is essential, as the corresponding latencies would directly add to the prediction time required to catch up with the real-time applications, which requires further research in the clock prediction of a longer time. Furthermore, different rounds of the processing could lead to the selection of different clock references, and eventually result in jumps in the time reference between subsequent rounds. This might require re-referencing the clock estimates to a stable time reference before broadcasting to users.