Recommendations: RTCM on BeiDou use, DHS on critical timing receivers

February 24, 2017  - By

Two documents of interest and importance to GNSS designers and manufacturers have been published, one from the Radio Technical Commission for Maritime Services (RTCM) and one from the U.S. Department of Homeland Security (DHS).

The latter document is the subject of a news story concerning receivers used in critical infrastructure, with an emphasis on timing receivers. It provides owners, operators, researchers, designers and manufacturers with information to improve the security and resilience of PNT equipment across the spectrum of equipment development, deployment and use. It makes specific recommendations.

The first-mentioned document is a white paper issued by the RTCM. It follows here, largely verbatim. It is titled “GNSS Community Benefit from Strong International Coordination and Cooperation,” and it addresses an important issue for GNSS receiver manufacturers and others concerning use of BeiDou signals. The authors believe that early publication and dissemination of the recommendation is needed to prevent possible confusion down the line.

GNSS Community Benefit from Strong International Coordination and Cooperation


The ephemeris broadcast by China’s BeiDou Navigation Satellites do not directly provide unique identifiers that are similar to the GPS’s “Issue of Data, Ephemeris” (IODE) and “Issue of Data, Clock” (IODC) values. Special Committee #104 (SC-104) of the Radio Technical Commission for Maritime Services (RTCM) has been working with the China Satellite Navigation Office (CSNO) to ensure that equivalent BeiDou IODE and IODC values can be generated.

This paper presents the BeiDou IODE and IODC calculation algorithms that were developed by RTCM’s SC-104 and are being shared with the GNSS community in an effort to promote consistent BeiDou IODE and IODC computational approaches within the community.


Most GNSS position and timing related algorithms need to know exactly where the satellite was at the moment the signal component of interest was transmitted. The signal sent from these satellites also contain messages, which contain parameters used to calculate the position and clock errors of that satellite for a moment of interest within the validity period of those orbital parameters. Because this validity period is relatively short (e.g., +/-4 hours of the current time), the satellites are periodically broadcasting new orbital parameters. These orbital parameters are often referred to as the satellite broadcast ephemeris. Plots from the different broadcast ephemeris for the same satellite do not directly overlay each other because there are forces acting on those satellites (such as solar wind, ionospheric drag, and gravitational anomalies) that do not permit long term exact prediction of orbits and clocks.

Many differential correction services require both the correction generator system (e.g., reference station and reference networks) and the correction consumer (e.g., GNSS rover receivers) know and use the exact same orbital parameters. That is, the consumer of the corrections needs to apply those corrections using the exact same orbital parameters as those used to create the corrections. Failure to do so results in errors and biases for reasons earlier described. In such correction services, the correction message contains information enabling the consumer to uniquely identify the orbital parameters used by the generator.

Correction services need a mechanism to uniquely identify the orbit parameters used by the correction generator system. The GPS Broadcast ephemeris messages are uniquely identified for a certain period of time by what are known as the “Issue Of Data, Ephemeris” (IODE) and the “Issue of Data, Clock” (IODC). Other GNSS constellations have similar concepts, or at least other parameters that can be used for similar purposes. Unfortunately, the 2011, 2012 and 2013 BeiDou Signal-In-Space Interface Control Documents (BDS-SIS-ICD) have offered no information enabling one to develop some mechanism for such a unique identification.

In 2013 RTCM SC-104 created the BeiDou Working Group (BDS WG). Since then, the BDS WG has worked closely with the China Satellite Navigation Office (CSNO) to ensure proper inclusion of BeiDou in RTCM standards and recommendations. As part of this effort, RTCM SC-104 and the CSNO explored several avenues concerning equivalent BeiDou values of IODE and IODC. Ultimately an approach was selected by the CSNO. The selected approach stems from a ground-segment based approach which does not require a change to the BeiDou broadcast message format. However, it does then require that the users of BeiDou needing IODE and/or IODC values ensure that they employ the exact same algorithm to compute those values from the data available in the broadcast ephemeris.

In May 2016, Kendall Ferguson (RTCM SC-104 Chair), Shaowei Han (Wuhan Navigation and LBS, Ltd. and Chair of the RTCM SC-104 BDS WG), and Dr. Hui Liu (Wuhan University /Wuhan Navigation and LBS, Ltd. and co-Chair of the RTCM SC-104 BDS WG) met with the Deputy Director of the CSNO. In that meeting, the CSNO Deputy Director indicated that a soon to be release BDS-SIS-ICD would provide information that would enable calculation of equivalent BeiDou IODE and IODC values. In November 2016, the CSNO released the BDS-SIS-ICD, Version 2.1, and that ICD contains the needed information.

The language in the new BDS-SIS-ICD indicates that the normal ephemeris update (i.e., with new ephemeris parameters) will occur every hour on the hour when everything is normal.  If new parameters are needed for whatever reason, they will occur on 12 minute slots within the hour.  Any parameter that is changed in a broadcast ephemeris that is related to toc will result in a new toc (coincident with the 12-minute slot of the hour).  Likewise, any parameter that is changed in a broadcast ephemeris that is related to toe will result in a new toe (coincident with the 12-minute slot of the hour).  Whenever toc changes so will toe.  There will be no repeated toc or toe values within a week.

On February 3, 2017, RTCM SC-104 formally approved algorithms for BeiDou ephemeris unique identifiers that can be computed by both message generators and message consumers. The reason for announcing this approval is to proactively prevent a wide variety of BeiDou IODE/IODC algorithms from emerging throughout the GNSS community.

These RTCM BeiDou IODE and IODC algorithms are:

BDS IODC=mod (toc / 720, 240)

BDS IODE=mod (toe / 720, 240)

The modulo 240 gives an 8-bit IODE (and an 8-bit IODC) that provides 2 days of uniqueness and which offers the smaller bit size needed for correction messages.   The values from 240 to 255 thus offer some future expansion should additional cases be needed.

Unlike the relationship between the GPS IODE and GPS IODC, the BDS IODC may not be equal to the BDS IODE. The BDS IODC may be updated much more often than BDS IODE. However, whenever the BDS IODE is changed, the BDS IODC is also changed at the same time. Thus, RTCM will be using the BDS IODC as the unique ephemeris identifier in its messages.


Special Committee #104 (SC-104) of the Radio Technical Commission for Maritime Services (RTCM) has been working with the China Satellite Navigation Office (CSNO) seeking methods where by BeiDou equivalents of the GPS IODE and IODC might become available. The BDS-SIS-ICD, Version 2.1, released November 2016, provides information about the constellation allowing computation of IODE and IODC values from its broadcast ephemeris. In February 2017, RTCM SC-104 approved the algorithms it will use to compute unique ephemeris identifiers that will be contained in its messages, thus allowing the recipients of RTCM BeiDou related messages to identify the ephemeris used by the sender of such messages. RTCM is announcing these algorithms in an effort to prevent a variety of such algorithms from emerging and thus causing community confusion.


Alan Cameron

About the Author:

Alan Cameron is editor-in-chief and publisher of GPS World magazine, where he has worked since 2000. He also writes the monthly GNSS Design & Test e-Newsletter and the Wide Awake blog.

Comments are currently closed.