PPP/PPP-RTK open formats: Overview, comparison, and proposal for an interoperable message

This paper presents and reviews the main existing open specifications for PPP/PPP-RTK services, including satellite navigation providers (QZSS, Galileo, BeiDou, GLONASS) and other industrial or scientific initiatives (RTCM, SAP-CORDA, 3GPP, IGS). To structure the comparison, we adapted PPP/PPP-RTK services to the well-known OSI model and defined them according to their properties in the OSI communication layers. We show how the proposed formats relate to the current standards, mainly RTCM SSR and CSSR, and what their differences and similarities are in terms of transmitted corrections and bandwidth. We compare the efficiency of the existing formats in two scenarios: a global PPP scenario with multi-GNSS corrections, and a regional PPP-RTK scenario, also multi-GNSS and including ionospheric corrections. We propose an interoperable format that can be an extension to CSSR and allows efficient transmission of corrections for both global-scale MEO-based PPP as well as nationwide IGSO/GEO-based PPP-RTK.

available satellites such as Galileo in medium Earth orbit (MEO), and regional or nationwide services can be provided by regionally available satellites such as the Quasi-Zenith Satellite System (QZSS) in inclined geosynchronous orbit (IGSO) or geostationary Earth orbit (GEO).
The Centimeter-Level Augmentation System (QZSS CLAS) is an open nationwide PPP-RTK service for Japan that has been operational since November 2018 (Cabinet Office, 2021).The multi-GNSS advanced demonstration tool for orbit and clock analysis (MADOCA) is a regional PPP service that is currently in the experimental phase (GPAS, 2017) (Alves et al., 2020;European Commission et al., 2020;Fernández-Hernández, 2020).BeiDou PPP is a regional PPP service for China and neighboring areas that has been operational since August 2020 (CSNO, 2020).
The Australian and New Zealand Satellite-based Augmentation System (SBAS) provided a working testbed for SBAS, dual-frequency multi-constellation (DFMC) SBAS, and PPP-via-SBAS (PVS) services, with plans for it to be made operational in 2022 as the Southern Positioning Augmentation Network (SouthPAN; Barrios et al., 2018;Geoscience Australia, 2020;Land Information New Zealand, 2020).GLONASS plans to have a commercial PPP service using its L3 signal by 2030 (Pasynkov, 2019).In addition to satellite-based services, ground-based PPP/PPP-RTK correction services will also be available in several countries.
Due to the number of national high accuracy programs, the International Committee on GNSS (ICG) established the PPP Interoperability Task Force (3PITF), chaired by the authors of this article, with a focus on improving the interoperability of PPP services globally.By encouraging the publication and dissemination of PPP signal and system information, the task force aims to make more highaccuracy services available to more user equipment types.
User applications need to support multiple receivers and providers, and interoperability between them is highly desirable to reduce development costs and increase usability.The correction data for PPP/PPP-RTK is provided in state-space representation (SSR) instead of observationspace representation (OSR) used in conventional RTK and network-RTK.PPP corrections include satellite orbit, clock corrections, and signal biases.They may also include ionospheric and tropospheric corrections for faster convergence.
For conventional RTK or network-RTK services, the Radio Technical Commission for Maritime Services (RTCM) defined the RTCM 3 format in the RTCM Special Committee 104 .It is widely accepted as an industry standard, and GNSS receivers supporting RTCM 3 can be compatible with several correction services.The lack of a widely accepted PPP/PPP-RTK open standard may force receiver manufacturers to spend considerable effort to support multiple services, so PPP/PPP-RTK is being standardized in RTCM SC-104 as RTCM SSR (RTCM SC-104, 2020).
This paper is divided into the following sections: After this introduction, PPP/PPP-RTK open correction formats are presented based on the Open Systems Interconnection (OSI) seven-layer model; then, QZSS CLAS/MADOCA, Galileo HAS, BeiDou PPP, and SAPCORDA formats are presented and compared, and the features and the efficiency including the required data rate per satellite are evaluated [for this comparison, typical-use cases such as global or regional PPP, precise point positioning with ambiguity resolution (PPP-AR), and nationwide PPP-RTK are investigated]; and finally, a generic message format for orbit, clock, and bias corrections is proposed as part of the compact SSR (CSSR) standard as a way to improve the interoperability between different service providers, and its effectiveness is investigated.
The purpose is to make PPP/PPP-RTK independent from the transmission method or service provider, thereby reducing the effort of receiver development.The interoperability of correction data between multiple correction service providers has not been achieved in conventional technologies such as network RTK, and is beyond the scope of this paper.

OPEN PPP/PPP-RTK FORMATS
Recently, several open formats for PPP/PPP-RTK have been proposed, as shown in Figure 1.CSSR (Hirokawa et al., 2016), which is highly efficient and compatible with RTCM SSR, is proposed and applied for QZSS CLAS (Cabinet Office, 2021).The format for Galileo HAS is also partly based on CSSR (European Commission et al., 2020) and the format for BeiDou PPP (CSNO, 2020) is similar to RTCM SSR.SAPCORDA has recently proposed an open-format, SPARTN, for its commercial correction service (SAP-CORDA, 2020).Geo++ recently proposed a highly efficient open format named SSRZ applying the entropy encoding for compression (Wübbena et al., 2020).and CSSR (3GPP, 2020).Lastly, the International GNSS Service (IGS) community is interested in the SSR-based correction service for scientific applications, and defined IGS SSR as a derivative of RTCM SSR (IGS, 2020).

PPP/PPP-RTK services viewed from the OSI model
A generic structure of open PPP/PPP-RTK services is represented in Figure 2 based on the OSI seven-layer model from top to bottom: application, presentation, session, transport, network, data-link, and physical.Some of the layers are grouped for the sake of simplicity.

Application layer
The top layer is the application layer, which provides a high accuracy position using a PPP/PPP-RTK algorithm.At the moment there are no official standards for position calcula-tion, but some open software packages such as PPPWizard or RTKLib are widely used for this purpose (CNES, 2021;Takasu, 2021).

Presentation/session layers
The next layers are the presentation layer and the session layer.The presentation layer represents the content of logical information for PPP/PPP-RTK services in an understandable format by several applications, or a standard.The session layer represents the mechanisms for handling multiple sessions between applications, and could be assimilated to the validity of high accuracy data.We therefore treat in this category the correction fields and validity time used by the PPP/RTK algorithm.
Conventionally, the messages defined in RTCM standards are widely used for RTK or network RTK as an industrial standard.Recently, CSSR and SPARTN were also proposed and applied to PPP-RTK.The service needs to reduce the maximum throughput to increase the number of subscribers or support multiple high-accuracy correction techniques such as PPP, PPP-AR (ambiguity resolution), and PPP-RTK.
Traditionally the large convergence time from 10 minutes to 30 minutes is a major drawback of PPP and PPP-AR.Recently, some research has been conducted to reduce the convergence time of PPP within a few minutes by using the triple-frequency ambiguity resolution method (Geng et al., 2020;Li et al., 2020;Psychas & Verhagen, 2020).
In order to minimize the convergence time further, some formats broadcast correction data for the ionospheric delay and tropospheric delay under a regional or local area, and it is in this case that we refer to PPP-RTK formats.The format can also provide corrections for three or four frequencies per satellite, also reducing convergence time (Laurichesse & Banville, 2018).In any case, as the addition of atmospheric corrections or multiple frequencies increases the required amount of the throughput, formats need to be highly efficient.
For the reduction of the throughput, the update interval of each state such as the clock, orbit, signal bias, and bit assignment needs to be optimized.The satellite clock error changes faster than the satellite orbit and signal bias errors, so the update interval of clock correction is typically shorter than that of other states.
In QZSS CLAS (CSSR), the update interval is 5 seconds for the clock and 30 seconds for other corrections.These corrections need to be mixed in the user application to make the range correction for each satellite, and they should be consistent.The consistency should be maintained by applying the conditional update to fix the slower states as constant.
For example, the receiver must be able to combine a 30-second-old orbit correction with a newer 5-second-old clock correction.The orbit correction represents the error of broadcast ephemeris, and depends on the generation of broadcast ephemeris identified by the issue of data ephemeris (IODE or IODnav).
For conventional correction services, corrected satellites are identified by GNSS ID and satellite number.For narrow-band correction services such as SBAS, the selected satellites are identified by the satellite mask identified by the issue of data.Therefore, the consistency with the broadcast ephemeris and the group of satellites needs to be considered in the format design.

Transport layer
The transport layer encapsulates the PPP/PPP-RTK messages prior to the physical data link, maximizing transmission reliability and ensuring the correctness of the data.
We include here auxiliary information such as preamble, service ID, sequence counter, error correction, parity, and outer-layer coding.For example, RTCM-3 defined a message structure consisting of an 8-bit preamble, 10-bit message-ID, data length, data content, and a 24-bit checksum.It is widely used for several ground-based correction services.
The QZSS-L6 message consists of a preamble (32 bits), message-ID (16 bits), alert flag (1 bit), data content (1,695 bits), and Reed-Solomon error correction flags (256 bits).Galileo defines a 24-bit CRC and a 448-bit page with 24-bit header and outer high-parity vertical Reed-Solomon encoding (Fernández-Hernández et al., 2020).3GPP defined LTE positioning protocol (LPP) to transmit communication data over broad areas and its available data rate could be more than several hundred kbps, which is beyond the reach for existing MEO/GEO/IGSO satellitebased services.

Network layer
The network layer is in charge of routing information packets through different nodes.Generally, PPP/PPP-RTK formats assume transmission through a single channel, and do not need to be optimized for the transmission using multiple channels.However, in GNSS, the user can observe multiple satellites broadcasting the message, and these channels could be mixed to have a higher effective data rate or to increase the level of redundancy However, the data rate of satellite signals is highly limited, typically up to 500 bps for global or regional PPP services, and 2,000 bps for nationwide PPP-RTK services, as shown earlier in Table 1.Satellite-based commercial services transmit in the upper L-band signal on the Mobile Satellite Services (MSS) band (1,559 MHz).For ground-based services, Wi-Fi (2.4 GHz, 5 GHz) and 3G/LTE/5G mobile communication are widely used.
Finally, the main open PPP/PPP-RTK formats are described, including RTCM SSR, IGS SSR, CSSR, Galileo HAS (herein referred to as GAL), 3GPP LPP, SPARTN, and BDS PPP.For each case, we list and qualitatively describe the fields provided.Note that SSRZ is not included because the specification of SSRZ was not openly available at the time of writing.

Definition of corrections for PPP, PPP-AR, and PPP-RTK
Figure 3 shows the definitions of multiple range error sources in GNSS positioning and positioning methods such as PPP/PPP-AR, RTK, and PPP-RTK.The range error sources include satellite signal-in-space (SIS) errors such as orbit, clock and signal bias (phase and code), atmospheric delays such as regional or local dependent troposphere and ionospheric delays, and receiver errors such as multi-path and receiver bias (code and phase).
The conventional RTK provides code and phase correction to correct the satellite SIS error and the atmospheric delay.PPP provides a centimeter-to-decimeter level positioning solution by compensating for the satellite SIS errors such as orbit, clock, and signal code bias.PPP-AR provides a centimeter level positioning solution by correcting signal phase bias to resolve the integer ambiguity of the carrier phase.
In PPP/PPP-AR positioning, the ionospheric delay is eliminated by constructing the ionospheric-free observable combination, and the tropospheric delay is estimated at the receiver.PPP-RTK is able to provide position solutions at centimeter level with fast convergence time similar to RTK by providing atmospheric correction for each sub-network.

Tropospheric delay ✓
The required corrections for PPP, PPP-AR, and PPP-RTK are shown in Table 2.The error of satellite orbits and clocks in the broadcast ephemeris and the code bias originated by the group delay for each satellite signal is provided in PPP to correct the SIS error.The phase bias of each satellite signal originated by the phase-clock correction is also provided in PPP-AR for the ambiguity resolution (Laurichesse, 2014).The atmospheric corrections including slant total electron content (STEC) and tropospheric delay are also provided by PPP-RTK for faster convergence.
The atmospheric corrections in PPP-RTK are defined on the grid points in the service area.Figure 4 shows an example for QZSS CLAS with 212 grid points (Cabinet Office, 2021).

RTCM SSR and IGS SSR
The SSR format standardization started in 2007 at the RTCM SC-104.The standardization process consists of four stages as follows:  RTCM SSR defines the orbit correction, clock correction, code bias, phase bias, and user range accuracy (URA) messages for each GNSS as shown in Table 3.The vertical total electron content (VTEC) proposed message includes the spherical harmonic term of the VTEC model.
The orbit correction includes the position and velocity term in range, along-track, and cross-track coordinates.The clock correction is represented as a second-order polynomial representing the bias, drift, and drift-rate terms.The high-rate clock correction includes only the bias term.The message types in parentheses are currently in the proposal phase and not completed yet.
The International GNSS Service (IGS) has published an open standard for their real-time service based on RTCM SSR (IGS, 2020).IGS SSR messages define the orbit correction, clock correction, code bias, phase bias, and URA for each GNSS and VTEC based on the content of the RTCM SSR Stages 1 and 2. The messages are identified in an RTCM-3-compatible format by a subtype of MT4076, as shown in Table 4.

CSSR
CSSR has been proposed in demand of an effective open format for PPP/PPP-RTK that is lighter than conven-tional SSR such as RTCM SSR and IGS SSR.CSSR is defined as a proprietary message of MT4073 in an RTCM-3-compatible format (Mitsubishi Electric, 2019), with these features: • Compact representation optimized for the satellitebased narrow-band service • Atmospheric corrections to support PPP-RTK • Quality indicators to support the protection level estimation in the user equipment CSSR supports multi-GNSS including modernized signals, and satellites and signal groups can be effectively selected using satellite and signal masks.CSSR is about 70% more bandwidth-effective than RTCM SSR for global PPP.
Although the primary target application of CSSR is QZSS CLAS, it has influenced other satellite-based and ground-based correction services.For example, Galileo HAS has taken into account CSSR fields as the baseline of the HAS message.Mobile communication applications in 3GPP also use CSSR in Rel.16 of LTE/5G standard (3GPP, 2020).
CSSR defines the messages shown in Table 5.To improve the effectiveness, the orbit includes only the position term, and the clock correction includes only the bias term.Whereas standalone messages define the format of The ionospheric delay (STEC) is represented as a twolayer model which consists of a functional part and a residual part.The tropospheric delay consists of a functional part containing a hydro-static term and a residual part containing a non-hydrostatic (wet) term.
The functional part is represented by a low-order function of the approximate user position, and the function type and coefficients are transmitted in the atmospheric correction message (Subtype 8 or 12).The residual part of atmospheric correction is defined on a grid, where the values should be defined by interpolating the values on the surrounding grid points at the user position.The residual part of STEC could be a large part of the stream in PPP-RTK service, the multiple set of parameters with different bit length and resolution are defined, and the parameters can be independently selected per satellite based on the condition of STEC irregularities to minimize the required data rate for the transmission of STEC residuals.
The grid coordinates for atmospheric corrections can be defined in the interface control document as in QZSS CLAS, or included in the data stream using the grid information message (Mitsubishi Electric, 2020).The grid information message is defined as a type of service information message, with a message structure compatible with 3GPP LPP (3GPP, 2020).
The stochastic estimation of errors in the correction messages is provided in CSSR messages.The signal-inspace errors are provided in the URA message (Subtype 7) while the errors in the atmospheric correction are provided in the atmospheric correction message (Subtype 8 or 12).An extension for correction message authentica-tion using Subtype 13 is also proposed to prevent spoofing attacks (Hirokawa & Fujita, 2019).
The range of states is optimized for a centimeter-level positioning service.The service information is defined to send slowly changing data such as the service operation information, grid definition, and coordinate transformation parameters (Hirokawa, 2019).An open-source implementation of a CSSR-to-OSR converter is available in Motooka et al. (2019).
Satellites and signals are selected using a mask message in Subtype 1 as shown in Figure 5.The selected satellites in each GNSS are identified with the satellite mask.The selected signals for each GNSS are identified with the signal mask, and the selected signals for each satellite are identified with the signal mask and the cell mask.
For each GNSS, each of the 40 bits in the satellite mask define the enabled PRN number.The scheme is similar to RTCM multiple signal messages (MSM).The atmospheric correction including ionospheric delay and tropospheric delay is provided in a local area, defined as a subset of the whole service area.The specific area is identified by the area-ID, and the group of satellites for the specific area is selected by the network SV mask as a subset of the satellite mask.
As an example, in Figure 4, 10 satellites (7 GPS, 3 QZSS) were selected by the satellite mask, five signals (GPS: L1C/A, L2C, L5; QZSS: L1C/A, L5) were selected by the signal mask, and a total of 20 signals for all 10 satellites were selected by cell mask.Eight local satellites were selected for a specific area as a subset of the selected satellites using the network SV mask.
The cell mask is useful to reduce the amount of data for GNSS including multiple satellite generations and signals for GPS. Figure 6 shows the required data rate for the signal bias of 31 GPS satellites with and without the cell mask.The code bias is transmitted for PPP and both code and phase biases are transmitted for PPP-AR.
The GPS constellation currently includes 9 Block IIR, 7 Block IIR-M, 12 Block IIF, and 3 Block III satellites, at the time of writing this article.L1 C/A and L2 P(Y) will be available for all generations until the late 2020s.L2C, L5, and L1C are available from Blocks IIR-M, IIF, and III, respectively.The code and phase bias require 10 bits and 17 bits for each signal, respectively.
The required data rate is calculated for a 30-second update rate using the definition of CSSR (Mitsubishi Electric, 2019).The signal bias data rate can be reduced considerably (by 34.2%) with the cell mask.For GNSS with a unique satellite type like Galileo, the cell mask can be disabled by the cell-mask availability flag.
The Issue of Data State-Space Representation (IOD SSR) identifies the generation of the mask and the generation of ephemeris.If the selected set of satellites has changed or the ephemeris has been updated, then the IOD SSR should be incremented.The consistency between orbit, clock, bias, and atmospheric corrections is implicitly guaranteed based on RTCM SSR, and the system requires consistency to be maintained by applying the conditional update.
The group of satellites with ionospheric delay is represented as the network satellite mask which is defined as the subset of the satellite mask.The group of satellites and signals is identified as IOD SSR.

Galileo HAS
Galileo HAS defines for the moment a unified message type (MT1) based on CSSR fields.It includes mask, orbit, clock, code bias, phase bias, and URA as defined in Table 6.The availability of each component is defined by header flags.The group of satellites is selected by the satellite mask, and the signals are selected using the signal mask and the cell mask as defined in CSSR.The mask is identified by the mask ID, and the generation of ephemeris is identified by an IOD Set ID, which defines a single ID for the set of satellite IODs corrected in a given message.The value range of phase bias and the resolution of orbit correction is slightly reduced to support the slow data rate of the Galileo HAS signal data channel (E6-B, 448 bps).Another feature of Galileo HAS is the clock subset section, which allows it to update the clocks of some satellites more frequently, in order to cope with the different performance of different satellite clocks.Notice also that the Galileo HAS Interface Control Document (ICD) in the public domain is only a testing version (European Commission et al., 2020) and parameters and ranges may slightly evolve in the near future.
The Galileo HAS message is very flexible but its performance has been reported according to the following configuration (Borio et al., 2020): two MT1 message types,

Long-Term Evolution (LTE) Positioning Protocol (LPP)
Based on the high demand for high-accuracy GNSS positioning in mobile communications, 3GPP, the international standardization group for LTE/5G mobile communications, defined the message structures to support the high-accuracy GNSS positioning in LPP, as shown in Table 7.The satellite part of corrections such as orbit, clock, and code bias based on RTCM SSR are included in Rel.15 (Release 15 of the standard) for PPP support.The atmospheric correction, phase bias, and URA based on CSSR are added for PPP-RTK support in Rel.16 (3GPP, 2020).
Based on the use case of mobile communication users, GNSS-SSR-CorrectionPoints and the structure of the message to define the grid position are defined.The coordinates of the grid are defined by reference points and the relative coordinates of each grid point.Two types of definitions for the relative coordinates, equally spaced grid points with bitmask, and the list of grid coordinates are included.The equally spaced grid points are highly effective to cover a large area, and the bitmask can be used to represent the complex shape of land and coast area.

SPARTN
Safe position augmentation for real-time navigation (SPARTN) is an industry-driven open format that has been designed for wide and global area broadcasts.Its requirements for modern positioning systems include a combination of low bandwidth, accuracy, availability, reliability, and integrity for the safety of life applications (SAPCORDA, 2020;Vana et al., 2019).
While the majority of contents in SPARTN is compatible with RTCM SSR and CSSR, there are several differences in the parameters and the structures.The message structure of SPARTN is independent, as shown in Table 8.The satellite correction part is defined as a unified message Type 0 for orbit, clock, and bias (OCB) including the mask, orbit, clock, code bias, phase bias, and URA.
The OCB message is defined for each GNSS.Currently, subtypes for GPS and GLONASS are defined, and subtypes for other GNSSs are planned for the upcoming version.The satellite group and the signals are selected by bitmask as in CSSR, whereas the signal mask is included for each satellite but the cell mask is not included in the specification.The mask information is included in the header of the OCB message; therefore, it should be included in all OCB messages.
Atmospheric correction is defined as a unified message named the High-Precision Atmospheric Correction (HPAC).It includes the functional model part represented as polynomials and the residual part for the ionospheric delay (STEC) and tropospheric delay.The value range, affecting the bit length, can be selected per satellite to minimize the required data rate.
The Geographic Area Definition (GAD) message is defined to inform about the coordinates of the grid in the stream.GAD includes the reference point and the reference coordinates represented by the equally spaced grid points, whereas the bitmask is not supported in the GAD.
The Basic-Precision Atmospheric Correction (BPAC) message, including the coordinates of the grid and VTEC correction, is defined to support the single-frequency users.The tropospheric delay correction is not included in BPAC.
The Encryption and Authentication Support (EAS) message is defined to support the encrypted data stream and the grouped subscription for commercial correction services.The inconsistency for the ephemeris update can be The definition of a satellite group for the clock correction message (Type 4) and the URA message (Type 5) is based on the mask message (Type 1).The mask message identified by IODP (Issue of Data, PRN mask) defines the selected group of satellites based on a 255-bit bitmask assigned for all GNSSs.
The index in full bitmask is used to select a group of satellites for the orbit correction message (Type 2) and the code bias message (Type 3).The signal mask and the cell mask are not used for the selection of signals.Two types of combined clock and orbit messages (Type 6 and 7) are also defined.The consistency between the orbit and the other corrections including the clock and the code bias messages is explicitly identified using the IOD of the correction (3 bits).
BDS also provides a ground-based augmentation service including a wide-area augmentation service, a network RTK service based on RTCM MSM, and a post-processing service for China and its neighboring areas (CSNO, 2020b).The wide-area augmentation service includes a singlefrequency pseudorange augmentation service, a singlefrequency carrier-phase augmentation service, and a dualfrequency carrier-phase augmentation service.
It uses an RTCM-3 format with some extensions as shown in Table 10.The message types surrounded by parentheses are non-standard messages in RTCM 3. The format for the single-frequency pseudorange augmentation service is MT1331, which includes ionospheric grid point (IGP) VTEC corrections.
The format for the single-frequency carrier-phase augmentation service is defined in MT1330, which is similar to Orbit (bit per sat., radial-along-cross resolution) Y (62, 0. the SSR Ionosphere VTEC Spherical Harmonics (MT1264) in RTCM 3.However, MT1330 supports a single layer only.
The dual-frequency carrier-phase augmentation service supports GPS and BeiDou using RTCM SSR whereas the special message types (MT1302, MT1303) are used for Bei-Dou support.It uses the combined orbit and clock messages to ensure the time consistency between the orbit correction and the clock correction.

Summary of characteristics of open formats
The structure and characteristics of the aforementioned open message formats (RTCM SSR, IGS SSR, CSSR, GAL, 3GPP LPP, SPARTN, and BDS-PPP) are summarized in Table 11.The values in parentheses indicate that a parameter is under definition and will be implemented in future versions.
The message framing of all formats except BDS-PPP uses variable-length encoding to have the flexibility for the number and type of satellites and signals.The message types of RTCM SSR, IGS SSR, and SPARTN are defined for each GNSS, whereas CSSR, GAL (Galileo HAS), and BDS-PPP define the unified message types for several GNSSs.
All formats support multiple GNSSs (G: GPS, R: GLONASS, E: Galileo, J: QZSS, S: SBAS, C: BDS), and there is room for extensions for new GNSSs.They also support corrections for orbit and clock, URA, and code bias for PPP.
All formats except BDS-PPP support phase biases for PPP-AR.CSSR, 3GPP LPP, and SPARTN support atmospheric corrections for PPP-RTK.RTCM SSR, IGS SSR, and SPARTN support VTEC (vertical TEC, total electron content) for single-frequency PPP.
The satellite mask included in CSSR, GAL, SPARTN, and BDS-PPP improves throughput efficiency.CSSR, GAL, and SPARTN also support signal masks for signal selection for each GNSS effectively.CSSR and GAL also support a cell The issue of data (IOD) to identify the mask is defined in GAL, SPARTN, and BDS-PPP, and the issue of data to identify the consistency of corrections against the generation of ephemeris is included in GAL, SPARTN, and BDS-PPP.In CSSR, the mask and the consistency of ephemeris change are identified by IOD SSR.
The assigned bit length and the resolution for corrections such as orbit, clock, and signal bias are also shown in Table 11.The resolution of code (orbit+clock+code bias) and phase (orbit+clock+phase bias) for all formats are 2 cm (or less) and 2 mm (or less), respectively; they are sufficiently small to realize the positioning accuracy of PPP/PPP-RTK service.

BANDWIDTH REQUIREMENTS AND COMPARISON
For the comparison of characteristics and efficiency between several open formats for PPP/PPP-RTK services, this section studies typical-use cases simulating a global PPP and a nationwide PPP-RTK service.

Global PPP case
The parameters of the global PPP service are defined in Table 12.It supports GPS, Galileo, and BeiDou with corrections for two signals per satellite.The number of satellites for GPS, Galileo, and BeiDou are 32, 24, and 28, respectively.The target data rate is 500 bps, and the update intervals for clock and other states are 10 s and 30 s, respectively.
Figure 7 shows the required data rate (bps) for the global PPP service for RTCM SSR, IGS SSR, 3GPP LPP, CSSR, GAL, SPARTN, and BDS PPP.The required data rate for each format was calculated based on the bit assignment defined in the ICDs and the parameters shown in Table 11.
The required data rate for CSSR (360.9 bps) is considerably smaller than that of RTCM SSR (846.3 bps) and IGS SSR (839.7 bps).The required data rate for LPP (452.6 bps) is smaller than that of RTCM SSR.This is because the orbit velocity term, clock drift, and drift-rate term are optional, and have been excluded.
The current data rate of GAL (346.1 bps) is slightly less (4.1%) than the original CSSR because of the unified structure and the reduced dynamic range of orbit correction.The data rate of SPARTN (487.5 bps) is larger than CSSR because it defines the message per GNSS; the unified OCB message includes the mask in the header part which should be included in all OCB messages.
The data rate of BDS PPP (599.4 bps) is larger than CSSR and SPARTN because the signal mask is not applied and fixed-length framing (486 bits) is used.The IOD correction is included in the orbit correction and the clock correction to ensure the consistency.
Figure 8 shows the required data rate (bps) of a global PPP-AR service for RTCM SSR, IGS SSR, LPP, CSSR, GAL, and SPARTN.The phase bias is included to support PPP-AR and 56 satellites of GPS and Galileo are selected, as shown in Table 13.BDS-PPP is excluded because it doesn't support the phase bias.The required data rate for each format was calculated based on the bit assignment defined in the ICD for each format and the parameters shown in Table 12.
The required data rate for CSSR (306.6 bps) is considerably smaller than that of RTCM SSR (738.7 bps) and IGS SSR (740.0 bps).The data rate of GAL (285.1 bps) is less (7.0%) than the original CSSR because of the reduced dynamic range of phase bias.The data rate of LPP (551.1 bps) is smaller than that of RTCM SSR because the orbit velocity term, clock drift, and drift-rate are options and the phase bias format is based on CSSR.

Nationwide PPP-RTK case
The parameters for a nationwide PPP-RTK service are defined in Table 14.The selected parameters for the total 240 grids are based on QZSS CLAS (Cabinet Office, 2021).It supports GPS (12 SVs), Galileo (10 SVs), and QZSS (3 SVs) with three signals per satellite.The target data rate is 2,000 bps and the update intervals for clock and other states are 5 s and 30 s, respectively.The number of areas for the local atmospheric correction and the number of grid points per area are 12 and 20, respectively.For the functional part of the troposphere and the ionosphere (STEC), the linear and the bi-linear model are applied respectively.For the residual part of STEC, the minimum bit length (4 bits) is applied in CSSR and SPARTN by assuming a modest ionosphere condition.
Figure 8 shows the required data rate (bps) of the nationwide PPP-RTK service for 3GPP LPP, CSSR, and SPARTN.The required data rate for each format was calculated based on the bit assignment defined in the ICD for each format and the parameters shown in Table 13.The other formats do not support PPP-RTK.
The required data rate for LPP, CSSR, and SPARTN are 2,944 bps, 1,686 bps, and 1,809 bps, respectively.The data rate of LPP is considerably larger than that of CSSR because the orbit, clock, and code bias are based on RTCM SSR, and the bit length of the residual part of STEC is fixed as 7 bits.
Figure 9 also shows that the residual term of atmospheric correction consumes approximately 50% of the stream for CSSR and SPARTN.If the residual term could be excluded for the medium grade application having 10 cm to 30 cm positioning accuracy, the required data rate could be reduced considerably (1,059.0bps for LPP, 816.1 bps for CSSR, and 940.3 bps for SPARTN).
A generic estimation of data rate for nationwide PPP-RTK is shown in Figure 10.In this figure, the number of satellites and number of grid points are selected as the parameter.The service area S [km 2 ] can be approximated by the following equation: where N grid is the total number of grid points, b is the interval of grid [km], and c is a ratio between short and long side of service area (c = 1 if the service area is square, 0<c<1 for others).

DEFINITION OF AN INTEROPERABLE FORMAT
In this section, a format to improve interoperability between the different PPP/PPP-RTK services is studied.This interoperable format needs to support satellite-based PPP or PPP-RTK services with single-link and multi-link as well as ground-based services.It also needs to support multi-GNSSs with multiple generations of satellites and multiple signals (e.g., L1C/A, L1C, L5I, L5Q. . . ) in a highly effective way.
The proposed format is defined in detail in Appendix 1 as an extension of CSSR messages.The following subsections cover two aspects of it: multi-satellite grouping depending on clock stability and nationwide PPP/RTK services.

Satellite grouping
Multiple satellite groups can support satellites with a high-quality onboard atomic clock and satellites with less-accurate clocks simultaneously and optimally.Figure 11 shows the Allan variance of clock correction for GPS, GLONASS, Galileo, and BeiDou satellites on August 22, 2020, using the real-time stream of RETICLE by DLR (Hauschild, 2018).The Allan deviation of the clock correction of GPS Block II-F using Rubidium (Rb) clock, Block III satellites, and Galileo satellites are at the level of 1 cm at 100 s of averaging time, which has higher stability than that of other satellites.This suggests that the update interval could be longer to reduce the effective data rate.
Satellites can be grouped using sub-masks as shown in Figure 12 using CSSR.In the mask message (ST1) with extension, the sub-mask is defined only if the sub-mask availability flag is set to one (1).The sub-mask is identified by sub-mask ID.The sub-mask is defined per GNSS.It determines the subset of satellite in the previously defined satellite mask.
If it is applied for the global PPP-AR service defined in Table 12, the satellite sub-mask defines the group of GPS satellites equipped with lower stability of onboard atomic clock, which is assumed to be 18 GPS satellites in this case.
For example, as per Figure 9, clock corrections for satellites with highly stable atomic clocks are sent every 30 seconds, and clock corrections for the 18 GPS satellites with less stable atomic clocks are sent every 10 seconds.This approach, compared to refreshing all clock data every 10 seconds, reduces the required data rate for clock corrections from 87.7 bps to 49.7 bps.

4.2
Nationwide PPP-RTK service using IGSO/GEO satellite constellations For a nationwide PPP-RTK service as defined in Table 13, a maximum of 25 satellites can be corrected at a data rate of 1,700 bps.If multiple satellites broadcasting the correction data can be tracked by the user receiver in a specific area, the effective data rate can be increased by mixing the multiple channels of these satellites.
For the proposed format based on CSSR, two or more different satellite groups can be supported simultaneously using the network SV mask in Figure 3. Figure 13 shows the number of visible GNSS satellites in Tokyo on August 22, 2020, with a 15-degree elevation mask.Up to 37 satellites are visible if GPS, Galileo, QZSS, GLONASS, and BeiDou-3 are supported.
Figure 14 shows the elevation angle of QZSS satellites in Tokyo in which multiple QZSS satellites are visible with a 40-degree elevation angle.If 25 satellites with the highest elevation are assigned for the data channel of the highest elevation QZSS satellite, and the remaining satellites The effectiveness and design flexibility of CSSR have been shown, as it reduces bandwidth approximately from 850 bps to 300 bps for global multi-GNSS PPP, and from 3,000 bps (LPP) to 1,600 bps, with nationwide multi-GNSS PPP-RTK, without significant accuracy loss.In the latter F I G U R E 1 1 Continued case, the bandwidth is highly sensitive to the ionospheric corrections format and data.
A general message format for satellite-based open PPP/PPP-RTK services to maximize interoperability is proposed as an extension of CSSR.We compare Allan variances for GPS, GLONASS, BeiDou, and Galileo satellites and show a highly diverse clock behavior, between 10 cm and 0.5 cm of variance for a 100-second averaging time.Therefore, by introducing a satellite sub-mask for clock corrections, the effectiveness is improved when GNSS satellites with different clock qualities are used in global PPP or PPP-AR services.
For the regional or nationwide PPP-RTK service, it is shown that the number of available satellites can be increased using multiple network SV masks transmitted from different satellites.The proposed format (CSSR with extension) can effectively be applied for global or regional PPP/PPP-AR and regional or nationwide PPP-RTK by introducing the satellite sub-mask.

F 1
Relationship of several open message formats for PPP/PPP-RTK [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com and www.ion.org]F I G U R E 2 Structure of PPP/PPP-RTK services based on OSI layers model [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com and www.ion.org]The mobile communications industry has shown interest in high accuracy and a standard for PPP/PPP-RTK is included in the Long-Term Evolution (LTE) Positioning Protocol (LPP) 5G specification developed by 3GPP (The 3 rd General Partnership Project), also based on RTCM SSR

F
I G U R E 3 Definition of range error sources and positioning methods [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com and www.ion.org]TA B L E 2 Required corrections for PPP, PPP-AR and PPP-RTK

F I G U R E 4 • Stage 1 :
The definition of grid points for QZSS CLAS [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com and www.ion.org]The satellite orbit, clock corrections, and code biases for PPP • Stage 2: The phase bias and the VTEC for PPP-AR and single-frequency PPP • Stage 3: The atmospheric corrections for PPP-RTK • Stage 4: Compression Stage 1 was completed in 2011 for GPS and GLONASS.However, Stage 1 for other GNSSs and Stage 2 and beyond are still not completed.

F
Concept of the satellite and signal selection in CSSR [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com and www.ion.org]F I G U R E 6 Required data rate (BPS) for the signal bias of 31 GPS satellites including code and phase bias for two to five signals (L1 C/A, L2 P(Y), L2C, L5C, L1C) with a 30-second update rate [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com and www.ion.org]

TA B L E 6
Structure of MT1 for Galileo HAS(European  Commission et al., 2020) signal selection per satellite.CSSR, 3GPP LPP, and SPARTN define the message to include coordinates of the grid.

F
Required data rate (bps) to transmit a global PPP service: 32 GPS + 24 Galileo + 28 BDS; two signals corrected per satellite; 10-second clock update rate; 30-second mask, orbit, bias, and URA update rate [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com and www.ion.org]F I G U R E 8 Required data rate (BPS) for a global PPP-AR service (GPS + Galileo) [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com and www.ion.org]

F
Required data rate (bps) for nationwide PPP-RTK service (GPS + Galileo + QZSS) [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com and www.ion.org]

F I G U R E 1 0
Required data rate (bps) using CSSR for nationwide PPP-RTK service: the real field performance of CSSR applied for nationwide PPP-RTK is already shown in Hirokawa et al. (2019) with a positioning accuracy (95%) of 6 cm (horizontal) and 12 cm (vertical).[Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com and www.ion.org]

F
Allan variance of clock correction (RETICLE/DLR, August 22, 2020) [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com and www.ion.org] are assigned for the data channel of lower elevation QZSS satellites, the correction data for all visible satellites shown in Figure 12 can be sent.5 CONCLUSION In this paper, several open-format specifications for PPP/PPP-RTK services are described and qualitatively compared.We use an adaptation of the seven-layer OSI model for comparison at different layers.SSR-based formats are mainly used by ground services (RTCM SSR, IGS SSR), and CSSR-based formats are mainly used by bandwidth-sensitive satellite services (QZSS CLAS, Galileo HAS).

F
Grouping of satellites using sub-mask [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com and www.ion.org]F I G U R E 1 3 Number of visible satellites in Tokyo (August 22, 2020) [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com and www.ion.org]F I G U R E 1 4 Elevation of QZSS satellites in Tokyo (August 22, 2020) [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com and www.ion.org]D I S C L A I M E R The content of this article does not necessarily reflect the official position of any organization.Responsibility for the information and views expressed lies entirely with the authors.O R C I D Rui Hirokawa https://orcid.org/0000-0002-1209-2585Ignacio Fernández-Hernández https://orcid.org/0000-0002-9308-1668Simon Reynolds https://orcid.org/0000-0001-8627-9740R E F E R E N C E S List of open satellite-based high-accuracy GNSS correction services . NAVIGATION.2021;68:759-778.wileyonlinelibrary.com/journal/navi759 TA B L E 1 Message types of RTCM SSR (RTCMSC-104, 2020) TA B L E 3 Message types and subtypes of SPARTN v1.8.0 (SAPCORDA, 2020) TA B L E 8 Message structure and characteristics of open formats TA B L E 1 1