Time and timing service have an increasingly important part to play in many applications, including:
- Enabling super fast 5G mobile coverage
- Underpinning the performance of a modern electricity grid
- Recording Financial Trading and other regulated data
- Time stamping of network events for fault tracing and analysis
In most cases, this has involved the installation of a standalone Time Server device using GPS and other GNSS signals.
Should the GNSS input fail, resilience will be found in the holdover technology. And while most will build a timing ‘pyramid’ through their network down to the end user devices, this pyramid will have a single point of failure: the GNSS Time Server.
In hosted datacentres, most have allowed the installation of a GNSS feed for each client. This often leads to a very crowded roof space and some very tight underfloor cable runs.
In the last ten years or so though these hosts have started to develop a timing service of some description. For instance, a GNSS distribution system for your own time server.
So, here are five key areas you need to consider when deciding on a timing service. I will be covering services that do not require the need for a time server application of your own.
Timing Service Performance
You need a service that is appropriate for your application. This does not necessarily mean you need the best market timing service.
For example, if your requirement is for time stamping events then this could be delivered through a basic NTP service. This is almost a ‘same second’ requirement, certainly the in tens of milliseconds. However, this would be delivered by the datacentre itself not from the Internet (see ‘Security’ for more on this).
There are applications that require a microsecond or better, such as timing for Synchrophaser measurements in power systems or high frequency trading servers in financial institutions. Generally, a timing service based on NTP would not suffice here and so PTP is the most likely network-based solution for you.
Reliability
It would not make sense if the host data centre simply replicated the type of setup you could deliver for yourself. Specifically, a standalone GNSS-based time server. There would be cost benefits from such a system being used by many customers. However, an unreliable service would have an impact on every user in the datacentre. While this is not a direct issue for you, it would be a reputation disaster for the host.
A reliable service would typically employ multiple time servers (a key recommendation on an NTP pyramid is three servers so that 2v1 qualification can be done by clients).
A next level reliable service would be multi-site, so that a loss of the GNSS signal in one site would not affect all servers that you have access to. Even multi city, multi country or multi continent!
Security
The key security consideration is not solely related to the timing service itself. It also covers the possibility that this timing service can be used as an attack vector for your wider network.
There have been many cases of UDP Port 123 (the port used by NTP) being used to take over networks. Whether simply through a gap in the firewall or from malformed NTP packets.
The bigger the prize, the harder hackers will work. This is a particular issue for Critical National Infrastructure such as utilities and broadcasters, and financial trading engines.
For network security, you may consider using a service that delivers a one pulse per second (1PPS) signal derived from GNSS or elsewhere. Perhaps complemented by a 10 MHz sine wave also derived from GNSS.
Traceability and Transparency for a Timing Service
Some applications (such as financial trading in the EU under the MiFID II regulations) have statutory requirements relating to timing accuracy and traceability. Some regions already have impacted mandatory traceable time series in utilities. many national laboratories are exploring the delivery of directly traceable timing services through a variety of means.
The tight timing requirements in many networks (such as 5G TDD) for relative timing between sites can best be satisfied by all sites using time traceable to UTC. Traceability of a third-party service here is critical for network operation. In fact, in 5G TDD a loss of timing performance means you will need to switch off your site to avoid interfering with other carriers. This is a direct threat to revenues.
You can only be satisfied that your timing service is appropriate, secure, reliable and traceable if there is transparency from the provider. This includes what services they deliver, how they deliver them and continuing data on performance, reliability and traceability.
Summary
We have seen both sides of this coin here at Chronos. Customers using timing servers delivered by other customers of ours. Although we can attest to the quality of the equipment used and our opinion of the companies involved. Quantifiable information on any services you use will be the best way for you to ensure these five requirements are met. Preferably verified by a third-party!
Please visit the Chronos Times area of our website to read the latest Insights and Bitesize articles, learn about our attendance at recent Events and much more.
