I want to talk a bit more about time, and in particular, I want to look at designing practical, workable, and above all, resilient systems. Live media systems using IP are in use today, and they all need time references.
You will remember that the source of reference time is a grandmaster clock, getting its own reference time over the air from GPS or Glonass. You put that into an ethernet switch and it is available to any number of master clocks and edge devices.
The grandmaster feeds a number of boundary clock switches. These are slaves to the grandmaster, but masters to the edge devices. As I explained last time, there is a defined means to monitor and manage latencies through the network and switches. That allows us to synchronize the network within a few microseconds, locking up in less than 10 seconds.
When you come to take the theory and design a practical system, your first decision is whether to make the PTP time signals in-band — part of the same network that carries the audio and video — or out-of-band — on a separate network. Actually, this is not a real decision because the only reason you would choose an out-of-band architecture would be if your budget was way too big and you liked chasing your tail trying to find the source of the on-air glitches.
You will also see questions raised about boundary clocks and transparent clocks. A boundary clock has one port which is a slave to the master above it — like the grandmaster — and a number of ports which are masters to the boundary clocks or edge devices below it. It takes sync in, and it disseminates sync on the outputs.
A transparent clock, as its name suggests, simply corrects the timestamp for its own internal latency.
A boundary clock improves security because slave devices will not see data from another device. The system designer also can limit which devices can become masters, eliminating the risk of rogue masters causing major disruption to synchronization.
But each boundary clock inevitably introduces a small amount of wander to the synchronization, which is not present in the transparent clock. That also means that the transparent clock can deliver slightly faster network convergence during a grandmaster fail-over.
Which brings us to the subject of redundancy. The fundamental design of a grandmaster clock to network switch to multiple master clocks to network switches to edge devices is fine in concept, but if anything goes wrong then the production center loses synchronization.
Obviously, you are going to have redundant grandmasters. But if they are routed through a common switch, what happens if the switch fails? Good design is to replicate anything that would be catastrophic if it failed.
Luckily for us, there is a standard that offers best practice for media installations: SMPTE ST 2022-7. This defines how we can use seamless packet switching in our industry. Essentially, the primary and secondary streams are carried independently on separate cables and separate switches to each destination, where the streams are combined.
All of which would be fine. But…
The behavior of PTP — and therefore SMPTE ST 2059 — is not defined over SMPTE ST 2022-7 networks, in either the IEEE or the SMPTE standards. But SMPTE ST 2110 depends upon timestamps that rely on SMPTE ST 2059. Yes, I know we are getting deep into standards now.
Different vendors are giving different recommendations on how to achieve satisfactory performance. Unfortunately, the empirical evidence is that not all network topologies work. I have my own recommendations for best practice.
After designing your network, talk to the grandmaster clock, switch and media node vendors, to ensure that everyone agrees your design will work. It is much easier to fix a paper design than fixing or replacing equipment in the racks.
The key takeaway is that while redundancy is always going to be a central part of any competent media architecture, just at the moment, it is not easy. SMPTE ST 2059 and SMPTE ST 2022-7 have different redundancy models, and care is required to make a design that will work.
Having designed a stable, synchronized system, you need to commission it. Which will be the subject of my next blog.