## 4 Tests and Results
### \"Mid-Gap\" Scenario  
As previously discussed, the \"mid-gap\" case of GNSS real-time products primarily impacts the near-real-time estimation aspect of the \"arc-estimation\", as illustrated in the right panel of Figure 2. This, in turn, influences the subsequent short-term prediction of LEO satellite clocks, ultimately affecting the precision of the real-time clocks. When employing the arc-processing method to determine near-real-time LEO clocks, as illustrated in Figure 3, it is crucial to minimize \(T_{\text{arc}}\) (\(BC\)) to shorten the prediction arc (\(CD\)), which helps minimize precision loss during prediction, thus achieving high-precision real-time clocks. Based on the existing analysis [16], setting \(\Delta T\) to 120 s and the near-real-time determination arc to 4 h is the preferable choice. Figure 10 displays the real-time clocks of Sentinel-3B estimated in a Kalman filter using the CNES real-time products without latency, denoted as K (see the black line), the corresponding clocks determined based on BLS and CODE final products, denoted as R (see the red line), and the connected near-real-time clocks (shifted by 5 min each session) estimated in a Kalman filter using the CNES real-time products without gaps, denoted as C (see the blue line). The differences between the C and K clocks are displayed in the top panel of Figure 11, and those between the C and R clocks are illustrated in the bottom panel. From Figures 10 and 11, it can be seen that the clock connection between different sessions does not significantly influence the clock performance, leading only to a 0.02 ns difference, as shown in the top panel of Figure 11. The precision of such a real-time clock estimation amounts to about 0.23 ns without gaps (see the bottom panel of Figure 11). \begin{table}
\begin{tabular}{c c c} \hline \hline
**Prediction Period (s)** & **STD (vs. K) (ns)** & **STD (vs. R) (ns)** \\ \hline
30 & 0.042 & 0.222 \\ \hline
60 & 0.055 & 0.224 \\ \hline
90 & 0.064 & 0.230 \\ \hline
120 & 0.081 & 0.232 \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Prediction precision of Sentinel-3B satellite clocks. Figure 9: The MDEVs of the satellite clocks (**left**) and the clock estimation errors and prediction errors over 120 s (**right**) for G16 and G30. From Figure 3, it can be observed that as the sliding window continuously moves (with \(\Delta T\) interval), the obtained near-real-time clocks can be added over the interval \([B,B+\Delta T]\) to the clocks processed in the previous session. Starting from 4:00 (GPST) on the test day, different lengths of mid-gap periods are set to discuss their impact on the LEO satellite clocks. As the sliding window continuously moves, when the end epoch of the LEO observation data falls within the \"mid-gap\" duration, the LEO satellite clock is determined by using the predicted GNSS clocks and orbits. Based on the analysis in the previous section, GNSS clock prediction will lead to a sharp degradation in LEO satellite clock determining precision, as shown in the top panel of Figures 12-14, especially when the prediction duration is tens of minutes. Therefore, the near-real-time LEO satellite clocks estimated based on extrapolated GNSS products are not included in the statistical analysis. When the end epoch of the observation data exceeds the mid-gap, the GNSS clocks and orbits used to determine the LEO satellite clocks are obtained through linear interpolation. In comparison, the GNSS satellite clocks are interpolated with a precision loss depending on the gap period, i.e., about 0.01, 0.013, and 0.015 ns for gaps over 5, 10, and 15 min, respectively. Figure 11: Differences between the C and K clocks (**top**) and C and R clocks (**bottom**) for Sentinel-3B.