Introduction

Since 1994, the GNSS user community takes advantage of precise GPS orbit products provided by International GNSS Service (IGS). The IGS products ensure long-term reference frame stability and enable centimeter-level accuracy, if one adheres to the IGS and IERS conventions (Dow et al. 2005; Kouba 2009). The IGS currently provides precise orbit and clock products for GPS and GLONASS, and further inclusion of other constellations is planned (Dow et al. 2009). The IGS products used to be derived with some delay, reaching up to 18 days for final products, so their main purpose is to be used in post-processing mode. Real-time users were limited in the sources of precise data, since only the predicted part of ultra-rapid products was available in real time. In this case, a prior download of orbit and clock data was necessary, but the predicted products have significantly worse performance than those derived from measurements.

In order to satisfy real-time users with more precise products, the IGS Real-Time Working Group (RTWG) was established in 2001 (Caissy and Agrotis 2011). During the IGS 2002 Workshop in Ottawa, held under the theme “Towards Real-Time”, a framework for development of a real-time service (RTS) was defined (IGS 2011). In June 2007, the IGS announced the “Call for Participation in the IGS Real-time Pilot Project” (http://www.rtigs.net). In August 2011, the RTWG declared that the pilot project had reached the initial operating capability, providing access to continuous streams with GNSS data, precise orbit and clock corrections. IGS RTS has been officially launched on April 1, 2013.

Currently available official real-time IGS products include only corrections to GPS satellite broadcast orbits and clocks. IGS01 is a single-epoch combination solution. IGS02 is a Kalman filter combination product. A third product, IGS03, which is a Kalman filter combination with correction for GPS and GLONASS, is in an experimental stage. RTS also provides real-time access to broadcast ephemeris: RTCM3EPH01 contains GPS orbit data and RTCM3EPH has capacity to include GPS, GLONASS and Galileo.

RTS products availability is especially important for real-time precise point positioning (PPP) (Collins et al. 2005; Dixon 2006). The basis of PPP technique is the application of products generated from observations from permanent and continuous GNSS station networks to utilize the computational potential of global network analysis. Precise satellite orbits and clock are introduced into the system of observation equations as fixed parameters; so their errors directly affect the quality of the positioning (Zumberge et al. 1997). Target accuracies of IGS combined real-time products are 5 cm for orbit and 0.3 ns for clock, which corresponds to 9 cm when multiplied by the speed of light. Real-time products are affected by some latency, which is a result of the time required to transmit the data, process observations, update the correction stream and, in case of the combined product and to combine solutions from each Analysis Center (AC). The RTS goal is providing a reliable real-time GNSS combination product free of outages and outliers (Mervart and Weber 2011).

The performance of real-time streams and the quality of products are monitored by the real-time analysis center coordinator. Precise clocks and orbits from the official RTS products are compared daily with IGS rapid solution. Results are presented in the IGS RTS webpage (http://rts.igs.org/). In general, products meet the target precision. The single-epoch solution (IGS01) is slightly more accurate than the Kalman filter combination (IGS02). Additionally, the indirect verification is performed by the application of the products into various PPP strategies, performed by the German Federal Agency for Cartography and Geodesy (BKG) AC using BKG NTRIP Client (BNC) software provided by BKG (2013). The RTS stream monitoring offers also information about current and historical stream availability. Such monitoring is consistent with other IGS product reporting, but the number and magnitude of outliers, as well as any other undesirable behaviors, are not well known. No advanced verification is performed or has ever been shown. Still there are a very limited number of papers showing methodology and results obtained while using RTS products. Examples of real-time correction application are presented, e.g., by Chen et al. (2013) and Ge et al. (2012).

This study is an attempt to review RTS products in detail and focus on issues important for end users. In the second section, the IGS RTS products application algorithm is presented. Main characteristics of corrections provided are described that one must be concerned with while using the corrections. The following sections contain descriptions and results of various analysis performed on RTS data recorded from July 27, 2013 (DOY 204), to August 2, 2013 (DOY 214), using BNC and Matlab software. Two sets of data were simultaneously recorded: one with GPS data only from the IGC01 stream and second with GPS and GLONASS data from the experimental IGS03 stream. IGC01 differs from IGS01 only by the fact that coordinates refer to satellite center of mass (CoM). IGS03 refers to satellite APC. The third section deals with the RTS availability and latency of corrections at the user site. These parameters are critical for real-time applications, because the delayed data may introduce additional errors and significantly degrade the results. The fourth section contains results obtained from real-time precise orbits and clocks comparison with final products. The results are presented separately per GNSS satellites, considering satellite block and type of onboard clock, as well as collectively for each GNSS system. Detected outliers are also the subject of analysis. In the fifth section, the relation between product latency and accuracy is investigated. It is evaluated with respect to onboard clock-type and satellite block. In the sixth section, some attempts of short-time prediction of the state space representation (SSR) corrections are presented. In the recorded correction data, correction stream gaps of different periods were simulated. Missing corrections have been forecast on the basis of previous data using various extrapolation techniques. The best of proposed methods allows extending the application period of obsolete data without a significant loss in orbit quality. The last section contains a summary of studies conducted and the conclusions regarding RTS precise orbits and clocks quality.

RTS products application

In order to provide real-time products, IGS joined the Radio Technical Commission for Maritime Services—RTCM (RTCM 2011). IGS RTS uses Networked Transport of RTCM via Internet Protocol (NTRIP) for streaming GNSS and differential correction data over the Internet (Weber et al. 2005). The RTS correction streams are formatted according to the RTCM-SSR standard. The SSR is a functional and optional stochastic description of the individual GNSS error components. Actual state parameters are transmitted to the rover, so the users correct their own observations from a single GNSS receiver with SSR corrections computed from the state parameters for his individual position (Wübbena et al. 2005).

Orbit and clock corrections refer to broadcast navigation data, so they should be compatible with the current navigation message. However, after update of the broadcast ephemeris, the corrections may still be referred to the previous message even up to few minutes. To avoid the combination of incompatible data, the messages include IOD for ephemeris (IODE) that indicates the broadcast ephemeris for which the corrections are valid. In case of corrections that refer to out of date navigation message, this outdated broadcast ephemeris should consequently be used until the change of the SSR-IODE value in the SSR message occurs.

Orbits corrected with official RTS products are expressed within ITRF08 (International Terrestrial Reference Frame 2008). Other real-time streams may or not refer to other regional reference frames. The information about the reference frame is indicated in the stream identifier. After applying the corrections, the satellite coordinates are referred to the APC. Therefore, the precise coordinates are directly prepared for positioning applications. However, the IGC01 stream and some single AC products refer to satellite CoM. In this case, phase center offset of each satellite is subtracted, so it should be added back in by user for proper positioning operation.

The orbit corrections \(\delta \varvec{O}\) are defined in radial (δO r), along-track (δO a) and cross-track (δO c) component. Each component consists of a correction term δO and its velocity \(\delta \dot{O}\). Such implementation results in reduced bandwidth. The application algorithm for RTCM-SSR orbit corrections is as follows:

  1. 1.

    recalculate orbit corrections from message reference time t 0 to current epoch t

    $$\delta \varvec{O} = \left[ {\begin{array}{*{20}c} {\delta O_{\text{r}} } \hfill \\ {\delta O_{\text{a}} } \hfill \\ {\delta O_{\text{c}} } \hfill \\ \end{array} } \right] + \left[ {\begin{array}{*{20}c} {\delta \dot{O}_{\text{r}} } \hfill \\ {\delta \dot{O}_{\text{a}} } \hfill \\ {\delta \dot{O}_{\text{c}} } \hfill \\ \end{array} } \right]\left( {t - t_{0} } \right)$$
    (1)
  2. 2.

    calculate direction unit vector e in radial (e r), along-track (e a) and cross-track (e c) directions

    $$e_{\text{a}} = \frac{{\dot{r}}}{{\left| {\dot{r}} \right|}},\quad e_{\text{c}} = \frac{{r \times \dot{r}}}{{\left| {r \times \dot{r}} \right|}},\quad e_{\text{r}} = e_{\text{a}} \times e_{\text{c}}$$
    (2)

    where r is the satellite broadcast position vector and \(\dot{r}\) is satellite broadcast velocity vector

  3. 3.

    transform the corrections to geocentric corrections \(\delta \varvec{X}\)

    $$\delta \varvec{X} = \left[ {\begin{array}{*{20}c} {e_{\text{r}} } & {e_{\text{a}} } & {e_{\text{c}} } \\ \end{array} } \right]\delta \varvec{O}$$
    (3)
  4. 4.

    apply the geocentric corrections to broadcast orbits \(\varvec{X}_{\varvec{b}}\) to obtain precise orbits \(\varvec{X}_{\varvec{p}}\)

    $$\varvec{X}_{\text{p}} = \varvec{X}_{\text{b}} - \delta \varvec{X}$$
    (4)

The geometric interpretation of orbit correction application is presented in Fig. 1.

Fig. 1
figure 1

Geometric interpretation of SSR for orbit corrections

Full size image

Clock corrections δC are given as offsets to the broadcast ephemeris satellite clock corrections. They consist of two constituents: polynomial (described with coefficients C i , i = {0, 1, 2}) and high-rate clock. Both constituents describe the complete state of clock, but the high-rate clock is optional and is not supported by RTS yet. To take advantage of RTS precise clocks:

  1. 1.

    recalculate the clock corrections from message reference time t 0 to current epoch t

    $$\delta C = C_{0} + C_{1} \left( {t - t_{0} } \right) + C_{2} \left( {t - t_{0} } \right)^{2}$$
    (5)
  2. 2.

    apply the corrections to the broadcast clock

    $$t^{\text{sat}} = t_{\text{broadcast}}^{\text{sat}} - \frac{\delta C}{c}$$
    (6)

    where c is the speed of light.

Originally, clock corrections estimated by ACs are affected by common offset per epoch. The combination process adopted by official IGS products removes a common offset from all satellite clocks at each epoch. However, for positioning and navigation, the clock standard deviation is the appropriate parameter for describing its quality, as the common offset in the satellite clocks will be absorbed by the station clock (Chen et al. 2013). The precise clock corrections do not eliminate the periodical relativistic effect; therefore, it should be handled exactly as it is described in the corresponding GNSS interface control document (ICD).

RTS availability and latency

In real-time applications, the availability and latency of products delivered to the users are of importance. Lack of correction data eliminates satellites from precise positioning, and the obsolete data may introduce additional errors. Both factors may significantly degrade the result of GNSS data processing.

To investigate the performance of real-time products, the BNC software was used. Each instance of software received ephemeris data, one correction stream (IGS01 for GPS, IGS03 for GLONASS) and observation data directly from the receiver at station WROC. The data were recorded with 30-s interval in RINEX format and simultaneously transmitted to the Matlab environment through TCP–IP connection. Procedures implemented in Matlab allowed storing real-time orbits and clocks with 1-s interval as well as additional information (e.g., reference epoch of corrections and epoch of observations) that cannot be stored in RINEX format. The data from the RINEX files obtained from BNC were used to verify the correctness of procedures for application of real-time corrections that were implemented by the authors.

From the data thus gathered, the availability of RTS corrections was checked. Figure 2 presents the unavailability of real-time data for each GPS and GLONASS satellite during the recorded period. In general, the availability of data is over 92 % for both satellite systems. This statistics neglects GPS satellites PRN 27 and 30, because no precise data were available for those satellites at all. GPS PRN30 was unusable since May 8, 2013, and the broadcast almanac did not include SVN49/PRN30 (according to Notice Advisory to NAVSTAR Users 2013029). The only problem with GPS PRN27 during the time of experiment was satellite modeling problem on DOY 212 (31.07.2013) reported by CODE IGS AC (ftp.unibe.ch/aiub/BSWUSER50/GEN/SAT_2013.CRX). The lowest availability (29 %) of corrections occurred for GPS PRN01, but even then they did not match IODE’s of broadcast orbit from the RTCMEPH3 stream, resulting in an effective 0 % availability.

Fig. 2
figure 2

Unavailability of correction data for GPS (green) and GLONASS (red) satellites, DOY 208-214, 2013. Eclipsing periods are marked with gray

Full size image

For ten GPS satellites, no interruption in precise data delivery occurred, and for another ten satellites, less than 1 % of data were missing. For GLONASS satellites, corrections were available for at least 76 % of the time, except for PRN08 for which the availability was only 23 % and no information about the satellite problem was found by the authors. There were at least 1 % of missing data for every GLONASS satellite. Apart from the GPS PRN01 and GLONAS PRN08, the length of the gaps in corrections did not exceed 8 h. The majority of gaps were shorter than 1 h. There were few cases, when a short gap occurred simultaneously for several satellites, e.g., DOY 208 after 18:00 and DOY 211 after 14:00 for GPS, DOY 213 after 1:00 for GLONASS. This might have been related to data transfer problems on the user or caster side.

GPS real-time orbits and clocks are provided also for eclipsing satellites. The subject was given special attention, because of the known problems with satellite yaw attitude determination during eclipse (Bar-Sever 1996). There are only few cases (GPS PRN06, PRN09 and PRN24) for which the correction data were unavailable during the eclipsing period. The situation was quite different for GLONASS, where corrections for satellites during eclipse were available only for 40 % of the time. Usually, corrections were available again within 30 min after the eclipsing period ended, except for GLONASS PRN 17, 20 and 21, when the unavailability lasted almost continuously for more than one revolution.

As to correction latency, we understand that the difference between the epoch of processed data and the reference epoch of applied correction. Each of the contributing AC needs about 10 s to deliver their precise, uncombined products, which is consistent with the target performance. In case of the combination solution, the Real-time Analysis Center Coordinator requires additional time to collect data, analyze results and eliminate outliers. It takes at minimum an additional 10 s to produce the combined product, but should result in more reliable and stable performance than that of any single AC product. Depending on the RTCM-SSR stream characteristics, the data update interval is 5 s for GPS combined orbit and clock corrections, 10 s for GPS and GLONASS clock corrections and 60 s for GPS and GLONASS orbit corrections (rts.igs.org/products/).

Using the data stored with Matlab procedures, the latency of corrections available on IGS01 and IGS03 streams was investigated. At first, two subsets of data (separately for orbit and clock corrections), containing only the corrections available at the epochs of stream update, were selected. The Latencies of these subsets reflect the time required for data processing and combining at the Analysis Centers and for data transfer through the NTRIP to the end user. Results show that the minimum time required to provide combined orbit and clock corrections is about 31 s for the IGS03 stream (Fig. 3) and about 28 s for IGS01. This difference is caused by the application of the Kalman filter in the IGS03 stream, while IGS01 is only single-epoch combination solution.

Fig. 3
figure 3

Histograms of latencies of orbit (left panel) and clock (right panel) corrections at the epochs of stream update in the IGS03 stream

Full size image

Second, another two subsets of data (separately for orbit and clock corrections), containing only the data available just before the update occurrence in the stream, were selected. The subsets contained data when the differences between the epoch of observations and correction reference epoch were the biggest. They reached 92 s for orbit corrections and 42 s for clock correction. However, these differences should not be confused with latency, since the corrections are provided with rates and therefore are valid over some period. For IGS RTS, this is currently true at least for orbits, because the corrections are from short-term predicted orbits and correction rates are provided to fit the complete 60 s interval. More problematic are the clock corrections, since they are instantaneous (temporarily correct), and only the constant term C 0 of clock correction polynomial is provided (5). To minimize the degradation of clock corrections, one can wait with data processing until the complete and synchronized set of SSR data arrives. Unfortunately, this will lead to a loss of real-time processing in favor of near-real-time processing, which may be not accepted in some applications In real-time applications, the available corrections will always have the reference epoch prior to the epoch of measurements.

Comparison of real-time orbits and clock with final products

In order to assess the accuracy of the IGS real-time products, the data from the IGS01 and IGS03 streams were used for GPS and GLONASS, respectively. Final products provided by the European Space Operations Centre (ESOC) were served as a reference data. These AC products were selected because the IGS final products do not contain GLONASS data, while the ESOC provides orbit and clock products for both GNSS systems. The difference between the ESOC final products and the IGS final products can be considered much smaller than the target accuracy of the RTS products (Griffiths and Ray 2009). To make the real-time precise orbit that is originally referred to APC comparable with the ESOC final orbits that are referred to the satellite CoM, the APC offsets were subtracted using the absolute IGS antenna correction file recommended by IGS (igs08_1745.atx). Orbit comparison was made every 15 min, according to the interval provided in ESOC final products. Clocks were compared every 30 s, according to the interval of ESOC final high-rate clocks.

General statistics of the comparison are presented in Table 1 for GPS and Table 2 for GLONASS. Non-eclipsing data subset does not contain eclipsing periods, whereas eclipsing data subset contains only epochs previously excluded. For both GNSS systems, the radial component is the most accurately determined—12 mm for GPS and 30 mm for GLONASS. The accuracy of the cross-track component is on average 2 times worse, and at least 3 times worse for the along-track component. The along-track component is slightly less accurate during eclipsing periods. The 3D orbit accuracy for GPS is 48 mm, and the clock accuracy is 84 mm (0.28 ns). The 3D orbit accuracy for GLONASS is 132 mm, and the clocks are determined with the accuracy of 245 mm (0.82 ns). During eclipsing periods, accuracy of the products becomes slightly worse. Results obtained for GPS are quite similar to the ones presented by Laurichesse et al. (2013) for the CNES AC real-time GPS products.

Table 1 RMS for GPS products (IGS01 stream) (m)
Full size table
Table 2 RMS for GLONASS products (IGS03 stream) (m)
Full size table

The statistics for each satellite are presented in Fig. 4. For three GPS satellites from block IIA (PRN 06, 09 and 32), orbit accuracy was clearly worse, especially for the along-track component. The same situation occurred for three GLONASS satellites from the third orbital plane (PRN 17, 20 and 21). Among these six satellites, only GPS PRN32 did not eclipse during the whole time of experiment. The average precision of the orbits was below 1 cm for GPS and 5 cm for GLONASS. Relatively large satellite-specific biases for GPS clock differences were related to satellite and AC-specific bias (Mervart and Weber 2011). Such biases are not present in the GLONASS clock statistics, because they were eliminated jointly with inter-frequency biases to make the comparison possible. The bias in real-time solutions was a result of processing C1 instead of P1 by some ACs, as well as different procedures applied by ACs for clock estimation. The combined product is just a mean value from individual clocks provided by the different ACs; hence, corresponding code biases are not provided for combined products. For precise application using carrier phases, the consistency of service with a particular frequency pair becomes critical. Providing code biases messages with real values is a potential field of improvement of RTS. Nevertheless, for decimeter-level accuracy, such systematic clock biases will not degrade positioning result unless the phase observations are used for the computation of the rover position in PPP mode (Weber et al. 2007).

Fig. 4
figure 4

RTS orbits and clocks quality with respect to ESOC final products during DOYs 208-214, 2013

Full size image

All of the residuals that exceed 2 standard deviations were detected and flagged as outliers. Outliers occurrence over time is presented in Fig. 5, and the spatial distribution is presented in Fig. 6 for GPS and Fig. 7 for GLONASS. In addition, Fig. 5 contains the information about epochs with the sudden clock-jump value exceeding 1 m (3.33 ns). Such jumps were probably related to the change in reference clock; however, further studies are required to fully investigate these events. The majority of GPS outliers were related to three satellites (PRN 6, 9 and 32) and occurred around South America and over the Pacific Ocean. For these areas, the outliers have repetitive character and their values were the highest, exceeding 20 cm. For PRN, 6 and 9 numerous outliers occur around Australia. For GLONASS, 94 % of orbit outliers are related to satellites from the third orbital plane, which was in eclipsing season. Clock outliers and jumps occur evenly for all satellites.

Fig. 5
figure 5

Outliers in RTS products for GPS (IGS01) and GLONASS (IGS03) during DOYs 208-214, 2013

Full size image
Fig. 6
figure 6

Spatial distribution of GPS orbit (green circles) and clock (orange crosses) outliers for DOYs 208-214, 2013

Full size image
Fig. 7
figure 7

Spatial distribution of GLONASS orbit (red circles) and clock (blue crosses) outliers for DOYs 208-214, 2013

Full size image

Among all detected outliers in GPS and GLONASS orbits and clocks, less than 5 % occur during the eclipsing time. Elimination of data for satellite during eclipsing period does not affect the general quality statistics of the RTS products (Tables 1, 2).

RTS corrections quality degradation over time

It can be assumed that the longer the latency of corrections, the lower their quality. To investigate this relation, the following experiment was carried out. First, the recorded SSR corrections were synchronized to precise orbit epochs, which means that the SSR message reference epoch was equal to the epoch of precise orbit and clock computation. Then, the correction was applied to broadcast orbits and clocks. This results in the most accurate real-time orbit and clock possible to obtain using RTS. These data are used as a reference in further comparisons. In the next step, precise orbits and clocks were calculated such that applied corrections were always taken from data available from some earlier epochs and recalculated to current epoch according to (1) and (5). This procedure simulated the situation when corrections have some additional delay. Various lengths of delay were used, from 5 s to 10 min at intervals of 5 s. Long delays were considered to simulate the situation, e.g., when the user loses the connection to the stream caster but continues to perform positioning, which goes against the RTCM-SSR standard. This was done for as an illustration of quality degradation. Finally, absolute differences between the reference synchronized set of data with each delayed data set were analyzed to produce degradation rates in radial, along-track and cross-track component and clocks as follows.

For each length of simulated delay, we calculated absolute differences with respect to the reference set and excluded 5 % of the most scattered data. To determine the mean degradation rates, straight line fitting was performed on the data corresponding to delays up to 2 min (Tables 3, 4). The nonlinear character of the dependency enforces the limit of 2 min, beyond which the number of corrections exceeds the 5-cm error. The GPS results are presented for example satellites of specific block and clock type (Fig. 8). For GLONASS satellites, examples and statistics are according to the year of launch (Fig. 9), because currently all the satellites are block M with Cs clocks on board.

Table 3 Degradation rates of RTS orbit and clock corrections for GPS system (cm/min)
Full size table
Table 4 Degradation rates of RTS orbit and clock corrections for GLONASS system [cm/min]
Full size table
Fig. 8
figure 8

Degradation of orbit and clock corrections over time for a representative set of GPS satellites: PRN03 (IIA + Cs), PRN24 (IIF + Cs), PRN04 (IIA + Rb), PRN11 (IIR + Rb), PRN17 (IIM + Rb) and PRN25 (IIF + Rb)

Full size image
Fig. 9
figure 9

Degradation of orbit and clock corrections over time for a representative set of GLONASS satellites: PRN19 (launched in 2007), PRN18 (2008), PRN01 (2009), PRN12 (2010), PRN07 (2011), PRN02 (2013)

Full size image

For the GPS system, satellites from the same block and of the same type of onboard clock were characterized, showing a similar dependence trends. In general, the clock corrections degrade faster than the orbit corrections. This result confirms the need for a higher stream update interval for clocks than for orbits. Irrespective of the onboard clock-type, clock corrections are affected with additional 5-cm error for delays beyond 1 min. Accuracy of corrected cesium (Cs) clocks may be lower than 20 cm just after 2 min. Rubidium (Rb) clocks appear slightly more stable, which corresponds with the results presented by Hesselbarth and Wanninger (2008). After 10 min of delay, accuracy of corrected Rb clock is at the level of 15 cm. The Rb clocks installed on GPS satellites of block IIF seem to be an exception of above conclusions. They are characterized which much higher short-term stability. Clock corrections degradation rate is only 1.7 cm per minute, which is at the same level as orbit corrections (Table 3). This means that they are affected with additional 5-cm error after about 3 min.

For GLONASS satellites launched before 2011, clock correction degradation rates are similar to GPS Cs clocks’. Two minutes of latency may degrade clock corrections by more than 20 cm. Combining RTS corrections with GLONASS clocks launched since 2011 gives similar results as with GPS IIM Rb clocks. After 1-min latency, clock corrections are affected with at least 5 cm of additional error.

The delay dependency for orbit corrections has almost a linear trend for both GPS and GLONASS systems (Figs. 8, 9). The along-track component relation is almost identical for all satellites within one GNSS system. Radial and cross-track component degradation rates are very similar within each satellite, as if they were highly correlated. These two orbital components usually degrade faster than the along-track component, except for few GPS satellites from block IIR and IIM (e.g., PRN 11) and two GLONASS satellites (PRNs 17 and 18). Orbit corrections for GLONASS degrade approximately 2 times faster than those for GPS. For GPS satellites, a 5-cm degradation in each component is expected after about 2 min. For GLONASS, only 1 min is necessary.

The explanation of the fact, that the radial component degrades faster than along-track, while the first one is usually the best determined orbital component, may be that the radial correction velocities are poorly determined and thus are a source of significant error after a few minute latency. This requires further investigation, but if one does not take correction velocity term into account, all of the orbital corrections degrade faster, and the radial component is the one that degrades the slowest.

Short-term prediction of corrections

Real-time precise positioning in changing environmental and spatial conditions requires reliable and precise orbits and clocks that are continuously available. As presented in the previous section, the RTS availability is lower than 100 % and the products are not free of outliers. They are provided with some latency and their precision degrades over time, especially for clocks. Furthermore, because one may have to deal with interruptions in caster connection, the real-time positioning may be impossible or severely affected.

This problem motivated us to search for a method that extends the correction validity period without degrading the solution significantly. The time series of orbit corrections between each IODE value change look like pieces of polynomial curves, both for GPS and GLONASS systems (Fig. 10). GPS orbits corrections values have lower variability than those of GLONASS. Particularly, the GPS radial corrections show very low fluctuations over time. The clock corrections have high-rate fluctuations, and one can see clear discontinuities not related to IODE change.

Fig. 10
figure 10

Time series of RTS corrections during 00:00 to 12:00 of DOY 210, 2013

Full size image

In order to determine the character of the curves, we fitted polynomials of degree 1 to 5 to every data set between IODE changes, separately for each correction component (Table 5). For GPS orbit corrections, increasing the polynomial degree up to four results in reduced standard deviation of residuals for each component. For the GLONASS system, using polynomials of degree higher than three does not provide significant improvement. Fitting a straight line results in residuals that exceed 10 cm. For the clock corrections, the increase in polynomial degree results in relatively small reduction in standard deviation of residuals.

Table 5 Standard deviation of polynomial fitting to the time series DOY 208-2014, 2013 of RTS corrections
Full size table

An experiment similar to the one described in previous section was performed, but this time polynomial extrapolation of corrections was used instead of their standard correction calculations to current epoch. Polynomials of degree 2 to 4 were applied, and various lengths of data required to properly extrapolate corrections were investigated.

Based on the number of performed simulations, we discover that it is possible to predict orbit corrections with high reliability. To achieve the most accurate predictions, one should fit polynomial to data that are at least 3 times longer than the prediction step. The minimum length of fitted data is 3 and 5 min for GPS and GLONASS, respectively. For GPS, polynomials of degree 2 should be used up to 5 min of prediction and for longer prediction using 3 degree gives better results. For GLONASS, polynomials of degree 3 are better for predictions longer than 2.5 min.

Prediction of clock corrections using polynomial models does not provide any improvement with respect to the direct application of obsolete clock corrections. Such a result was expected since the satellite clock contains stochastic variations that are accumulated over time, and some of them have white noise characteristics. More sophisticated models should be used in order to improve the short-term clock correction prediction. Further studies may investigate the application of quadratic polynomial model, improved gray model (Zheng et al. 2009) or embedded linear prediction (Heo et al. 2010). Predictions should be accompanied with extrapolated noise characteristics to be used operationally, e.g., Allan deviations.

Results obtained from the proposed strategy are presented in Fig. 11. For GPS satellites, it is possible to forecast orbit corrections with 1-cm accuracy up to 4 min, and with 2-cm accuracy up to 8 min. For GLONASS, the time limits decrease to 2 and 4 min, respectively. For both GNSS, the prediction of along-track component is less reliable than that of the radial and the cross-track component.

Fig. 11
figure 11

Degradation over time of orbit and clock corrections prediction using the proposed strategy

Full size image

Conclusions

Since April 2013, the IGS RTS provides access to precise orbit and clock corrections, code biases as well as broadcast ephemeris via NTRIP protocol, using RTCM-SSR messages. Details on RTCM-SSR application can be found in (RTCM 2011), but we described the application methodology in a compact form, paying attention to the most important topics.

To assess the quality of RTS products, we used the data between DOY 208 and DOY 214, 2013 from the official IGC01 stream for GPS, the experimental IGS03 stream for GLONASS and the RTCMEPH stream for ephemeris data of both systems. In general, the availability of GPS correction was over 95 %. The majority of data gaps were shorter than 1 h, but in extreme cases no data were available for up to 8 h. The availability of GLONASS corrections was over 90 %. Real-time orbits and clocks are provided also for eclipsing satellites. For GPS, there are only single cases when corrections were unavailable for an eclipsing satellite. On the other hand, for GLONASS eclipsing satellites, the availability is only 40 %.

From the comparison of RTS products with ESA/ESOC final products, we confirmed that the RTS orbits are of high accuracy—in general, it is 48 mm for GPS and 132 mm for GLONASS. Real-time clocks accuracy is 84 mm (0.28 ns) and 245 mm (0.82 ns) for GPS and GLONASS, respectively, so estimation of real-time GLONASS clocks require further development to reach the target level of 0.3 ns. The accuracy of GPS real-time corrections provided for satellites during eclipsing is slightly worse. For eclipsing GLONASS satellites, the accuracy of corrections is significantly lower than that for other satellites.

Further studies were related to RTS corrections quality degradation over time and to attempts of short-time prediction of correction on the basis of prior data. The relation between product latency and accuracy, with respect to GPS block and type of onboard clock or GLONASS year of launch, is determined. On average, 5 cm of additional error is expected when using orbit corrections with 3 min latency and clock correction with 1 min latency. Using polynomial fitting, it is possible to reliably forecast the orbit corrections up to 8 min for GPS and 4 min for GLONASS. The proposed short-term prediction methodology can be used, e.g., for the outliers detection in RTS corrections. Clock correction prediction requires further studies with more sophisticated prediction models.