## 4 Tests and Results
### \"End-Loss\" Scenario  
Under normal circumstances, GNSS real-time orbits and clocks are received via the internet in State Space Representation (SSR) format. Depending on the network quality, the GNSS orbits and clocks are assumed to be delayed with the same latency. However, due to the varying prediction accuracy loss of GNSS orbits and clocks, it is necessary to analyze not only the impact on LEO satellite clocks when both GNSS orbits and clocks are missing but also the impact when each is lost separately. The five scenarios of \"end-loss\" are detailed in Table 2. Scenarios A and B involve the loss of both the GNSS clocks and orbits; while the orbits are extrapolated using the Nevil model, the clocks of the last available epoch are used for Scenario A and linearly extrapolated in Scenario B. Scenarios C and E assume only the delay of the GNSS real-time clocks, with the clocks of the last available epoch used in Scenario C and linearly extrapolated in Scenario E. To compare the impacts of the clock and orbit loss, Scenario D assumes the latency of only the orbits. It is worth noting that real-time GNSS satellite clocks with an unstable time reference can be re-referenced to the clocks of a selected GNSS satellite before predicting the GNSS clocks. Assuming that the latency of GNSS real-time products typically does not exceed 120 s, the latency is set to 30, 60, 90, and 120 s for further evaluation. The analysis started from scenario A. Figure 5 illustrates the comparison between the real-time Sentinel-3B satellite clocks determined using the CNES real-time products with different latencies (Scenario A in Table 3). The real-time clocks using the CNES products without latency are used as a reference in Figure 5 to illustrate the precision loss caused by only the latencies. It can be inferred that as the latency of the GNSS product loss increases from 30 to 120 s, the fluctuation in the clocks visibly increases. Figure 4: **(Top)**: Sentinel-3B satellite clocks determined using the Kalman filter-based kinematic model with the CNES real-time products without latency (blue line) and using the BLS-based reduced-dynamic model with the CODE final products (red line); (**Bottom**): differences between the two sets of clocks (real-time and final) in the top panel after unifying the time reference. When using the BLS clocks and employing the CODE final products as the reference, the four cases in Figure 5, together with the case without latency in the GNSS products, are shown in Figure 6 (for Scenario A in Table 3). Comparing the dark blue line with the other lines, it can be seen that the degradations caused by latencies of the GNSS products, even at 30 s, are significant. The degradation increases with the latency of the GNSS products. Taking the CNES real-time products with 120 s loss at the end as an example, Figures 7 and 8 illustrate the LEO satellite clock errors in the five scenarios in Table 3 compared with the case without latency in the CNES real-time products, as shown in Figure 7, and those  
Figure 5: Sentinel-3B clocks determined using the Kalman filter-based kinematic model and CNES real-time products with different latencies for Scenario A. The clocks using CNES real-time products without loss at the end are used as the reference. Figure 6: Sentinel-3B clocks determined using the [PERSON] filter-based kinematic model and CNES real-time products with different latencies for Scenario A. The BLS clocks using the CODE final products are used as the reference. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Scenario** & **Lost Products** & **Lost Duration (s)** \\ \hline A & Clocks and orbits (predicted) & 30/60/90/120 \\ \hline B & Clocks (predicted) and orbits (predicted) & 30/60/90/120 \\ \hline C & Clocks & 120 \\ \hline D & Orbits (predicted) & 120 \\ \hline E & Clocks (predicted) & 30/60/90/120 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Five scenarios of “end-loss” situation.