## 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 \(\Delta 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+\Delta T,E+\Delta T]\). In general, \(T_{pre}\) (\(BE\)) must be longer than the sum of \(T_{process}\) (\(BD\)) and \(\Delta T\) to provide users with real-time LEO satellite clocks; \(T_{process}\) is typically shorter than \(\Delta T\) to avoid overlapped processing and to save computational resources; \(T_{pre}\) needs to be determined according to \(\Delta 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+\Delta 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. Figure 5: Processing timeline of the real-time LEO satellite clock determination based on near-real-time clock determination and ultra-short-term clock prediction. 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. 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.