The effects of the January 2016 UTC offset anomaly on GPS-controlled clocks monitored at NIST Jian Yao, Michael A. Lombardi, Andrew N. Novick, Bijunath Patla, Jeff A. Sherman, and Victor Zhang Time and Frequency Division, National Institute of Standards and Technology, Boulder, Colorado, USA ABSTRACT Errors in the Coordinated Universal Time (UTC) offset parameters broadcast by Global Positioning System (GPS) satellites caused many thousands of GPS-controlled clocks to be in error by approximately -13 µs on January 25-26, 2016. The erroneous UTC offset information was broadcast by 15 GPS satellites, or half of the available constellation, during the anomaly. This paper discusses the technical reasons for the UTC offset anomaly, its effect on clocks controlled by GPS satellites (hereafter referred to as GPS clocks), and how it was detected at the National Institute of Standards and Technology (NIST). It then discusses the impact of the UTC offset anomaly on GPS clocks maintained and monitored by NIST, including clocks located in Boulder, Colorado and those at remote locations. Some analysis is presented of the effects of the UTC offset anomaly on GPS clocks located at 19 sites in North, Central, and South America. I. INTRODUCTION Through its remote frequency and time calibration services and its participation in the Sistema Interamericano de Metrologia Time Network (SIMTN) [1], NIST continuously monitors more than 90 single-frequency (L1 band) GPS receivers that are deployed as clocks, meaning that their function is to output a UTC time stamp and a 1 pulse per second (pps) time signal synchronized to UTC. In most cases, these clocks are part of a common-view system that is used to either measure or adjust the primary frequency or time standard at each location with respect to UTC(NIST), the official NIST time scale. Some of the GPS clocks are located at the NIST laboratories in Boulder, Colorado, but most, some 76 clocks, are located at various sites around the world, primarily in North, Central, and South America, as shown in Fig. 1. Figure 1. The locations of GPS clocks that are continuously monitored by NIST. The large group of GPS clocks that NIST monitors and maintains allowed us to study the effects of the UTC offset anomaly that occurred on January 25-26, 2016, when, ironically, most of the authors of this paper were attending the 2016 Institute of Navigation Precise Time and Time Interval (ION PTTI) meeting. Here we present the results of our study. Section II provides U.S. Government work not protected by U.S. copyright 155 a technical description of the UTC anomaly. Section III describes how the problem was detected by NIST personnel. Section IV summarizes the impact the UTC offset anomaly had on GPS clocks monitored and maintained by NIST both in Boulder, Colorado and at the sites shown in Fig. 1. Section V provides an analysis of the failure using data collected from 19 sites in North, Central, and South America. Finally, Section VI provides a summary. II. TECHNICAL DESCRIPTION OF UTC OFFSET ANOMALY The UTC offset anomaly was caused by a software “bug” that was triggered by the decommissioning of PRN 32 on January 25, 2016 at 2200 UTC [2], a satellite whose space vehicle (SV) number was 23. The PRN numbers refer to the satellite’s pseudo random noise code, the SV numbers are assigned consecutively in the order of the satellite launch dates. The software failure occurred not because the highest PRN number (32) was removed from the constellation, but rather because the lowest SV number (and hence the oldest satellite) was removed. The first of the Block IIA satellites, SVN 23 was launched on November 26, 1990, and thus was in service for more than 25 years. The software failure caused three of the parameters used to correlate Coordinated Universal Time (UTC) to GPS time, A0, tot, and WNt, to be incorrect [3]. These parameters are included in subframe 4, page 18, of the GPS navigation message. The content of subframes 4 and 5 is common for all satellites so a receiver can obtain the UTC parameters by tracking just one satellite. The UTC offset correction, ΔtUTC, is computed as [4] = + + ( + 604800( )), (1) UTC LS 0 1 E ot t where ∆ ∆ − − ΔtLS is the number of leap seconds introduced into UTC since GPS time began (equal to 17 when the anomaly occurred), A0 is the constant UTC offset parameter expressed in seconds, A1 is a dimensionless frequency offset value that allows the correction of the time error accumulated since the UTC reference time, tot, which is when A0 was last determined, tE is GPS time (also known as the time of interest or the time being converted to UTC), 604800 is a constant that equals the number of seconds in one week. tot is the reference time for UTC data, WN is the GPS week number, and WNt is the UTC reference week number. The first part of Eq. (1), ΔtLS + A0, essentially takes care of the UTC correction. The ΔtLS term is the large, integer second part of the correction, equal to the number of leap seconds that have occurred since January 6, 1980, the start of the GPS time scale. The ΔtLS value was correctly broadcast as 17 during the anomaly. The A0 term is the small, nanosecond part of the correction, equal to the difference between the GPS and UTC(USNO) second markers, with UTC(USNO) being the UTC time scale -8 maintained by the United States Naval Observatory. The A0 term is broadcast in units of seconds, but is typically < 1 × 10 s, or < 10 ns. For example, the three values of A0 broadcast by GPS immediately before and after the UTC anomaly (six values total) ranged from -2.79 ns to +1.86 ns. The erroneous value of A0 broadcast during the timing anomaly was approximately - 13696.03 ns, which rounds to the -13.7 µs value [5] that was widely reported by media outlets. The second part of Eq. (1) fine tunes the UTC output of a GPS clock by applying a dimensionless frequency offset, provided by A1, as a drift correction for the interval between the time specified by tot and WNt and the current time. This is normally a sub-nanosecond correction, because A0 is updated in the GPS broadcast more than once per day and the drift correction supplied -14 by A1 is typically near 1 ns per day. During the anomaly, a correct A1 value of 1.24345 × 10 was broadcast, a frequency offset that translates to a time offset of about 1.07 ns per day. However, this correction was applied across a much longer than normal interval. The correct GPS week number was 1881 and the correct value for WNt, broadcast in an 8-bit field, should have been modulo (1881, 256) or 89. Instead, it was broadcast as 0. Similarly, tot is also broadcast as an 8-bit field. The correct value 156 would have expressed a time, given in multiples of 4096 s (212 s), that occurred approximately 70 h after the first valid transmission time for the UTC data set [4]. Instead, tot was also erroneously broadcast as 0 during the anomaly. Referring to Eq. (1), broadcasting WNt as 0 resulted in WN - WNt being equal to 623 days (89 weeks × 7 days). Broadcasting tot as 0 resulted in tE - tot being equal to ~2 days, instead of the usual fractional part of a day, because the anomaly occurred near the Monday/Tuesday transition, about two days after the GPS week began on the Saturday/Sunday transition. Therefore, the drift correction supplied by A1 was applied to a period of ~625 days (623 + ~2 days) [3, 5]. This added a correction of ~671 ns and reduced the UTC offset to about -13024 ns. Thus, GPS clocks that applied A1 were offset from UTC by about -13.0 µs and those that did not were offset by about -13.7 µs [5]. The GPS clocks in our study all applied the A1 drift correction. The erroneous UTC offset parameters were transmitted by 15 of the 30 satellites that remained in the GPS constellation after PRN 32 was decommissioned. Table 1 lists the 15 satellites and the periods when bad data were transmitted [5]. Table 1. Periods when erroneous UTC correction data were broadcast by GPS satellites. PRN Start of bad End of bad Duration transmission transmission (hh:mm) 13 1/25/16, 23:30 1/26/16, 11:45 12:15 9 1/25/16, 23:45 1/26/16, 12:45 13:00 10 1/25/16, 23:45 1/26/16, 13:15 13:30 29 1/26/16, 00:15 1/26/16, 12:30 12:15 14 1/26/16, 00:30 1/26/16, 11:45 11:15 27 1/26/16, 00:45 1/26/16, 12:45 12:00 6 1/26/16, 01:00 1/26/16, 12:30 11:30 11 1/26/16, 01:15 1/26/16, 12:15 11:00 20 1/26/16, 03:00 1/26/16, 12:00 09:00 3 1/26/16, 03:15 1/26/16, 13:15 10:00 25 1/26/16, 04:30 1/26/16, 12:15 07:45 28 1/26/16, 05:30 1/26/16, 12:00 06:30 24 1/26/16, 07:00 1/26/16, 13:15 06:15 26 1/26/16, 07:00 1/26/16, 13:00 06:00 23 1/26/16, 08:00 1/26/16, 13:00 05:00 The time stamps in Table 1 refer to GPS system time.