PTP Boundary Clock RTC Circuit Frequency Distribution
Solution Overview
Problem
Current Precision Time Protocol (PTP) systems for frequency synchronization in telecommunications networks require a Global Positioning System (GPS) receiver as a primary reference clock and do not support boundary clocks for redundancy and inter-GMOC communication, limiting their scalability and redundancy capabilities.
Innovation Solution
The implementation of a Sync-E Syntonization mechanism that allows frequency distribution across a PTP network with only one PTP network entrance requiring a synchronous source, eliminating the need for GPS receivers, and utilizing a data network node with a real-time clock (RTC) circuit that can operate in multiple modes based on available clock signals, providing a graceful clock-redundancy model and network path protection.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If GPS receiver is required as primary reference clock input for PTP grandmaster ordinary clocks, then frequency synchronization can be achieved, but device complexity and cost increase
Solution Approach 1:
The patent extracts and removes the GPS receiver requirement from the PTP grandmaster ordinary clock system. Instead of requiring GPS as a primary reference clock input, the invention uses alternative clock sources and synchronization methods that eliminate the need for GPS hardware while maintaining frequency synchronization capability.
Solution Approach 2:
The patent enables PTP clocks to function universally without being tied to GPS receivers. The system can operate with multiple clock sources including local oscillators and network-synchronized clocks, making the system adaptable to various deployment scenarios without requiring specialized GPS hardware.
2Adaptability or versatility
If boundary clock support is not allowed in PTP profile G.8265.1, then the protocol implementation is simpler, but scalability and redundancy capabilities are limited
Solution Approach 1:
The patent introduces boundary clock functionality that segments the PTP network into hierarchical levels. Boundary clocks can synchronize multiple slave clocks and propagate time information across network segments, enabling scalable network expansion without requiring all clocks to directly communicate with the grandmaster.
Solution Approach 2:
The patent introduces boundary clocks as intermediary devices between the grandmaster and slave clocks. These boundary clocks receive synchronization information from upstream and distribute it to downstream slaves, acting as mediators that enable network expansion and provide redundancy paths without complicating the core PTP protocol.
3Reliability
If inter-GMOC communication is not allowed, then synchronization control is simpler, but redundancy and fault tolerance are reduced
Solution Approach 1:
The patent implements feedback mechanisms that allow grandmaster ordinary clocks to communicate synchronization status and quality information. This enables the network to detect failures, switch to backup clocks, and maintain synchronization even when some GMOCs fail, providing redundancy without requiring complex manual control.
4Measurement precision
If Sync-E support is required on all PTP clocks, then phase distribution quality is improved, but device complexity and cost increase
Solution Approach 1:
The patent applies local quality by enabling Sync-E functionality only where needed in the network hierarchy. Boundary clocks and grandmaster clocks that require high precision phase distribution can implement Sync-E support, while simple slave clocks can operate with standard PTP synchronization, optimizing the balance between precision and complexity.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A data network node is configured for operation as a time-transfer boundary clock, and has at least one time-transfer slave network interface and several time-transfer master interfaces, all configured for operation according to a time-transfer protocol. The data network node also includes a clock source interface configured for connection to a synchronous clock source supplied from a remote node, as well as a real-time clock (RTC) circuit. The RTC circuit supplies time-of-day data for time-transfer messages sent via the second network port and selectively operates in a first mode, wherein the RTC frequency is driven by a clock signal from the clock source interface, a second mode, wherein the RTC frequency is driven by a clock signal derived from time- transfer messages received by the time-transfer slave interface, and a third mode, wherein the RTC frequency is driven by a local clock signal from local clock source.