It’s not quite the Millennium Bug for GPS receivers, but it could have a serious impact on computer networks and operational systems if not addressed.
On 6 April 2019, the Global Positioning System (GPS) will enter its third epoch since it went live in 1980. The transition to the new time period may cause some older GPS receivers to behave strangely, affecting any systems that rely on the time and date information they produce.
If any of your systems, services or applications rely on time data from GPS, it’s essential that you check your receivers now to make sure they can handle the rollover event without issue.
And if you’re not sure whether your critical systems ultimately obtain time data from a GPS receiver, now is the time to find out – before any unexpected issues occur.
What is the GPS Week Number Rollover?
As I’ve blogged previously, the GPS week number rollover is a known issue caused by the way GPS originally handled the week element of the timestamp data in the navigation message. The first GPS signals used a 10-bit field to encode the week number, creating a maximum time period of 1,024 weeks, known as an “epoch”. At the end of each epoch, the week number resets to zero.
The first GPS satellites came online on 6 January 1980, so the first epoch of GPS time lasted for the following 19.7 years, ending on 21 August 1999. We’re now coming to the end of the second epoch, which will fall on 6 April 2019. From that date onwards, we’re likely to start seeing rollover problems in GPS receivers that aren’t programmed to handle the week number reset. The US Naval Observatory has a good introduction to the issue in this short PDF.
What types of receiver are affected?
The problem mainly affects older GPS receivers that haven’t been updated to handle the rollover. Most receiver manufacturers have issued advisories and firmware updates to fix the issue, but it’s been up to the user to heed the advisories and implement the updates.
If this hasn’t been done, or if the manufacturer hasn’t updated their firmware for whatever reason, receivers may be vulnerable. While the time they output will still be accurate in terms of hours, minutes and seconds, the date stamp is likely to revert to 19.7 years in the past, which can cause serious knock-on effects in systems that rely on that data.
Important Note: The week number rollover issue may not manifest on 6/7 April 2019 itself. Many receivers are programmed to start counting the 1,024 weeks from the date the firmware was compiled, rather than the start date of the GPS epoch. So a receiver may continue to work as normal for weeks or months after 6 April, but will still reset when its 1,024 weeks are up.
What kinds of systems could be affected?
Many GPS-dependent systems can be affected by the issue. Recent reports to the US Coastguard Navigation Center’s GPS Problem Reporting database show that the issue is spread across industry sectors, and reveal the kind of behaviour an uncorrected receiver may exhibit:
In October, a timing application user in Colorado reported that “GPS 1PPS synchronization units of one make reporting incorrect time. On 22 October the units began reporting a date of 11 March 1999.”
In November, a first responder in Indiana reported that “on 22 October the units began reporting a date of 11 March 1999. Time is correct, date is off.”
In December, a surveyor in North Carolina reported that their “GPS unit has ceased to display valid date and time information and reverted to the year 1999. I contacted the manufacturer who denied any manufacturing defects and could not offer a solution except to obtain another device at my expense (out of warranty for several years).”Note that these reports may relate to receivers developed late in the first GPS epoch, as we shouldn’t start to see second-epoch problems until after 6 April 2019.
Online service providers and large computer networks could see problems
The first report above hints at what may turn out to be a major problem for online service providers and large computer networks. Networks rely on accurate time, distributed using Network Time Protocol (NTP) or Precision Time Protocol (PTP) to keep individual servers in sync.
NTP and PTP servers often ultimately obtain their time data from GPS – and if the GPS receiver can’t handle the week number rollover, the knock-on effect on the network, and the user experience, could be huge.
Services that could be affected include security certificates (this article from APNIC is a very interesting read on that topic) and authentication, as well payment processing and any other applications that rely on accurate date stamps.
We can get some idea of the potential impact from the way many web services, including Reddit, Gawker and Mozilla, failed to cope with the leap second insertion in 2012. While the issue here was with the Linux operating system, rather than the GPS receiver, it does show how a timing glitch is capable of paralysing networks and the services that run on them.
Four steps to check your receiver
If you’re concerned about your GPS receiver’s handling of the Week Number Rollover, get it checked now. Here are four steps you can follow:
Step 1: Identify where older GPS receivers are used in your devices or systems architecture, and check the receiver manufacturer.
Step 2: Find out if the manufacturer has issued an advisory, and see if you need a firmware update. You may be able to find this on their website (here is TomTom’s advisory page, for example), or you can contact them directly.
Step 3: If you can’t get hold of the manufacturer – or if they have gone out of business – it’s easy to test the receiver using a GPS simulator. It’s just a case of setting the date in the simulated timing message to 20+ years in the future, and seeing what date the receiver reports. This may in fact be quicker and easier than tracking down the manufacturer.
Step 4: If your receiver is affected and there’s no firmware update available, you will probably have to replace it. Newer GPS receivers use a newer version of the GPS signal, in which the date is encoded in a 13-bit field – ensuring it will output the right date for the next 150 years at least.
Spirent can test your receiver for you
Step 3 above (using a GPS simulator) is by far the quickest and easiest way to check your receiver for Week Number Roll Over issues. If you don’t have access to a GPS simulator, Spirent can carry out the test for you – just contact us for details.
We also have test scenarios and procedures that can check GPS receivers for other possible configuration issues, like this known IODC glitch, at the same time.
Stay up to date with GPS and GNSS vulnerabilities
Threats to position, navigation and timing (PNT) systems are evolving all the time. To stay up to date with the latest vulnerabilities, join the growing community in the GNSS Vulnerabilities LinkedIn Group.