As 5G introduces new concepts & new network architectures that will have a deep impact on core, transport and radio network design, how will synchronisation be affected? More than half of the Communication Services Providers surveyed at Mobile World Congress this year said they were in the early stages of rolling out 5G, so timing & synchronisation options should be at the centre of architecture discussions now! In the same survey respondents said the most important requirement in switch/router hardware was "quality 5G timing & synchronisation".

5G's RAN functional decomposition brings some of the philosophies of NFV & SDN to 5G and its use of CPRI/eCPRI to fronthaul data brings its own synchronisation challenges, with IEEE & ITU liaisons looking at timing aspects of this part of the network. Time Alignment Errors proposed in the new 3GPP specifications for 5G are in some cases many orders of magnitude smaller than current requirements, with 65ns being the tightest requirement. (It is worth noting however that some of the most stringent tolerances are intra-node only, not transport/network wide requirements.) Many operators are still in the process of moving from frequency-only sync to providing time & phase sync distribution for existing 4G/LTE-A services.

So, what's the problem? It's sometimes referred to as the "millennium bug of GPS" but what exactly is it?

The GPS System provides navigation & timing by using synchronised messages sent from a constellation of satellites orbiting the earth to a user's receiver - whether that be a dedicated navigation receiver (i.e. "Sat Nav") or a specialised timing receiver. The synchronised messages contain a time code, using a timescale known as "GPSTIME" that is encoded in its own unique way. So here comes the problem; within that encoding system the week number can only be represented by 1024 unique values.... so, every 1024 weeks the code repeats. The opportunity for a problem occurs when the week number changes from 1023 back to zero, or "rolls over". This has happened before, on 21st Aug 1999 as GPS "week zero" originally started 6th Jan 1980. So, the next one's coming pretty soon... 6th April 2019 to be precise.

So what might happen? Well, older receivers might get confused and think it's 1999 again... or worse 1980! As this has happened once already the GPS industry as a whole should be prepared for it, and many receivers will carry on working correctly without issue. You should only be concerned if you have a receiver that has been in continuous operation for more than ~10 years without any firmware update or if your receiver forms part of a critical system - can you afford to just wait and see?
First port of call should be the GPS receiver's manufacturer (or their service/support representatives) to see what they have to say, for example if the receiver and its software have been tested to handle the rollover without issue. If that's not possible then you may have to resort to performing provocative testing with GPS simulators that can provide the exact conditions that will occur in a week rollover scenario.

How any failure will manifest itself is difficult to say; as it's a software bug it depends on so many other things unique to each manufacturer's implementation... some receivers may carry on apparently unaffected apart from the wrong date, some may reboot/restart and sort themselves out whilst others may just fail and not recover.


For more information:

Chronos test solutions:
https://www.gps-world.biz/products/test-a-measurement/labsat-3-gnss-simulators

GNSS Vulnerabilities linkedin group:

Timing dependent applications rely on their clocks being correct within the set tolerances required by that technology.In order to achieve this, timing is transferred between clocks using various methods that enable time or frequency, phase or time of the required quality to be available to the application.The activity of transferring time between clocks is known as synchronisation. ​