Fundamental networks no longer rely on timing for their own performance. However, there are many applications at the edge of these networks that still do. And it is these requirements that are becoming increasingly tight with each new generation.
For those of us in the timing supply and support world, the ‘legacy’ networks gave us plenty of challenges. Thankfully, there were always ones that could be resolved by swapping hardware modules. Occasionally you had to turn it off and back on again, but in general life for timing experts was fairly easy. Our time signals were an external input into network devices, and most hardware, especially in core networks, had a large degree of hardware resilience. Dual power, dual clock, and dual modules are examples of such built-in robustness.
Solutions for remote management (an on-device red light or SNMP trap) flagged up the error. Subsequently, a hardware swap would usually resolve the issue. Finding the roots of issues was a fairly easy and straightforward endeavour, especially because timing was an external import that came in separately from other network traffic. This made timing errors and issues relatively easy to spot and diagnose.
The move from PDH/SDH has made troubleshooting significantly harder. We are now operating in non-deterministic networks. This means that timing signals are now in with the rest of the traffic, making it a lot harder to identify, diagnose and quickly solve timing issues. It becomes more difficult to determine if a specific issue is the result of a timing or a network problem. Timing packets may have priority status, but this still presents challenges that the timing community had not really encountered before. While these timing transport issues have successfully been addressed, many old certainties surrounding timing issues have all but disappeared.
The first big challenge is the increasing complexity of modern networks. Time-focused solutions are now less modular (not built around different modules), and highly dependent on software to deliver the functionality required. Simple hardware fixes are increasingly not an option. This often leads to an interesting and sometimes difficult discussion: what is a customer’s error and what services are causing it?
Furthermore, time issues formerly diagnosed with a call and an interrogation of the device now often require deeper investigation. A series of meetings between many departments and contractors may be needed to identify the issue. This increases the complexity of troubleshooting.
For us at Chronos, this has meant a massive shift in the ways our day-to-day support operation works. In a growing number of cases, we need an operator to work with specialised timing supply/support teams to maintain effective network operation.
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.