English
Some GPS receivers may malfunction on or after 6 April 2019 due to the GPS Week Rollover. Here’s what that means and how to check if a receiver is vulnerable.
If your vehicles or equipment rely on GPS receivers, now is the time to check if they’re affected by the GPS Week Number Rollover issue.
If they are, you may find your receivers start to behave strangely on – or more likely at some point after – 6 April 2019. The data they output may suddenly jump backwards in time, putting timestamps on your timing and navigation data that are nearly 20 years out of date.
This won’t affect the receiver’s ability to navigate and/or calculate precise time from the day level down to the microsecond level. But it will create week, month and year timestamps that are wildly wrong, which could seriously impact any systems and applications that rely on GPS data at that level.
(To give just one example, GPS trackers employed in a fleet management system to track deliveries could cause system errors or even a crash if they suddenly start to output location data timestamped with a date 20 years in the past.)
Similar – but different – to the Millennium Bug
As we’ll see, it’s not quite the Millennium Bug for GPS receivers, but it does share some similarities. The good news is, it’s easy to check now whether your receivers are affected or not, giving plenty of time to implement a solution.
But first, let’s look at what’s causing the problem.
What is the GPS Week Rollover issue?
The Week Rollover Problem is a known issue caused by the way that GPS used to handle the week element of the data that forms an essential part of the navigation signal. GPS used a 10 bit field to encode the week number in each GPS time message, which means that a maximum of 1,024 weeks (19.7 years), could be handled. Each of these periods is known in GPS terms as an “epoch”.
At the end of each epoch of 1,024 weeks, the receiver resets the week number to zero and starts counting again.
The first GPS satellites went live on 6 January 1980, meaning that the first epoch of GPS time lasted until 21 August 1999. We are now nearing the end of the second epoch, which will fall on the 6 April 2019. That means from that date onwards, we are likely to start seeing rollover problems in GPS receivers that aren’t programmed to cope with the week number reset.
Problems could occur on or after 6 April 2019
One of the things that makes this issue different from the Millennium Bug is that the impact won’t necessarily be felt on rollover day itself. In fact, it’s much more likely that an affected receiver won’t start outputting erroneous data until long after the 6 April 2019.
That’s because many receiver manufacturers have sought to maximise the default lifespan of their receivers by implementing the 1,024-week limit from the date the firmware was compiled, rather than from the date the current GPS epoch began.
In effect this means that older GPS receivers will operate normally for almost 20 years before problems begin to occur – and if firmware is implemented in this manner, no issue is likely to be seen when the GPS epoch changes.
For example, while the second GPS epoch began on 26 August 1999, a receiver manufactured in January 2005 may have a “pivot date” of January 2005 + 1,024 weeks coded into its firmware – meaning it will function smoothly until August 2025. This diagram shows how hard-coded pivot dates work:
The GPS modernization program is an ongoing, multibillion-dollar effort to upgrade the features and overall performance of the Global Positioning System. The upgraded features include new civilian and military GPS signals. To improve the situation regarding Week Number Roll Over, message types (CNAV and MNAV) use a 13-bit field to represent the GPS week number and newer GPS receivers that utilise that 13-bit field will not have a problem with 1,024-week epochs.
Week Number Rollover issues have happened before
We already have some good insight into how hard-coded pivot dates can create problems long after the official epoch rollover day. In November 2017, the US Naval Observatory published a partial list of legacy receivers that started to malfunction on dates in December 2014, February 2016, August 2016 and July 2017 – see slide 22 of this PDF presentation.
These receivers were still running their original firmware from the first GPS epoch, which ended in 1999. But because they were manufactured near the end of that epoch, the manufacturers were able to implement pivot dates in 2014, 2016 and 2017 – causing problems nearly 20 years after the epoch ended.
If the users of these receivers had been aware of the problem, in many cases they could have obtained a firmware update from the manufacturer before the receiver failed. That would have resolved the issue either by creating a new pivot date far into the future, or by replacing the affected receiver with a newer one that uses 13 bits to encode the week number.
How big a problem is it?
The fact that many users didn’t seek a solution to the problem the first time around indicates that many GPS receiver users aren’t aware of it.
That’s not (always) due to negligence on their part. In our experience at Spirent, many organisations aren’t fully aware of how many GPS receivers they have, or the role played by GPS data in the proper functioning of seemingly-unrelated systems.
As organisations use more GPS receivers, and become more reliant on the data they output, issues like the Week Rollover become much more significant. For that reason, I’d encourage everyone who relies on GPS in their organisation – whether for navigation, positioning or timing – to investigate now whether their receivers are vulnerable to the problem.
How to check whether a receiver is affected
The good news is that it’s easy to check whether a receiver is vulnerable to the Week Rollover problem. There are two important steps to take:
Firstly, contact the receiver manufacturer to understand if the receiver in question uses the 10-bit or 13-bit method of encoding the week number. If the 10-bit, ask about the vulnerability, whether there’s a pivot date coded into the firmware, and if so, when the issue is likely to manifest. Ask for a firmware update if there is one available, and make sure it’s properly installed and tested.
Secondly (or firstly, if you can’t get hold of the manufacturer), use a GPS simulator to conduct a simple test to double-check whether your receiver is vulnerable. This is just a matter of setting the date in the simulated timing message to 19.7 years into the future, and seeing what week, month and year data the receiver reports. If that data is wrong, if new firmware doesn’t resolve the issue, or if there’s no new firmware available, you may consider upgrading to a new, 13-bit receiver.
If you don’t have access to a GPS simulator, do get in touch with Spirent (www.spirent.com), as we may be able to conduct this test for you – either at your premises or ours.
Test now and check for IS-GPS-200H compliance as well
The Week Rollover issue isn’t the only firmware issue currently affecting GPS receivers. Just before Christmas, the US Air Force (USAF) alerted GPS users and equipment manufacturers to another issue that has been causing problems in thousands of receivers.
On the 21st September 2017, the USAF made a minor software update to the Global Positioning System. Shortly afterwards it began to receive reports that “several thousand receivers were impacted.”
In a 7th December memo to GPS users and equipment manufacturers, the USAF said: “Due to the nature of the impacted receivers, 2 SOPS subsequently removed the software update.” The Resilient Navigation and Timing Foundation reported that most of the receivers impacted were in first responder systems used in Japan and Korea.
GPS satellites broadcast a GPS time-related value (called “Issue of Data, Clock”, or IODC) as a number with one to three digits. Beginning on September 21st 2017, that changed to a number with one to four digits. This new scheme complied with specifications that had been in place since 2014. Apparently, impacted receivers began failing about three days later.
The importance of simulation in assessing system issues
A GPS simulator could have helped with both the Week Number Rollover issue and the IODC issue. When it comes to looking at the effects of system errors, using live sky or record and playback simulation is ineffective as it cannot model the changes to the format of the broadcast satellite navigation signal.
A good Radio Frequency GNSS simulator, by contrast, allows the user to tweak the broadcast signal data within the ICD specification (for example simulating a Week Number Roll Over and checking weeks in new epoch, or changing IODC format) and even to experiment with outputs that are not in accordance with the ICD.
The latter could also be important to protect against hackers. For example, in one incident, hackers were able to cause some GPS receivers to crash by sending them faulty ephemeris data that showed that the GPS satellites were orbiting below Earth’s surface.
Learn more about GNSS threats in the GNSS Vulnerabilities LinkedIn Group
The more we collectively rely on GPS, the more important it is to stay informed on the different vulnerabilities that can impact its proper functioning. You can join the GNSS Vulnerabilities LinkedIn Group to stay abreast of the latest threats to satellite position, navigation and timing systems.
