Critical Decisions for Critical Infrastructure: How to Achieve the Most Accurate Timing and Synchronization

Critical Decisions for Critical Infrastructure: How to Achieve the Most Accurate Timing and Synchronization

Critical infrastructure services such as telecommunications, utilities, transportation and defense require positioning, navigation and timing (PNT) technologies to operate. However, the widespread adoption of the Global Positioning System (GPS) as the primary source of PNT information introduces vulnerabilities.

When developing a PNT solution for critical infrastructure, operators must make two of the most critical decisions: 1) Should resiliency, redundancy, and security be deployed at every layer of the architecture? 2) Which security strategy should be employed?

Decision 1: Deploy on every tier?

Operators have good reason to be concerned that they cannot justify the costs associated with deploying resiliency, redundancy, and security at every layer of the architecture. Having new timing and synchronization solutions and design options can help to achieve an ideal cost structure, providing a robust and reliable solution.

Typically, a trade-off is made between cost and solution type depending on the deployment location. With the migration from SDH/TDM to Ethernet and the development of mobile LTE/4G and 5G, the number of cluster offices and network access points located at the edge has increased significantly. This has necessarily led to smaller equipment (typically 1U rack-mountable equipment) and costs consistent with today's small form factor edge base stations (including small cells and gNodeBs). In this environment, operators must decide how to provide redundancy, resiliency, and security at both the architectural and design levels.

Redundancy can be designed at the architectural level by deploying core functions at both the east and west ends. For example, the virtual primary reference clock (vPRTC) architecture provides directional redundancy and high-performance capabilities with dual paths. The architecture also utilizes efficient high-precision time transmission over long distances for cost-effective distribution.

Another approach is to deploy redundancy in the equipment itself. The best approach is to use software redundancy, which can achieve a low-cost, high-efficiency, and high-performance distributed solution. This solution reduces the cost of space-consuming hardware modules (usually for input and output ports) while avoiding having to sacrifice other valuable functions in exchange for the advantages of added redundancy. For example, if redundancy is supported, there are trade-offs and other compromises when choosing between 10 Gigabit Ethernet (GE) support and multi-band Global Navigation Satellite System (GNSS). In contrast, software redundancy does not require the removal of any hardware and does not lose related functions.

Figure 1 shows a common redundancy use case involving two aggregation routers using Virtual Router Redundancy Protocol (VRRP).

Figure 1. Example of redundant connections between active and standby units

Another advantage of software redundancy is that it enables total redundancy of the entire device. The working unit and the standby unit are identical. All functions are redundant, including oscillators, GNSS receivers, ports, and inputs/outputs. Hardware modules are redundant only with respect to their own functions, not the rest of the unit.

Similar to redundancy, resiliency is also deployed at the architectural level and the device level. Resilience is deployed at the architectural level so that the grandmaster clocks in the network can be connected to each other. When the grandmaster clocks are connected to GNSS and used as a source of time and frequency, these grandmaster clocks must be connected to other 1588 grandmaster clocks for Assisted Partial Time Support (APTS). APTS can help achieve backup by utilizing Automatic Asymmetry Correction (AAC) to calibrate the different paths to/from the uplinked grandmaster clock that may be used by the Precision Timing Protocol (PTP) flow if GNSS fails at the grandmaster clock location. The backup path to the uplinked grandmaster clock can guarantee uninterrupted precise timing and phase operation. This architecture ensures that GNSS can be backed up via IEEE 1588 PTP in the event of an outage while utilizing the best path.

Another option is vPRTC. It allows operators to achieve high accuracy over long distances (usually over optical networks) through a high-performance boundary clock chain using PTP. This architecture uses PTP as its primary source of time and phase, reducing reliance on GNSS.

At the device level, resilience is achieved by selecting the best oscillator (from OCXO to Rubidium atomic clock). The specific choice depends on the location, use case and timing keep-up performance requirements. Specifying multi-band GNSS receivers is critical. Because only these receivers can measure and reduce the significant delays during periodic ionospheric events (such as solar storms) by exploiting the delay differences of the time information sent by GNSS satellites in multiple frequency bands. This is critical for applications that require a 40 ns Primary Reference Clock Class B (PRTC-B) and a 30 ns enhanced PRTC (ePRTC).

Decision 2: Which security strategy to adopt?

The ideal security approach is to start with a standard framework and consider other vulnerabilities including evolving jamming and spoofing threats.

Standards-based authentication and authorization options include Terminal Access Controller Access Control System + (TACACS+) and Remote Authentication Dial-In User Service (RADIUS). In addition to the security provided by username and password, two-factor authentication (2FA) provides an extra layer of protection.

Providing different levels of security profiles for the Secure Shell (SSH) extension provides more granularity in determining user types and associated access rights and restrictions. The high security profile will ensure that the most stringent access rules can be defined and enforced. In addition, script vulnerabilities and related Common Vulnerabilities and Exposures (CVE®) issues need to be addressed. This ensures that all potential security vulnerabilities are reviewed and addressed. Signal monitoring as well as consistency checks and remediation must be performed to curb evolving interference and spoofing threats.

To ensure continued performance, the right architectural choices need to be made, which requires a comprehensive network engineering design study. This must include a careful analysis of where the grandmaster clocks will be deployed and the performance and accuracy requirements they will need to provide. This assessment will guide the selection process for precision timing and synchronization equipment. Network planners and synchronization engineers should also consider the cost and other implications of choosing fanless equipment or equipment that requires fans, implementing redundancy through modular hardware or software, and whether to use embedded or modular GNSS. With the right information and a comprehensive understanding of their options, critical infrastructure operators can cost-effectively deploy the necessary redundancy, resiliency, and security to create a robust and reliable PNT solution.

More information on architectural choices and solutions can be found here. White papers on this and other topics can be downloaded via this link.