Introduction

The observations from Global Navigation Satellite System (GNSS) systems can be used to study the state of the troposphere at a given location and time by estimating the respective amount of zenith total delay (ZTD) and converting this to integrated water vapor (IWV) using surface meteorological data (Bevis et al. 1994). Both of these GNSS-derived tropospheric parameters (ZTD and IWV) can further be assimilated into numerical weather prediction (NWP) models having a positive impact on the quality of weather forecasts (Bennitt and Levick 2011; de Haan 2011; Gutman et al. 2004; Vedel et al. 2004). As of today, the global positioning system (GPS) is the most widely used GNSS in operational meteorology. However, research is ongoing for the inclusion of other GNSS in meteorological applications. Therefore, in the following text, the term GNSS would refer to GPS unless otherwise stated.

Over the last decade, a number of international research projects and programs in Europe (Elgered 2001; Huang et al. 2003), North America (Smith et al. 2007) and Asia (Iwabuchi et al. 2000) have investigated the use of GNSS-derived near real-time (NRT) ZTD estimates in NWP models. Since 2005, the EUMETNET EIG GNSS Water Vapor Program (E-GVAP) enables various analysis centers across Europe to submit their NRT ZTD estimates for assimilation into the NWP models of the partner meteorological institutions (Vedel et al. 2013). In late 2012, another European project “COST Action ES1206: Advanced GNSS Tropospheric Products for Monitoring Severe Weather Events and Climate (GNSS4SWEC)” (Jones et al. 2014) was approved to investigate GNSS meteorology further in the light of modern challenges and developments.

As of today, the NRT ZTD estimates are assimilated into local-, regional- and global-scale NWP models that are run with 3–6 h update cycles and produce long-term (up to a few days) weather forecasts. However, with the developments of high update-rate NWP models, e.g., the rapid update cycle (RUC) (Benjamin et al. 2010) and the real-time meso-analysis high-resolution rapid refresh (RTMA-HRRR) (Brian et al. 2014), and in order to use the ZTD estimates for NWP nowcasting and monitoring extreme short-term weather changes, it is desired to obtain them with a minimal latency of 10 or even 5 min while maintaining an accuracy of 5–30 mm (Offiler 2010).

The real-time (RT) transport of GNSS observational data and products is carried out in the formats specified by the Special Committee 104 (SC104) of the Radio Technical Commission for Maritime Services (RTCM) (http://www.rtcm.org/) using the Network Transport of RTCM via Internet Protocol (NTRIP) (Weber et al. 2006). Since December 2012, the real-time service (RTS) of the International GNSS Service (IGS) (Caissy et al. 2012; Dow et al. 2009) and its associated analysis centers are making RT orbit and clock products officially available to the GNSS community. These products include the broadcast ephemeris and the orbit and clock corrections. The IGS together with RTCM-SC104 has defined different formats for the dissemination of observation and correction data in RT. The format for observation data messages is called RTCM-3 and that for orbit and clock correction messages is called RTCM-SSR, where SSR stands for state space representation (Wübbena et al. 2005). The RTCM-SSR real-time streams are composed of various types of messages.

Using the RT data and products, ZTD can be estimated in RT, but different strategies result in different accuracies of the ZTD estimates. The availability of orbit and clock products in RT triggers the possibility to perform precise point positioning (PPP) (Zumberge et al. 1997) in RT. Although both the double-differenced (DD) and PPP processing strategies can be implemented in RT, PPP is highly suitable for RT processing due to being computationally more efficient.

Various error sources can affect the accuracy of the GNSS-derived ZTD estimates. In PPP processing, the ZTD is more sensitive to the radial component of the orbit error, whereas in DD processing, it is more sensitive to the tangential component of the orbit error (Douša 2012). Although the first-order ionospheric delay is eliminated using the linear combination of the measurements from two different carriers, there remains still a smaller effect from the higher-order terms of the ionospheric delay, especially during the times of high solar activity. There is a linear dependency between the daily mean of the total electron content (TEC) unit and the estimated vertical position (Fritsche et al. 2005). If the error in ZTD is approximated as one-third of the vertical position error (Hill et al. 2009), it would mean that an increase of the TEC unit from 25 to 175 will result in a ZTD error ranging from 0.6 to 4 mm if higher-order ionospheric corrections are not applied. Furthermore, errors in the a priori zenith hydrostatic delay (ZHD) caused by the use of inaccurate surface pressure values could result in an error of −0.1 to −0.2 mm/hPa in vertical position estimates (Tregoning and Herring 2006), and this could also lead to an error in the ZTD. Antenna-related errors, e.g., phase center offsets (PCO) and variations (PCV) and radome geometry, also lead to errors in the vertical position and the ZTD estimates. Byun and Bar-Sever (2009) and Thomas et al. (2011) have shown that differences in the estimated ZTD with and without the PCV corrections may vary from 2 to 10 mm. The effect of inaccurate or unaccounted PCOs may be even larger (up to few centimeters). The tropospheric mapping functions (MF), which are used to map the tropospheric delay from other angles (slant) to zenith, also have an elevation-dependent effect on the corresponding ZTD, although the effect of the MF reduces with an increase in any elevation cut-off angle used for observations (Ning 2012).

Fixing of integer phase ambiguities enhances the precision of the position estimates. In the DD strategy, common errors are removed and it becomes easier to identify and fix such integer ambiguities. However, for un-differenced observations, it was not possible to fix the integer phase ambiguities until recently (Geng et al. 2010). Among others, the Centre National d’Etudes Spatiales (CNES) has developed strategies to fix integer ambiguities of un-differenced phase measurements by first fixing the difference between the ambiguities on the two carrier frequencies and then fixing the remaining ambiguity in a global network solution (Loyer et al. 2012). To date, only few studies have been performed to study the impact of ambiguity resolution on GNSS-based ZTD estimates in RT-PPP with some of them benefitting from software and products not necessarily available to the community (Shi and Gao 2012; Li et al. 2014).

We have evaluated the suitability of RT-PPP ZTD estimates for meteorological applications through a comparison with the IGS final troposphere product and collocated radiosonde (RS) observations. These estimates have been obtained by three different PPP software packages using RT orbit and clock products from the IGS RTS as well as from the individual analysis center CNES. The effect of integer ambiguity resolution on ZTD estimates has also been studied. All three software packages and products used are freely available.

The next sections describe the RT-PPP software packages, the RT data and products, and the reference solutions used in this study followed by results, discussion and conclusions.

Real-time PPP systems

The real-time processing for a selection of GNSS stations and time periods was simultaneously performed at the University of Luxembourg (UL) and the Geodetic Observatory Pecny (GOP). UL generated the solutions from BNC2.7 and PPP-Wizard, whereas GOP generated the solutions using the Tefnut application from their G-Nut software library.

The BKG Ntrip Client (BNC), developed by the Bundesamt für Kartographie und Geodäsie (BKG) (Weber and Mervart 2012), is capable of performing PPP in RT (RT-PPP). For this study, version 2.7 of the BNC has been used to perform RT-PPP using streams of code plus phase observations, the broadcast ephemeris and correction streams for satellite orbits and clocks. During the processing in BNC, these corrections from the RT streams are applied to the broadcast ephemeris. Along with the precise position estimates, the ZTD estimates can also be obtained as one of the outputs. The recent study by Yuan et al. (2014) is also based on this software package; however, they have modified it to implement some precise bias models such as ocean tide loading, receiver antenna PCV and computation of hydrostatic and wet mapping functions from Global Pressure and Temperature 2 (GPT2) model (Lagler et al. 2013).

To promote their ambiguity-fixing strategy, CNES developed the “Precise Point Positioning with Integer and Zero-difference Ambiguity Resolution Demonstrator (PPP-Wizard)” and started to produce a RT product containing corrections for integer ambiguity resolution, which can be used to fix ambiguities in RT-PPP mode (Laurichesse et al. 2009, Laurichesse 2011). Similar to BNC2.7, the PPP-Wizard was not developed with this particular application of RT GNSS meteorology in mind.

The G-Nut software library (Václavovic et al. 2013) has been developed at the Geodetic Observatory Pecny (GOP) since 2011 in order to support development of high-accuracy GNSS analysis. Several end user applications have been derived for meteorology and climatology (Tefnut), geodesy and seismology (Geb) and GNSS quality checking (Anubis). We have used the G-Nut/Tefnut software, which is capable of estimating GNSS tropospheric parameters in RT, NRT and post-processing modes (Douša and Vaclavovic 2014).

All the above-mentioned software packages use a Kalman filter. The configuration and characteristics of the software packages used in this study are shown in Table 1. For the BNC2.7 and PPP-Wizard solutions, the a priori coordinates of the stations were computed by a 20-day average of coordinates obtained using PPP with the Bernese GPS Software 5.0 (BSW50) (Dach et al. 2007). The G-Nut/Tefnut does not need a priori coordinates; however, if precise station coordinates are available, they can be introduced into the processing as a priori values. In this campaign, G-Nut/Tefnut was used without introducing a priori coordinates. During the RT data processing, BNC2.7 computed the receiver coordinates (unconstrained) in every epoch, whereas the version of PPP-Wizard used for this study did not estimate the receiver coordinates in order to reduce the number of unknown parameters. Hence, in the PPP-Wizard solution, the coordinates were fixed to the values provided a priori and the ZTD was estimated every 5 s. The G-Nut/Tefnut software applied simultaneous coordinate and ZTD estimations. The former were tightly constrained to remain stable over time, while the latter were constrained loosely to optimally balance between stable and reliable tropospheric parameter estimates.

Table 1 Configuration of the software packages used in this study

The convergence time of the RT-PPP solutions (coordinates and ZTD) is generally between 20 and 60 min depending among others on the quality of the station data and satellite constellation if no precise a priori coordinates are provided. However, as mentioned above, for PPP-Wizard and BNC2.7, the a priori coordinates were provided, and hence, the convergence time was not significant. For G-Nut/Tefnut, the results were filtered to include only the epochs after the convergence time.

The software packages BNC2.7 and PPP-Wizard are meant for RT and kinematic applications and therefore do not employ the most precise bias models, e.g., ocean tide loading and higher-order ionospheric corrections. The G-Nut/Tefnut is, however, meant for tropospheric applications, but it is still undergoing some developments and lacks some precise bias models such as the ocean tide loading.

Real-time data and products

The network of GNSS stations selected for this study comprises 22 globally distributed IGS stations, which provide RT observation data (Fig. 1). Table 2 provides the relevant station information. A dataset containing RT-PPP ZTD estimates for these stations and a time period of 31 days (2013-04-18 to 2013-05-18) was obtained using the software packages listed in the previous section. Only GPS observations have been used in this study. Table 3 provides some characteristics of the RT product streams used for this study.

Fig. 1
figure 1

IGS real-time stations used in this study

Table 2 Receiver and antenna information for IGS real-time stations used in this study
Table 3 Real-time correction streams (http://rts.igs.org/products/, http://www.ppp-wizard.net/caster.html)

The first reference dataset used to compare the RT-PPP ZTD estimates is the IGS final troposphere product (hereafter termed IGFT) generated by the U.S. Naval Observatory (USNO) (Byram et al. 2011). The IGFT is based on the final IGS orbit and clock products and contains the ZTD estimates computed by processing 27-h observation window using PPP with BSW50 at an output sampling interval of 5 min.

The second reference dataset consists of the ZTD estimates derived from the observations of RS (NCAS-BADC 2006) collocated with five selected GNSS stations. The ZHD and the zenith wet delay (ZWD) at the RS locations have been corrected for height differences (to the GNSS station height). The height correction on ZHD has been applied using the method described in Douša and Elias (2014), whereas the ZWD has been corrected for height using the method described in Gyori and Douša (2013). However, no correction has been applied for the horizontal separation between the GNSS station and the collocated RS. Table 4 shows the selection of the RS sites along with their horizontal and vertical distances to the respective GNSS stations. The ZTD from GNSS observations (at the five stations shown in Table 4) has then been compared with the ZTD from the corresponding RS.

Table 4 The selected radiosondes used for comparison

The statistics for the comparisons have been computed using only the common epochs in the respective datasets. Considering the noise level in the RT-PPP ZTD estimates, we argue that the statistics computed over the one month give a good indication of the quality (precision and the stability of biases) of the estimates. However, we acknowledge that the seasonality of the IWV may have a small influence on the comparison between the GNSS-derived and RS-based ZTD (Park et al. 2012), which cannot be seen using the one month period.

Results

This section provides the results of the comparisons. For brevity, we will below refer to the BNC2.7 solutions using the IGS01 products as BN01, the BNC2.7 solutions using the IGS02 products as BN02, the PPP-Wizard (ambiguity float) solutions as PWFL, the G-Nut/Tefnut solutions using IGS01 products as GN01, and the G-Nut/Tefnut solutions using IGS02 products as GN02. Table 5 gives an overview of the product streams and software used in each of the solutions. IGS01 and IGS02 (tested with BNC2.7 and G-Nut/Tefnut) streams contain single-epoch and Kalman filter combined solutions, respectively, and could help studying any impact of the combination approaches on the RT-PPP ZTD estimates. Although the PPP-Wizard is also able to ingest the IGS01 and IGS02 product streams in non-ambiguity-fixing mode, however, it was tested only with the CLK9B stream in order to examine the impact of ambiguity fixing only by keeping all other parameters in the fixed and float solutions consistent. Various technical problems, often related to data communication, compromise the transfer of real-time data and lead to gaps in the observation data, and hence, 100 % of the data are not available in real time, which results in gaps in the RT-PPP ZTD time series. In addition, some software packages provide more ZTD estimates than others based on the same input data. Table 6 shows the percentage of ZTD estimates obtained from each of the RT solutions for each station.

Table 5 Combinations of software package and product streams used in RT-PPP ZTD solutions
Table 6 Percentage of available RT-PPP ZTD epochs in different solutions

On average, the RT-PPP ZTD estimates were available for 78 % of the selected time period from BNC27, 65 % from PPP-Wizard, and 92 % from G-Nut/Tefnut. The lower amount of available RT-PPP ZTD estimates from PPP-Wizard is due to missing data and product streams caused by a temporary network-related issue at UL from 2013-05-10 to 2013-05-18. Apart from the missing data, another reason for missing estimates for some epochs is that during the PPP convergence period, after a data gap, the ZTD estimates with large formal sigma are rejected.

Internal evaluation

For all the stations used in this study, the RT-PPP ZTD time series (not shown) obtained from all the solutions follow the same pattern. Figure 2 shows the time series of the difference between the RT-PPP ZTD estimates and the IGFT for these stations. The difference time series of PWFL solution in Fig. 2 has been plotted after removing the mean bias (considering the fact that the bias in the ZTD is removed before NWP assimilation, however, it is important that the bias is stable over time). The gap in the PWFL difference time series around day 11 for all 4 stations is due to a temporary interruption in the CLK9B product stream. For the station BOR1 (top right), the gap in the difference time series for all the RT solutions around day 3 is due to interruption of data stream from that station for this period. The gap in the GN01 and GN02 solution for the station BUCU (bottom left) around day 14 is due to an interruption in the data stream at that time at GOP.

Fig. 2
figure 2

Difference of RT-PPP ZTD estimates and IGFT for the stations ALBH, BOR1, BUCU and HERT in days since 2013-04-18 18:00:00UTC. Panels from the top: BN01, BN02, PWFL, GN01, GN02

The overall biases between the RT-PPP ZTD estimates from the individual RT solutions and the IGFT are shown in Table 7. It can be seen that the G-Nut/Tefnut solutions (GN01 and GN02) have a better stability (i.e., lower standard deviation) of the mean bias as compared to the BNC2.7 solutions (BN01 and BN02). It should be noted that the two G-Nut/Tefnut solutions used the same strategy, software and data access, so any difference in results reflects the stability and reliability issues related to the applied products. Similarly, for the two BNC2.7 solutions, same processing strategy was used and the only difference was in the applied products. However, unlike the G-Nut/Tefnut solutions, the mutual difference (in terms of bias) between the two BNC2.7 solutions is relatively larger. One possible reason for the lower bias in BN02 as compared to that in BN01 could be the use of a Kalman Filter combination orbit/clock correction stream (IGS02) rather than a correction stream with single-epoch solution (IGS01) as in BN01. The RMS of the difference between the RT-PPP ZTD from the BNC software and that from the IGFT as shown by Yuan et al. 2014 is lower than that found in this study, and this is because of the fact that they have implemented ocean tide loading corrections, improved mapping function and receiver antenna PCV correction in their version of BNC. The PPP-Wizard’s ambiguity float solution (PWFL) has the largest mean bias, which is a consequence of the fact that the PPP-Wizard currently does not allow the application of antenna up eccentricity (height) and receiver antenna phase center models for offsets and variations, hence resulting in a mismatch between the constrained coordinates of the survey marker and the ZTD estimation at the antenna phase center. Table 8 shows the station-wise biases in PWFL with respect to the up eccentricities of the antenna ARP. However, for the assimilation into NWP models, it can be argued that the standard deviation of the ZTD is of more importance than the bias, because any station-specific biases are corrected for during the screening process before the assimilation. Also, aforementioned mean biases of the RT-PPP ZTD solutions (calculated over all stations) have less significance than that of the standard deviations because the biases vary with location and characteristics of the station.

Table 7 Biases in RT-PPP ZTD solutions to IGFT
Table 8 Station-wise mean bias in PWFL and the ARP UP eccentricity

As mentioned earlier, the PPP-Wizard is capable of resolving integer ambiguities in RT-PPP. In order to study the effect of integer ambiguity resolution on the RT-PPP ZTD estimates, another RT solution for the same stations and time period as above was obtained using PPP-Wizard with the ambiguity resolution feature. We term this solution as PWFX. Keeping in view the time needed for ambiguity convergence, only those epochs (≈40 % of the total) from PWFX have been included in the evaluation for which the number of fixed ambiguities is ≥4. The difference between the RT-PPP ZTD of PWFL and PWFX solutions was found to be 0.61 ± 4.66 cm with an RMS of 4.93 cm. The observed impact of ambiguity resolution on ZTD is approximately 6 mm, which compares well to, e.g., the 20 % (4–5 mm) impact observed by Geng et al. (2009). The recent study by Li et al. (2014), which is based on their in-house software and products, also reported on the insignificant differences between the RT-PPP float and fixed solutions after sufficiently long times of convergence. However, they demonstrated the usefulness of ambiguity fixing for the rapid re-initialization of an RT-PPP estimation system (e.g., after an interruption in the data stream).

To verify the claimed reason for the large bias in the PPP-Wizard solutions, i.e., the lack of ARP eccentricity and PCO corrections, another processing experiment for a different 1-week long period using the PPP-Wizard was conducted in which the coordinates were corrected for ARP eccentricities and the PCO prior to processing. The L 1 and L 2 PCOs have been combined by using the ionospheric free linear combination, i.e.,

$${\text{PCO}}_{{L_{1} + L_{2} }} = \frac{{f_{1}^{2} {\text{PCO}}_{{L_{1} }} - f_{2}^{2} {\text{PCO}}_{{L_{2} }} }}{{f_{1}^{2} - f_{2}^{2} }}$$

where f 1 = 1575.42 MHz, f 2 = 1,227.60 MHZ, and PCO values are in millimeters.

Integer ambiguity fixing was also applied during this experiment. We name the PPP-Wizard solution from this new experiment as PWFX2. The RT-PPP ZTD estimates from PWFX2 were then compared with the corresponding IGFT estimates. The bias between IGFT and PWFX2 was found to be 2.33 ± 2.76 cm (in contrast to 6.81 ± 2.42 cm for IGFT–PWFL) with an RMS of 4.60 cm (in contrast to 14.96 cm for IGFT–PWFL). This implies that after applying the ARP eccentricity and PCO corrections to the a priori coordinates, the mean bias between the ZTD estimates from PPP-Wizard and IGFT has been reduced by approximately 66 % and the RMS of this bias has been reduced by approximately 70 %.

External evaluation

The statistics from the comparison of GNSS-derived ZTD and RS-based ZTD are summarized in Table 9. In terms of standard deviation, the G-Nut/Tefnut solutions (GN01 and GN02) show the best agreement to the RS-based ZTD, whereas in terms of the mean bias, BNC2.7 solutions (BN01 and BN02) show the best agreement to the RS-based ZTD. The BNC2.7 solutions show mean biases between 1 and 2 cm, whereas G-Nut/Tefnut and PPP-Wizard solutions show mean biases between 2 and 3 cm with the RS-based ZTD. In contrast to the comparison with IGFT, the mean bias of the BN01 solution is lower than that of the G-Nut/Tefnut solutions, which is because of the fact that the statistics of the RS comparisons are based on the five selected stations (unlike 22 stations in the case of IGFT comparisons) and the biases are station specific. Figure 3 shows the time series of GNSS-derived and RS-based ZTD estimates for the station HERT as an example. It can be seen that all the time series follow the same pattern, and both the GNSS-derived and RS-based ZTD are sensitive to the variations in a similar fashion. This is also the case for the other 4 stations not shown in Fig. 3. The time series of the difference between the RT-PPP ZTD solutions and the RS-based ZTD for the station HERT are show in Fig. 4.

Table 9 Statistics of comparison between GNSS-derived and RS-based ZTD
Fig. 3
figure 3

RT-PPP ZTD estimates and RS-based ZTD for station HERT

Fig. 4
figure 4

Difference of RT-PPP ZTD and RS-based ZTD estimates for station HERT

Discussion

The COST Action 716: Exploitation of Ground-Based GPS for Climate and NWP Analysis, which was a demonstration project to study the potential of ZTD products from ground-based GPS networks for NWP and climate monitoring, specified various user requirements (Offiler 2010) for GNSS meteorology, which define threshold and target values on timeliness, accuracy and resolution, etc., of ZTD and IWV estimates for use in NWP nowcasting and climate monitoring. These requirements are widely accepted for quality control during operational use. Table 10 summarizes the current user requirements for NWP nowcasting; however, during the new COST Action ES1206 (GNSS4SWEC), these requirements will be revised. The typical value of the dimensionless conversion factor Q (Askne and Nordius 1987) used for the conversion of ZWD to IWV is approximately 6, and therefore, 1 kg/m2 of IWV is equivalent to about 6 mm of ZTD (Glowacki et al. 2006). Using this equivalence, the accuracy requirements for IWV can be translated into their equivalent for ZTD, which are 6 mm (0.6 cm) target and 30 mm (3 cm) threshold values. Considering the IGFT as the truth and the RMS of the bias of each solution from IGFT as a measure of its relative accuracy, the obtained RT-PPP ZTD solutions can be compared with these requirements. Table 11 shows this comparison for each RT solution generated in this study.

Table 10 User requirements for GNSS meteorology (NWP nowcasting)
Table 11 Comparison of RT relative accuracies to user requirements of GNSS meteorology

It can be seen from Table 11 that BN02, GN01 and GN02 meet the threshold requirement for relative accuracy, whereas BN01 and PWFL exceed the threshold. Although the application of the ARP eccentricity and PCO corrections on the coordinates prior to processing has improved the relative accuracy of the PPP-Wizard solution, it currently exceeds the threshold requirements for NWP nowcasting.

A similar comparison (not shown) with these user requirements conducted by considering the RMS of the difference between GNSS-derived ZTD and RS-based ZTD as a measure of relative accuracy yields that only the two G-Nut/Tefnut solutions (GN01 and GN02) meet the threshold requirements, whereas the others exceed the threshold. However, the RS-based ZTD also has an uncertainty, and it is possible that it has a bias due to inaccurate height corrections.

Conclusions

The suitability of RT-PPP ZTD estimates from three different software packages for operational meteorology was assessed through a comparative analysis using the IGS final troposphere product and RS data as references. In terms of standard deviation, it was seen that the solutions from the G-Nut/Tefnut software library achieves the best agreement with these. The solutions from BNC2.7 are the next closest to the references. Among the BNC2.7 solutions, lower biases have been found for the solutions computed using the correction stream containing a Kalman Filter combination (IGS02) rather than the one computed using a single-epoch solution correction stream (IGS01). The ambiguity float solution from the PPP-Wizard has the largest bias to the IGFT because of the fact that it currently does not apply receiver ARP eccentricity and PCO corrections during processing. However, the application of ARP eccentricity and PCO corrections on the coordinates prior to processing leads to a 66 % reduction in this bias. Integer ambiguity resolution using the PPP-Wizard seems to have a millimeter-level effect on the RT-PPP ZTD estimates.

The RT-PPP ZTD solutions were compared with the established user requirements for NWP nowcasting by using RMS bias to IGFT as a measure of relative accuracy. It was found that GN01, GN02, and BN02 fulfill the threshold requirements on ZTD accuracy, whereas BN01, and PWFL, PWFX (and PWFX2) exceed this threshold. The RT-PPP ZTD solutions were also compared with RS-based ZTD, and an agreement of 1–3 cm in terms of bias and 1–4 cm in terms of standard deviation was found between the two. Furthermore, the comparison with the user requirements was repeated by using the RMS bias between GNSS-derived ZTD and RS-based ZTD as a measure of relative accuracy, and it showed that only the two G-Nut/Tefnut solutions (GN01 and GN02) meet the threshold requirements, whereas the BNC2.7 and PPP-Wizard solutions, without the implementation of precise bias models in the software, exceed the threshold. However, the implementation of precise bias models such as receiver antenna PCV, ocean tide loading and higher-order ionospheric corrections in these software packages can enhance their suitability for NWP nowcasting.