日本語
Older iPhones and iPads are among the latest devices to experience a GNSS issue. Tech websites including The Verge and The Next Web warned users to upgrade to iOS 10.3.4 or higher before 3rd November, or risk seeing a host of functions fail: from GPS to email, App Store access and 4G/Wi-Fi connectivity.
The culprit in this instance is the GPS Week Number Rollover; a known issue arising from the fact that GPS satellites used to broadcast the week element of their timestamp in a 10-bit format.
In devices that still use a 10-bit field to process the GPS timestamp, the week counter resets to zero when it reaches 1,024 weeks. A swathe of Apple devices reached the 1,024-week mark on 3rd November, potentially causing issues in unpatched phones and tablets.
A reminder to test for all possible events
The 3rd November rollover issue is a timely reminder that receiver developers should test their devices in all possible scenarios. The nature of GNSS means that unusual and unexpected errors crop up relatively frequently for users, and developers must anticipate them in their receiver designs.
One significant recent event was the six-day outage experienced by Europe’s Galileo system in June. The exact circumstances that led to Galileo failing for almost a week are still unclear, but GPS World has a very good summary of what we do know, by Fabio Dovis and his team at the Politecnico di Torino. There’s also an interesting analysis of the effect of the fault on a dual GPS/Galileo device by Huibert-Jan Lekkerkerk, who was conducting validation tests while the outage was in progress.
Other recent issues that have impacted user devices include the inaccurate time signal broadcast by GPS for five hours in January 2016, affecting many precision timing receivers for broadcast media and mobile telecoms, and the incident in 2014 where GLONASS transmitted inaccurate and misleading data for up to 10 hours, affecting dual GPS/GLONASS devices.
It’s important to note that issues with GNSS systems are extremely rare, and that GNSS remains an invaluable ‘fourth utility’ that enables a huge and growing proportion of human activity. However, these recent events show that errors do happen, and that no system is totally immune to them.
Receiver developers must ensure the system’s ICD is correctly implemented
So what can developers and users of GNSS-reliant devices do to ensure their systems are robust and resilient in the face of rare-but-not-unthinkable issues? One priority should be to ensure the relevant satellite system’s Interface Control Document (ICD) is properly implemented in the device.
The ICD is a public document that lays out the specifications of the GNSS signal, for developers of GNSS chipsets and receivers to use when programming firmware. It sets out the many types of signal error state that the device might encounter, enabling developers to program how the device should respond upon encountering those errors.
The week rollover is a useful example. In an ideal world, device firmware will specify what the device should do if the GPS week number resets to zero. In that ideal world, it would be a response that ensures the device either continues to work (perhaps by prompting a failover to GLONASS, Galileo or another positioning system), or raises an alert that it has started to output unreliable data.
If clear instructions haven’t been programmed in the firmware, GNSS receivers – and the systems that depend on them – can exhibit unexpected behaviour, as Guy Buesnel explored in a previous blog.
Limited test coverage means uncommon segment errors are often overlooked
The onus is then on the developer to re-create those error states during testing to verify that the device responds appropriately. The problem is that there are hundreds of possible error states just for a single-constellation device, let alone for a device that receives signals from multiple satellite constellations – and potentially other sources of position and timing data as well.
That means that less-common error states – ‘edge cases’ like the 2016 GPS timing error, or Galileo’s six-day outage – tend to be deprioritised in testing, in favour of more common error states like degraded signals, ionospheric scintillation, multipath and signal jamming.
The upshot is that devices are released without the manufacturer knowing exactly how they will react when an issue is encountered. Given that many software applications now rely on GNSS time and position data, this means that the impact on critical and non-critical systems is unknown. With segment errors becoming more common, this creates an unacceptable risk for many systems.
Spirent can help to recreate known GNSS errors in the test lab
Testing against rare error states is an area where Spirent is particularly well placed to help. All the GNSS segment errors I’ve mentioned in this blog – as well as other issues, including leap second insertions – can be re-created in the test lab using Spirent’s range of GNSS Radio Frequency Constellation Simulators, and our professional services team can provide help to recreate them.
What’s more, Spirent continuously records the live local signal environment from our premises in Paignton, UK, using our GSS6450 RF Record and Playback System, and we preserve recordings of interesting and anomalous events. We have recordings of key sequences of the Galileo outage in June, including the initial failure and subsequent recovery.
If you have any questions about how to test your device’s response to the full range of GNSS system errors, or if you are interested in using our live recordings in your GNSS device testing, please do get in touch.
