RTCM 10403.

1
RTCM Paper 177-2006-SC104-STD
© RTCM – Not for reproduction or redistribution

RTCM STANDARD 10403.1

FOR

DIFFERENTIAL GNSS
(GLOBAL NAVIGATION SATELLITE SYSTEMS)
SERVICES – VERSION 3

DEVELOPED BY
RTCM SPECIAL COMMITTEE NO. 104

OCTOBER 27, 2006

COPYRIGHT©2006 RTCM

Radio Technical Commission For Maritime Services

1800 N. Kent St., Suite 1060
Arlington, Virginia 22209
E-Mail: info@rtcm.org
Web Site: http://www.rtcm.org
© RTCM – Not for reproduction or redistribution

The Radio Technical Commission For Maritime Services (RTCM) is an incorporated non-profit
organization, with participation in its work by international representation from both
government and non-government organizations. The RTCM does not work to induce sales, it
does not test or endorse products, and it does not monitor or enforce the use of its standards.

The RTCM does not engage in the design, sale, manufacture or distribution of equipment or in
any way control the use of this standard by any manufacturer, service provider, or user. Use of,
and adherence to, this standard is entirely within the control and discretion of each
manufacturer, service provider, and user.

For information on RTCM Documents or on

participation in development of future RTCM documents contact:

Radio Technical Commission For Maritime Services

1800 N. Kent St., Suite 1060
Arlington, Virginia 22209-2109 USA

Telephone: +1-703-527-2000
Telefax: +1-703-351-9932
E-Mail: info@rtcm.org
 RTCM 10403.1
RTCM Paper 177-2006-SC104-STD
© RTCM – Not for reproduction or redistribution

RTCM STANDARD 10403.1

FOR

DIFFERENTIAL GNSS
(GLOBAL NAVIGATION SATELLITE SYSTEMS)
SERVICES – VERSION 3

DEVELOPED BY
RTCM SPECIAL COMMITTEE NO. 104

OCTOBER 27, 2006

COPYRIGHT©2006 RTCM

Radio Technical Commission For Maritime Services

1800 N. Kent St., Suite 1060
Arlington, Virginia 22209
E-Mail: info@rtcm.org
Web Site: http://www.rtcm.org
© RTCM – Not for reproduction or redistribution

This page intentionally left blank.

 RTCM 10403.1

PREFACE
This standard has been developed by RTCM SC-104 as a more efficient alternative to the
documents entitled "RTCM Recommended Standards for Differential Navstar GPS Service,
Version 2.x”. Service providers and vendors represented on the SC-104 Committee requested
© RTCM – Not for reproduction or redistribution

the development of a new standard that would be more efficient, easy to use, and more easily
adaptable to new situations. The main complaint was that the Version 2 parity scheme, which
uses words with 24 bits of data followed by 6 bits of parity, was wasteful of bandwidth. Another
complaint was that the parity was not independent from word to word. Still another was that
even with so many bits devoted to parity, the actual integrity of the message was not as high as it
should be. Plus, 30-bit words are awkward to handle. The new standard, Version 3, is intended
to correct these weaknesses.

Unlike Version 2.x, the Version 3 standards do not include tentative messages. The messages in
Version 3 have undergone testing for validity and interoperability, and are considered to be
permanent. Future modifications of the standard may change the meaning of reserved bits or
provide additional clarifying text, but no changes will be made in the data fields. Changes will
require new messages to be developed. In addition to the messages described in this document,
the Committee is also developing a number of new messages, which are described in a separate
document. As new messages and capabilities have been demonstrated through validity and
interoperability testing, they will be incorporated into future versions of the Version 3 standard,
either as Supplements or as a new revision of standard 10403.x. Supplements will be made
available electronically to those who have purchased the standard. Periodically, accumulated
Supplements will be incorporated into a complete revision of standard 10403.x.

The initial release of the new standard, i.e., Version 3.0 (RTCM Paper 30-2004/SC104-STD),
consisted primarily of messages designed to support real-time kinematic (RTK) operations. The
reason for this emphasis was that RTK operation involves broadcasting a lot of information, and
thus benefits the most from an efficient data format. Version 3.0 provided messages that
supported GPS and GLONASS RTK operations, including code and carrier phase observables,
antenna parameters, and ancillary system parameters.

This release, Version 3.1 – now designated as RTCM Standard 10403.1, incorporates GPS
Network Corrections, which enable a mobile receiver to obtain accurate RTK information valid
over a large area. In addition, new GPS and GLONASS messages provide orbital parameters to
assist in rapid acquisition. A Unicode text message is also provided for the transmission of
textual data. Finally, a set of messages are reserved for vendors who want to encapsulate
proprietary data in their broadcasts.

RTCM SC-104 believes that the new Standard 10403.1 for DGNSS services will prove useful in
supporting highly accurate differential and kinematic positioning as well as a wide range of
navigation applications worldwide throughout the next decade.

i
 © RTCM – Not for reproduction or redistribution

ii
This page intentionally left blank.
 RTCM 10403.1

TABLE OF CONTENTS

1 INTRODUCTION AND SCOPE...................................................................................... 1-1

1.1 Introduction................................................................................................................ 1-1
1.2 Scope............................................................................................................................ 1-2
© RTCM – Not for reproduction or redistribution

2 APPLICATION LAYER................................................................................................... 2-1

3 PRESENTATION LAYER ............................................................................................... 3-1
3.1 Introduction................................................................................................................ 3-1
3.1.1 Version 3 Database Architecture........................................................................ 3-1
3.1.2 Message Groups .................................................................................................. 3-1
3.1.3 Operation with Multiple Services ....................................................................... 3-4
3.1.4 Reference Receiver Time and Observations ...................................................... 3-5
3.1.5 GPS Network RTK corrections........................................................................... 3-6
3.1.6 Proper handling of antenna phase center variation corrections ...................... 3-6
3.2 Message Type Summary.......................................................................................... 3-10
3.3 Data Types ................................................................................................................ 3-12
3.4 Data Fields ................................................................................................................ 3-14
3.5 Messages.................................................................................................................... 3-40
3.5.1 GPS RTK Messages .......................................................................................... 3-40
3.5.2 Stationary Antenna Reference Point Messages............................................... 3-45
3.5.3 Antenna Description Messages ........................................................................ 3-48
3.5.4 GLONASS RTK Observables............................................................................ 3-50
3.5.5 System Parameters ............................................................................................ 3-55
3.5.6 GPS Network RTK Correction Messages......................................................... 3-56
3.5.7 GPS Ephemerides ............................................................................................. 3-63
3.5.8 GLONASS Ephemerides................................................................................... 3-66
3.5.9 Unicode Text String .......................................................................................... 3-69
3.6 Proprietary Messages .............................................................................................. 3-72
4 TRANSPORT LAYER...................................................................................................... 4-1
4.1 Description.................................................................................................................. 4-1
4.2 Example ...................................................................................................................... 4-3
5 DATA LINK LAYER ........................................................................................................ 5-1
6 PHYSICAL LAYER.......................................................................................................... 6-1

Appendix A. SUGGESTIONS AND EXAMPLES FOR NETWORK OPERATION……A-1

iii
 © RTCM – Not for reproduction or redistribution

iv
This page intentionally left blank.
 RTCM 10403.1

1 INTRODUCTION AND SCOPE

1.1 Introduction
© RTCM – Not for reproduction or redistribution

The Global Positioning System (GPS) and the GLObal NAvigation Satellite System
(GLONASS) are satellite-based positioning systems that are currently providing global service
24 hours each day. Collectively, these two systems, plus other systems currently being designed
and implemented, notably Galileo, are called Global Navigation Satellite Systems (GNSS’s).
GNSS’s typically provide navigation and positioning services having accuracies in the 5-40
meter range (2drms). Differential operation provides meter-level accuracy, while Real-Time
Kinematic (RTK) operation provides decimeter accuracy or better.

The RTCM Special Committee 104 (SC-104), Differential GNSS Service, has examined the
technical and institutional issues and formulated recommendations on the data format and
content that are designed to support the most stringent applications in an efficient manner. The
Committee has attempted to accommodate the widest possible user community, including not
only maritime users, but land-based and airborne users as well. Radiolocation, surveying, and
radionavigation applications are supported.

Standard 10403.1 (i.e. Version 3.1) describes messages and techniques for supporting GPS and
GLONASS operation with one reference station or a network. However, the format is
specifically designed to make it straightforward to accommodate new systems that are under
development, Galileo in particular, as well as modifications to existing systems (e.g., new L2C
and L5 signals). It can also accommodate augmentation systems that utilize geostationary
satellites with transponders operating in the same frequency bands. Generically these are called
Satellite-Based Augmentation Systems (SBAS’s), and they have been designed to be
interoperable. The first to be implemented is the Wide-Area Augmentation System (WAAS),
which has been developed by the U.S. Federal Aviation Administration to supplement the GPS.
The second is the European Geostationary Navigational Overlay System (EGNOS), which will
soon be implemented to augment both GPS and GLONASS. The new systems will be
accommodated by adding new messages.

Specifically, this document contains four new sets of messages that were not in Version 3.0: (1)
GPS Network RTK Corrections, which enable a real-time kinematic rover receiver to accept and
process pseudorange and carrier phase observables from a coordinated network of reference
stations, (2) a GPS Ephemeris message, which provides a record of the GPS satellite
ephemerides in use by the reference station, (3) a GLONASS Ephemeris message, which
provides a record of the GLONASS satellite orbit parameters in use by the reference station, (4)
a UNICODE message, which provides textual information, and (5) a set of message types
reserved for proprietary use by vendors who wish to broadcast special information to their users.

The Committee assumes that Selective Availability has been permanently set to zero on the GPS
satellites, so that the GPS signal variations will be dominated by natural causes. No system
modifications, augmentations or new systems are considering this kind of intentional accuracy
degradation.

1-1
 RTCM 10403.1

The higher efficiency of the new format, coupled with the absence of Selective Availability, will
make it possible to support RTK services with significantly reduced bandwidths. The U.S. Coast
Guard’s NDGPS-GWEN expansion would be able to support a decimeter-level RTK using the
new standard, as well as supporting all existing services with a reduced data broadcast burden.
The Committee expects that it will find use in vessel tracking systems as well. Potential land
© RTCM – Not for reproduction or redistribution

uses include robotic mining, construction, and rapid surveying.

In summary, the Committee expects that the Version 3 format will support the most stringent and
unique applications of these high-accuracy positioning techniques.

1.2 Scope
This standard defines a flexible messaging structure to support augmentation of navigation
systems. It is the purpose of this structure to provide integrity and capability for existing and
future applications an efficient manner. In order to promote these qualities this standard has
been designed using a layered approach adapted from the Open System Interconnection (OSI)
standard reference model.
1) Application Layer
2) Presentation Layer
3) Transport Layer
4) Data Link Layer
5) Physical Layer

Application Layer considerations are briefly discussed in Section 2, and include instructions on
creating and applying data for navigation and positioning applications. Section 3, which
comprises the bulk of the document, addresses the Presentation Layer, and describes the
messages, the data elements, and the data definitions. The Transport Layer is described in
Section 4, and includes the definition of the message frames, the method of implementing
variable-length messages, and the Cyclic Redundancy Check (CRC) that provides message
integrity. The Data Link Layer is tailored around the Physical Layer, which defines how the data
is conveyed at the electrical and mechanical level.

1-2
 RTCM 10403.1

2 APPLICATION LAYER
The Application Layer defines how the Version 3 messages can be applied for different end user
applications. The fundamental feature of Differential Service is that it is a broadcast service, not
a 2-way data link. As such, information is developed centrally by a Service Provider, who has an
institutional or commercial interest in providing a positioning or navigation service. Recently,
© RTCM – Not for reproduction or redistribution

point-to-multipoint services using cell phones and Internet connections have become popular, but
such services primarily support a one-way flow of information.

In general navigation applications are serviced very well with 1-10 meter horizontal accuracy
positioning. (An exception is the GNSS-based aircraft landing system, called the Local Area
Augmentation System, or LAAS. A separate standard has been developed for this by RTCM’s
sister organization, RTCA, Inc., which develops aviation standards.) Conventional differential
GNSS service supports these applications nicely, and they utilize broadcast links with relatively
low data rates. These low data rates can be supported by low-frequency broadcasts that are
received over large areas, and it just so happens that high accuracy is maintained over hundreds
of miles.

As innovative engineers and scientists have found uses for sub-meter accuracy positioning, RTK
service has increased in importance. RTK service requires the transmission of significantly more
data, so that generally line-of-sight broadcasts and point-to-multipoint services that utilize higher
bandwidths are employed. Tropospheric and ionospheric variations cause phase and time delay
variations in the GNSS signals that limit the area over which a given accuracy can be achieved.
For example, relative positioning accuracies of one centimeter or better using single-frequency
GNSS signals can be achieved only over distances of 10 kilometers or so (from reference station
to user). Using dual-frequency GNSS signals enables one to estimate the ionospheric effects,
and water vapor measurements can be made which improve tropospheric delay estimation, so
that using these techniques the range can be extended to 50 kilometers or so in certain parts of
the world. Dual-frequency RTK is very common, thus is supported by this standard. Because
RTK provides relative positioning, the knowledge of the absolute (usually fixed) position of the
reference station enables the user to achieve high absolute position accuracies, too.

To achieve the highest accuracy, it is important to account for GNSS antenna variations.
Antenna patterns differ slightly from manufacturer to manufacturer and even from model to
model. Differential GNSS service supports this by transmitting messages with reference station
antenna information. Antenna patterns can also vary between different units of the same model
and can vary due to environmental effects, but these can be mitigated by manufacturing design
and reference site selection, respectively. Such variations are outside the scope of this document.

The applications of RTK to air, water and land operations are too many to enumerate, but a
sampling is useful:
• Marine – Hydrographic surveying, dredge operations, navigation in narrow channels,
buoy placement and auditing, even tidal height
• Air – Aerial surveying, landing system testing, calibration of other navigation
systems
• Land – Surveying, building and bridge construction, surface mining, agriculture, road
construction, asset location and management

2-1
 RTCM 10403.1

It turns out that the RTK requirements for all these different applications don’t vary that much.
The broadcast link bandwidth and update rates are primarily determined by the accuracy
requirements and the signal blockage environment. Otherwise the required services are similar
for air, land and sea applications.
© RTCM – Not for reproduction or redistribution

2-2
 RTCM 10403.1

3 PRESENTATION LAYER
3.1 Introduction
3.1.1 Version 3 Database Architecture
RTCM 10403.1 is written in a database format, loosely patterned after the recent NMEA 2000
© RTCM – Not for reproduction or redistribution

standard. Whereas the NMEA standard is written for a networked set of different electronic
units, the Differential GNSS Version 3 standard is written for a centralized distribution of data.
For the Version 3 broadcast every bit counts in the frequently repeated messages, so while lining
up on byte boundaries is desirable, forcing each data field to occupy whole numbers of bytes is
not practical.

Also, the NMEA 2000 database has a wide disparity between Data Dictionary (DD) and Data
Field (DF) records. In the case of RTCM 10403.1 broadcasts, there would be little difference.
As a consequence, rather than utilize both DF and DD tables, these are collapsed into one DF
definition. Rather than referring to “Parameter Groups”, this document will use the more
familiar term “Message Types”.

In the tables below, the GPS and GLONASS RTK messages are defined so as to avoid placing
flags in the messages that change the length or the meaning of data elements in the message.
There is some variability that can’t be avoided, because the number of satellites is not fixed.
However, it is possible to determine the number of satellites by examining the message length as
defined in the transport layer, because the number of satellites is the only variable quantity
employed. For messages whose lengths don't line up with byte boundaries, the reference station
designer should use zeros for undefined bits to fill out the last unfilled byte.

3.1.2 Message Groups

Message types contained in the current Version 3 standard (RTCM 10403.1) have been
structured in different groups. For proper operation of a particular service the provider needs to
transmit messages from each of several groups, as shown in Table 3.1-1. In particular, the
provider must transmit at least one message type from each of the following groups:
Observations, Station Coordinates, and Antenna Description. The different message types in
each group contain messages with similar information content. The shorter ones contain the
minimum needed to provide the service, while the other message types contain additional
information for enhancing the performance of the service. For example, Message Type 1001
contains the shortest version of a message for GPS Observations, namely L1-only observables.
For a broadcast link limited in throughput, use of 1001 might be appropriate. Message Type
1002 contains additional information that enhances performance. If throughput is not limited and
the additional information is available, it is recommended to use the longer version of messages.
Similarly Message Type 1003 provides minimum data for L1/L2 operation, while Message Type
1004 provides the full data content. The shorter observation messages save throughput, but
contain less information. However, since the additional information in the longer observation
messages does not change very often, they could be sent less often.

3-1
 RTCM 10403.1

Table 3.1-1. RTK Message Groups

Group Name Sub-Group Name Message Type
Observations GPS L1 1001
1002
GPS L1 / L2 1003
© RTCM – Not for reproduction or redistribution

1004
GLONASS L1 1009
1010
GLONASS L1 / L2 1011
1012
Station Coordinates 1005
1006
Antenna Description 1007
1008
Network RTK Corrections Network Auxiliary Station 1014
Data Message
Ionospheric Correction 1015
Differences
Geometric Correction 1016
Differences
Combined Geometric and 1017
Ionospheric Correction
Differences
Auxiliary Operation Information System Parameters 1013
Satellite Ephemeris Data 1019
1020
Unicode Text String 1029
Proprietary Information Currently assigned
message numbers
4088 – 4095

The basic types of RTK service supported in this initial version of the standard are (1) GPS, (2)
GLONASS, and (3) combined GPS/GLONASS. Since a full GLONASS constellation is not
operating at the time of publication, the most likely service types will be GPS and combined
GPS/GLONASS. Table 3.1-2 shows various levels of RTK services that could be supported
today, with the Message Types that support them. It also provides the appropriate set of
messages for both the mobile and reference station receivers for each service.

3-2
 RTCM 10403.1

Table 3.1-2. Message Types Supporting Different RTK Service Levels

Service Group Mobile Reference Station

Receiver Message Type(s)
(minimum Minimum Full
decoding
© RTCM – Not for reproduction or redistribution

Service Service
requirement) Operation Operation
Precision GPS Observations (GPS) 1001-1004 1001 1002
L1 only Station Description 1005 and 1005 or 1005 or
1006 1006 1006
Antenna Description 1007 and 1007 or 1007 or
1008 1008 1008
Auxiliary Operation Information 1013
Precision GPS Observations (GPS) 1003-1004 1003 1004
RTK, L1 & L2 Station Description 1005 and 1005 or 1005 or
1006 1006 1006
Antenna Description 1007 and 1007 or 1007 or
1008 1008 1008
Auxiliary Operation Information 1013

Precision Observations (GLONASS) 1009-1012 1009 1010

GLONASS L1 Station Description 1005 and 1005 or 1005 or
only 1006 1006 1006
Antenna Description 1007 and 1007 or 1007 or
1008 1008 1008
Auxiliary Operation Information 1013
Precision Observations (GLONASS) 1011-1012 1011 1012
GLONASS Station Description 1005 and 1005 or 1005 or
RTK 1006 1006 1006
Antenna Description 1007 and 1007 or 1007 or
1008 1008 1008
Auxiliary Operation Information 1013
Precision GPS Observations (GPS) 1001-1004 1001 1002
and GLONASS Observations (GLONASS) 1009-1012 1009 1010
L1 only Station Description 1005 and 1005 or 1005 or
1006 1006 1006
Antenna Description 1007 and 1007 or 1007 or
1008 1008 1008
Auxiliary Operation Information 1013

3-3
 RTCM 10403.1

Service Group Mobile Reference Station

Receiver Message Type(s)
(minimum Minimum Full
decoding Service Service
requirement) Operation Operation
© RTCM – Not for reproduction or redistribution

Precision GPS Observations (GPS) 1003-1004 1003 1004

and GLONASS Observations (GLONASS) 1011-1012 1011 1012
RTK, L1 & L2 Station Description 1005 and 1005 or 1005 or
1006 1006 1006
Antenna Description 1007 and 1007 or 1007 or
1008 1008 1008
Auxiliary Operation Information 1013
Precision GPS Observations (GPS) 1003-1004 1003 1004
Network RTK Station Description 1005 and 1005 or 1005 or
1006 1006 1006
Antenna Description 1007 and 1007 or 1007 or
1008 1008 1008
Auxiliary Operation Information 1013
Network RTK Corrections 1014 1014
1017 1015 and
1016

Service Providers can provide a variety of different services ranging from a basic to a complete
service. A basic service would involve, e.g., a GPS single-frequency operation, with no attempt
to optimize accuracy or ambiguity resolution time. A complete service would provide dual-
frequency operations, possibly involving both GPS and GLONASS, attempting to optimize
accuracy, baseline length, and ambiguity resolution time, as well as providing helpful ancillary
data for quick startup and post-mission analysis.

Mobile equipment should be designed to decode all the message types in a group, even if all the
information is not processed. For example, by decoding a Message Type 1002, the RTK
observable data that matches that of Message Type 1001 can be utilized, but the additional
information may be ignored. If the mobile equipment only operates on L1, it should still be
designed to decode Message Types 1003 and 1004 and to pull out the L1 information.

3.1.3 Operation with Multiple Services

Providing information for multiple GNSS’s (e.g., GNSS1=GPS and GNSS2=GLONASS) can be
accommodated if guidelines are carefully followed. In particular:
1. The messages for all satellites of a particular system should be grouped in one message. For
example, for GPS L1/L2 operation, each 1003 or 1004 message should contain the data for

3-4
 RTCM 10403.1
all GPS satellites that are processed. This ensures that a GPS-only mobile receiver will be
certain that all relevant data has been received even if the “Synchronous GNSS Message
Flag”, which indicates that more GNSS data (e.g., GLONASS) referenced to the same time
epoch will be transmitted next, is set to “1”.
2. When the “extended” messages, i.e., Message Types 1002, 1004, 1010, and 1012, are
transmitted, they should include the entire set of satellites processed.
© RTCM – Not for reproduction or redistribution

3. For combined GPS/GLONASS operation, GPS data should be transmitted first. This is
because it will reduce latency for GPS-only mobile receivers, while combined
GPS/GLONASS mobile receivers will suffer no penalty.
4. If the GNSS1 and GNSS2 data are not synchronous (i.e., the observations are not taken
within one microsecond of each other), the “Synchronous GNSS Message Flag” should be
set to zero for each set.
When the GLONASS constellation becomes complete and/or the Galileo system becomes
operational, these rules may have to be re-examined and modified.

3.1.4 Reference Receiver Time and Observations

The reference receiver shall maintain its clock to align the measurement epoch times to the
GNSS system time if possible. This is commonly referred to as Clock Steering. If clock steering
is not possible, the observation shall be adjusted to correct for the receiver clock offset

When adjusting for clock offset, the consistency between the observations shall be maintained:

Transmitted Pseudorange =
Raw Pseudorange – (Clock Offset * PhaseRange Rate) – (Clock Offset * Speed of light)

Transmitted PhaseRange =
Raw PhaseRange – (Clock Offset * PhaseRange Rate) – (Clock Offset * Speed of light)

The resulting receiver epoch time should align with the GNSS system epoch time to within
±1 µs. Note that the PhaseRange has the same sign as the Raw Pseudorange.

For combined GNSS operation, if all GNSS observables are measured at the same instant of
receiver time (in other words, if GNSS1 and GNSS2 clocks are based on the same oscillator), the
clock offset utilized in the formulas above should be identical for the correction of all
observations across both satellite systems and frequencies. The relations of differences between
different clock biases in the observations are maintained in their original form. In this case,
"Single Receiver Oscillator Indicator" (DF142) should contain “1”. Also, "Synchronous GNSS
Message Flag" (DF005) should indicate that GNSS measurements are synchronous as described
in point 3.1.3. Some reference station installations may not allow for identical clock offsets over
all the satellite systems tracked (for example, if two or more independent receiver boards
produce the observations). Correspondingly, the "Single Receiver Oscillator Indicator" (DF142)
should be set to "0". However, in such a case all GNSS’s might be still synchronous, indicating
that the observations have been obtained within one microsecond. The "Synchronous GNSS

3-5
 RTCM 10403.1
Message Flag" (DF005) should identify the proper state. It should be noted that the conditions
for DF005 and DF142 refer to the configuration of the reference station equipment, thus do not
change during the transmission of a data stream.

3.1.5 GPS Network RTK corrections

© RTCM – Not for reproduction or redistribution

The fundamental functionality of networking software that combines the information of several
permanent reference stations is the determination of integer ambiguities between the reference
stations. The resulting integer ambiguities may be used for reducing the original raw reference
station observations. This manipulation of the raw observations leaves the general properties of
the carrier phase observations (troposphere, ionosphere, phase center variations, etc.) untouched,
since only integer numbers have been introduced. This process is named “integer ambiguity-
leveling” and the resulting observations of permanent reference stations are “(integer) ambiguity-
leveled”.

An application accessing ambiguity-leveled observations of a single reference station will not see
any difference. The modeling requirements within the application are identical. However, when
an application uses the observations of more than one reference station, the application will no
longer have to account for integer ambiguities between the reference stations on the same
ambiguity level. Roving user equipment receiving observations of more than one reference
station on the same ambiguity level and utilizing the observations in its positioning algorithm
may switch from one reference station to another without reinitialization of its filter.

In order to preserve throughput Network RTK messages utilize data fields that extend the
approach described above: the raw observations are reduced by the geometric representation of
the satellite and receiver distance; and inter-reference station single differences are used (see
Appendix A). Network RTK Corrections are designed as additional information for improved
performance and precision. A service provider utilizing the network capability will broadcast
previously defined Precision GPS RTK messages for the Master Reference Station, but will
broadcast Auxiliary Reference Station information as well. Until this version of the standard is
revised or a new version published, service providers are advised to limit the data stream to
information associated with one single Master Reference Station and its associated Auxiliary
Reference Stations. Participating mobile receivers must be designed to accept and process the
Network RTK Corrections. Mobile equipment operating close to the Master Reference Station
may be designed to use the Observation, Station Description, and Antenna Description
information of the Master Reference Station exclusively.

3.1.6 Proper handling of antenna phase center variation corrections

Antennas designed for precise RTK operation account for so-called antenna phase center offsets
and variations in the centimeter-range. These offsets and variations can be corrected within
precise RTK equipment using calibration information. Antenna model type calibrations are
available from several sources (e.g. IGS, and NGS). For high precision applications in particular
individual antenna calibrations are sometimes performed. Also, within permanent reference
station networks individually calibrated antennas are increasingly being used. The proper
handling of dissimilar antennas is a pressing issue for the interoperability of RTK network data.
Therefore for Network RTK operation adjustments may be made to raw observations for the
Master Reference Stations as depicted in messages (1001 – 1004) for antenna biases (phase

3-6
 RTCM 10403.1
center offsets and phase center variations). When corrections of antenna phase center variations
are required, one should ensure that consistent sets are used throughout the application. The best
way to ensure a consistent set of antenna phase center variations is to use only information from
a single source (e.g. IGS, NGS) and ensure that the same form of representation is used
consistently throughout each application (note the difference between absolute and relative
representations). Note that reference station network software and rover firmware are different
© RTCM – Not for reproduction or redistribution

applications and thus may use different representations. It is recommended that published
antenna parameters be used as they are. It is crucial to avoid mixing different forms of
representation, and/or “fine-tuning” given sets of information by assembling a new set out of
different sources (e.g. mixing offsets of one calibration with phase center variations with another
calibration for one antenna). Offsets and phase center variations comprise a self-consistent set of
information for a particular antenna. Both parts of the information are correlated with each other.
The shape of one particular antenna phase pattern may be represented in principle by an
indefinite number of different consistent sets of information (e.g. the introduction of a different
value in the offset will be compensated by the antenna phase center variations).

In the event that it is necessary to change Master Reference Stations within a Precision Network
RTK operation, a bias error could occur in the rover position as a consequence of using
inconsistent phase center correction sets at the rover (e.g., obtained from different sources).
Furthermore, achieving consistency of antenna correction models within large network setups
would require storing antenna phase center corrections for dozens of Master Reference Stations,
in order to allow use of the most accurate information that would be obtained from individually
calibrated antennas. There is another approach to achieving consistent operation of user
equipment, which is recommended here: namely, the observation data messages (1001 – 1004)
for all Master Reference Stations of a homogenous Network should be referenced to a single
antenna (preferably, the ADVNULLANTENNA). The modification of the observation
information with respect to antenna phase center variations must be indicated in the disseminated
data stream using antenna descriptor messages (1007 or 1008). The antenna descriptor field must
then state the descriptor of the antenna (e.g., ADVNULLANTENNA ). Note that the reduction to
the ADVNULLANTENNA is defined through the correction of the antenna phase center offsets
and variations based on the absolute antenna correction representation.

3.1.7 Scheduling of Network RTK messages

Scheduling of the Network RTK messages is a crucial procedure in the rover application. In
general the concept chosen for Network RTK messages accommodates a number of different
schemes. In order to achieve interoperability, some guidelines are necessary that limit the
scheduling but not the resulting performance.

The recommended guidelines for scheduling are:

• First, dissemination of raw observation message (1003 or 1004) containing Master
Reference Station data at a high data rate (0.5 – 2 Hz) immediately when information is
available (low latency).
• Next, dissemination of ionospheric (dispersive) and geometric (non-dispersive)
Correction Difference messages for all Auxiliary Reference Stations ((1015 and 1016) or
1017) at identical epoch time. The chosen epoch time should be identical to an epoch

3-7
 RTCM 10403.1
time as for raw observations of the Master Reference Station. The update rate may be
identical or at a lower data rate than for raw observations. For operation with Correction
Difference messages 1015 and 1016, the epoch time of both should be identical. The
maximum interval should not exceed 15 seconds. When Correction Differences are
updated at a lower rate than the Master Reference Station observations, both the
dispersive and the non-dispersive components may be filtered to reduce the effect of
© RTCM – Not for reproduction or redistribution

noise.
• Next, Station Information messages (1014). The complete set of Station Information
messages for all Master and Auxiliary Reference Stations within the data stream may be
distributed over time in order to optimize throughput. The dissemination should be
completed after a maximum time span of 15 seconds (optimization of start-up time of
rover operation).
• Other messages with additional information as needed for proper rover operation (see
Table 3.1-2) should be transmitted as for single baseline operation required.

Scheduling schemes within these bounds are recommended for best operation of a Network RTK
provider service with Network RTK messages.

These recommended guidelines are based on the scheduling used during interoperability testing,
using two different update rates. These rates were chosen to represent typical RTK operations in
the field, and are described in Tables 3.1-3 and 3.1-4. Other update rates can be employed, but a
Service Provider should be aware that these are the only ones that were actually tested for
interoperability.

Table 3.1-3 High Update, for Ease of Comparison Between Different Data Streams
Group Name Message Type Update Rate
Observations (GPS) 1004 1 Hz
Station Description 1005 or 1006 As typical in an RTK
operation
Antenna description 1007 or 1008 As typical in an RTK
operation
Network RTK Network Auxiliary 1014
Station Data
Network RTK GPS Ionospheric 1015 1 Hz
Correction
Difference
Network RTK GPS Geometric 1016 1 Hz
Correction
Difference

3-8
 RTCM 10403.1

Table 3.1-4 Update Rate for Typical Operation

Group name Message Type Update rate
Observations (GPS) 1004 1 Hz
Station Description 1005 or 1006 As typical in an RTK
operation
© RTCM – Not for reproduction or redistribution

Antenna description 1007 or 1008 As typical in an RTK

operation
Network RTK Network Auxiliary 1014
Station Data
Network RTK GPS Ionospheric 1015 Update completed
Correction every 10 seconds
Difference
Network RTK GPS Geometric 1016 Update completed
Correction every 10 seconds
Difference

3-9
 RTCM 10403.1

3.2 Message Type Summary

© RTCM – Not for reproduction or redistribution
The message types for supporting RTK GPS and GLONASS operation are shown in Table 3.2-1.
Table 3.2-1. Message Type Table

Message Message Name No. of Bytes * Notes

Type
1001 L1-Only GPS RTK Observables 8.00+7.25*Ns Ns = No. of Satellites
1002 Extended L1-Only GPS RTK Observables 8.00+9.25*Ns
1003 L1&L2 GPS RTK Observables 8.00+12.625*Ns
1004 Extended L1&L2 GPS RTK Observables 8.00+15.625*Ns
1005 Stationary RTK Reference Station ARP 19
1006 Stationary RTK Reference Station ARP 21
with Antenna Height
1007 Antenna Descriptor 5-36
1008 Antenna Descriptor & Serial Number 6-68
1009 L1-Only GLONASS RTK Observables 7.625+8*Ns Ns = No. of Satellites
1010 Extended L1-Only GLONASS RTK 7.625+9.875*Ns
Observables
1011 L1&L2 GLONASS RTK Observables 7.625+13.375*Ns
1012 Extended L1&L2 GLONASS RTK 7.625+16.25*Ns
Observables
1013 System Parameters 8.75+3.625*Nm Nm = Number of Message Types Transmitted
1014 Network Auxiliary Station Data 14.625
1015 GPS Ionospheric Correction Differences 9+3.75*Ns Ns = Number of Satellites

3-10
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
Message Message Name No. of Bytes * Notes
Type
1016 GPS Geometric Correction Differences 9+4.5*Ns Ns = Number of Satellites
1017 GPS Combined Geometric and Ionospheric 9+6.625*Ns Ns = Number of Satellites
Correction Differences
1018 RESERVED for Alternative Ionospheric
Correction Difference Message
1019 GPS Ephemerides 62 One message per satellite
1020 GLONASS Ephemerides 45 One message per satellite
1021- RESERVED for Coordinate
1028 Transformation Messages
1029 Unicode Text String 9+N N = Number of UTF-8 Code Units
4001- Proprietary Messages These message types are assigned to specific companies
4095 for the broadcast of proprietary information. See
Section 3.6.

* Fill bits (zeros) must be used to complete the last byte at the end of the message data before the CRC in order to maintain the
last byte boundary. Thus the total number of bytes must be the next full integer if fill bits are needed. For example, 55.125 computed
bytes means 56 bytes total.

3-11
 RTCM 10403.1

3.3 Data Types

© RTCM – Not for reproduction or redistribution
The data types used are shown in Table 3.3-1. Note that floating point quantities are not used.

Table 3.3-1. Data Type Table

Data Description Range Data Type Notes

Type
bit(n) bit field 0 or 1, each bit Reserved bits set to “0”
char8(n) 8 bit characters, ISO 8859-1 character set Reserved or unused characters: [0x00]
(not limited to ASCII)
int14 14 bit 2’s complement integer -8192 to +8191
int16 16 bit 2’s complement integer ± 32,767 -32,768 indicates data not available
int17 17 bit 2’s complement integer ± 65,535 -65,536 indicates data not available
int20 20 bit 2’s complement integer -524,288 to +524, 287
int21 21 bit 2’s complement integer ± 1,048,575 -1,048,576 indicates data not available
int22 22 bit 2’s complement integer ± 2,097,151 -2,097,152 indicates data not available
int23 23 bit 2’s complement integer ± 4,194,303 -4,194,304 indicates data not available
int24 24 bit 2’s complement integer ± 8,388,607 -8,388,608 indicates data not available
int30 30 bit 2’s complement integer ± 536,870,911 -536,870,912 indicates data not available
int32 32 bit 2’s complement integer ± 2,147,483,647 -2,147,483,648 indicates data not available
int38 38 bit 2’s complement integer -137,438,953,472 to +137,438,953,471
uint3 3 bit unsigned integer 0 to 7
uint4 4 bit unsigned integer 0 to 15
uint5 5 bit unsigned integer 0 to 31
uint6 6 bit unsigned integer 0 to 63
uint7 7 bit unsigned integer 0 to 127

3-12
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
Data Description Range Data Type Notes
Type
uint8 8 bit unsigned integer 0 to 255
uint10 10 bit unsigned integer 0 to 1023
uint11 11 bit unsigned integer 0 to 2047
uint12 12 bit unsigned integer 0 to 4095
uint16 16 bit unsigned integer 0 to 65,535
uint17 17 bit unsigned integer 0 to 131,071
uint18 18 bit unsigned integer 0 to 262,143
uint20 20 bit unsigned integer 0 to 1,048,575
uint23 23 bit unsigned integer 0 to 8,388,607
uint24 24 bit unsigned integer 0 to 16,777,215
uint25 25 bit unsigned integer 0 to 33,554,431
uint27 27 bit unsigned integer 0 to 134,217,727
uint30 30 bit unsigned integer 0 to 1,073,741,823
uint32 32 bit unsigned integer 0 to 4,294,967,295
intS5 5 bit sign-magnitude integer ± 15 See Note 1
intS11 11 bit sign-magnitude integer ± 1023 See Note 1
intS22 22 bit sign-magnitude integer ± 2,097,151 See Note 1
intS24 24 bit sign-magnitude integer ± 8,388,607 See Note 1
intS27 27 bit sign-magnitude integer ± 67,108,863 See Note 1
intS32 32 bit sign-magnitude integer ± 2,147,483,647 See Note 1
utf8(N) Unicode UTF-8 Code Unit 00h to FFh 8-bit value that contains all or part of a
Unicode UTF-8 encoded character

3-13
 RTCM 10403.1

Note 1. Sign-magnitude representation records the number's sign and magnitude. MSB is 0 for positive numbers and 1 for
© RTCM – Not for reproduction or redistribution
negative numbers. The rest of the bits are the number’s magnitude. For example, for 8-bit words, the representations of the
numbers “-5” and “+5” in a binary form are 10000101 and 00000101, respectively. Negative zero is not used.

3.4 Data Fields

The data fields used are shown in Table 3.4-1. Each Data Field (DF) uses one of the Data Types of Table 3.3-1. Note that the Data
Field ranges may be less than the maximum possible range allowed by the Data Type.

Table 3.4-1. Data Field Table

DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF001 Reserved bit(n) All reserved bits should be set to “0”. However, since the value is
subject to change in future versions, decoding should not rely on a
zero value.

DF002 Message Number 0-4095 uint12 Self-explanatory

DF003 Reference Station 0-4095 uint12 The Reference Station ID is determined by the service provider. Its
ID primary purpose is to link all message data to their unique source. It
is useful in distinguishing between desired and undesired data in cases
where more than one service may be using the same data link
frequency. It is also useful in accommodating multiple reference
stations within a single data link transmission.
In reference network applications the Reference Station ID plays an
important role, because it is the link between the observation
messages of a specific reference station and its auxiliary information
contained in other messages for proper operation. Thus the Service
Provider should ensure that the Reference Station ID is unique within
the whole network, and that ID’s should be reassigned only when
absolutely necessary.
Service Providers may need to coordinate their Reference Station ID
assignments with other Service Providers in their region in order to
avoid conflicts. This may be especially critical for equipment
accessing multiple services, depending on their services and means of
information distribution.

3-14
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF004 GPS Epoch Time 0-604,799,999 ms 1 ms uint30 GPS Epoch Time is provided in milliseconds from the beginning of
(TOW) the GPS week, which begins at midnight GMT on Saturday
night/Sunday morning, measured in GPS time (as opposed to UTC).

DF005 Synchronous bit(1) If the Synchronous GNSS Message Flag is set to “0”, it means that no
GNSS Message further GNSS observables referenced to the same Epoch Time will be
transmitted. This enables the receiver to begin processing the data
Flag immediately after decoding the message. If it is set to “1”, it means
that the next message will contain observables of another GNSS
source referenced to the same Epoch Time.
Note: “Synchronous" here means that the measurements are taken
within one microsecond of each other

DF006 No. of GPS 0-31 uint5 The Number of GPS Satellite Signals Processed refers to the number
Satellite Signals of satellites in the message. It does not necessarily equal the number
of satellites visible to the Reference Station.
Processed
DF007 GPS Divergence- bit(1) 0= Divergence-free smoothing not used
free Smoothing 1= Divergence-free smoothing used
Indicator
DF008 GPS Smoothing See Table 3.4-4 bit(3) The GPS Smoothing Interval is the integration period over which
Interval reference station pseudorange code phase measurements are averaged
using carrier phase information. Divergence-free smoothing may be
continuous over the entire period the satellite is visible.

DF009 GPS Satellite ID 1-63 (See Table uint6 A GPS Satellite ID number from 1 to 32 refers to the PRN code of the
3.4-3) GPS satellite. Satellite ID’s higher than 32 are reserved for satellite
signals from Satellite-Based Augmentation Systems (SBAS’s) such as
the FAA’s Wide-Area Augmentation System (WAAS). SBAS PRN
codes cover the range 120-138. The Satellite ID’s reserved for SBAS
satellites are 40-58, so that the SBAS PRN codes are derived from the
Version 3 Satellite ID codes by adding 80.

DF010 GPS L1 Code bit(1) The GPS L1 Code Indicator identifies the code being tracked by the
Indicator reference station. Civil receivers can track the C/A code, and
optionally the P code, while military receivers can track C/A, and can
also track P and Y code, whichever is broadcast by the satellite.
“0” = C/A Code;
“1” = P(Y) Code Direct

3-15
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF011 GPS L1 0-299,792.46 m 0.02 m uint24 The GPS L1 Pseudorange field provides the raw L1 pseudorange
Pseudorange measurement at the reference station in meters, modulo one light-
millisecond (299,792.458 meters). The GPS L1 pseudorange
measurement is reconstructed by the user receiver from the L1
pseudorange field by:
(GPS L1 pseudorange measurement) = (GPS L1 pseudorange field)
modulo (299,792.458 m) + integer as determined from the user
receiver's estimate of the reference station range, or as provided by the
extended data set. If DF012 is set to 80000h, this field does not
represent a valid L1 pseudorange, and is used only in the calculation
of L2 measurements.

DF012 GPS L1 ± 262.1435 m 0.0005 m int20 The GPS L1 PhaseRange – L1 Pseudorange field provides the
information necessary to determine the L1 phase measurement. Note
PhaseRange – L1 (See Data Field that the PhaseRange defined here has the same sign as the
Pseudorange pseudorange. The PhaseRange has much higher resolution than the
Note)
pseudorange, so that providing this field is just a numerical technique
to reduce the length of the message. At start up and after each cycle
slip, the initial ambiguity is reset and chosen so that the L1
PhaseRange should match the L1 Pseudorange as closely as possible
(i.e., within 1/2 L1 cycle) while not destroying the integer nature of
the original carrier phase observation.
The Full GPS L1 PhaseRange is constructed as follows (all quantities
in units of meters):
(Full L1 PhaseRange) = (L1 pseudorange as reconstructed from L1
pseudorange field) + (GPS L1 PhaseRange – L1 Pseudorange field)
Certain ionospheric conditions might cause the GPS L1 PhaseRange –
L1 Pseudorange to diverge over time across the range limits defined.
Under these circumstances the computed value needs to be adjusted
(rolled over) by the equivalent of 1500 cycles in order to bring the
value back within the range.
See also comments in sections 3.1.6 and 3.5.1 for correction of
antenna phase center variations in Network RTK applications.
Note: A bit pattern equivalent to 80000h in this field indicates the L1
phase is invalid, and that the DF011 field is used only in the
calculation of L2 measurements.

3-16
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF013 GPS L1 Lock See Table 3.4-2 uint7 The GPS L1 Lock Time Indicator provides a measure of the amount
Time Indicator of time that has elapsed during which the Reference Station receiver
has maintained continuous lock on that satellite signal. If a cycle slip
occurs during the previous measurement cycle, the lock indicator will
be reset to zero.

DF014 GPS Integer L1 0-76,447,076.790 299,792.458 uint8 The GPS Integer L1 Pseudorange Modulus Ambiguity represents the
Pseudorange m m integer number of full pseudorange modulus divisions (299,792.458
m) of the raw L1 pseudorange measurement.
Modulus
Ambiguity
DF015 GPS L1 CNR 0-63.75 dB-Hz 0.25 dB-Hz uint8 The GPS L1 CNR measurements provide the reference station's
estimate of the carrier-to-noise ratio of the satellite’s signal in dB-Hz.
The value “0” means that the CNR measurement is not computed.

DF016 GPS L2 Code bit(2) The GPS L2 Code Indicator depicts which L2 code is processed by
the reference station, and how it is processed.
Indicator 0= C/A or L2C code
1= P(Y) code direct
2= P(Y) code cross-correlated
3= Correlated P/Y
The GPS L2 Code Indicator refers to the method used by the GPS
reference station receiver to recover the L2 pseudorange. The GPS L2
Code Indicator should be set to 0 (C/A or L2C code) for any of the L2
civil codes. It is assumed here that a satellite will not transmit both
C/A code and L2C code signals on L2 simultaneously, so that the
reference station and user receivers will always utilize the same
signal. The code indicator should be set to 1 if the satellite’s signal is
correlated directly, i.e., either P code or Y code depending whether
anti-spoofing (AS) is switched off or on. The code indicator should
be set to 2 when the reference station receiver L2 pseudorange
measurement is derived by adding a cross-correlated pseudorange
measurement (Y2-Y1) to the measured L1 C/A code. The code
indicator should be set to 3 when the GPS reference station receiver is
using a proprietary method that uses only the L2 P(Y) code signal to
derive L2 pseudorange.

3-17
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF017 GPS L2-L1 ± 163.82 m 0.02m int14 The GPS L2-L1 Pseudorange Difference field is utilized, rather than
the full L2 pseudorange, in order to reduce the message length. The
Pseudorange
(See Data Field receiver must reconstruct the L2 code phase pseudorange by using the
Difference following formula:
Note)
(GPS L2 pseudorange measurement) =
(GPS L1 pseudorange as reconstructed from L1 pseudorange field) +
(GPS L2-L1 pseudorange field)
Note: A bit pattern equivalent to 2000h (-163.84m) means that there is
no valid L2 code available, or that the value exceeds the allowed
range.

DF018 GPS L2 ± 262.1435 m 0.0005 m int20 The GPS L2 PhaseRange - L1 Pseudorange field provides the
information necessary to determine the L2 phase measurement. Note
PhaseRange – L1 (See Data Field that the PhaseRange defined here has the same sign as the
Pseudorange pseudorange. The PhaseRange has much higher resolution than the
Note)
pseudorange, so that providing this field is just a numerical technique
to reduce the length of the message. At start up and after each cycle
slip, the initial ambiguity is reset and chosen so that the L2
PhaseRange should match the L1 Pseudorange as closely as possible
(i.e., within 1/2 L2 cycle) while not destroying the integer nature of
the original carrier phase observation.
The Full GPS L2 PhaseRange is constructed as follows (all quantities
in units of meters):
(Full L2 PhaseRange) = (L1 pseudorange as reconstructed from L1
pseudorange field) + (GPS L2 PhaseRange – L1 Pseudorange field)
Certain ionospheric conditions might cause the GPS L2 PhaseRange –
L1 Pseudorange to diverge over time across the range limits defined.
Under these circumstances the computed value needs to be adjusted
(rolled over) by the equivalent of 1500 cycles in order to bring the
value back within the range. Note: A bit pattern equivalent to 80000h
in this field indicates an invalid carrier phase measurement that should
not be processed by the mobile receiver. This indication may be used
at low signal levels where carrier tracking is temporarily lost, but code
tracking is still possible.
See also comments in sections 3.1.6 and 3.5.1 for correction of
antenna phase center variations in Network RTK applications.

3-18
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF019 GPS L2 Lock See Table 3.4-2 uint7 The GPS L2 Lock Time Indicator provides a measure of the amount
Time Indicator of time that has elapsed during which the Reference Station receiver
has maintained continuous lock on that satellite signal. If a cycle slip
occurs during the previous measurement cycle, the lock indicator will
be reset to zero.

DF020 GPS L2 CNR 0-63.75 dB-Hz 0.25 dB-Hz uint8 The GPS L2 CNR measurements provide the reference station's
estimate of the carrier-to-noise ratio of the satellite’s signal in dB-Hz.
The value “0” means that the CNR measurement is not computed.

DF021 ITRF Realization uint6 Since this field is reserved, all bits should be set to zero for now.
Year However, since the value is subject to change in future versions,
decoding should not rely on a zero value.
The ITRF realization year identifies the datum definition used for
coordinates in the message.

DF022 GPS Indicator bit(1) 0=No GPS service supported

1=GPS service supported

DF023 GLONASS bit(1) 0=No GLONASS service supported

Indicator 1=GLONASS service supported

DF024 Galileo Indicator bit(1) 0=No Galileo service supported

1=Galileo service supported

DF025 Antenna Ref. Point ± 0.0001 m int38 The antenna reference point X-coordinate is referenced to ITRF epoch
ECEF-X 13,743,895.3471 as given in DF021.
m
DF026 Antenna Ref. Point ± 0.0001 m int38 The antenna reference point Y-coordinate is referenced to ITRF epoch
ECEF-Y 13,743,895.3471 as given in DF021.
m
DF027 Antenna Ref. Point ± 0.0001 m int38 The antenna reference point Z-coordinate is referenced to ITRF epoch
ECEF-Z 13,743,895.3471 as given in DF021.
m

3-19
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF028 Antenna Height 0-6.5535 m 0.0001 m uint16 The Antenna Height field provides the height of the Antenna
Reference Point above the marker used in the survey campaign.

DF029 Descriptor Counter 0-31 uint8 The Descriptor Counter defines the number of characters (bytes) to
follow in DF030, Antenna Descriptor

DF030 Antenna char8 Alphanumeric characters. IGS limits the number of characters to 20
Descriptor (n) at this time, but this DF allows more characters for future extension.

DF031 Antenna Setup ID 0-255 uint8 0=Use standard IGS Model

1-255=Specific Antenna Setup ID#
The Antenna Setup ID is a parameter for use by the service provider
to indicate the particular reference station-antenna combination. The
number should be increased whenever a change occurs at the station
that affects the antenna phase center variations. While the Antenna
Descriptor and the Antenna Serial Number give an indication of when
the installed antenna has been changed, it is envisioned that other
changes could occur. For instance the antenna might been repaired, or
the surrounding of the antenna might have been changed and the
provider of the service may want to make the user station aware of the
change. Depending on the change of the phase center variations due
to a setup change, a change in the Antenna Setup ID would mean that
the user should check with the service provider to see if the antenna
phase center variation in use is still valid. Of course, the provider
must make appropriate information available to the users.

DF032 Serial Number 0-31 uint8 The Serial Number Counter defines the number of characters (bytes)
Counter to follow in Antenna Serial Number

DF033 Antenna Serial char8 Alphanumeric characters. The Antenna Serial Number is the
Number (n) individual antenna serial number as issued by the manufacturer of the
antenna. A possible duplication of the Antenna Serial Number is not
possible, because together with the Antenna Descriptor only one
antenna with the particular number will be available. In order to
avoid confusion the Antenna Serial Number should be omitted when
the record is used together with reverse reduction to model type
calibration values, because it cannot be allocated to a real physical
antenna.

3-20
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF034 GLONASS Epoch 0-86,400,999 ms 1 ms uint27 GLONASS Epoch Time of measurement is defined by the GLONASS
ICD as UTC(SU) + 3.0 hours. It rolls over at 86,400 seconds for
Time (tk) GLONASS, except for the leap second, where it rolls over at 86,401.

DF035 No. of GLONASS 0-31 1 uint5 The Number of GLONASS Satellite Signals Processed refers to the
Satellite Signals number of satellites in the message. It does not necessarily equal the
number of satellites visible to the Reference Station.
Processed

DF036 GLONASS bit(1) 0= Divergence-free smoothing not used

Divergence-free 1= Divergence-free smoothing used
Smoothing
Indicator
DF037 GLONASS See Table 3.4-4 bit(3) The GLONASS Smoothing Interval is the integration period over
Smoothing which reference station pseudorange code phase measurements are
averaged using carrier phase information. Divergence-free smoothing
Interval may be continuous over the entire period the satellite is visible.

DF038 GLONASS 0-63 (See Table uint6 A GLONASS Satellite ID number from 1 to 24 refers to the slot
Satellite ID 3.4-3) number of the GLONASS satellite. A Satellite ID of zero indicates
that the slot number is unknown. Satellite ID’s higher than 32 are
(Satellite Slot reserved for satellite signals from Satellite-Based Augmentation
Number) Systems (SBAS’s). SBAS PRN codes cover the range 120-138. The
Satellite ID’s reserved for SBAS satellites are 40-58, so that the
SBAS PRN codes are derived from the Version 3 GLONASS Satellite
ID codes by adding 80.
Note: For GLONASS-M satellites this data field has to contain the
GLONASS-M word “n”, thus the Satellite Slot Number is always
known (cannot be equal to zero) for GLONASS-M satellites.

DF039 GLONASS L1 bit(1) “0” = C/A Code;

Code Indicator “1” = P Code

3-21
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF040 GLONASS 0-20 (See 1 uint5 The GLONASS Satellite Frequency Channel Number identifies the
Satellite Table 3.4-5) frequency of the GLONASS satellite. By providing both the Slot ID
and the Frequency Code of the satellite, the user instantly knows the
Frequency frequency of the satellite without requiring an almanac.
Channel Number
0 indicates channel number –07
1 indicates channel number –06
…..
20 indicates channel number +13

DF041 GLONASS L1 0-599,584.92 m 0.02 m uint25 The GLONASS L1 Pseudorange field provides the raw L1
Pseudorange pseudorange measurement at the reference station in meters, modulo
two light-milliseconds (599,584.916 meters). The L1 pseudorange
measurement is reconstructed by the user receiver from the L1
pseudorange field by:
(L1 pseudorange measurement) = (L1 pseudorange field) modulo
(599,584.916 m) + integer as determined from the user receiver's
estimate of the reference station range, or as provided by the extended
data set.

3-22
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF042 GLONASS L1 ± 262.1435 m 0.0005 m int20 The GLONASS L1 PhaseRange – L1 Pseudorange field provides the
information necessary to determine the L1 phase measurement. Note
PhaseRange – L1
(See Data Field that the PhaseRange defined here has the same sign as the
Pseudorange pseudorange. The PhaseRange has much higher resolution than the
Note)
pseudorange, so that providing this field is just a numerical technique
to reduce the length of the message. At start up and after each cycle
slip, the initial ambiguity is reset and chosen so that the L1
PhaseRange should match the L1 Pseudorange as closely as possible
(i.e., within 1/2 L1 cycle) while not destroying the integer nature of
the original carrier phase observation.
The Full GLONASS L1 PhaseRange is constructed as follows (all
quantities in units of meters):
(Full L1 PhaseRange) = (L1 pseudorange as reconstructed from L1
pseudorange field) + (GLONASS L1 PhaseRange – GLONASS L1
Pseudorange field)
Certain ionospheric conditions might cause the GLONASS L1
PhaseRange – L1 Pseudorange to diverge over time across the range
limits defined. Under these circumstances the computed value needs
to be adjusted (rolled over) by the equivalent of 1500 cycles in order
to bring the value back within the range.
Note: A bit pattern equivalent to 80000h in this field indicates an
invalid carrier phase measurement that should not be processed by the
mobile receiver. This indication may be used at low signal levels
where carrier tracking is temporarily lost, but code tracking is still
possible.

DF043 GLONASS L1 See Table 3.4-2 uint7 The GLONASS L1 Lock Time Indicator provides a measure of the
Lock Time amount of time that has elapsed during which the Reference Station
receiver has maintained continuous lock on that satellite signal. If a
Indicator cycle slip occurs during the previous measurement cycle, the lock
indicator will be reset to zero.

DF044 GLONASS Integer 0-76,147,284.332 599,584.916 uint7 The GLONASS Integer L1 Pseudorange Modulus Ambiguity
L1 Pseudorange m m represents the integer number of full pseudorange modulus divisions
(599,584.916 m) of the raw L1 pseudorange measurement
Modulus
Ambiguity

3-23
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF045 GLONASS L1 0-63.75 dB-Hz 0.25 dB-Hz uint8 The GLONASS L1 CNR measurements provide the reference
CNR station's estimate of the carrier-to-noise ratio of the satellite’s signal in
dB-Hz.
The value “0” means that the CNR measurement is not computed.

DF046 GLONASS L2 bit(2) The GLONASS L2 Code Indicator depicts which L2 code is
processed by the reference station.
Code Indicator 0= C/A code
1= P code
2, 3 Reserved

DF047 GLONASS ± 163.82 m 0.02m int14 The GLONASS L2-L1 Pseudorange Difference field is utilized, rather
than the full L2 pseudorange, in order to reduce the message length.
L2-L1 (See Data Field The receiver must reconstruct the L2 code phase pseudorange by
Pseudorange using the following formula:
Note)
Difference (GLONASS L2 pseudorange measurement) =
(L1 pseudorange as reconstructed from L1 pseudorange field) + (L2-
L1 pseudorange field)
Note: A bit pattern equivalent to 2000h (-163.84) means that there is
no valid L2 code available, or that the value exceeds the allowed
range

3-24
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF048 GLONASS L2 ± 262.1435 m 0.0005 m int20 The GLONASS L2 PhaseRange - L1 Pseudorange field provides the
PhaseRange – L1 information necessary to determine the L2 phase measurement. Note
(See Data Field that the PhaseRange defined here has the same sign as the
Pseudorange Note) pseudorange. The PhaseRange has much higher resolution than the
pseudorange, so that providing this field is just a numerical technique
to reduce the length of the message. At start up and after each cycle
slip, the initial ambiguity is reset and chosen so that the L2
PhaseRange should match the L1 Pseudorange as closely as possible
(i.e., within 1/2 L2 cycle) while not destroying the integer nature of
the original carrier phase observation.
The Full GLONASS L2 PhaseRange is constructed as follows (all
quantities in units of meters):
(Full L2 PhaseRange) = (L1 pseudorange as reconstructed from L1
pseudorange field) + (GLONASS L2 PhaseRange – L1 Pseudorange
field)
Certain ionospheric conditions might cause the GLONASS L2
PhaseRange – L1 Pseudorange to diverge over time across the range
limits defined. Under these circumstances the computed value needs
to be adjusted (rolled over) by the equivalent of 1500 cycles in order
to bring the value back within the range.
Note: A bit pattern equivalent to 80000h in this field indicates an
invalid carrier phase measurement that should not be processed by the
mobile receiver. This indication may be used at low signal levels
where carrier tracking is temporarily lost, but code tracking is still
possible.

DF049 GLONASS L2 See Table 3.4-2 uint7 The GLONASS L2 Lock Time Indicator provides a measure of the
Lock Time amount of time that has elapsed during which the Reference Station
receiver has maintained continuous lock on that satellite signal. If a
Indicator cycle slip occurs during the previous measurement cycle, the lock
indicator will be reset to zero.

DF050 GLONASS L2 0-63.75 dB-Hz 0.25 dB-Hz uint8 The GLONASS L2 CNR measurements provide the reference
CNR station's estimate of the carrier-to-noise ratio of the satellite’s signal in
dB-Hz.
The value “0” means that the CNR measurement is not computed.

3-25
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF051 Modified Julian 0-65,535 days 1 day uint16 Modified Julian Day number (MJD) is the continuous count of day
Day (MJD) numbers since November 17, 1858 midnight. For example, the first
day in GPS week 0 has MJD 44244. The full MJD number shall
Number always be transmitted. At this point in time the rollover of the MJD is
quite far away in time, but experience with the Y2K problem showed
that the actual life of software and applications can be considerably
longer than expected. Therefore, it is foreseen to have a rollover of
the MJD in calendar year 2038. At day 65,536 MJD the counter will
start at 0 again.

DF052 Seconds of Day 0-86,400 s 1 second uint17 Seconds Of Day (UTC) are the seconds of the day counted from
(UTC) midnight Greenwich time. GPS seconds of week have to be adjusted
for the appropriate number of leap seconds. The value of 86,400 is
reserved for the case that a leap second has been issued.

DF053 Number of 0-31 1 uint5 The Number of Message ID Announcements to follow informs the
Message ID receiver of the number of message types and the frequency of their
Announcements broadcast by the reference station.

to Follow (Nm)
DF054 Leap Seconds, 0-254 s 1 second uint8 See the GPS/SPS Signal Specification, available from the U.S. Coast
GPS-UTC Guard Navigation Information Service.
255 indicates that the value is not provided.

DF055 Message ID 0-4095 1 uint12 Each announcement lists the Message ID as transmitted by the
reference station.

DF056 Message Sync bit(1) 0=Asynchronous – not transmitted on a regular basis

Flag 1=Synchronous – scheduled for transmission at regular intervals

DF057 Message 0-6,553.5 s 0.1 seconds uint16 Each announcement lists the Message Transmission Interval as
Transmission transmitted by the reference station. If asynchronous, the
transmission interval is approximate.
Interval
DF058 Number of 0 – 31 1 uint5 Number of Auxiliary Reference Stations transmitted in conjunction
Auxiliary Stations with designated Master Reference Station. Defines the number of
different messages received of one type.
Transmitted

3-26
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF059 Network ID 0 - 255 1 uint8 Network ID defines the network and the source of the particular set of
reference stations and their observation information belongs to. The
service provider should ensure that the Network ID is unique in the
region serviced. The Network ID indicates an area and its reference
stations where the service providers will provide a homogenous
solution with leveled integer ambiguities between its reference
stations. In general the area indicated by Network ID will comprise
one subnetwork with a unique Subnetwork ID. (See description on
how to use Network IDs and Subnetwork IDs in Section 3.5.6.).

DF060 Master Reference 0 – 4095 1 uint12 Station ID of Master Reference Station. The Master Reference Station
Station ID must have the identical ID as one of the reference stations used within
the same data stream for providing observation or correction
information. The Master Auxiliary Concept allows in principle for
several Master Reference Stations in the same data stream. Every
Master Reference Station would require a separate raw observation
message transmitted for the identical reference station. However for
the current version of the standard it is recommended to have only
one Master Reference Station in a data stream (see also Section
3.1.5).

DF061 Auxiliary 0 – 4095 1 uint12 Station ID to identify Auxiliary Reference Station used to derive
Reference Station attached information.
ID
DF062 Aux-Master Delta ±13.1071 25 x 10-6 int20 Delta value in latitude of Antenna Reference Point of “Auxiliary
Latitude degrees degrees Reference Station minus Master Reference Station” in geographical
coordinates based on GRS80 ellipsoid parameters for the same ECEF
system as used in message 1005 or 1006 within the same data stream.
Note: in severe ionospheric conditions it may not be possible to
provide complete service over the entire allowed range, because
Ionospheric Correction Differences may exceed the allowed range of
DF069.

3-27
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF063 Aux-Master Delta ±26.2142 25 x 10-6 int21 Delta value in longitude of Antenna Reference Point of “Auxiliary
Longitude degrees degrees Reference Station minus Master Reference Station” in geographical
coordinates based on GRS80 ellipsoid parameters for the same ECEF
system as used in message 1005 or 1006 within the same data stream.
Note: in severe ionospheric conditions it may not be possible to
provide complete service over the entire allowed range, because
Ionospheric Correction Differences may exceed the allowed range of
DF069.

DF064 Aux-Master Delta ±4194.303 m 1 mm int23 Delta value in ellipsoidal height of Antenna Reference Point of
Height “Auxiliary Reference Station minus Master Reference Station” in
geographical coordinates based on GRS80 ellipsoid parameters for
the same ECEF system as used in message 1005 or 1006 within the
same data stream.

DF065 GPS Epoch Time 0 - 603,799.9 sec 0.1 sec uint23 Epoch time of observations used to derive correction differences
(GPS TOW)
DF066 GPS Multiple 0-1 1 bit(1) Set to 1 in case messages with the same Message Number and Epoch
Time will be transmitted in sequence. Set to 0 for last message of a
Message Indicator sequence.
DF067 # of GPS Satellites 0 - 15 1 uint4 Number of correction differences for GPS satellites contained in
message. Only one message per Auxiliary-Master Reference Station
pair and Epoch Time is allowed. Each message shall contain
respective correction differences for all satellites tracked at the
relevant Master-Auxiliary Reference Station combination
DF068 GPS Satellite ID 1 – 32 1 uint6 GPS Satellite ID’s only

3-28
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF069 GPS Ionospheric ±32.767 m 0.5 mm int17 Ionospheric Carrier Phase Correction Difference (ICPCD) is the
Carrier Phase Correction Difference for ionospheric part calculated based on integer
leveled L1 and L2 correction differences (L1CD and L2CD).
Correction
Difference f 22 f 22
ICPCD = L1CD − L 2CD
f 22 − f12 f 22 − f12

L1CD, L2CD, and ICPCD are presented in meters.

(See discussion of L1 and L2 corrections in Section 3.5.6.)
In extreme conditions the value of this field may lie outside the
specified range. If this happens, the data block for the specific
satellite containing this field (Tables 3.5-18 & 20) should not be
transmitted.

DF070 GPS Geometric ±32.767 m 0.5 mm int17 Geometric Carrier Phase Correction Difference (GCPCD) is the
Carrier Phase Correction Difference for geometric part calculated based on integer
leveled L1 and L2 correction differences (L1CD and L2CD).
Correction
Difference f12 f 22
GCPCD = L1CD − L 2CD
f12 − f 22 f12 − f 22

L1CD, L2CD, and ICPCD are presented in meters.

(See discussion of L1 and L2 corrections in Section 3.5.6.)

DF071 GPS IODE 1 bit(8) IODE value of broadcast ephemeris used for calculation of Correction
Differences.

3-29
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF072 Subnetwork ID 0 – 15 uint4 Subnetwork ID identifies the subnetwork of a network identified by
Network ID. In general the area indicated by Network ID will consist
of one subnetwork. The Subnetwork ID indicates the actual solution
number of integer ambiguity level (see the description of Integer
Ambiguity Level in Section 3.5.6). If one network has only one
subnetwork, this indicates that an ambiguity level throughout the
whole network is established. In case of problems it might not be
possible to have one homogenous integer ambiguity leveled solution
throughout the whole network. The solution might break up into
several homogeneous solutions, which can be indicated and
distinguished by separate Subnetwork IDs. Every independent
homogeneous integer ambiguity leveled solution needs to have an
independent Subnetwork ID. Master Reference Stations with different
Subnetwork IDs indicate that no hand-over from one to another
Master Reference Station is possible since the solutions are not
consistent and have no common stations. (See description on how to
use Network IDs and Subnetwork IDs in Section 3.5.6. or Appendix
A.1.)
Note: Subnetwork ID’s greater than “0” should be utilized only if the
associated messages for Master Reference Station observations (1001
through 1004) are brought to the same Ambiguity Level. It is
recommended that this field be set to 0” for now. In the future a
Subnetwork ID of “0” will indicate that corresponding raw data
streams are not ambiguity-leveled.
Note: for Version 10403.1 of the standard, only one Master Reference
Station with its associated Auxiliary Stations should be used in a
single data stream. The result of this restriction is that Subnetwork
ID’s may not be needed. Future versions are expected to support
Subnetwork ID’s.
DF073 RESERVED for 0 – 255 uint8 Unique ID identifying a service provider for a region. Service
Provider ID providers have to make that they are using a unique ID that is not
used by another service provider in the region.

3-30
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF074 GPS Ambiguity 0–3 bit(2) 0 reserved for future use (artificial observations)
Status Flag 1 Correct Integer Ambiguity Level for L1 and L2
2 Correct Integer Ambiguity Level for L1-L2 widelane
3 Uncertain Integer Ambiguity Level. Only a likely guess is used.
(See the description of Correct Integer Ambiguity Level and
Ambiguity Status Flag in Section 3.5.6.)

DF075 GPS Non Sync 0–7 uint3 Whenever an unrecoverable cycle slip occurs this count shall be
Count increased. The counter shall not be increased more than once per
minute. (See the discussion of cycle slips and ambiguity levels in
Section 3.5.6)

DF076 GPS Week number 0 -1023 1 week uint10 GPS week number. Roll-over every 1024 weeks starting from
Midnight on the night of January 5/Morning January 6, 1980

DF077 GPS SV Acc. N/A bit(4) meters; see GPS SPS Signal Spec, 2.4.3.2
(URA)
DF078 GPS CODE ON 0-3 1 bit(2) 00 = reserved; 01 = P code ON; 10 = C/A code ON; 11 = L2C ON
L2
DF079 GPS IDOT See Note 1 2-43 int14 semi-circles/sec

DF080 GPS IODE 0-255 1 uint8 unitless; see GPS SPS Signal Spec, 2.4.4.2

DF081 GPS toc 607,784 24 uint16 seconds

DF082 GPS af2 See Note 1 2-55 int8 sec/sec2

DF083 GPS af1 See Note 1 2-43 int16 sec/sec

DF084 GPS af0 See Note 1 2-31 int22 seconds

DF085 GPS IODC 0-1023 1 uint10 unitless. The 8 LSBs of IODC contains the same bits and sequence as
those in IODE; see GPS SPS Signal Spec, 2.4.3.4.

DF086 GPS Crs See Note 1 2-5 int16 meters

3-31
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF087 GPS Δn (DELTA See Note 1 2-43 int16 semi-circles/sec
n)
DF088 GPS M0 See Note 1 2-31 int32 semi-circles

DF089 GPS Cuc See Note 1 2-29 int16 radians

DF090 GPS Eccentricity 0.03 2-33 uint32 unitless

(e)
DF091 GPS Cus See Note 1 2-29 int16 radians

DF092 GPS (A)1/2 See Note 1 2-19 uint32 meters1/2

DF093 604,784 24 uint16 seconds

GPS toe
DF094 GPS Cic See Note 1 2-29 int16 radians

2-31 semi-circles
DF095 GPS Ω0 See Note 1 int32
(OMEGA)0
DF096 GPS Cis See Note 1 2-29 int16 radians

DF097 See Note 1 2-31 int32 semi-circles

GPS i0
DF098 GPS Crc See Note 1 2-5 int16 meters

2-31 semi-circles
DF099 GPS ω (Argument See Note 1 int32
of Perigee)
DF100 GPS See Note 1 2-43 int24 semi-circles/sec
OMEGADOT
(Rate of Right
Ascension)
DF101 See Note 1 2-31 int8 seconds
GPS tGD

3-32
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF102 GPS SV HEALTH See GPS SPS 1 uint6 MSB: 0 = all NAV data are OK;
1 = some or all NAV data are bad.
Signal Spec, See GPS SPS Signal Spec, 2.4.3.3.
2.4.5.3
DF103 GPS L2 P data flag Subframe 1, 1 bit(1) 0: L2 P-Code NAV data ON
Word 4, Bit 1 1: L2 P-Code NAV data OFF

DF104 GLONASS bit(1) GLONASS almanac health (Cn word)

almanac health
DF105 GLONASS bit(1) 0= GLONASS almanac has not been received: GLONASS almanac
almanac health health is not available;
availability 1= GLONASS almanac has been received: GLONASS almanac
indicator health is available;

DF106 GLONASS P1 bit(2) GLONASS P1 word

DF107 GLONASS tk bits 11-7: bit(12) Time referenced to the beginning of GLONASS subframe within the
0-23 current day. The integer number of hours elapsed since the beginning
of current day occupies 5 MSB. The integer number of minutes
bits 6-1: occupies next six bits. The number of thirty-second intervals occupies
0-59 the LSB.

bit 0: 0-1
DF108 GLONASS MSB bit(1) GLONASS MSB of Bn word. It contains the ephemeris health flag.
of Bn word
DF109 GLONASS P2 bit(1) GLONASS P2 word

DF110 GLONASS tb 1-95 15 minutes uint7 Time to which GLONASS navigation data are referenced.

DF111 GLONASS xn(tb), ±4.3 km/s ±2-20 km/s intS24 GLONASS ECEF-X component of satellite velocity vector in PZ-90
first derivative datum

DF112 GLONASS xn(tb) ±27000 km ±2-11 km intS27 GLONASS ECEF-X component of satellite coordinates in PZ-90
datum

3-33
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF113 GLONASS xn(tb), ±6.2*10-9 km/s ±2-30 km/s2 intS5 GLONASS ECEF-X component of satellite acceleration in PZ-90
second derivative datum

DF114 GLONASS yn(tb), ±4.3 km/s ±2-20 km/s intS24 GLONASS ECEF-Y component of satellite velocity vector in PZ-90
first derivative datum

DF115 GLONASS yn(tb) ±27000 km ±2-11 km intS27 GLONASS ECEF-Y component of satellite coordinates in PZ-90
datum

DF116 GLONASS yn(tb), ±6.2*10-9 km/s ±2-30 km/s2 intS5 GLONASS ECEF-Y component of satellite acceleration in PZ-90
second derivative datum

DF117 GLONASS zn(tb), ±4.3 km/s ±2-20 km/s intS24 GLONASS ECEF-Z component of satellite velocity vector in PZ-90
first derivative datum

DF118 GLONASS zn(tb) ±27000 km ±2-11 km intS27 GLONASS ECEF-Z component of satellite coordinates in PZ-90
datum

DF119 GLONASS zn(tb), ±6.2*10-9 km/s ±2-30 km/s2 intS5 GLONASS ECEF-Z component of satellite acceleration in PZ-90
second derivative datum

DF120 GLONASS P3 bit(1) GLONASS P3 word

DF121 GLONASS γn(tb) ±2-30 2-40 intS11 GLONASS relative deviation of predicted satellite carrier frequency
from nominal value

DF122 GLONASS-M P 0-3 bit(2) GLONASS-M P word

DF123 GLONASS-M ln bit(1) GLONASS-M ln word extracted from third string of the subframe
(third string)
DF124 GLONASS τn(tb) ±2-9 seconds 2-30 intS22 GLONASS correction to the satellite time relative to GLONASS
system time

DF125 GLONASS-M Δτn ±13.97*10-9 2-30 intS5 GLONASS time difference between navigation RF signal transmitted
seconds in L2 sub-band and navigation RF signal transmitted in L1 sub-band

DF126 GLONASS En 0-31 days 1 day uint5 The age of GLONASS navigation data

DF127 GLONASS-M P4 bit(1) GLONASS-M P4 word

3-34
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF128 GLONASS-M FT 0-15 uint4 GLONASS-M predicted satellite user range accuracy at time tb

DF129 GLONASS-M NT 1-1461 1 day uint11 GLONASS calendar number of day within four-year interval starting
from the 1-st of January in a leap year.
Note. For GLONASS satellites this data field (if it is not equal to
zero) may contain computed calendar number of day that corresponds
to the parameter tb.

DF130 GLONASS-M M 0-3 bit(2) Type of GLONASS satellite. If this data field contains “01”, the
satellite is GLONASS-M. Correspondingly, all GLONASS-M data
fields are valid. If this parameter equals “00”, GLONASS-M
parameters are not valid, thus they may contain arbitrary values.

DF131 GLONASS The bit(1) The rest parameters of GLONASS ephemeris message contain data
Availability of (data fields DF132-DF136) extracted from the fifth string of the
subframe. These parameters do not belong to predefined ephemeris
Additional Data data. Nevertheless, they can be useful for positioning and timing.
Given flag defines whether the parameters are available (=1) in the
message. If this flag is set to zero, DF132-DF136 may contain
arbitrary values.

DF132 GLONASS NA 1-1461 1 day uint11 GLONASS calendar number of day within the four-year period to
which τc is referenced.

DF133 GLONASS τc ±1 second 2-31 intS32 Difference between GLONASS system time and UTC(SU). This
parameter is referenced to the beginning of day NA.

DF134 GLONASS-M N4 1-31 4-years uint5 GLONASS four-year interval number starting from 1996
interval

DF135 GLONASS-M ±1.9*10-3 seconds 2-31 intS22 Correction to GPS system time relative to GLONASS system time.
τGPS
DF136 GLONASS-M ln bit(1) GLONASS-M ln word extracted from fifth string of the subframe
(fifth string)
DF137 GPS Fit Interval Subframe 2, 1 bit(1) 0: curve-fit interval is 4 hours
Word 10, Bit 17 1: curve-fit is greater than 4 hours

3-35
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DF # DF Name DF Range DF Data Data Field Notes
Resolution Type
DF138 Number of 0-127 1 character uint7 Provides the number of fully formed Unicode characters in the
Characters to message text. It is not necessarily the number of bytes in the string.
Follow

DF139 Number of UTF-8 0-255 1 byte uint8 The number of UTF-8 Character Code Units in the message.
Code Units
DF140 UTF-8 Character utf8(n) Code units of a Unicode 8-bit string.
Code Units
DF141 Reference-Station bit(1) 0: Real, Physical Reference Station
Indicator 1: Non-Physical or Computed Reference Station
Note: A Non-Physical or Computed Reference Station is typically
calculated based on information from a network of reference stations.
Different approaches have been established over years. The Non-
Physical or Computed Reference Stations are sometimes trademarked
and may not be compatible. Examples of these names are “Virtual
Reference Stations”, “Pseudo-Reference Stations”, and
“Individualized Reference Stations”.
DF142 Single Receiver bit(1) 0: Indicates that all raw data observations in messages 1001-1004 and
Oscillator 1009-1012 may be measured at different instants. This indicator
should be set to “0” unless all the conditions for “1” are clearly met.
Indicator
1: Indicates that all raw data observations in messages 1001-1004 and
1009-1012 are measured at the same instant, as described in Section
3.1.4.

Note 1: Effective range is the maximum range attainable with the indicated bit allocation and scale factor.

3-36
 RTCM 10403.1

Table 3.4-2. Lock Time Indicator, Data Fields DF013, DF019, DF043, DF049 (Note 1)
© RTCM – Not for reproduction or redistribution
Indicator (i) Minimum Lock Time (s) Range of Indicated Lock Times
0-23 i 0 < lock time < 24
24-47 i ⋅ 2 − 24 24 ≤ lock time < 72
48-71 i ⋅ 4 − 120 72 ≤ lock time < 168
72-95 i ⋅ 8 − 408 168 ≤ lock time < 360
96-119 i ⋅ 16 − 1176 360 ≤ lock time < 744
120-126 i ⋅ 32 − 3096 744 ≤ lock time < 937
127 --- lock time ≥ 937

Note 1 - Determining Loss of Lock: In normal operation, a cycle slip will be evident when the Minimum Lock Time (MLT) has
decreased in value. For long time gaps between messages, such as from a radio outage, extra steps should be taken on the rover to
safeguard against missed cycle slips.

Table 3.4-3. SBAS PRN Codes, Data Fields DF009, DF038

SBAS GPS/GLONASS SBAS GPS/GLONASS SBAS GPS/GLONASS
Code Satellite ID Code Satellite ID Code Satellite ID
120 40 127 47 134 54
121 41 128 48 135 55
122 42 129 49 136 56
123 43 130 50 137 57
124 44 131 51 138 58
125 45 132 52
126 46 133 53

3-37
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
Table 3.4-4. Carrier Smoothing Interval of Code Phase, DF008 and DF037

Indicator Smoothing Interval

000 (0) No smoothing
001 (1) < 30 s
010 (2) 30-60 s
011 (3) 1-2 min
100 (4) 2-4 min
101 (5) 4-8 min
110 (6) >8 min
111 (7) Unlimited smoothing interval

3-38
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
Table 3.4-5. GLONASS Carrier Frequencies in L1 and L2 Bands
Satellite Frequency No. of channel Nominal value of frequency in Nominal value of frequency in
Channel Indicator L1 Band, MHz L2 Band, MHz
0 -07 1598.0625 1242.9375
1 -06 1598.6250 1243.3750
2 -05 1599.1875 1243.8125
3 -04 1599.7500 1244.2500
4 -03 1600.3125 1244.6875
5 -02 1600.8750 1245.1250
6 -01 1601.4375 1245.5625
7 00 1602.0 1246.0
8 01 1602.5625 1246.4375
9 02 1603.125 1246.875
10 03 1603.6875 1247.3125
11 04 1604.25 1247.75
12 05 1604.8125 1248.1875
13 06 1605.375 1248.625
14 07 1605.9375 1249.0625
15 08 1606.5 1249.5
16 09 1607.0625 1249.9375
17 10 1607.625 1250.375
18 11 1608.1875 1250.8125
19 12 1608.75 1251.25
20 13 1609.3125 1251.6875

3-39
 RTCM 10403.1

3.5 Messages
© RTCM – Not for reproduction or redistribution
This section describes the messages. Each message contains a specific set of data fields, sometimes repeated, as in the case where
information on several satellites is provided. The data fields are broadcast in the order listed. Multi-byte values are expressed with
the most significant byte transmitted first and the least significant byte transmitted last. Unlike version 2 of the SC-104 standard
(RTCM 10402.x), there is no reversal of bits within a byte.

3.5.1 GPS RTK Messages

Tables 3.5-1 through 3.5-5 provide the contents of the GPS real-time kinematic (RTK) messages, which are based on raw data. From
these data, valid RINEX files can be obtained, although when the Pseudorange Modulus Ambiguity (DF014, DF044) is not provided,
ephemeris and clock information will be required to make the conversion. As a consequence, this set of messages offers a high level
of interoperability and compatibility with standard surveying practices. If GPS RTK Messages (1001-1004) are used in a Network
RTK application, their content representing L1 and L2 PhaseRanges might be altered by correcting for antenna phase center variations
(see also 3.1.6). However the properties of the PhaseRanges have to be indicated properly with an Antenna Description message.
Note: observations corrected for antenna phase center variations are no longer compatible with RINEX standard definition.

Table 3.5-1. Contents of the Message Header, Types 1001, 1002, 1003, 1004: GPS RTK Messages

DATA FIELD DF DATA NO. OF

NUMBER TYPE BITS
Message Number (e.g.,“1001”= 0011 1110 1001) DF002 uint12 12
Reference Station ID DF003 uint12 12
GPS Epoch Time (TOW) DF004 uint30 30
Synchronous GNSS Flag DF005 bit(1) 1
No. of GPS Satellite Signals Processed DF006 uint5 5
GPS Divergence-free Smoothing Indicator DF007 bit(1) 1
GPS Smoothing Interval DF008 bit(3) 3
TOTAL 64

3-40
 RTCM 10403.1

The Type 1001 Message supports single-frequency RTK operation. It does not include an indication of the satellite carrier-to-noise
© RTCM – Not for reproduction or redistribution
ratio as measured by the reference station.

Table 3.5-2. Contents of the Satellite-Specific Portion of a Type 1001 Message, Each Satellite – GPS Basic RTK, L1 Only

DATA FIELD DF DATA NO. OF

NUMBER TYPE BITS
GPS Satellite ID DF009 uint6 6
GPS L1 Code Indicator DF010 bit(1) 1
GPS L1 Pseudorange DF011 uint24 24
GPS L1 PhaseRange – L1 Pseudorange DF012 int20 20
GPS L1 Lock time Indicator DF013 uint7 7
TOTAL 58

3-41
 RTCM 10403.1

The Type 1002 Message supports single-frequency RTK operation, and includes an indication of the satellite carrier-to-noise (CNR)
© RTCM – Not for reproduction or redistribution
as measured by the reference station. Since the CNR does not usually change from measurement to measurement, this message type
can be mixed with the Type 1001, and used primarily when a satellite CNR changes, thus saving broadcast link throughput.

Table 3.5-3. Contents of the Satellite-Specific Portion of a Type 1002 Message, Each Satellite – GPS Extended RTK, L1 Only

DATA FIELD DF DATA NO. OF

NUMBER TYPE BITS
GPS Satellite ID DF009 uint6 6
GPS L1 Code Indicator DF010 bit(1) 1
GPS L1 Pseudorange DF011 uint24 24
GPS L1 PhaseRange – L1 Pseudorange DF012 int20 20
GPS L1 Lock time Indicator DF013 uint7 7
GPS Integer L1 Pseudorange Modulus DF014 uint8 8
Ambiguity
GPS L1 CNR DF015 uint8 8
TOTAL 74

3-42
 RTCM 10403.1

The Type 1003 Message supports dual-frequency RTK operation, but does not include an indication of the satellite carrier-to-noise
© RTCM – Not for reproduction or redistribution
(CNR) as measured by the reference station.

Table 3.5-4. Contents of the Satellite-Specific Portion of a Type 1003 Message, Each Satellite – GPS Basic RTK, L1 & L2

DATA FIELD DF DATA NO. OF

NUMBER TYPE BITS
GPS Satellite ID DF009 uint6 6
GPS L1 Code Indicator DF010 bit(1) 1
GPS L1 Pseudorange DF011 uint24 24
GPS L1 PhaseRange – L1 Pseudorange DF012 int20 20
GPS L1 Lock time Indicator DF013 uint7 7
GPS L2 Code Indicator DF016 bit(2) 2
GPS L2-L1 Pseudorange Difference DF017 int14 14
GPS L2 PhaseRange – L1 Pseudorange DF018 int20 20
GPS L2 Lock time Indicator DF019 uint7 7
TOTAL 101

3-43
 RTCM 10403.1

The Type 1004 Message supports dual-frequency RTK operation, and includes an indication of the satellite carrier-to-noise (CNR) as
© RTCM – Not for reproduction or redistribution
measured by the reference station. Since the CNR does not usually change from measurement to measurement, this message type can
be mixed with the Type 1003, and used only when a satellite CNR changes, thus saving broadcast link throughput.

Table 3.5-5. Contents of the Satellite-Specific Portion of a Type 1004 Message, Each Satellite – GPS Extended RTK, L1 & L2

DATA FIELD DF DATA NO. OF

NUMBER TYPE BITS
GPS Satellite ID DF009 uint6 6
GPS L1 Code Indicator DF010 bit(1) 1
GPS L1 Pseudorange DF011 uint24 24
GPS L1 PhaseRange – L1 Pseudorange DF012 int20 20
GPS L1 Lock time Indicator DF013 uint7 7
GPS Integer L1 Pseudorange Modulus DF014 uint8 8
Ambiguity
GPS L1 CNR DF015 uint8 8
GPS L2 Code Indicator DF016 bit(2) 2
GPS L2-L1 Pseudorange Difference DF017 int14 14
GPS L2 PhaseRange – L1 Pseudorange DF018 int20 20
GPS L2 Lock time Indicator DF019 uint7 7
GPS L2 CNR DF020 uint8 8
TOTAL 125

3-44
 RTCM 10403.1

3.5.2 Stationary Antenna Reference Point Messages

© RTCM – Not for reproduction or redistribution
Message Type 1005 (see Table 3.5-6) provides the earth-centered, earth-fixed (ECEF) coordinates of the antenna reference point
(ARP) for a stationary reference station. No height above a monument is provided.

Message Type 1006 (see Table 3.5-7) provides all the same information as Message Type 1005, but additionally provides the height of
the ARP above a survey monument.

These messages are designed for GPS operation, but are equally applicable to GLONASS and the future Galileo, and system
identification bits are reserved for them.

The phase center is not a point in space that can be used as a standard reference. For one thing, it varies with frequency. In addition,
the location of L1 phase center is strongly dependent on the antenna calibration method used during the calibration process.
Therefore, the location of the L1 phase center may vary between different calibration tables for the same antenna model. Message
Types 1005 and 1006 avoid the phase center problem by utilizing the Antenna Reference Point, which is used throughout the
International GPS Service (IGS).

Message Types 1005 and 1006 contain the coordinates of the installed antenna’s ARP in Earth-Center-Earth-Fixed (ECEF)
coordinates -- datum definitions are not yet supported. The coordinates always refer to a physical point on the antenna, typically the
bottom of the antenna mounting surface.

3-45
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
Table 3.5-6. Contents of the Type 1005 Message – Stationary Antenna Reference Point, No Height Information

DATA FIELD DF DATA NO. OF

NUMBER TYPE BITS
Message Number (“1005”= 0011 1110 1101) DF002 uint12 12
Reference Station ID DF003 uint12 12
Reserved for ITRF Realization Year DF021 uint6 6
GPS Indicator DF022 bit(1) 1
GLONASS Indicator DF023 bit(1) 1
Reserved for Galileo Indicator DF024 bit(1) 1
Reference-Station Indicator DF141 bit(1) 1
Antenna Reference Point ECEF-X DF025 int38 38
Single Receiver Oscillator Indicator DF142 bit(1) 1
Reserved DF001 bit(1) 1
Antenna Reference Point ECEF-Y DF026 int38 38
Reserved DF001 bit(2) 2
Antenna Reference Point ECEF-Z DF027 int38 38
TOTAL 152

3-46
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
Table 3.5-7. Contents of the Type 1006 Message – Stationary Antenna Reference Point, with Height Information

DATA FIELD DF DATA NO. OF

NUMBER TYPE BITS
Message Number (“1006”= 0011 1110 1110) DF002 uint12 12
Reference Station ID DF003 uint12 12
Reserved for ITRF Realization Year DF021 uint6 6
GPS Indicator DF022 bit(1) 1
GLONASS Indicator DF023 bit(1) 1
Reserved for Galileo Indicator DF024 bit(1) 1
Reference-Station Indicator DF141 bit(1) 1
Antenna Reference Point ECEF-X DF025 int38 38
Single Receiver Oscillator Indicator DF142 bit(1) 1
Reserved DF001 bit(1) 1
Antenna Reference Point ECEF-Y DF026 int38 38
Reserved DF001 bit(2) 2
Antenna Reference Point ECEF-Z DF027 int38 38
Antenna Height DF028 uint16 16
TOTAL 168

3-47
 RTCM 10403.1

3.5.3 Antenna Description Messages

© RTCM – Not for reproduction or redistribution

Table 3.5-8 provides an ASCII descriptor of the reference station antenna. As noted for DF031 in Table 3.4-1, the International GPS
Service (IGS) Central Bureau convention will be used most of the time, since it is universally accessible.

Table 3.5-9 provides the same information, plus the antenna serial number, which removes any ambiguity about the model number or
production run.

The Committee adopted the naming convention from the IGS equipment-naming table as supplied by the International GPS Service
Central Bureau (IGS CB). This table provides a unique antenna descriptor for antennas used for high-precision surveying type
applications, which is utilized in the Antenna Descriptor (DF030). IGS limits the number of characters to 20 at this time, but the
standard allows more characters for future extension.

The Antenna Setup ID (DF031) is a parameter for use by the service provider to indicate the particular reference station-antenna
combination. "0" for this value means that the values of a standard model type calibration should be used. The Antenna Serial
Number (DF033) is the individual antenna serial number as issued by the manufacturer of the antenna

Table 3.5-8. Contents of the Type 1007 Message – Antenna Descriptor

DATA FIELD DF DATA NO. OF NOTES

NUMBER TYPE BITS
Message Number (“1007”=0011 1110 1111) DF002 uint12 12
Reference Station ID DF003 uint12 12
Descriptor Counter N DF029 uint8 8 N ≤ 31
Antenna Descriptor DF030 char8(N) 8*N
Antenna Setup ID DF031 uint8 8
TOTAL 40+8*N

3-48
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
Table 3.5-9. Contents of the Type 1008 Message – Antenna Descriptor & Serial Number

DATA FIELD DF DATA NO. OF NOTES

NUMBER TYPE BITS
Message Number (“1008”=0011 1111 0000) DF002 uint12 12
Reference Station ID DF003 uint12 12
Descriptor Counter N DF029 uint8 8
Antenna Descriptor DF030 char8(N) 8*N N ≤ 31
Antenna Setup ID DF031 uint8 8
Serial Number Counter M DF032 uint8 8
Antenna Serial Number DF033 char8(M) 8*M M ≤ 31
TOTAL 48+
8*(M+N)

3-49
 RTCM 10403.1

3.5.4 GLONASS RTK Observables

© RTCM – Not for reproduction or redistribution
Tables 3.5-9 through 3.5-14 provide the contents of the GLONASS real-time kinematic (RTK) messages, which are based on raw
data. From these data, complete RINEX files can be obtained. As a consequence, this set of messages offers a high level of
interoperability and compatibility with standard surveying practices. The service provider using these messages should also transmit
an Antenna Reference Point message (Type 1005 or 1006) and an Antenna Descriptor message (Type 1007 or 1008). A provider of
combined GPS-GLONASS service should provide completely independent sets of Observables. In addition, if the time tags of the
GPS and GLONASS RTK data are synchronized, the Synchronous GNSS Flag should be used to connect the entire RTK data block.

Table 3.5-10 Contents of the Message Header, Types 1009 through 1012: GLONASS RTK Messages

DATA FIELD DF DATA NO. OF

NUMBER TYPE BITS
Message Number (“1009”=0011 1111 0001) DF002 uint12 12
Reference Station ID DF003 uint12 12

GLONASS Epoch Time (tk) DF034 uint27 27

Synchronous GNSS Flag DF005 bit(1) 1

No. of GLONASS Satellite Signals Processed DF035 uint5 5
GLONASS Divergence-free Smoothing Indicator DF036 bit(1) 1
GLONASS Smoothing Interval DF037 bit(3) 3
TOTAL 61

3-50
 RTCM 10403.1

The Type 1009 Message supports single-frequency RTK operation, but does not include an indication of the satellite carrier-to-noise
© RTCM – Not for reproduction or redistribution
(CNR) as measured by the reference station.

Table 3.5-11.
Contents of the Satellite-Specific Portion of a Type 1009 Message, Each Satellite – GLONASS Basic RTK, L1 Only

DATA FIELD DF DATA NO. OF

NUMBER TYPE BITS
GLONASS Satellite ID (Satellite Slot Number) DF038 uint6 6
GLONASS Code Indicator DF039 bit(1) 1
GLONASS Satellite Frequency Channel Number DF040 uint5 5
GLONASS L1 Pseudorange DF041 uint25 25
GLONASS L1 PhaseRange – L1 Pseudorange DF042 int20 20
GLONASS L1 Lock time Indicator DF043 uint7 7
TOTAL 64

3-51
 RTCM 10403.1

The Type 1010 Message supports single-frequency RTK operation, and includes an indication of the satellite carrier-to-noise (CNR)
© RTCM – Not for reproduction or redistribution
as measured by the reference station. Since the CNR does not usually change from measurement to measurement, this message type
can be mixed with the Type 1009, and used only when a satellite CNR changes, thus saving broadcast link throughput.

Table 3.5-12.
Contents of the Satellite-Specific Portion of a Type 1010 Message, Each Satellite – GLONASS Extended RTK, L1 Only

DATA FIELD DF DATA NO. OF

NUMBER TYPE BITS
GLONASS Satellite ID (Satellite Slot Number) DF038 uint6 6
GLONASS L1 Code Indicator DF039 bit(1) 1
GLONASS Satellite Frequency Channel Number DF040 uint5 5
GLONASS L1 Pseudorange DF041 uint25 25
GLONASS L1 PhaseRange – L1 Pseudorange DF042 int20 20
GLONASS L1 Lock time Indicator DF043 uint7 7
GLONASS Integer L1 Pseudorange Modulus DF044 uint7 7
Ambiguity
GLONASS L1 CNR DF045 uint8 8
TOTAL 79

3-52
 RTCM 10403.1

The Type 1011 Message supports dual-frequency RTK operation, but does not include an indication of the satellite carrier-to-noise
© RTCM – Not for reproduction or redistribution
(CNR) as measured by the reference station.

Table 3.5-13.
Contents of the Satellite-Specific Portion of a Type 1011 Message, Each Satellite – GLONASS Basic RTK, L1 & L2

DATA FIELD DF DATA NO. OF

NUMBER TYPE BITS
GLONASS Satellite ID (Satellite Slot Number) DF038 uint6 6
GLONASS L1 Code Indicator DF039 bit(1) 1
GLONASS Satellite Frequency Channel Number DF040 uint5 5
GLONASS L1 Pseudorange DF041 uint25 25
GLONASS L1 PhaseRange – L1 Pseudorange DF042 int20 20
GLONASS L1 Lock time Indicator DF043 uint7 7
GLONASS L2 Code Indicator DF046 bit(2) 2
GLONASS L2-L1 Pseudorange Difference DF047 uint14 14
GLONASS L2 PhaseRange – L1 Pseudorange DF048 int20 20
GLONASS L2 Lock time Indicator DF049 uint7 7
TOTAL 107

3-53
 RTCM 10403.1

The Type 1012 Message supports dual-frequency RTK operation, and includes an indication of the satellite carrier-to-noise (CNR) as
© RTCM – Not for reproduction or redistribution
measured by the reference station. Since the CNR does not usually change from measurement to measurement, this message type can
be mixed with the Type 1011, and used only when a satellite CNR changes, thus saving broadcast link throughput.

Table 3.5-14.
Contents of the Satellite-Specific Portion of a Type 1012 Message, Each Satellite – GLONASS Extended RTK, L1 & L2

DATA FIELD DF DATA NO. OF

NUMBER TYPE BITS
GLONASS Satellite ID (Satellite Slot Number) DF038 uint6 6
GLONASS L1 Code Indicator DF039 bit(1) 1
GLONASS Satellite Frequency Channel Number DF040 uint5 5
GLONASS L1 Pseudorange DF041 uint25 25
GLONASS L1 PhaseRange – L1 Pseudorange DF042 int20 20
GLONASS L1 Lock time Indicator DF043 uint7 7
GLONASS Integer L1 Pseudorange Modulus DF044 uint7 7
Ambiguity
GLONASS L1 CNR DF045 uint8 8
GLONASS L2 Code Indicator DF046 bit(2) 2
GLONASS L2-L1 Pseudorange Difference DF047 uint14 14
GLONASS L2 PhaseRange – L1 Pseudorange DF048 int20 20
GLONASS L2 Lock time Indicator DF049 uint7 7
GLONASS L2 CNR DF050 uint8 8
TOTAL 130

3-54
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
3.5.5 System Parameters
The complete list of record announcements summarizes all messages transmitted by the particular reference station.

3.5-15 Contents of the Type 1013 Message, System Parameters

DATA FIELD DF DATA NO. OF

NUMBER TYPE BITS
Message Number DF002 uint12 12
Reference Station ID DF003 uint12 12
Modified Julian Day (MJD) Number DF051 uint16 16
Seconds of Day (UTC) DF052 uint17 17
No. of Message ID Announcements to Follow (Nm) DF053 uint5 5
Leap Seconds, GPS-UTC DF054 uint8 8
Message ID #1 DF055 uint12 12
Message #1 Sync Flag DF056 bit(1) 1
Message #1 Transmission Interval DF057 uint16 16
Message ID #2 DF055 uint12 12
Message #2 Sync Flag DF056 bit(1) 1
Message #2 Transmission Interval DF057 uint16 16
(Repeat until Nm sets)
TOTAL 70+29* Nm

3-55
 RTCM 10403.1

3.5.6 GPS Network RTK Correction Messages

© RTCM – Not for reproduction or redistribution

The use of single reference stations to transmit RTK data is limited by the fact that the accuracy and reliability of integer ambiguity
resolution deteriorates with increasing distance from the reference station. A powerful solution to this problem is offered by a
synchronized network of RTK stations. Networks of reference stations mitigate the distance-dependency of RTK solutions. With such
networks, a provider can generate measurement corrections for receivers operating within a large defined region, and this information
can be supplied to the user in a standard format. As the current kinematic and high-accuracy message types 1001-1012 do not support
an efficient use of data from multiple reference stations, new approaches must be developed to facilitate the valuable information
afforded by networks of reference stations.

The standardization of network information and processing models is also necessary to reduce the size of the network RTK
corrections, as well as the satellite-independent error information. A simplified approach of transmitting data from reference station
networks to roving users is utilized below in the form of a new message set capable of supporting reference network operations.

Individual reference stations often support more than one network in a large region. A detailed description of how the message set
below supports these networks is given below. The approach used here provides considerable flexibility for the service provider to
support a wide variety of services within range of a large network of reference stations.

The principle of determining L1 and L2 corrections is defined in Version 2.3 (RTCM Paper 136-2001/SC104-STD – now designated
as RTCM 10402.3) as 4.3.18 section B. However version 2.3 is defined for any type of geodetic carrier phase observation, while
version 3 assumes clock adjusted carrier phase observations (see RTCM Paper 30-2004/SC104-STD or RTCM 10402.3 section 3.1.4).

The Correction Difference components have been split into a dispersive and a non-dispersive part. The dispersive Correction
Difference is also called ionospheric Correction Difference, after its contributor. The opposite, the non-dispersive, is also called
ionosphere-free Correction Difference or geometric Correction Difference, recognizing that it is not purely due to geometry because of
the tropospheric contribution.

The L1 Correction (L1C) and the L2 Correction (L2C) can be determined in general by:
c
L1C S = s S − Φ S ,1 ( t ) − N S ,1 + t S ,1 + A S ,1 , and
f1

c
L 2C S = s S − Φ S ,2 (t ) − N S , 2 + t S , 2 + A S , 2 , with
f2

sS = Computed Geometric Range in meters between the ARP of station S and satellite

3-56
 RTCM 10403.1

Φ S ,1 ( t ) = Phase Range Measurement in meters for station S, L1 (similarly for L2)

© RTCM – Not for reproduction or redistribution
c = Integer Ambiguity part scaled to meters, L1 (similarly for L2). The integer can be arbitrarily chosen for
N S ,1
f1
an initial measurement in order to bring the resulting Phase Correction within range of the field
definition. For Network RTK the all-integer ambiguities have to be brought onto a common integer
level. Therefore all values per-satellite and per-frequency have to be synchronized between reference
stations.
t S ,1 , t S , 2 = Receiver clock term for the respective frequency of Phase Range Measurement

AS ,1 , AS , 2 = Antenna Offset and Phase Center Variation Correction for the respective frequency; the service provider
has to ensure that the antenna phase center corrections does not introduce biases. (See also Section
3.1.6, ”Proper Handling of Antenna Phase Center Variation Corrections”)
f1 = L1 carrier frequency
f2 = L2 carrier frequency
Satellite and relativistic clock term have been neglected in the given formula. These terms cancel sufficiently in the inter-station
single difference. A difference of the clock between both station receivers remains in the Correction Differences. However, the value
common to all Correction Differences for every Master-Auxiliary Reference Station pair can be estimated and removed from the
Correction Differences. These inter-station clock biases are also minimized for typical Network RTK applications. The clock
difference term between reference stations in the L1 and L2 Correction Difference may be treated independently. Therefore clock
effects may influence Ionospheric and Geometric Correction Differences. Nevertheless, this approach chosen is sufficient for general
positioning approaches, since residual clock effects are removed in double differences. Proper treatment of antenna phase center
corrections are crucial to avoid unrecoverable biases in Correction Differences (See also section 3.1.6, “Proper handling of antenna
phase center variation corrections”).

The L1 Correction Difference (L1CD) is calculated as the single-difference of the “Auxiliary Reference Station Carrier Phase
Correction” minus “Master Reference Station Carrier Phase Correction”.
L1CD = L1C A − L1C M
An alternate way of calculation is to carry out:
c
L 1CD = Δ s AM ( t ) − ΔΦ AM ,1 (t ) − ⋅ ΔN AM ,1 + Δ t AM ,1 + Δ A AM ,1
f1

3-57
 RTCM 10403.1

ΔΦ AM ,1 (t ) = Single-differenced Phase Ranges of Auxiliary Reference Station A minus Master Reference Station M
© RTCM – Not for reproduction or redistribution
Δs AM (t ) = Single-differenced slope distances between Satellite and reference station antenna of Auxiliary
Reference Station A minus Master Reference Station M
c
⋅ ΔN AM ,1 = Single-differenced Integer Ambiguity values of Auxiliary Reference Station A minus Master Reference
f1
Station M scaled to meters. In practice only double-differenced Integer Ambiguities can be fixed due to
insufficient modeling of various error sources. The single-differenced Integer Ambiguities for a
particular Auxiliary Reference Station minus Master Reference Station might incorporate an arbitrary
Integer number. The number is arbitrary but common for all satellites and therefore is observed as a
common clock error.
Δt AM ,1 = Estimated single differenced receiver clock term on L1.

ΔAAM ,1 = Single-differenced antenna offset and PCV on L1

Similarly, the L2 Correction Difference (L2CD) is computed as follows:

c
L 2CD = Δs AM (t ) − ΔΦ AM , 2 (t ) − ⋅ ΔN AM , 2 + Δt AM , 2 + ΔAAM , 2
f2

Correct integer ambiguity resolution between reference stations is only possible on a double-difference basis. The correct set of
double-differenced integer ambiguities is unique for a given data set. A common Integer Ambiguity Level indicates that Correction
Differences are derived from a homogenous solution satisfying the double-difference requirement between all involved reference
stations.

Correction Differences are typically based on integer-adjusted raw observation data. Certain rules must be observed to preserve the
correctness of the double-difference requirement. In particular, introducing a cycle for one specific satellite-station combination must
be compensated for by adjusting other satellite-station combinations in order to maintain a homogenous solution.

However, the Correction Differences are defined as single-differenced values between two reference stations. Therefore the
introduction of a fixed number of cycles for the observations of one satellite for all reference stations throughout the whole network
will not show up in the Correction Differences. Changing all observations for a specific reference station by a fixed number of cycles
will change all Correction Differences. The number of introduced cycles will be absorbed by the clock bias estimation in the rover.

3-58
 RTCM 10403.1

Two subsets of a network might satisfy the requirement of correct double-differenced Integer Ambiguities, without necessarily being
© RTCM – Not for reproduction or redistribution
on the same Integer Ambiguity Level since the choices of integers are arbitrary. As soon as a reference station has common Integer
Ambiguity Levels with two subsets of a network these two subsets can be joined and brought to the same Integer Ambiguity Level.
These two subsets will then form one subnetwork with the same Integer Ambiguity Level. If circumstances are such that not enough
satellites with correct fixed Integer Ambiguities are available for one reference station or a number of reference stations connecting
two subsets of a network, it is advisable to treat the subsets separately. Both subsets will be considered to form different subnetworks
with different Integer Ambiguity Levels indicated by assigning different subnetwork ID’s.

The Correct Integer Ambiguity Level L1-L2 widelane indicates that only the L1-L2 widelane is correctly fixed. The individual L1
and L2 integer ambiguities may contain integer offsets. The L1 and the L2 offsets will be the same.

Changing the Ambiguity Status Flag from 3 to 2, 3 to 1, or 2 to 1 without increasing the Non Sync Count indicates that the previous
good guess of the integer ambiguity turned out to be the correct integer and the correctness of the integer has been approved by the
networking software.

Unrecoverable cycle slips might occur for permanent reference station applications as well. If the Integer Ambiguity for the satellite
with the cycle slip is on the Integer Ambiguity Level (see also the discussion above on Integer Ambiguity Level), the unrecoverable
cycle will cause the loss of the Integer Ambiguity Level for the specific satellite, reference station, and frequency. Correction
Difference information for this specific combination needs proper flagging in the Ambiguity Status Flag and increasing the Non Sync
Count. The Non Sync Count must be increased if there is an unrecoverable cycle slip in a Correction Difference that is not on the
Integer Ambiguity Level. Frequent cycle slips may cause problems with the counter’s range. The Non Sync Count should not be
increased more than once per minute in order to reduce counter roll-overs. Satellites with cycle slips more frequent than once per
minute should not be transmitted.

Arbitrarily fixed, and therefore possibly non-correct integers, provide only sufficient information when the identical integers are used
for a certain amount of time. An increase of the Non Sync Count will be associated with Ambiguity Status Flag of 3. In the
continuation of the operation the networking software might prove that the arbitrarily chosen integers are actually on the correct
integer ambiguity level. Under these circumstances the Ambiguity Status Flag might be changed to the appropriate status of 1 or 2.
This is discussed further in Appendix A.1

3-59
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
Table 3.5-16 Contents of the Network Auxiliary Station Data Message 1014

DATA FIELD DF DATA NO. OF NOTES

NUMBER TYPE BITS
Message Number DF002 uint12 12 1014
Network ID DF059 uint8 8
Subnetwork ID DF072 uint4 4
Number of Auxiliary Stations Transmitted DF058 uint5 5 0 - 31
Master Reference Station ID DF060 unit12 12
Auxiliary Reference Station ID DF061 uint12 12
Aux-Master Delta Latitude DF062 int20 20
Aux-Master Delta Longitude DF063 int21 21
Aux-Master Delta Height DF064 int23 23
TOTAL 117

3-60
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
Table 3.5-17 Contents of Header Network RTK -- Messages 1015, 1016 or 1017

DATA FIELD DF DATA NO. OF NOTES

NUMBER TYPE BITS
Message Number DF002 uint12 12 1015, 1016 or 1017
Network ID DF059 uint8 8
Subnetwork ID DF072 uint4 4
GPS Epoch Time (GPS TOW) DF065 uint23 23
GPS Multiple Message Indicator DF066 bit(1) 1
Master Reference Station ID DF060 uint12 12
Auxiliary Reference Station ID DF061 uint12 12
# of GPS Sats DF067 uint4 4
TOTAL 76

Table 3.5-18 Contents of Data Block for GPS Ionospheric Correction Differences 1015

DATA FIELD DF DATA NO. OF NOTES

NUMBER TYPE BITS
GPS Satellite ID DF068 uint6 6
GPS Ambiguity Status Flag DF074 bit(2) 2
GPS Non Sync Count DF075 uint3 3
GPS Ionospheric Carrier Phase Correction DF069 int17 17
Difference
TOTAL 28

3-61
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
Table 3.5-19 Contents of Data Block for GPS Geometric Correction Differences 1016

DATA FIELD DF DATA NO. OF NOTES

NUMBER TYPE BITS
GPS Satellite ID DF068 uint6 6
GPS Ambiguity Status Flag DF074 bit(2) 2
GPS Non Sync Count DF075 uint3 3
GPS Geometric Carrier Phase Correction DF070 int17 17
Difference
GPS IODE DF071 uint8 8
TOTAL 36

Table 3.5-20 Contents of Data Block for GPS Combined Geometric and Ionospheric Correction Differences 1017

DATA FIELD DF DATA NO. OF NOTES

NUMBER TYPE BITS
GPS Satellite ID DF068 uint6 6
GPS Ambiguity Status Flag DF074 bit(2) 2
GPS Non Sync Count DF075 uint3 3
GPS Geometric Carrier Phase Correction DF070 int17 17
Difference
GPS IODE DF071 uint8 8
GPS Ionospheric Carrier Phase Correction DF069 int17 17
Difference
TOTAL 53

3-62
 RTCM 10403.1

3.5.7 GPS Ephemerides

© RTCM – Not for reproduction or redistribution
The GPS ephemeris message contains GPS satellite ephemeris information. This message could be broadcast in the event that the
IODC does not match the IODE, which would require the differential reference station to base corrections on the previous good
satellite ephemeris. This would allow the user equipment just entering the differential system to utilize the corrections being broadcast
for that ephemeris, and would support the use of the satellite for differential navigation despite the fact that the satellite ephemeris was
in error. It is anticipated that this message type would be broadcast every 2 minutes or so while this condition persisted. The schedule
would be maintained until the satellite broadcast was corrected, or until the satellite dropped below the coverage area of the reference
station.

Another use of the message is to assist user receivers to quickly acquire satellites. For example, if the user receiver has access to a
wireless service with this message, rather than waiting until one satellite has been acquired and its almanac data processed, it can
utilize the ephemeris information immediately.

All data fields have the same number of bits, the same scale factor and units defined in GPS SPS Signal Specification, Sections 2.4.3
and 2.4.4. The name of the data fields are also kept as close as possible to those defined in GPS SPS Signal Specification document
for cross-reference.

Table 3.5-21. Contents of GPS Satellite Ephemeris Data, Message Type 1019

DATA FIELD DF DATA NO. OF NOTES

NUMBER TYPE BITS
Message Number DF002 uint12 12 1019
GPS Satellite ID DF009 uint6 6
GPS Week Number DF076 uint10 10 0 - 1023
GPS SV ACCURACY DF077 uint4 4 See GPS SPS Signal Specification, 2.4.3
GPS CODE ON L2 DF078 bit(2) 2 00 = Reserved
01 = P code on
10 = C/A code on
11 = L2C on
GPS IDOT DF079 int14 14 See GPS SPS Signal Specification, 2.4.3
GPS IODE DF071 uint8 8 See GPS SPS Signal Specification, 2.4.3

3-63
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DATA FIELD DF DATA NO. OF NOTES
NUMBER TYPE BITS
GPS toc DF081 uint16 16 See GPS SPS Signal Specification, 2.4.3

GPS af2 DF082 int8 8 See GPS SPS Signal Specification, 2.4.3

GPS af1 DF083 int16 16 See GPS SPS Signal Specification, 2.4.3

GPS af0 DF084 int22 22 See GPS SPS Signal Specification, 2.4.3
GPS IODC DF085 uint10 10 See GPS SPS Signal Specification, 2.4.3
GPS Crs DF086 int16 16 See GPS SPS Signal Specification, 2.4.3
GPS Δn (DELTA n) DF087 int16 16 See GPS SPS Signal Specification, 2.4.3
GPS M0 DF088 int32 32 See GPS SPS Signal Specification, 2.4.3
GPS Cuc DF089 int16 16 See GPS SPS Signal Specification, 2.4.3
GPS Eccentricity (e) DF090 uint32 32 See GPS SPS Signal Specification, 2.4.3
GPS Cus DF091 int16 16 See GPS SPS Signal Specification, 2.4.3
GPS (A)1/2 DF092 uint32 32 See GPS SPS Signal Specification, 2.4.3
GPS toe DF093 uint16 16 See GPS SPS Signal Specification, 2.4.3
GPS Cic DF094 int16 16 See GPS SPS Signal Specification, 2.4.3
GPS Ω0 (OMEGA)0 DF095 int32 32 See GPS SPS Signal Specification, 2.4.3
GPS Cis DF096 int16 16 See GPS SPS Signal Specification, 2.4.3
GPS i0 DF097 int32 32 See GPS SPS Signal Specification, 2.4.3
GPS Crc DF098 int16 16 See GPS SPS Signal Specification, 2.4.3
GPS ω (Argument of Perigee) DF099 int32 32 See GPS SPS Signal Specification, 2.4.3
GPS OMEGADOT (Rate of Right Ascension) DF100 int24 24 See GPS SPS Signal Specification, 2.4.3
GPS tGD DF101 int8 8 See GPS SPS Signal Specification, 2.4.3

3-64
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DATA FIELD DF DATA NO. OF NOTES
NUMBER TYPE BITS
GPS SV HEALTH DF102 uint6 6 See GPS SPS Signal Specification, 2.4.3
GPS L2 P data flag DF103 bit(1) 1 0: L2 P-Code NAV data ON
1: L2 P-Code NAV data OFF
GPS Fit Interval DF137 bit(1) 1 See GPS SPS Signal Specification, 2.4.3
TOTAL 488

3-65
 RTCM 10403.1

3.5.8 GLONASS Ephemerides

© RTCM – Not for reproduction or redistribution
The GLONASS ephemeris message contains GLONASS satellite ephemeris information. One use of the message is to assist user
receivers to quickly acquire satellites. For example, if the user receiver has access to a wireless service that distributes this message, it
can utilize the ephemeris information immediately, rather than waiting until one satellite has been acquired and its almanac data
processed. The GLONASS ephemeris message contains GLONASS satellite ephemeris information. This message could be broadcast
in the event that an anomaly in new ephemeris data set is detected, which would require the differential reference station to base
corrections on the previous good satellite ephemeris. This would allow the user equipment just entering the differential system to
utilize the corrections being broadcast for that ephemeris, and would support the use of the satellite for differential navigation despite
the fact that the satellite ephemeris was in error. It is anticipated that this message type would be broadcast every 2 minutes or so
while this condition persisted. The schedule would be maintained until the satellite broadcast was corrected, or until the satellite
dropped below the coverage area of the reference station.

The GLONASS ephemeris message contains GLONASS satellite ephemeris information. This message could be broadcast in the
event that an anomaly in new ephemeris data set is detected, which would require the differential reference station to base corrections
on the previous good satellite ephemeris. This would allow the user equipment just entering the differential system to utilize the
corrections being broadcast for that ephemeris, and would support the use of the satellite for differential navigation despite the fact
that the satellite ephemeris was in error. It is anticipated that this message type would be broadcast every 2 minutes or so while this
condition persisted. The schedule would be maintained until the satellite broadcast was corrected, or until the satellite dropped below
the coverage area of the reference station.

All data fields have the same number of bits, the same scale factor and units defined in the 5th edition of GLONASS ICD, which
contains the most recent information about GLONASS-M navigation data. This document can be downloaded from the official source
of information about GLONASS at the website http://www.glonass-center.ru, under the heading “ICD 2002”. The names of the data
fields are also kept as close as possible to those defined in the GLONASS ICD for cross-referencing.

Table 3.5-22. Contents of GLONASS Satellite Ephemeris Data, Message Type 1020

DATA FIELD DF DATA NO. OF NOTES

NUMBER TYPE BITS
Message Number DF002 uint12 12 1020
GLONASS Satellite ID (Satellite Slot Number) DF038 uint6 6
GLONASS Satellite Frequency Channel Number DF040 uint5 5
GLONASS almanac health (Cn word) DF104 bit(1) 1 See GLONASS ICD Version 5.0

3-66
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DATA FIELD DF DATA NO. OF NOTES
NUMBER TYPE BITS
GLONASS almanac health availability indicator DF105 bit(1) 1 See GLONASS ICD Version 5.0
GLONASS P1 DF106 bit(2) 2 See GLONASS ICD Version 5.0
GLONASS tk DF107 bit(12) 12 See GLONASS ICD Version 5.0
GLONASS MSB of Bn word DF108 bit(1) 1 See GLONASS ICD Version 5.0
GLONASS P2 DF109 bit(1) 1 See GLONASS ICD Version 5.0
GLONASS tb DF110 uint7 7 See GLONASS ICD Version 5.0
GLONASS xn(tb), first derivative DF111 intS24 24 See GLONASS ICD Version 5.0
GLONASS xn(tb) DF112 intS27 27 See GLONASS ICD Version 5.0
GLONASS xn(tb), second derivative DF113 intS5 5 See GLONASS ICD Version 5.0
GLONASS yn(tb), first derivative DF114 intS24 24 See GLONASS ICD Version 5.0
GLONASS yn(tb) DF115 intS27 27 See GLONASS ICD Version 5.0
GLONASS yn(tb), second derivative DF116 intS5 5 See GLONASS ICD Version 5.0
GLONASS zn(tb), first derivative DF117 intS24 24 See GLONASS ICD Version 5.0
GLONASS zn(tb) DF118 intS27 27 See GLONASS ICD Version 5.0
GLONASS zn(tb), second derivative DF119 intS5 5 See GLONASS ICD Version 5.0
GLONASS P3 DF120 bit(1) 1 See GLONASS ICD Version 5.0
GLONASS γn(tb) DF121 intS11 11 See GLONASS ICD Version 5.0
GLONASS-M P DF122 bit(2) 2 See GLONASS ICD Version 5.0
GLONASS-M ln (third string) DF123 bit(1) 1 See GLONASS ICD Version 5.0
GLONASS τn(tb) DF124 intS22 22 See GLONASS ICD Version 5.0
GLONASS-M Δτn DF125 intS5 5 See GLONASS ICD Version 5.0
GLONASS En DF126 uint5 5 See GLONASS ICD Version 5.0

3-67
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
DATA FIELD DF DATA NO. OF NOTES
NUMBER TYPE BITS
GLONASS-M P4 DF127 bit(1) 1 See GLONASS ICD Version 5.0
GLONASS-M FT DF128 uint4 4 See GLONASS ICD Version 5.0
GLONASS-M NT DF129 uint11 11 See GLONASS ICD Version 5.0
GLONASS-M M DF130 bit(2) 2 See GLONASS ICD Version 5.0
GLONASS The Availability of Additional Data DF131 bit(1) 1 See GLONASS ICD Version 5.0
GLONASS NA DF132 uint11 11 See GLONASS ICD Version 5.0
GLONASS τc DF133 intS32 32 See GLONASS ICD Version 5.0
GLONASS-M N4 DF134 uint5 5 See GLONASS ICD Version 5.0
GLONASS-M τGPS DF135 intS22 22 See GLONASS ICD Version 5.0
GLONASS-M ln (fifth string) DF136 bit(1) 1 See GLONASS ICD Version 5.0
Reserved bit(7) 7
TOTAL 360

Note: GLONASS-M data are valid for GLONASS-M satellites only: refer to the description of data field DF130.

3-68
 RTCM 10403.1

3.5.9 Unicode Text String

© RTCM – Not for reproduction or redistribution

Message type 1029 contains a variable length text string for any displayable information the service provider may want to transmit to
the user. For maximum flexibility, the characters in this message are in the Unicode encoding scheme. Unicode is a system for
providing a unique numeric code for each character in every language, while allowing for support of any subset of the complete code
space. See http://www.unicode.org for the Unicode specification and conformance information.

The characters in this message are in the UTF-8 encoding form to provide transparency for ASCII code points (00h-7Fh). That is, the
128 ASCII characters are encoded in the identical 8-bit form in UTF-8. All other characters are multi-byte and each byte in that
sequence will be in the range 80h-FFh. Therefore, each byte does not necessarily constitute a full character, but is instead referred to
as a “code unit” of a character. The Unicode specification defines how to identify the number of 8-bit code units constituting a
received character and how to handle unknown or ill-formed characters.

Because the length of the string is known, a terminating NULL must not be included.

3-69
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
Table 3.5-23. Contents of the Unicode Text String, Message Type 1029

DATA FIELD DF NUMBER DATA TYPE NO. OF NOTES

BITS
Message Number DF002 uint12 12 1029

Reference Station ID DF003 uint12 12

Modified Julian Day (MJD) Number DF051 uint16 16 (Note 1)

Seconds of Day (UTC) DF052 uint17 17 (Note 1)

Number of Characters to Follow DF138 uint7 7 This represents the number of fully formed Unicode
characters in the message text. It is not necessarily
the number of bytes that are needed to represent the
characters as UTF-8. Note that for some messages it
may not be possible to utilize the full range of this
field, e.g. where many characters require 3 or 4 byte
representations and together will exceed 255 code
units.
Number of UTF-8 Code Units (N) DF139 uint8 8 The length of the message is limited by this field, or
possibly by DF+1 (see previous note).
UTF-8 Character Code Units DF140 utf8(N) 8*N
TOTAL 72+8*N

Note 1 – The time tag used in this message refers to the approximate time of message transmission (the actual time of transmission
may be delayed by buffering). If a different time of applicability is required, the service provider may include that time within the
Unicode message text.

3-70
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution
Example Unicode Text String Message

The following is an example of the Unicode Text String Message represented in hexadecimal with the UTF-8 code units in bold:
D3 00 27 40 50 17 00 84 73 6E 15 1E 55 54 46 2D
38 20 D0 BF D1 80 D0 BE D0 B2 D0 B5 D1 80 D0 BA
D0 B0 20 77 C3 B6 72 74 65 72 ED A3 3B

The parameters of the message are

• Message Number = 1029
• Reference Station ID = 23
• Modified Julian Day (MJD) Number = 132
• Seconds of Day (UTC) = 59100
• Number of Characters to Follow = 21
• Number of UTF-8 Code Units = 30

The message text used in the example is “UTF-8 проверка wörter” (UTF-8 check words) without quotes. The Unicode code points
and character names for this message are:

0055 LATIN CAPITAL LETTER U 0440 CYRILLIC SMALL LETTER ER

0054 LATIN CAPITAL LETTER T 043A CYRILLIC SMALL LETTER KA
0046 LATIN CAPITAL LETTER F 0430 CYRILLIC SMALL LETTER A
002D HYPHEN-MINUS 0020 SPACE
0038 DIGIT EIGHT 0077 LATIN SMALL LETTER W
0020 SPACE 00F6 LATIN SMALL LETTER O WITH DIAERESIS
043F CYRILLIC SMALL LETTER PE 0072 LATIN SMALL LETTER R
0440 CYRILLIC SMALL LETTER ER 0074 LATIN SMALL LETTER T
043E CYRILLIC SMALL LETTER O 0065 LATIN SMALL LETTER E
0432 CYRILLIC SMALL LETTER VE 0072 LATIN SMALL LETTER R
0435 CYRILLIC SMALL LETTER IE

3-71
 RTCM 10403.1

3.6 Proprietary Messages

© RTCM – Not for reproduction or redistribution
The 95 message types from 4001 through 4095 are reserved for proprietary use. Each company or organization may be assigned by
RTCM one message type for proprietary use. The format is similar to the other messages, in that the transport layer is defined in the
same way, and the first data field is a 12-bit message number. Each company is free to define several sub-types of messages, but they
must all utilize the assigned message type.

At the time of printing, the following Proprietary Message types have been assigned. Contact RTCM to acquire a new message type.

Table 3.6-1. Assigned Proprietary Message Types

Message Type Organization Contact

4095 Magellan Navigation Inc. http://www.magellangps.com
4094 Trimble Navigation Ltd. http://www.trimble.com
4093 NovAtel Inc. http://www.novatel.ca
4092 Leica Geosystems http://www.leica-geosystems.com
4091 Topcon Positioning Systems http://www.topconpositioning.com
4090 Geo++ http://www.geopp.de
4089 Septentrio Satellite Navigation http://www.septentrio.com
4088 IfEN GmbH http://www.ifen.com
4087-4001 RESERVED

3-72
 RTCM 10403.1

4 TRANSPORT LAYER
4.1 Description
The transport layer defines the frame architecture for sending or receiving RTCM SC-104 Version 3
messages. The purpose of defining this layer is to ensure that RTCM 10403.1 data can be properly
decoded by applications. The frame is mandatory from this respect but it is not required throughout
© RTCM – Not for reproduction or redistribution

the transmission of the data. Providers may package the messages into a separate frame structure
that best suits the transmission medium. The data set would need to have this frame structure re-
established before transfer to the application. For high-integrity applications, it would be up to the
provider to demonstrate that adequate integrity is maintained in the process of disassembling and
reassembling the transport layer frame structure. The basic frame structure consists of a fixed
preamble, a message length definition, a message, and a 24-bit Cyclic Redundancy Check (CRC)
for high data transfer integrity.

The structure of the frame format is shown in Table 4-1.

Table 4-1. Version 3 Frame Structure

Preamble Reserved Message Length Variable Length CRC

Data Message
8 bits 6 bits 10 bits Variable length, 24 bits
integer number of
bytes
11010011 Not defined Message length in bytes 0-1023 bytes QualComm
– set to definition
000000 CRC-24Q

The Preamble is a fixed 8-bit sequence.

The next six bits are reserved in RTCM10403.1 and should be set to zero by the Transport Layer
Control for all messages. The mobile user receiver should ignore these bits and not assume they
will always be set to zero. In future versions these bits may contain the version number of the
standard.

The Variable Length Messages are those defined in Chapter 3. If the data link requires short
messages in order to maintain a continuous stream of data, the message length may be set to "0",
providing a "filler" message of 48 bits in length, because the data message length will be zero.

This standard uses the QualComm CRC algorithm. Twenty-four bits of CRC parity will provide
protection against burst as well as random errors with a probability of undetected error
≤ 2-24 = 5.96×10-8 for all channel bit error probabilities ≤ 0.5. The CRC operates on the sequence
of bits beginning with the preamble, through to the end of the Variable Length Message Field, using
a seed of 0. The sequence of 24 bits (p1,p2,...,p24) is generated from the sequence of information bits
(m1,m2,...,m8N), where N is the total number of bytes in the sequence consisting of the message plus
preamble and Message Length Definition Parameter. This is accomplished by means of a code that
is generated by the polynomial

4-1
 RTCM 10403.1

24
g( X ) = ∑ gi X i
i =0
where
gi = 1 for i = 0, 1, 3, 4, 5, 6, 7, 10, 11, 14, 17, 18, 23, 24
= 0 otherwise
© RTCM – Not for reproduction or redistribution

This code is called CRC-24Q (Q for Qualcomm Corporation). The generator polynomial of this
code is in the following form (using binary polynomial algebra):
g( X ) = (1 + X ) p( X )
where p(X) is the primitive and irreducible polynomial

p( X ) = X 23 + X 17 + X 13 + X 12
+ X 11 + X 9 + X 8 + X 7 + X 5 + X 3 + 1
When, by the application of binary polynomial algebra, the above g(X) is divided into m(X)X24,
where the information sequence m(X) is expressed as

m( X ) = mk + mk −1 X + mk − 2 X 2 + ⋅⋅⋅ + m1 X k −1

the result is a quotient and a remainder R(X) of degree < 24. The bit sequence formed by this
remainder represents the parity check sequence. Parity bit pi, for any i from 1 to 24, is the
coefficient of X24-i in R(X).

This code has the following characteristics:

1) It detects all single bit errors per code word.
2) It detects all double bit error combinations in a codeword because the generator
polynomial g(X) has a factor of at least three terms.
3) It detects any odd number of errors because g(X) contains a factor 1+X.
4) It detects any burst error for which the length of the burst is ≤ 24 bits.
5) It detects most large error bursts with length greater than the parity length r = 24 bits.
The fraction of error bursts of length b > 24 that are undetected is:
a) 2-24 = 5.96 × 10-8, if b > 25 bits.
b) 2-23 = 1.19 × 10-7, if b = 25 bits.

As noted earlier, the reference station should insert zero’s in all reserved fields, and for messages
whose lengths that don’t line up with byte boundaries, zero’s should be used for undefined bits to
fill out the last unfilled byte.

4-2
 RTCM 10403.1

4.2 Example
The following is a Hex-ASCII example of a message type 1005 (Stationary Antenna Reference
Point, No Height Information).

D3 00 13 3E D7 D3 02 02 98 0E DE EF 34 B4 BD 62
AC 09 41 98 6F 33 36 0B 98
© RTCM – Not for reproduction or redistribution

The parameters for this message are:

• Reference Station Id = 2003
• GPS Service supported, but not GLONASS or Galileo
• ARP ECEF-X = 1114104.5999 meters
• ARP ECEF-Y = -4850729.7108 meters
• ARP ECEF-Z = 3975521.4643 meters

4-3
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution

This page intentionally left blank.

4-4
 RTCM 10403.1

5 DATA LINK LAYER

The Data Link Layer defines how the RTCM 10403.1 message data stream is encoded on the
Physical Layer. This may also include flow control, packetization, encryption, or additional error
checking.
© RTCM – Not for reproduction or redistribution

It is up to the service provider to determine how to define this layer as appropriate to the
application.

5-1
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution

This page intentionally left blank.

5-2
 RTCM 10403.1

6 PHYSICAL LAYER
The Physical Layer defines how the RTCM 10403.1 message data is conveyed at the electrical and
mechanical level – e.g.: beacons, MSK; UHF, VHF Modems; DARC FM Subcarrier, Satellite links,
© RTCM – Not for reproduction or redistribution

fixed cable.

It is up to the service provider to determine how to define this layer as appropriate to the
application.

6-1
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution

This page intentionally left blank.

6-2
 RTCM 10403.1

APPENDIX A. SUGGESTIONS AND EXAMPLES FOR NETWORK OPERATION

The following two sections provide additional guidance and information for Vendors, Service
Providers and Mobile Users. Appendix A.1 provides guidance to Service Providers on the selection
of master and auxiliary stations, and to Users on how to best use the information in the messages.
Appendix A.2 provides a scheduling example that demonstrates one method of utilizing the
© RTCM – Not for reproduction or redistribution

Synchronous Message Flags and Multiple Message Indicators to support operation with multiple
GNSS’s.

A.1 How to Use Network ID’s and Subnetwork ID’s

Figure A.1-1 gives an example of a network

containing 23 reference stations identified by 1
2 4
Network ID. In general the network will consist of 3
7 10
only one subnetwork identified by Subnetwork ID. 5 8
Every one of these 23 reference stations can be 13 9
6
used as a Master Reference Station and all 12
11 14
reference stations within a certain range around the 16 17 15
Master Reference Station might be used as 19 18
22 20
Auxiliary Reference Stations. The figure shows 3 21
23
different Master Reference Stations (11 <red>, 14
<blue>, and 17 <purple>) and associated radii. The
radii are defining in the example the range holding Figure A.1-1. Network Example
all associated Auxiliary Reference Stations for the
designated Master Reference Station. However other ways of selecting Auxiliary Reference
Stations for a designated Master Reference Station are possible and the selection process might
have to be adapted to the specific environment of the permanent networking application.

Master Reference Station M11 has the Auxiliary Reference Stations A1, A2, A5, A6, A7, A8, A12,
A13, A14, A16, A17, A19, A21, and A22. Master Reference Station M14 has the Auxiliary
Reference Stations A2, A3, A7, A8, A9, A11, A13, A15, A16, A17, A18, A22, and A23. Master
Reference Station M17 has the Auxiliary Reference Stations A7, A8, A11, A13, A14, A15, A16,
A18, A19, A21, A22, and A23. All three Master Reference Stations (M11, M14, and M17) are also
Auxiliary Reference Stations (A11, A14, and A17) for each other. Under the assumption that all
Master Reference Stations are on a common Integer Ambiguity Level, a handover to the next
Master Reference Station data stream would be possible without reinitialization of the integer
ambiguities as used in the rover application. However, Integer Ambiguity Leveling is not
mandatory for Master Reference Stations. Normally, all stations would be available to a network
processing facility and a networking provider could combine all stations in one network (e.g. 122).
When all Reference Stations could be brought to a joint Ambiguity Level, a common Subnetwork
ID 0 would be assigned.

An example of individual data streams may be for Master Reference Stations M11, M14, and M17
respectively as a sequence of information of Network ID (122), Subnetwork ID (0), Master
Reference Station ID, Auxiliary Reference Station ID,…:

A-1
 RTCM 10403.1

122, 0, M11, A1, … 122, 0, M14, A2, … 122, 0, M17, A7, …

122, 0, M11, A2, … 122, 0, M14, A3, … 122, 0, M17, A8, …
122, 0, M11, A5, … 122, 0, M14, A7, … 122, 0, M17, A11, …
122, 0, M11, A6, … 122, 0, M14, A8, … 122, 0, M17, A13, …
122, 0, M11, A7, … 122, 0, M14, A9, … 122, 0, M17, A14, …
122, 0, M11, A8, … 122, 0, M14, A11, … 122, 0, M17, A15, …
© RTCM – Not for reproduction or redistribution

122, 0, M11, A12, … 122, 0, M14, A13, … 122, 0, M17, A16, …

122, 0, M11, A13, … 122, 0, M14, A15, … 122, 0, M17, A18, …
122, 0, M11, A14, … 122, 0, M14, A16, … 122, 0, M17, A19, …
122, 0, M11, A16, … 122, 0, M14, A17, … 122, 0, M17, A21, …
122, 0, M11, A17, … 122, 0, M14, A18, … 122, 0, M17, A22, …
122, 0, M11, A19, … 122, 0, M14, A22, … 122, 0, M17, A23, …
122, 0, M11, A21, … 122, 0, M14, A23, …
122, 0, M11, A22, …

Message streams such as those in the example above might be transmitted on separate data links or
jointly in one data link. Note that the current standard document recommends disseminating only
one Master Reference Station per data link (See section 3.1.5).

As long as all reference stations are on the same

1
integer ambiguity level, a hand-over to another 2 4
3
Master Reference Station is possible as long as the 7 10
new Master Reference Station was already an 5 8
13 9
Auxiliary Reference Station for the previous 6
Master Reference Station. In the example user 12
11 14

equipment could operate using the red Master 16 17 15

Reference Station with fixed integer ambiguities 19 18

22 20
on the rover. When roving it might be desirable to 21
23
switch to the pink or blue Master Reference
Station and its associated Auxiliary Reference
Stations. Note that with the current Figure A.1-2. Example of Multiple Solutions
recommendation of only one Master Reference
Station per data link, switching Master Reference Stations requires that different data links be used.

There are situations where a homogeneous integer ambiguity solution might fall apart. For
instance, some stations in the center could have communication problems with the central
computation facility, or their observations might become unavailable for some other reason. The
example given in Figure A.1-2 shows 2 independent homogenous solutions with separated integer
ambiguity levels (gray shaded areas). The circles marking the initial area with all the associated
Auxiliary Reference Stations for particular Master Reference Stations span both shaded areas.

Since the correction differences (with Ambiguity Status Flag = 1, i.e., correct Integer Ambiguity
Level for L1 and L2) may be generated only between Master Reference Station and its Auxiliary
Reference Stations on the same integer ambiguity level, the example data streams will be different:

A-2
 RTCM 10403.1

122, 1, M11, A1, … 122, 2, M14, A3, … 122, 2, M17, A8, …

122, 1, M11, A2, … 122, 2, M14, A8, … 122, 2, M17, A14, …
122, 1, M11, A5, … 122, 2, M14, A9, … 122, 2, M17, A15, …
122, 1, M11, A6, … 122, 2, M14, A15, … 122, 2, M17, A18, …
122, 1, M11, A7, … 122, 2, M14, A17, … 122, 2, M17, A23, …
© RTCM – Not for reproduction or redistribution

122, 1, M11, A12, … 122, 2, M14, A18, …

122, 1, M11, A16, … 122, 2, M14, A23, …
122, 1, M11, A19, …
122, 1, M11, A21, …

Note: It is possible to form other Correction Differences as well, but their Ambiguity Status Flag
will be different from “1”.

The reaction of the user system may be manifold and is strongly dependent on the processing
strategy implemented in the system itself. The simplest strategy is to use only homogenous
information of Master Reference Station-Auxiliary Reference Stations combinations referring to the
identical epoch. In this case the implementation and handling within the user system is quite
straightforward. The user system will first receive the homogenous ones of any of the Master
Reference Station-Auxiliary Reference Station combinations and may correct its observations.
When a second data stream, with a different Master Reference Station, becomes more suitable the
user system may switch to the new data stream, and probably needs only to ensure that no jump
occurs in its results due to the switch of the Master Reference Station. However this again is
dependent on designated strategy of the user system’s processing strategy.

When a homogenous solution with a common integer ambiguity level as given in Figure A.1-1
breaks apart, resulting in a setup as given in Figure A.1-2, the reaction of the user system might
depend on the area of actual operation. Within the white area, the zone where the reference stations
are no longer part of any solution, the user system’s only chance is to use the remaining information
and try an extrapolation. The resulting positioning will probably be degraded under this
circumstance.

If the user system is operating in one of the gray areas and is using a Master Reference Station-
Auxiliary Reference Station combination outside his gray area, the user system may continue
without major interruption, but eventually with less flexibility in modeling the information for
proper mitigation of biases.

If the user system is operating in one of the gray areas, but is utilizing a Master Reference Station-
Auxiliary Reference Station combination of the opposite gray area, the user system probably will
have to change to a Master Reference Station-Auxiliary Reference Station combination in its area of
operation. Ultimately this will probably result in a reset of the user system’s integer ambiguities
and the user has to reinitialize again.

As stated above, a processing strategy using only information of the latest available epoch is
probably the simplest strategy possible. More sophisticated processing strategies may involve the
usage of the information of Master Reference Station-Auxiliary Reference Station combinations of
different Master Reference Stations and/or different observation epochs. The information of the
Network RTK messages have the potential to be used within another centralized networking
solution. In the future a further application might be a complete network solution on a user

A-3
 RTCM 10403.1

receiver. The status information of the network calculation transmitted in form of the data fields
Network ID and Subnetwork ID provide sufficient proof to indicate to the user system that it is
secure or non-secure to continue operation with the new set of information. At the time the
complete description of all these potential applications is not possible, due to the number of
variations. The experienced developer in the field of network RTK will understand the meaning of
the Network ID and Subnetwork ID for his envisioned applications. Therefore further details are
© RTCM – Not for reproduction or redistribution

left open and will need further description in case the given description is considered ambiguous.

A.2 A Scheduling Example for RTK Networks Demonstrating the Proper Use of
Synchronous Message Flags and Multiple Message Indicators

It is anticipated that RTK services in the future will transmit data for more than one satellite system
concurrently. Such facilities already exist for non-network RTK service, using GPS and
GLONASS data, all referenced to the same time epoch. Such operation supports the mixing of
measurements from different GNSS’s. As Galileo comes on line, it will initially be used in
conjunction with GPS and GLONASS, so RTK services utilizing multiple GNSS’s will be common.
The Synchronous Message Flags and Multiple Message Indicator in the RTK messages are
designed to support multiple GNSS operation.

However, not all rover receivers will be designed to receive and process information from more
than one GNSS, and the RTCM standard should enable rovers to know when relevant information
has been completely transmitted for a particular epoch. Otherwise such user receivers would have
to wait until data for the next epoch has been received before they could begin processing. Such
delays are neither desirable nor necessary.

TheSynchronous Message Flag supports the use of two or more GNSS’s. It is set to “1” if data
from another GNSS will follow, and it is set to “0” if there are no other services, or if this data set is
for the last GNSS for that epoch.

With networks, it might be necessary to transmit data for different Auxiliary Reference Stations at
different times, but referenced to a single epoch. For example, if there are 5 Auxiliary Reference
Stations and one particular message is sent for one auxiliary station every epoch, it will take 5
epochs to provide a complete set of information. The Multiple Message Indicator is set to “0” for
the last Auxiliary Reference Station in the specific message set (e.g. 1015 or 1016), and the others
are set to “1”.

With more than one GNSS, the data stream will contain the Auxiliary Reference Station data first
for one satellite system, then the other.

How these rules are applied is demonstrated in Table A.2-1 below for a combined GPS and
GLONASS service. The Epoch is the reference time in seconds. GPS 1004 refers to the GPS
Master Reference Station reference epoch, and 1004 SMF refers to the value of the Synchronous
Message Flag in the 1004 message. GLONASS 1012 refers to the GLONASS Master Reference
Station reference epoch, and1012 SMF refers to the corresponding GLONASS flag. For ease of
explanation at each epoch Network RTK data for one Auxiliary Reference Station and one GNSS is
transmitted. Actual service implementations may send several messages per epoch, but the
explained principle is readily apparent. GPS 1015 refers to the reference epoch for the GPS
Auxiliary Reference Station Iono message, and the corresponding MMI refers to the value of the
Multiple Message Indicator in the 1015 message; similarly for the 1016 Geometric message. The

A-4
 RTCM 10403.1

corresponding GLONASS values are then given, where 1015* refers to the not-yet-defined
GLONASS Iono message, and similarly for 1016*.

Table A.2-1. Example Showing the Use of SMF’s and MMI’s

GPS GLONASS GPS Network RTK GLONASS Network RTK

© RTCM – Not for reproduction or redistribution

Epoch 1004 SMF 1012 SMF 1015 MMI 1016 MMI 1015* MMI 1016* MMI
1 1 1 1 0 1 1 1 1
2 2 1 2 0 1 1 1 1
3 3 1 3 0 1 1 1 1
4 4 1 4 0 1 1 1 1
5 5 1 5 0 1 1 1 1
6 6 1 6 0 1 1 1 1
7 7 1 7 0 1 1 1 1
8 8 1 8 0 1 1 1 1
9 9 1 9 0 1 0 1 0
10 10 1 10 0 1 1 1 1
11 11 1 11 0 1 1 1 1
12 12 1 12 0 1 1 1 1
13 13 1 13 0 1 1 1 1
14 14 1 14 0 1 0 1 0
15 15 1 15 0 15 1 15 1
16 16 1 16 0 15 1 15 1
17 17 1 17 0 15 1 15 1
18 18 1 18 0 15 1 15 1
19 19 1 19 0 15 1 15 1
20 20 1 20 0 15 1 15 1
21 21 1 21 0 15 1 15 1
22 22 1 22 0 15 1 15 1
23 23 1 23 0 15 0 15 0
24 24 1 24 0 15 1 15 1
25 25 1 25 0 15 1 15 1
26 26 1 26 0 15 1 15 1
27 27 1 27 0 15 1 15 1
28 28 1 28 0 15 0 15 0

It can be seen that all the GPS and GLONASS Auxiliary Reference Station messages are referenced
to Epoch 1, until the entire set of data has been broadcast, after which the data is referenced to
Epoch 15. Note that the GPS SMF’s are all “1”, indicating that the GLONASS message is to
follow, while the GLONASS SMF’s are all “0”, indicating that there is not a third GNSS
represented in the data stream. The final MMI for each GNSS and message type is set to “0”,
indicating that the complete set of network corrections have been transmitted, and the rover can
proceed immediately to apply them.

The extension of this technique to three or more GNSS’s is readily apparent.

A-5
 RTCM 10403.1
© RTCM – Not for reproduction or redistribution

This page intentionally left blank.

A-6