Selecting and managing clock sources to enhance holdover and synchronization in precision time protocol (PTP) networks

Abstract

Systems and methods (300, 1030, 3080, 4090) are disclosed for selecting and managing clock sources in packet-based networks (10, 1010, 3010, 4010) to enhance holdover and synchronization recovery. A network element (100, 1016, 3036, 4020-2) receives timing information from multiple master clocks (12, 14, 1012, 3032, 4012) and monitors link stability (ptsfjinkstability), CRC errors (ptsfjinkcrc), and clock class fluctuations (ptsf_m asterci kclass). An enhanced Best Master Clock Algorithm (BMCA) (306) selects a stable grandmaster to reduce flapping. During holdover, an enhanced Best Time Transmitter Clock Algorithm (BTCA) (1030, 3080) considers a Frequency Traceable flag for Synchronous Ethernet (SyncE) sources (1018, 1020) to prioritize frequency-traceable clocks. When a Global Navigation Satellite System (GNSS) source (20, 3040, 3060) is unavailable, backup clocks (3074, 3076) are compared based on offset variability to select the most stable substitute. In branched systems (4010, 4030), Ethernet Synchronization Messaging Channel (ESMC) PDUs (4060) convey source recovery indicators, enabling downstream selection units (4022, 4042) to prefer physical-layer over packet-layer references, ensuring robust 5G / NR synchronization.

Description

Selecting and Managing Clock Sources to Enhance Holdover and Synchronization in Precision Time Protocol (PTP) NetworksCROSS-REFERENCE

[0001] This PCT Application claims priority to the following India and U.S. Patent Applications.:FIELD OF THE DISCLOSURE

[0002] The present disclosure relates generally to networking. More particularly, it pertains to systems and methods for maintaining accurate time synchronization in packet-based networks, including monitoring and selecting a stable Precision Time Protocol (PTP) master, enhancing holdover in PTP networks, selecting an alternative PTP backup source when a Global Navigation Satellite System (GNSS) reference is unavailable, and improving holdover or recovery in networks of synchronized clocks by selecting the best available clock source, such as a Synchronous Ethernet (SyncE) clock source.BACKGROUND OF THE DISCLOSURE

[0003] PTP is a network protocol defined by the IEEE 1588 standard for achieving precise time synchronization across devices in packet-switched networks. PTP operates by exchanging timestamped messages between master and slave clocks, enabling devices to measure and compensate for network delays. A core component of PTP is the Best Master Clock Algorithm (BMCA), which dynamically selects the most suitable clock to serve as the grandmaster by evaluating clock quality attributes in Announce messages (e.g., priority values, clock class, accuracy, variance, and identity). This decentralized process ensures that the network consistently synchronizes to the mostaccurate and reliable time source, thereby enhancing timing precision and robustness. PTP is defined in IEEE Std 1588-2019 (Revision of IEEE Std 1588-2008), published 16 June 2020, commonly referred to as IEEE 1588v2.x, the contents of which are incorporated by reference in their entirety.

[0004] For telecommunications applications, the International Telecommunication Union (ITU-T) has developed a comprehensive family of Recommendations for time, frequency, and phase synchronization. In particular, ITU-T G.8275.1 (11 / 2022) specifies a PTP telecom profile for phase / time synchronization with full timing support (FTS) from the network, while ITU-T G.8275.2 (11 / 2022) addresses partial timing support (PTS) scenarios where not all nodes provide synchronization. Performance criteria for equipment in these environments are defined in ITU-T G.8273.2 (06 / 2023) for boundary and slave clocks with FTS, and ITU-T G.8273.4 (08 / 2024) for time slave clocks with PTS. Collectively, these Recommendations define network architectures, clock performance requirements, and operational behaviors to ensure high-accuracy synchronization in both tightly controlled and more flexible deployment scenarios.

[0005] More broadly, the ITU-T synchronization framework encompasses Recommendations G.8264, G.8265.1 , G.8271 , G.8271.1 , G.8271.2, G.8272, G.8272.1 , G.8272.2, G.8273, G.8273.3, G.8275, and amendments thereto. Together with IEEE 1588 versions (2002, 2008, 2019), these standards provide the foundation for precise synchronization in modern communication networks. The contents of these synchronization Recommendations, protocols, and standards are incorporated by reference in their entirety.BRIEF SUMMARY OF THE DISCLOSURE

[0006] The present disclosure relates to systems and methods for improving time synchronization in packet networks using PTP. Conventional Best Master Clock Algorithm (BMCA) and Best Time Transmitter Clock Algorithm (BTCA) processes may result in unstable grandmaster selection, inadequate holdover performance, or suboptimal backup source selection, particularly when Global Navigation Satellite System (GNSS) sources are unavailable or when synchronized clocks operate in degraded conditions.

[0007] In various embodiments, the disclosure enhances BMCA operation by incorporating additional inputs such as operational state, physical link quality, and error statistics. These inputs allow selection not only of the best grandmaster but also the most stable grandmaster, reducing flapping, improving robustness of time synchronization, and supporting the requirements of 5G and 5G NR applications. The use of TTL values contained in the IP header of packets originating from clock sources such as T-GM nodes can additionally or alternatively be used for selection of a clock source.

[0008] The disclosure further enhances time holdover by extending BTCA to consider frequency traceability and backup quality. A Frequency Traceable flag, set when a node is traceable to a reliable source such as Synchronous Ethernet (SyncE), is advertised and used as a selection criterion. This ensures that, when nodes enter holdover, the system can select the option with superior frequency support, thereby improving stability and accuracy during prolonged synchronization outages.

[0009] In additional embodiments, the disclosure provides techniques for selecting among multiple backup PTP clocks when a GNSS reference becomes unavailable. Backup clocks are compared based on offset characteristics — such as peak-to-peak variability, average, or median offset values — derived over a recent time interval. The system then selects the backup source with the lowest variability as a substitute grandmaster, improving resilience against degraded or unreliable time inputs.

[0010] The disclosure also provides mechanisms for synchronization recovery in networks with multiple upstream branches, such as PTP and SyncE. Source recovery indicators may be signaled, for example, via Ethernet Synchronization Messaging Channel (ESMC), to convey the origin and reliability of frequency sources. A prioritization strategy then selects between upstream Master clocks, preferring physical-layer timing sources over packet-layer sources when appropriate, and enabling seamless recovery of frequency, phase, and time alignment.

[0011] Embodiments can involve monitoring stability and quality of timing information, and selecting a clock source as a reference based on same. The stability and quality information can include one or more aspects such as stability and quality of links, whether or not a clock frequency is traceable, clock offset characteristics, and timing source recovery information. The aspects can be based at least in part on characteristics of the network located between the selecting device and the ultimate source of timing information.

[0012] These techniques can be implemented as methods, network elements with appropriate circuitry, or non-transitory computer-readable media storing instructions that cause one or more processors to perform the steps. Collectively, the disclosed enhancements provide more stable grandmaster selection, improved holdover with reliable frequency support, intelligent selection of backup clocks during GNSS outages, and robust synchronization recovery across mixed PTP and SyncE environments.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The present disclosure is detailed through various drawings, where like components or steps are indicated by identical reference numbers for clarity and consistency.

[0014] FIG. 1 illustrates a network diagram of a network having two grandmasters, T- GM-1 , T-GM-2, for illustrating BMCA along with the additional details included therein for link stability, Cyclic Redundancy Check (CRC) errors, and master clock class.

[0015] FIG. 2 illustrates a block diagram of a network element, depicted in a simplified functional format.

[0016] FIG. 3 illustrates a block diagram of an example processing device.

[0017] FIG. 4 illustrates a flowchart of a process for monitoring and selecting a stable and best PTP master in a packet network.

[0018] FIG. 5 illustrates a network diagram of a network for illustration of the problems with the current Best Time Transmitter Clock Algorithm (BTCA) approach.

[0019] FIG. 6 illustrates a flowchart of a BTCA process that includes consideration of frequency to overcome the deficiencies described with reference to FIG. 5.

[0020] FIG. 7 illustrates a network diagram of the network in FIG. 5 for illustration of the BTCA process of FIG. 6.

[0021] FIG. 8 illustrates a network diagram of a network for illustrating another scenario where the BTCA decision may not be optimal based on the conventional approach.

[0022] FIG. 9 illustrates a network diagram of the network in FIG. 4 for illustration of the BTCA process of FIG. 6.

[0023] FIG. 10 illustrates a flowchart of a process for an enhanced BTCA process that enhances time holdover in a PTP network involve leveraging the best available frequency support while disqualifying time input from a degraded PTP clock.

[0024] FIG. 11 illustrates a diagram of an embodiment of a system for improving holdover of a PTP network.

[0025] FIG. 12 illustrates a diagram of an embodiment of a system for improving holdover in an APTS network.

[0026] FIG. 13 illustrates a diagram of an embodiment of a system for improving holdover in an APTS network.

[0027] FIG. 14 is a graph illustrating an example of offset from a primary time reference (e.g., local time reference, GNSS or GPS time source, etc.) over time.

[0028] FIG. 15 illustrates a flow diagram of a process that represents an enhancement to the BTCA as described in various synchronization standards and protocol.

[0029] FIG. 16 illustrates a flow diagram of a process for selecting a backup clock source.

[0030] FIG. 17 is a diagram illustrating an embodiment of a branched communication system in which a clock is selected from upstream Masters for synchronization recovery.

[0031] FIG. 18 illustrates a diagram of another embodiment of a branched communication system in which a clock is selected for synchronization recovery.

[0032] FIG. 19 illustrates a chart showing the Protocol Data Unit (PDU) designation for the Ethernet Synchronization Message Channel (ESMC) as defined in ITU-T Rec. G.8264.

[0033] FIG. 20 illustrates a table showing an embodiment of a bit designation scheme whereby two bits (e.g., “bit x” and “bit y”) are used for indicating characteristics of a frequency recovery source of a Master node.

[0034] FIG. 21 illustrates a flow diagram of an embodiment of a process for selecting a backup clock source.

[0035] FIG. 22 illustrates a network diagram of a network having two grandmasters, T-GM-1 and T-GM-2, for illustrating the impact of hop counts on PTP master selection.

[0036] FIG. 23 illustrates a network including ITU interworking functions (IWFs) in G.8275 that translate between profiles, for example from G.8275.2 to G.8275.1.

[0037] FIG. 24 illustrates a flowchart of a BTCA process that includes consideration of TTL values to overcome the deficiencies described with reference to FIGS. 22-23.

[0038] FIG. 25 illustrates the fields of an Announce packet, including the reserved field renamed as “ptpUnawareHopsToUpstreamTimeTransmitter.”DETAILED DESCRIPTION OF THE DISCLOSURE

[0039] The present disclosure relates to systems and methods for enhancing time synchronization in packet-based networks by unifying improvements across multiple aspects of Precision Time Protocol (PTP) operation and associated synchronization frameworks. In particular, the disclosure builds upon conventional IEEE 1588 and ITU-T Recommendations by extending the Best Master Clock Algorithm (BMCA) to consider additional inputs such as link stability, CRC errors, and master clock class stability; augmenting the Best Time Transmitter Clock Algorithm (BTCA) with frequency traceability awareness to improve holdover performance; introducing selection techniques for backup clocks when Global Navigation Satellite System (GNSS) references are unavailable by comparing offset variability; and enabling synchronization recovery in branched network architectures by incorporating source recovery indicators, such as in Ethernet Synchronization Messaging Channel (ESMC) signaling, to prioritize physical-layer frequency sources over packet-based alternatives. Collectively, these techniques improve stability of grandmaster selection, extend reliable holdover during degraded conditions, enhance backup clock selection, and ensure resilient synchronization recovery in multi-branch PTP and SyncE networks.§1 Monitoring and Selecting a Stable and Best PTP Master

[0040] Again, the present disclosure relates to systems and methods for monitoring and selecting a stable and best PTP master in a packet network. Relevant standards include IEEE Standard 1588-2019, “IEEE Standard fora Precision Clock Synchronization Protocol for Networked Measurement and Control Systems,” Institute of Electrical and Electronics Engineers, ITU-T Recommendation G.8275.1 (2016), “Precision time protocol telecom profile for phase / time synchronization with full timing support from the network,” International Telecommunication Union, ITU-T Recommendation G.8275.2 (2016), “Precision time protocol telecom profile for phase / time synchronization with partial timing support from the network,” International Telecommunication Union, the contents of each are incorporated by reference in their entirety.

[0041] IEEE 1588 defines PTP, enabling precise synchronization of clocks across networked devices with sub-microsecond accuracy. The standard outlines the mechanisms for clock synchronization, including the exchange of timestamped messages and the BMCA algorithm for selecting the optimal master clock within a network. The 2019 revision of IEEE 1588 introduces enhancements like improved accuracy, robustness against network delays, and security features to protect against timing attacks. A grandmaster clock in a PTP network serves as the primary source ofaccurate time for all devices within that network. It is the topmost clock selected through the BMCA algorithm, which assesses all clocks based on criteria like priority levels, clock class, accuracy, and stability to determine the most qualified one. Once designated, the grandmaster clock distributes its precise time information to subordinate clocks by sending timestamped messages, ensuring that all devices are synchronized. ITU-T G.8275.1 specifies a PTP profile tailored for precise time and phase synchronization in telecom networks and includes modifications to the standard BMCA to suit telecommunication requirements. ITU-T G.8275.2 defines telecom profile for phase and time synchronization in networks that provide partial timing support, enabling accurate synchronization even when only some network elements are timing-aware.

[0042] Note, the terms master and grandmaster clock are related, but not identical. The grandmaster clock is the primary source of time for the entire network — the most accurate and stable clock selected through the BMCA. It sits at the top of the synchronization hierarchy and provides the reference time to all other clocks in the network. A master clock, on the other hand, is any clock that provides synchronization to one or more subordinate clocks (sometimes called slave or ordinary clocks). In hierarchical PTP networks, there can be intermediate master clocks that receive time from the grandmaster and distribute it downstream to other devices. These master clocks act as both slaves (to their upstream master or grandmaster) and masters (to their downstream slaves). Therefore, while all grandmaster clocks are master clocks, not all master clocks are grandmasters. The grandmaster is the ultimate master clock in the network, whereas master clocks can exist at various levels within the synchronization hierarchy.

[0043] A T-GM, or Telecom grandmaster, is a specialized grandmaster clock used in telecommunications networks that implement PTP. Specifically defined in recommendations like ITU-T G.8275.1 and G.8275.2, the T-GM serves as the primary source of precise time and phase synchronization for telecom networks requiring high levels of accuracy. In the context of PTP, the T-GM distributes accurate timing information to downstream network elements such as Telecom Boundary Clocks (T-BCs) and Telecom Time Slave Clocks (T-TSCs). It interfaces with a highly accurate reference time source, typically a Global Navigation Satellite System (GNSS) like GPS. The T-GM then uses PTP to propagate this timing information across the network, ensuring that all devices are synchronized to the same precise time. The T-GM is designed to meet thestringent synchronization requirements of modern telecom applications, such as 4G LTE- Advanced and 5G networks.

[0044] BMCA is used to select both the grandmaster clock (i.e. , the T-GM) and the master clocks. BMCA operates by having each device in the network exchange Announce messages containing their clock attributes. Based on these attributes, each device independently evaluates and determines the best clock to act as the grandmaster — the primary source of time for the entire network. In addition to selecting the grandmaster clock, BMCA also helps establish the hierarchical relationships between clocks at different levels. Devices like boundary clocks and ordinary clocks use BMCA to decide whether they should function as master or slave clocks relative to their neighbors. This means that BMCA is continually used to configure the roles of devices throughout the network, creating a synchronized hierarchy where master clocks provide timing to slave clocks downstream.

[0045] Of note, BMCA reacts on every event and is designed to always select best master or grandmaster. Specifically, BMCA operates continuously by having each clock regularly exchange Announce messages containing their clock attributes. Upon receiving these messages, each clock independently evaluates the potential masters using a hierarchical set of criteria defined by the BMCA. This evaluation process is ongoing, allowing each device to maintain an up-to-date understanding of the best available master clock. BMCA reacts to every event by dynamically adjusting to changes in the network. For instance, if a new clock with superior attributes joins the network, its Announce messages prompt other devices to recognize it as the new best master, leading them to reconfigure their synchronization accordingly. Conversely, if the current grandmaster clock fails or its quality degrades, other clocks detect the absence or decline in its Announce messages and automatically select the next best master based on the BMCA criteria. This continual operation ensures that the network promptly responds to events like clock additions, removals, or fluctuations in clock performance, maintaining optimal synchronization across all devices.

[0046] If there are momentary failures, then BMCA switches to next available best master and can reselect old master after the failures clear, and these additional BMCA reselections may cause transients and convergence issues related to the synchronization.

[0047] An objective herein is to reduce network transients and convergence delays caused by T-GM reselection and restoration. Specifically, the BMCA is enhanced toconsider additional inputs related to the operation state and statistics on physical links in the network, in addition to standard inputs related to clock stability. These additional inputs enhance BMCA to select the best and most stable master, rather than a better clock at the moment that is less stable. This enhancement helps 5G network operators in maintaining T-GM resiliency by selecting the stable and best T-GM considering network stability factors. This enhancement also helps in reducing network transients and network convergence delays caused by T-GM reselection and restoration.

[0048] In an example use case, 5G applications demand stringent time alignment across the radio elements, and PTP is the best solution to deliver the required timing accuracy over the packet-based network. Accordingly, PTP accuracy and performance has become a critical Key Performance Indicator (KPI) for the 5G network. It has been determined that network issues related to link stability, CRC errors, and the PTP master clock stability itself can cause a slave clock to flap or end up with PTP providing bad accuracy.

[0049] Long Term Evolution- Time Division Duplexing (TDD) (LTE-TDD) and 5G NR network timing accuracy requirements are in the nanosecond range, and debugging any PTP issue in a production network is complex. However, the consequences of operational problems are severe, having a high impact on service stability. With 5G adoption, PTP protocol stability and its capability to handle network failures has become a key demand of every network operator.

[0050] Today, ITU-T BMCA and Alternate BMCA algorithms are available to support master clock resiliency, however during selection of a master clock, they do not account if there are network issues like link instability, CRC errors, or frequent changes in PTP Master ClockClass parameter. Link instability and CRC errors can have a significant impact on the operation of BMCA. BMCA relies on the regular and reliable exchange of Announce messages and other PTP packets to evaluate and select the optimal master and grandmaster clocks for synchronization. If a network link is unstable or experiencing high CRC errors, PTP messages may be delayed, lost, or corrupted. This can cause devices to miss or misinterpret Announce messages, leading them to incorrectly assume that the current grandmaster is unavailable or that a better master clock has become available. As a result, the BMCA may trigger unnecessary re-elections of the grandmaster, causing frequent switching between master clocks — a phenomenon known as flapping. This instability disrupts the time synchronization across the network,potentially degrading the performance of time-sensitive applications and leading to synchronization errors.

[0051] Also, frequent changes in the PTP Master ClockClass parameter can significantly impact the operation of BMCA. The ClockClass parameter is a critical attribute that indicates a clock's quality and traceability to a primary time source; it plays a key role in BMCA's selection of the grandmaster clock. If a clock's ClockClass value fluctuates often — due to issues like intermittent GPS signals or instability in its reference time source — BMCA will continuously re-evaluate the hierarchy of clocks in the network. This can lead to frequent switching between master clocks, i.e., flapping, causing instability in time synchronization. Such instability can degrade the performance of timesensitive applications by introducing synchronization errors and reducing overall network reliability.

[0052] Since these details are not considered in BMCA and its variants, it can lead to BMCA switching back and forth between primary and backup masters.

[0053] FIG. 1 illustrates a network diagram of a network 10 having two grandmasters, T-GM-1 , T-GM-2, 12, 14, for illustrating BMCA along with the additional details included therein for link stability, CRC errors, and master clock class. The network 10 includes the T-GM-1 12 and the T-GM-2 14 and two T-BCs 16, 18, each of which can be at a network element in the network 10. FIG. 2 illustrates a diagram of a network element 100.

[0054] By deploying two T-GMs 12, 14, one can act as the primary time source while the other serves as a backup; if the primary fails, the BMCA automatically selects the backup, ensuring continuous synchronization. Additionally, having T-GMs 12, 14 in different locations can reduce latency and improve accuracy by allowing devices to sync with the nearest T-GM 12, 14. This setup also facilitates load balancing and enables network segments to operate independently during failures or maintenance. Proper configuration of BMCA priorities and careful network design are essential to prevent timing loops and ensure consistent synchronization across the network when multiple T- GMs are present.

[0055] The T-BCs 16, 18 connect to the T-GMs 12, 14 by receiving timing messages from the T-GM, adjusting for network delays, and synchronizing their local clocks. After synchronization, the T-BCs 16, 18 forward accurate timing information downstream to other devices or further T-BCs, ensuring that precise time is maintained across the network. In this example, the T-BC 18 connects to both the T-GMs 12, 14, whereas the T-BC 16 connects to the T-GM 12 and the T-BC 18. The T-BC 16 can select betweenthe T-GM 12 and the T-BC 18 using BMCA. Additionally, GPS 20 can provide frequency and phase references to the T-GMs 12, 14 and a testing device 22 connected to the T- BC 16.

[0056] In this example, links between the T-GM 12 and the T-BCs 16, 18 are unstable. This can cause the T-BC 18 to flap between the T-GM 12 and the T-GM 14, as well as the T-BC 16 to flap between the T-GM 12 and the T-BC 18. This constant flapping between T-GM 12, 14 will cause not only transient jump but will also cause Timestamp jumps for PTP Servo algorithm on the T-BC 18 as the path to different PTP Masters may have different Link Asymmetries. Of note,

[0057] PTP Telecom Synchronization Fail (PTSF) alarms are used in PTP and in the BMCA. These alarms serve as indicators when a device experiences synchronization failures, prompting the BMCA to take appropriate actions to maintain network-wide timing accuracy. Here’s how PTSF alarms interact with BMCA:

[0058] (1 ) Detection of Synchronization Issues: When a device (e.g., a TelecomBoundary Clock (T-BC) or Telecom Time Slave Clock (T-TSC)) experiences problems like loss of Sync messages or Announce messages, it raises PTSF alarms such as PTSF-lossSync or PTSF-lossAnnounce. These alarms indicate that the device can no longer maintain reliable synchronization with its current master clock.

[0059] (2) Re-Evaluation of the Clock Hierarchy: Once a PTSF alarm is raised, BMCA is triggered to re-evaluate the available master clocks. The BMCA checks whether a better master or grandmaster clock is available by comparing the clock attributes (e.g., ClockClass, priority levels, accuracy, stability) from the received Announce messages of other clocks in the network.

[0060] (3) Selection of a New Master: If the current master clock is deemed unusable(e.g., because it has stopped sending Announce messages or is providing inaccurate time), BMCA will select a new master or grandmaster based on the best available clock attributes. This ensures that the device can maintain synchronization even in the event of a failure.

[0061] (4) Fallback to a Backup Master: In cases where a grandmaster clock or upstream T-BC fails and a PTSF alarm is triggered, BMCA can select a backup master or grandmaster. This process ensures network resilience and continuity of time synchronization by allowing devices to switch to a different clock when synchronization from the original source is lost.

[0062] (5) Continuous Monitoring and Recovery: BMCA continuously monitors the network, using PTSF alarms to detect issues in real time. If the original master clock recovers or a better one becomes available, BMCA will re-select the optimal master based on updated clock attributes, ensuring that devices always synchronize to the best possible source.

[0063] Existing PTSF alarms include:

[0064] (1) PTSF-lossSync: Loss of Sync messages.

[0065] (2) PTSF-lossAnnounce: Loss of Announce messages.

[0066] (3) PTSF-lossFollowUp: Loss of Follow_Up messages.

[0067] (4) PTSF-unusable: Unusable timing information.

[0068] (5) PTSF-holdover: Device in holdover mode.

[0069] An active PTSF alarm affects BMCA by indicating that the current master clock is no longer providing reliable synchronization, prompting the BMCA to re-evaluate the network’s clock sources. The affected master is deprioritized or excluded from consideration, and BMCA searches for a new, more reliable master clock from the remaining available clocks. This ensures that the device maintains synchronization despite the failure. If multiple clocks are available, BMCA selects the best alternative, ensuring continuous network stability and accurate time synchronization.

[0070] The present disclosure adds three new PTSF alarms, which can be used individually or in combination with one another and with other PTSF alarms, to select a best stable master. The three new PTSF alarms include

[0071] (1) Link Stability (ptsf_linkstability)

[0072] (2) CRC errors on the link (ptsf_linkcrcj

[0073] (3) Master Clock class flap (ptsf_masterclkclass)

[0074] These alarms can be used individually or in combination with one another, along with the other PTSF alarms, i.e., PTSF-lossSync, PTSF-lossAnnounce, PTSF- lossFollowUp, PTSF-unusable, and PTSF-holdover. Specifically, these three new PTSF alarms are raised and used to dissuade BCMA from selecting a given clock when present, indicating stability issues either on the link (link stability or CRC errors) or on the clock (clock class flap).

[0075] (1 ) Link Stability (ptsfjinkstability) - This property indicates whether the physical link or network path towards each PTP Master is regarded as reliable. In an embodiment, the default value is FALSE meaning the physical link or network path is reliable, and it is set to TRUE as soon as a link down or link quality issue is detected.When the link is restored or the link quality improves, then a wait to restore timer is started.

[0076] Measuring link stability on a packet link involves assessing key factors like packet loss, latency, jitter, and throughput consistency. Those skilled in the art will appreciate there are various techniques to monitor packet loss, latency, jitter, and throughput consistency, all of which are contemplated herewith. These generally include test packets sent for measuring these aspects as well as heartbeat packets to monitor link continuity. Any method of detection of an issue in the network path is contemplated and can be done by using any existing protocols or any implementation specific method. For example, G.8275.2 uses PTP over Internet Protocol (IP) and that’s why PTP layer may not be aware of the physical link used for PTP over IP packet transmission hence it will use some method to find out the link being used for PTP packet exchange. That physical link needs to be monitored for this PTSF.

[0077] Detection of link stability is considered as one or more failures in a specific time duration. This duration and number of failures can be configurable. When running, the wait to restore timer restarts if another link down or reliability issue is detected, otherwise the property ptsf Jinkstability is set to FALSE on expiry. The wait to restore timer value can also be configurable.

[0078] (2) CRC errors on the link (ptsfjinkcrc) - CRC errors represent the number of packets arriving that failed the CRC check and are assumed to be corrupted. CRC is an error-detection mechanism used to ensure the integrity of data transmitted over a network. The sender generates a CRC value from the data using an algorithm and attaches it to the packet. Upon receipt, the receiver recalculates the CRC value from the data and compares it with the attached CRC. If the values match, the data is considered intact; if not, the packet is flagged as corrupted. CRC checks efficiently detect common transmission errors like bit flips, helping maintain data integrity with minimal overhead in real-time communication systems._Additionally, a device can use the reliability number for this purpose, which is a metric indicating the ratio of error free versus total packets.

[0079] In an embodiment, the default value for ptsfjinkcrc is FALSE, i.e. , no CRC errors. There can be a threshold for CRC error in last n seconds. After detecting more than a certain number of CRC errors in the previous n seconds, the property ptsf_li nkcrc is set to TRUE and the wait to restore timer is started. When the wait to restore timer is running, the timer restarts if CRC errors are again seen within n seconds, otherwise the property ptsfjinkcrc is set to FALSE on expiry.

[0080] (3) Master Clock class flap (ptsf_masterclkclass) - This property is maintained for every defined master, and, in an embodiment, it is set to TRUE as soon as a clock class flap is detected in the Announce message of that Master. At the same time, the wait to restore timer is started. When the wait to restore timer is running, this timer restarts if a clock class flap is again detected, otherwise the property ptsf_masterclkclass is set to FALSE on expiry.

[0081] Any change in the state of the properties in the three new PTSF alarms triggers the BMCA selection process to reselect a new stable master as the best. The BMCA only considers masters for selection that have the above PTSF properties set to FALSE. Of course, if all clocks have PTSF alarms, BMCA can select the clock with the least severe alarms.

[0082] FIG. 2 illustrates a block diagram of a network element 100, depicted in a simplified functional format. It is important to note that a more practical design of this router would likely include additional components and processing logic to accommodate standard operating features, which are not detailed here. The network element 100 may represent any network element operable in a network using optical and packet protocols, and includes various interconnected modules, such as modules 102 and 104, via an interface 106. These modules, also known as blades or line cards, are typically mounted on the chassis of a data switching device. Each module can house numerous electronic or optical devices on a circuit board, complete with various interconnects, including interfaces to the chassis itself.

[0083] Specifically, the diagram illustrates two types of modules: line modules 102, which feature multiple Ethernet ports for external connections, and a control module 104. The line modules facilitate data traffic switching between ports via a switching fabric, integrated across the modules, potentially centralized in a separate unit or module, as well as a combination. This switching fabric includes hardware, software, and firmware that routes incoming data to the appropriate port. The control module 104 is equipped with a microprocessor, memory, software, and a network interface to manage operations such as configuration and monitoring of the network element 100. It may also communicate with external network management systems or databases that handle provisioning and operational data.

[0084] Lastly, while FIG. 2 provides a basic view, those skilled in the art will understand that the network element 100 could include additional components or be configured differently, such as in a distributed arrangement or as an integrated, rack-mounted unit (often referred to as a "pizza-box" configuration). This depiction in FIG. 2 is intended to convey functional aspects, with actual hardware implementations varying widely.

[0085] The hardware configuration of a T-GM in the network element 100 is designed to serve as the primary source of precise time. It typically includes a highly accurate reference clock, such as a GPS / GNSS receiver or atomic clock, and an internal oscillator, such as a rubidium or oven-controlled crystal oscillator (OCXO), to maintain time during temporary losses of the external reference. The T-GM also includes time stamping units (TSUs) for generating and inserting accurate timestamps into PTP messages, ensuring sub-microsecond precision in time distribution. High-performance network interface cards (NICs) with multiple ports allow the T-GM to communicate with downstream devices, distributing time synchronization across the network, while synchronization control modules manage timing and monitor the system for issues, raising alarms when necessary. The T-BC, as an intermediary device, is configured to receive and forward timing messages from upstream clocks, such as the T-GM. It also includes time stamping units (TSUs) to adjust for delays and ensure accurate forwarding of timing data to downstream devices. T-BCs have high-performance network interfaces and built-in oscillators (typically TCXOs or OCXOs) to maintain time accuracy during brief disruptions. The hardware also includes packet-processing engines for low-latency handling of PTP messages and monitoring systems for detecting synchronization issues. Both T-GM and T-BC devices support redundancy and monitoring features like SNMP to ensure reliable time synchronization in telecom networks, where accuracy is critical.

[0086] FIG. 3 illustrates a block diagram of an example processing device 200. The processing device 200 may be integrated within the network element 100 or function as a standalone unit connected to the network element 100. It may also be known as an apparatus, a control module, shelf controller, shelf processor, or system controller. The core of the processing device 200 is a processing unit 202, a hardware unit that runs software instructions. The processing unit 202 could be one or more custom or commercially available processors, i.e. , one or more processors. During operation, the processing unit 202 executes software from memory, manages data communication with the memory, and controls the processing device 200 operations based on the software.

[0087] The processing device 200 also features several components connected to the processing unit 202: a network interface 204, a data store 206, memory 208, and an I / O interface 210. The network interface 204, possibly an Ethernet device, allows theprocessing device 200 to communicate over a data network and includes necessary connections for address, control, and data communication. The data store 206 stores various types of data such as telemetry data, Operations, Administration, Maintenance, and Provisioning (OAM&P) data, etc., and may include both volatile (e.g., RAM) and nonvolatile (e.g., ROM, hard drives) memory elements. Similarly, the memory 208 includes volatile and nonvolatile storage media, potentially employing a distributed architecture where components are located remotely but accessible by the processing unit 202. The I / O interface facilitates communication between processing device 200 and external devices.

[0088] FIG. 4 illustrates a flowchart of a process 300 for monitoring and selecting a stable and best Precision Time Protocol (PTP) master in a packet network. The process 300 can be implemented as a) methods having steps, b) circuitry configured to implement the steps, c) a network element configured to implement the steps, and d) non-transitory computer-readable media storing instructions for programming one or more processors to execute the steps.

[0089] The steps include communicating with a master clock for Precision Time Protocol (PTP) (step 302); monitoring one or more of link stability to the master clock, errors in packets to the master clock, and clock class stability of the master clock (step 304); and performing a Best Master Clock Algorithm (BMCA) based on the monitored one or more of the link stability, the errors, and the clock class stability (step 306). The BMCA is further performed based on one or more of loss of synchronization messages, loss of announce messages, loss of follow up messages, unusable timing information, and a holdover mode. The monitored one or more of the link stability, the errors, and the clock class stability can each be a PTP Telecom Synchronization Fail (PTSF) alarm. The BMCA can be performed responsive to an alarm for the monitored one or more of the link stability, the errors, and the clock class stability.

[0090] In an embodiment, the BMCA is performed based on the link stability where an alarm is raised when a quality issue of a link to the master clock is detected, and where the alarm is removed after a wait to restore time where the quality issue is not detected during the wait to restore time. The quality issue can be based on any of packet loss, latency, jitter, and throughput consistency. In another embodiment, the BMCA is performed based on the errors which are Cyclic Redundancy Check (CRC) where an alarm is raised when a certain number of CRC errors are detected on a link to the master clock, and where the alarm is removed after a wait to restore time where the CRC errorsnot detected during the wait to restore time. In a further embodiment, the BMCA is performed based on the clock class stability where an alarm is raised when a certain number of clock class flops are detected on the master clock, and where the alarm is removed after a wait to restore time where the clock class flops are not detected during the wait to restore time. Additionally or alternatively, TTL values in IP packets transmitted by clock sources such as the master clock(s) can be used can be used to influence clock selection, as described elsewhere herein. TTL values, variations thereof, or both, can be used as indicators of link quality.§2 Enhancing Time Holdover in a FTP network

[0091] Also, in a packet network, a switch, router, or any network device such as an evolved node B (eNodeB) (also referred to herein as a node) use the PTP to achieve time synchronization by exchanging timestamped packets with PTP masters and slaves in the network. The protocol ensures accurate synchronization of clocks across network elements by compensating for delays introduced by packet transmission. The switch acts as either a PTP boundary clock or a PTP transparent clock, where boundary clocks synchronize with an upstream source and distribute timing downstream, while transparent clocks measure and correct for delay variations within the network. This precise timing is critical in 5G applications, where ultra-reliable low-latency communication (URLLC), time-sensitive networking (TSN), and massive machine-type communications (mMTC) demand highly accurate synchronization to meet stringent latency and jitter requirements. The clocks may be synchronized both with respect to the time at which they update to the next state, as well as an indication of the current clock state for example representing a cumulative count of past state changes.

[0092] Timing in these networks originates from Primary Reference Clocks (PRCs), which are highly stable and accurate clock sources compliant with ITU-T standards, such as those described herein. PRCs typically derive their timing from atomic clocks or Global Positioning Satellite (GPS) systems, providing the foundation for network-wide synchronization. Secondary Synchronization Units (SSU-A clocks) act as intermediate timing sources that maintain synchronization during short interruptions in PRC availability. These clocks, designed with holdover capabilities, ensure continuity and accuracy of timing even in challenging scenarios. Together, PTP-enabled switches, PRCs, and SSU-A clocks enable the precise timing required for the seamless functioning of advanced 5G networks.

[0093] The duration a node can remain in holdover is directly determined by the quality of its frequency source. A node with a clock traceable to a PRC will typically exhibit slower time deviation compared to one relying on a SSU-A clock, which is less stable. In scenarios where two interconnected nodes lose connectivity to the grandmaster Clock (GMC), the network protocol dictates that one node assumes the role of Master while the other becomes a Slave. The Slave node synchronizes with the Master and thus inherits the same rate of deviation as the Master. However, challenges arise when the node selected as the Master does not have a robust frequency backup and deviates rapidly. In such a case, even the Slave node, despite having a better frequency source, would deviate at the same accelerated rate as the Master, leading to suboptimal network synchronization. This issue is a direct consequence of the Best TimeTransmitter Clock Algorithm (BTCA) defined in ITU-T G.8275.2 Amendment 1 and G.8275.2. The BTCA selects the Master based on predefined criteria, which may not always account for the quality of the frequency backup, potentially compromising the stability and accuracy of the overall network timing during holdover. FIG. 5 illustrates a network diagram of a network 1010 for illustration of the problems with the current BTCA approach.

[0094] As mentioned previously, a T-GM 1012, or Telecom grandmaster, is a specialized grandmaster clock used in telecommunications networks that implement PTP. The T-GM 1012 distributes accurate timing information to downstream network elements such as Telecom Boundary Clocks (T-BCs) 1014, 1016 and Telecom Time Slave Clocks (T-TSCs). The T-GM 1012 interfaces with a highly accurate reference time source, typically a Global Navigation Satellite System (GNSS) 1016 like GPS. The T-GM 1012 then uses PTP to propagate this timing information across the network 1010, ensuring that all devices are synchronized to the same precise time.

[0095] The BTCA in ITU-T G.8275.2 plays a vital role in ensuring robust time synchronization in networks with Partial Timing Support (PTS). G.8275.2 addresses scenarios where not all network elements provide full timing support, i.e., the PTS, making it more challenging to maintain synchronization accuracy. The BTCA is designed to select the Best Time Transmitter (BTT) among multiple PTP clocks available in the network 10. It evaluates various parameters, such as those contained in PTP Announce messages, including clock priority, clock quality, and stability, to determine the most reliable source of timing. In a PTS environment, where some nodes 1014, 1016 may lack full synchronization support, the BTCA ensures that nodes can make informed decisions about which time source to use. Unlike the Best Master Clock Algorithm (BMCA), theBTCA incorporates a stronger focus on the quality of frequency backup and the reliability of timing inputs, which is critical for networks prone to disruptions or partial support scenarios. By selecting the most stable and accurate clock, the BTCA enhances the resilience of synchronization systems in G.8275.2 networks, ensuring continuity and precision in time distribution even when full timing support is unavailable. The Alternate Best Time Clock Algorithm (A-BTCA) is a variation of the BTCA designed to enhance timing resilience by incorporating additional criteria, such as topology awareness or specific network conditions, for selecting the Best Time Transmitter, whereas the standard BTCA primarily focuses on predefined parameters like clock quality and frequency backup, without accounting for network-specific factors.

[0096] With respect to the terms master and grandmaster, a grandmaster clock, e.g., the T-GM 1012, is the primary source of time for the network 1010. It is chosen based on its superior clock quality, stability, and attributes such as priority and accuracy. The grandmaster is responsible for providing the reference time to all other clocks in the network 1010, which synchronize with it to maintain accurate timing. A master clock, on the other hand, is any clock in the network that is actively distributing timing information to other clocks (slaves) within its domain. While the grandmaster clock is always a master clock, not all master clocks are grandmaster clocks. For instance, in certain network configurations or holdover scenarios, a local node might become a master clock temporarily, distributing time to nearby devices even though it is not the primary reference (GMC). In BTCA, the distinction becomes significant during degraded scenarios or holdover periods. The algorithm may select a master clock to act as the active timing source based on its relative stability and quality in that specific context, even if it is not the original grandmaster. This ensures that timing accuracy is preserved as much as possible, especially in networks with Partial Timing Support (as in G.8275.1 ). Thus, while the grandmaster is the preferred ultimate time source, BTCA allows for flexibility in selecting an alternative master clock based on the best available timing conditions. The present disclosure addresses improvements in BTCA for selecting the master clock during disruptions to the grandmaster, for purposes of improving holdover.

[0097] In the network 10, the T-GM 1012 and the T-BCs 1014, 1016 are at the nodes or network elements and links A, B, C, D, E interconnect the various nodes. For illustration purposes, the T-BC-2 1016 has a backup local Synchronous Ethernet (SyncE) clock 1018 other than its congruent primary PTP connection to the T-GM 1012, thus if the T-BC-2 1016 loses (due to degradation) the PTP connection, it still has its PRC 1020traceable to the SyncE clock 1018. However, the existing BTCA does not check Frequency T raceability (one of the flags in the PTP Announce Message) of its local clock or the PTP clock input. As a result of this, BTCA may end up selecting, as its source, a PTP clock which is in holdover rather than selecting a better source, including one being in its Time holdover with an available PRC traceable Frequency input.

[0098] An example is illustrated in FIG. 1 , where the T-BCs 1014, 1016 lose or have a degradation to the T-GM 1012. Here, the BTCA on T-BC-2 1016 selects T-BC-1 1014 as its Time Transmitter for its PTP input, despite T-BC-2 1016 having its PRC 1020 traceable to the SyncE 1018 frequency source. Consider following sequence of events:

[0099] (1 ) The T-GM 1012 goes into Holdover.

[0100] (2) The T-BC-1 1014 and the T-BC-2 1016 also go into a Holdover state.

[0101] (3) The T-BC-1 1014 and the T-BC-2 1016 start publishing Holdover ClockClass (CC) to each other on the link C.

[0102] (4) The T-BC-1 1014 and the T-BC-2 1016 each run BTCA / A-BTCA algorithms and end up with one node as a Time Transmitter and the other as a Time receiver.

[0103] (5) In the given scenario, the T-BC-2 1016 has the PRC 1020 frequency input.Despite this fact, since BTCA / A-BTCA algorithms do not consider frequency traceable flags, the result may be that the T-BC-1 1014 is selected as the Time Transmitter.

[0104] The selection of T-BC-1 1014 as the time source is suboptimal because its time will drift according to the quality of its own oscillator. Similarly, an evolved Node B (eNodeB) 1022 could end up using the T-BC-1 1014 clock, causing its time to drift based on T-BC-1 1014's holdover performance.

[0105] The present disclosure addresses the deficiencies in the above topology, namely that BTCA could still select the T-BC-1 1014 as the time transmitter (which is drifting at faster rate than the T-BC-2 1016). Of course, this adversely affects the holdover duration of the PTP clock considering the fact that the PRC 20 backup can provide a very long duration holdover to the network 1010 as compared to a stratum 3 local oscillator at the T-BC-1 1014.

[0106] FIG. 6 illustrates a flowchart of a BTCA process 1030 that includes consideration of frequency to overcome the deficiencies described with reference to FIG. 5. The BTCA process 1030 is implemented by any node in the network 1010, such as the T-BC-1 1014, T-BC-2 1016, and the eNodeB 1022, when there is a need to select a new time transmitter. It is contemplated that the BTCA process 1030 may be implemented as a method with steps, via circuitry configured to implement the steps, andas a non-transitory computer-readable medium storing instructions that, when executed, cause circuitry to implement the steps.

[0107] The BTCA process 1030 is an enhancement of the BTCA specified in ITU-T Recommendation G.8275.2 Amendment 1 , Figure 3. The BTCA process 1030 is used by a node to select a time transmitter based on the data sets, referred to as data sets A and B each of which correspond to the attributes of two distinct clocks being compared to determine the Best Time Transmitter (BTT). These data sets are constructed from parameters extracted from the PTP Announce messages exchanged between clocks in the network 10. The algorithm ensures systematic evaluation of both clocks to select the optimal timing source, essential for maintaining synchronization accuracy and stability. For example, in FIG. 5, the data set A could correspond to the T- BC-1 1014 and the data set B could correspond to the T-BC-2 1016.

[0108] The BTCA process 1030 works by comparing various points in the data sets A and B and selects either A or B at each step based on a comparison or moves to the next step if the values are equal. First, the BTCA process 1030 compares the clockClass values of the data sets A and B (step 1031), selecting the lower value or moving to the next step. That is, the lower clockClass value indicates the better clock. The clockClass values indicates a clock's traceability and stability, reflecting its synchronization quality and reliability within the network 1010.

[0109] Next, the BTCA process 1030 compares the clockAccuracy values of the data sets A and B (step 1032), selecting the lower value or moving to the next step. Also, the lower clockAccuracy value indicates the better clock. The clockAccuracy values specify the precision of a clock's timekeeping relative to a reference standard, indicating how closely the clock's time aligns with the true time. Next, the BTCA process 1030 compares the OffsetScaledLogVariance values of the data sets A and B (step 1033), selecting the lower value or moving to the next step. The OffsetScaledLogVariance values quantify a clock's stability by measuring the variance of its time offset, providing insight into its precision and frequency consistency over time.

[0110] The present disclosure introduces a new check of a Frequency T raceable flag of the data sets A and B (step 1034), selecting one that is true if the other is false, or moving to the next step if both are the same. The Frequency T raceable flag is an indicator within PTP message headers that specifies whether the clock's frequency is traceable to a recognized primary reference, such as the PRC 1020. When this flag is set to 'true,' it signifies that the clock's frequency is derived from a reliable and accurate source,ensuring synchronization stability across the network. Conversely, if the flag is set to 'false,' it suggests that the clock's frequency may not be traceable to a primary reference, potentially affecting the precision of time synchronization. This flag is crucial for applications requiring high-precision timing, as it helps network devices assess the quality of the timing information they receive.

[0111] Generally speaking, traceability of a clock, or a clock’s frequency, to a reference, may pertain to the property that the output of the clock can be related to the reference (which may also be a clock), through an unbroken chain of comparisons and / or dependencies. Each of the comparisons can have an associated uncertainty; each dependency can have an associated amount of error. Therefore, for example, a clock’s frequency can be declared traceable to a primary reference clock on the basis that the clock’s frequency depends on output of the primary reference clock either directly or indirectly. The dependency may be maintained via signals which are ongoing. A device may determine that a clock’s frequency is traceable by determining the existence of such maintenance signals.

[0112] Next, the BTCA process 1030 compares the pri ori ty2 values of the data sets A and B (step 1035), selecting the lower value or moving to the next step. The priority2 values are a user-configurable parameter that provides a secondary level of priority for clock selection, allowing network administrators to influence the BTCA by assigning values between 0 and 255, where lower numbers indicate higher priority. Next, the BTCA process 1030 compares the localPriority values of the data sets A and B (step 1036). The localPriority values are a per-port configuration setting used as a tie-breaker when selecting between clocks received on different ports within a single network element, with lower values indicating higher priority.

[0113] Next, the BTCA process 1030 checks if the ClockClass of clock A is less than 127 (step 1037). This check is crucial because, in PTP, a ClockClass value of 127 indicates that a clock is in holdover mode, meaning it has lost synchronization with its primary reference source and is relying on its internal oscillator to maintain time. Clocks with a ClockClass less than 127 are considered to be synchronized to a valid time source and are therefore preferred over those in holdover mode. By performing this comparison, the BTCA ensures that clocks with active synchronization are prioritized as time sources, thereby enhancing the accuracy and stability of time distribution within the network.

[0114] Finally, the BTCA process 1030 compares the clockidentity values of the data sets A and B (step 1038), selecting the lower value or not selecting either clock.The clockidentity is a unique 64-bit identifier assigned to each clock, typically derived from the device's MAC address by inserting the hexadecimal value OxFFFE in the middle, ensuring global uniqueness within the network.

[0115] By comparing the data sets A and B of two clocks, the BTCA process 1030 supports the most stable and accurate clock being selected as the Best Time Transmitter (BTT). This selection can be critical in maintaining network synchronization, particularly during degraded scenarios such as holdover. The BTCA's structured evaluation process mitigates the risks of propagating timing errors by avoiding the selection of clocks with inferior attributes. Unlike the Best Master Clock Algorithm (BMCA), which uses similar parameters but focuses on selecting a grandmaster Clock (GMC) during normal operation, the BTCA is specifically designed for choosing between potential time sources, especially in scenarios where holdover or timing degradation occurs. The BTCA's emphasis on a thorough, parameter-driven comparison provides enhanced stability in complex networks such as those operating under PTS.

[0116] An advantage of the BTCA process 1030 is that it will work in the network 1010 where third party devices are connected without causing any interoperability issues. That is, the BTCA process 1030 works in the network 1010 where some of the devices do not support the BTCA process 1030. Here, those non-supportive devices use the BTCA process in ITU-T Recommendation G.8275.2 Amendment 1 , Figure 3, omitting the step 1034. But all devices can include the BTCA process - either the BCTA process 1030 or the BTCA process in ITU-T Recommendation G.8275.2 Amendment 1 , Figure 3, providing a selection of the Time Transmitter. The devices supporting the BTCA process 30 will advantageously make a better selection resulting in longer holdover support.

[0117] According to FIG. 6, a series of comparisons are made in order until a first one of the comparisons allows for a distinction of whether data set A or B is better. The comparison step 1034 is included at a certain step in this order. The ordering of the steps can be as shown or else varied. Certain steps can be removed, or additional steps can be added. Other comparison approaches can also be used, for example in which two or more comparison steps are performed in parallel and the results combined.

[0118] FIG. 7 illustrates a network diagram of the network 1010 for illustration of the BTCA process 1030. The T-BC-2 1016 would implement the BTCA process 1030 and select the PRC 1020 traceable SyncE source, remain in Time Holdover due to loss or degradation of the T-GM 1012, and publish its Frequency Traceable flag as True in Holdover ClockClass (CC) to the T-BC-1 1014 via the link C and the eNodeB 1022 viathe link E. In the BTCA process 1030, the T-BC-1 sees the Frequency Traceable flag as true in the data set associated with the T-BC-2 1016 thereby selecting the T-BC-2 1016 in the BTCA process 1030. The eNodeB 1022 receives the same flag and similarly selects the T-BC-2 1106. Now, all three of the T-BC-1 1014, the T-BC-2 1016, and the eNodeB 1022 would stay in holdover much longer due to the stable PRC 1020 as a reference.

[0119] The BTCA process 1030 selects the BTT, serving as both the time source and / or the frequency source for synchronization. The BTCA evaluates potential clocks based on parameters such as clock quality (ClockClass), accuracy, and stability (OffsetScaledLogVariance) to ensure that the chosen source offers the most reliable and precise synchronization. As a time source, the selected clock provides the reference for distributing accurate timestamps across the network, ensuring devices stay synchronized in time. As a frequency source, it delivers a stable frequency reference that ensures consistent timing intervals, critical for applications requiring precise time alignment, such as 5G networks and financial trading systems. By addressing both time and frequency aspects, the BTCA process 1030 supports that the network operates with desirably good or optimal synchronization stability and reliability, even under challenging conditions such as partial timing support or holdover scenarios.

[0120] Advantageously, a clock lasts longer in holdover mode with a stable frequency reference because the accuracy of its timekeeping during holdover depends entirely on the stability of its internal oscillator. A stable frequency reference, such as an Oven- Controlled Crystal Oscillator (OCXO) or a Rubidium oscillator, minimizes drift and frequency errors over time. These high-quality oscillators maintain a consistent frequency output, reducing the rate at which the clock's time deviates from the true time. Conversely, less stable references, like basic quartz oscillators, are more susceptible to temperature changes, aging, and other environmental factors, which cause faster and larger deviations in time. Consequently, a clock with a stable frequency reference can sustain precise timekeeping for longer durations in holdover, making it critical for applications where synchronization continuity is essential during disruptions.

[0121] FIG. 8 illustrates a network diagram of a network 1050 for illustrating another scenario where the BTCA decision may not be optimal based on the conventional approach. The network 1050 includes the same nodes as the network 1010 in a different interconnect via links A, B, C. With the conventional approach, ITU-T Recommendation G.8275.2 Amendment 1 , Figure 3:

[0122] (1 ) The connection between T-BC-1 1014 and the T-GM 1012 goes down on link A.

[0123] (2) The T-BC-1 1014 goes into Holdover, starts publishing CC 135 (as per in- spec Holdover duration) with degraded Quality Level (QL), and Frequency Traceable as False. A Holdover Clock Class (Holdover CC) of 135 indicates that the clock is in holdover mode with a degraded time synchronization state. That is, the T-BC-1 1014 has lost synchronization with its primary reference, such as the grandmaster Clock (GMC), and is relying on its internal oscillator to maintain time. A clock with ClockClass 135 typically represents:

[0124] Degraded Holdover Accuracy: The clock is operating without an external reference and is likely to deviate over time due to limitations in the stability of its internal frequency source.

[0125] No Active Synchronization: It is no longer traceable to a primary time source, such as a GPS-synchronized PRC.

[0126] Operational Indication: This classification serves as an indicator to other network nodes that the clock is in holdover and should not be used as a preferred time source unless no better option is available.

[0127] Clocks with lower ClockClass values (e.g., 6 for PRC traceability) are always preferred over those with a Holdover CC of 135, as they represent more stable and accurate timing sources. This classification is vital in networks to ensure robust time synchronization even during degraded conditions.

[0128] (3) The T-BC-2 1016 selects the T-BC-1 1014 in the conventional BTCA process for time (PTP), but selects its local PRC 1020 for frequency.

[0129] (4) The T-BC-1 1014 PTP output is drifting without any frequency reference and it is publishing Frequency Traceable as False but since the conventional BTCA process does not check on Frequency Traceable flag value, the T-BC-2 1016 BTCA selects the T-BC-1 1014 for its Time input. The T-BC-1 1014 in this case may also have a PRC 20 traceable to SyncE 1018, but that connection is lost, degraded, etc.

[0130] FIG. 9 illustrates a network diagram of the network 1050 for illustration of the BTCA process 1030. Here,

[0131] (1 ) The T-BC-2 1016 BTCA process 1030 checks that it has a local PRC frequency input.

[0132] (2) The T-BC-1 1014 PTP Announce messages indicate that it is in Holdover with no Frequency input.

[0133] (3) The T-BC-2 1016 decides not to select the T-BC-1 1014 as input and remains in its Holdover with PRC frequency.

[0134] (4) The T-BC-2 1016 publishes its Holdover CC with Frequency Traceable flag as TRUE.

[0135] (5) The eNodeB 1022 remains locked with the T-BC-2 1016 which is havingPRC frequency input for long duration.

[0136] Additionally, with the PRC backup active, operator would have significantly more time to resolve the actual issue causing time holdover. This is advantageous to operations teams tasked with resolving the issue.

[0137] FIG. 10 illustrates a flowchart of a process 1300 for an enhanced BTCA process that enhances time holdover in a PTP network involve leveraging the best available frequency support while disqualifying time input from a degraded PTP clock. The process 1300 contemplates implementation as a method with steps, via circuitry such as at the network element 100 configured to implement the steps, and as a non- transitory computer-readable medium storing instructions that, when executed, cause circuitry to implement the steps.

[0138] The steps include entering holdover in Precision Time Protocol (PTP) indicating a degraded time synchronization state (step 1302); determining parameters for a Best Time Clock Algorithm (BTCA), the parameters including a Frequency Traceable flag (step 1304); providing the parameters to other nodes in the network (step 1306); and implementing the BTCA including consideration of the Frequency Traceable flag, to select a Best Time Transmitter (BTT) while in the holdover (step 1308). The steps can include selecting the BTT based on the BTCA (step 1310).

[0139] The BTT can be a local Primary Reference Clock (PRC) having frequency traceability. The frequency traceability is to a Synchronous Ethernet (SyncE) source. The Frequency Traceable flag can be set to TRUE, and the consideration of the Frequency Traceable flag in the BTCA includes selecting a clock where the Frequency Traceable flag is TRUE over another clock where it is FALSE.

[0140] The consideration of the Frequency Traceable flag in the BTCA includes selecting a clock where the Frequency Traceable flag is TRUE over another clock where it is FALSE. The various parameters include one or more of clockClass, clockAccuracy, Offsets caled Log Variance, priority2, local Priority, and clockidentity. The BTCA selects a clock having a lower value of the various parameters or the Frequency Traceable flag as TRUE.

[0141] The BCTA selects a clock having values of the parameters which are preferred, according to a predetermined selection scheme, the selection scheme including that the Frequency Traceable flag being TRUE is preferred over the Frequency Traceable flag being FALSE. The Frequency Traceable flag is set based on whether a clock’s frequency is traceable to a primary reference. The Frequency Traceable flag can be set to FALSE, and wherein the implementing the BTCA including consideration of the Frequency T raceable flag includes selecting another clock for the BTT with the another clock having its Frequency Traceable flag set to TRUE.§3 Selecting a Best Available RTF Backup when a GNSS Clock Source is Unavailable

[0142] In a packet network, a switch (also referred to herein as a node) uses the Precision Time Protocol (PTP) to achieve timing synchronization by exchanging timestamped packets with PTP masters and slaves in the network. The protocol ensures accurate synchronization of clocks across network elements by compensating for delays introduced by packet transmission. The switch acts as either a PTP boundary clock or a PTP transparent clock, where boundary clocks synchronize with an upstream source and distribute timing downstream, while transparent clocks measure and correct for delay variations within the network. In particular, this precise timing is critical in 5G applications, where Ultra-Reliable Low-Latency Communication (URLLC), Time- Sensitive Networking (TSN), and massive Machine-Type Communications (mMTC) demand highly accurate synchronization to meet stringent latency and jitter requirements.

[0143] Timing in these networks originates from Primary Reference Clocks (PRCs), which are highly stable and accurate clock sources compliant with ITU-T standards, such as those described herein. PRCs typically derive their timing from atomic clocks or Global Positioning Satellite (GPS) systems, providing the foundation for network-wide synchronization. Secondary Synchronization Units (SSU-A clocks) act as intermediate timing sources that maintain synchronization during short interruptions in PRC availability. These clocks, designed with holdover capabilities, ensure continuity and accuracy of timing even in challenging scenarios, whereby “holdover” refers to a time period between synchronization events. Together, PTP-enabled switches, PRCs, and SSU-A clocks enable the precise timing required for the seamless functioning of advanced 5G networks.

[0144] As mentioned previously, the duration a node can remain in holdover is directly determined by the quality of its frequency source. Reference is made here to the previous discussion of holdover.

[0145] IEEE 1588 defines PTP, enabling precise synchronization of clocks across networked devices with sub-microsecond accuracy. The standard outlines the mechanisms for clock synchronization, including the exchange of timestamped messages and the BTCA algorithm for selecting the optimal clock within a network. The 2019 revision of IEEE 1588 (i.e., IEEE 1588-2019) introduces enhancements like improved accuracy, robustness against network delays, and security features to protect against timing attacks. A grandmaster clock in a PTP network serves as the primary source of accurate time for all devices within that network. It is the topmost clock selected through the BTCA algorithm, which assesses all clocks based on criteria like priority levels, clock class, accuracy, and stability to determine the most qualified one. Once designated, the grandmaster clock distributes its precise time information to subordinate clocks by sending timestamped messages, ensuring that all devices are synchronized.

[0146] In mobile networking (e.g., Radio Access Networks (RANs), etc.), the Global Navigation Satellite System (GNSS) can be used as a primary source for synchronization. Utilizing GNSS to synchronize radios and Base Band Units (BBUs) at a cell site has been a common method in mobile networks. It should be noted that there is a need for suitable network engineering practices to enable synchronization via transport network demands. However, with the evolution of the 5G, it has been discovered that using only GNSS clocks is not a legitimate solution to synchronize a network, specifically since the GNSS is subject to changes due to atmospheric conditions.

[0147] FIG. 11 illustrates a diagram of an embodiment of a system 3010 for improving holdover of a PTP network. The system 3010 may be similar to an example in ITU-T Recommendation G.8271 .2 for addressing network limits for deployment in an Assisted Partial Timing Support (APTS) network. APTS, as defined in ITU-T Recommendation G.8275.2, provides a method allowing operators to use GNSS as a primary source, while a PTP over IP can be used as a backup when the primary source is unavailable. In APTS, when GNSS is used as an active source of synchronization, PTP is kept as a backup which keeps calculating its offset from the GNSS and compensates the offset in case of GNSS failure. It is to be noted that PTP over IP network is prone to Packet DelayVariation (PDV) due to the intermediate IP network. Hence, proper network engineering techniques are needed to ensure time delivery via the PTP packets over the IP network.

[0148] The system 3010 includes a Primary Reference Time Clock (PRTC) 3012 (e.g., Primary Reference Clock (PRC), Primary Reference Source (PRS), etc.), a Telecom - grandmaster (T-GM) 3014, a Partial Timing Support (PTS) packet network 3016, a Telecom - Time Slave Clock - Assisted (T-TSC-A) 3018, a local time reference 3020 (e.g., a GNSS), and an end application 22.

[0149] The PTP network of the system 3010 calculates its offset based upon the matrices given in standard as follows

[0150] The clock type T-BC-A (Telecom - Boundary Clock - Assisted) is targeted for the APTS scenario described in ITU-T Rec. G.8271 .2, where the PTP input is used only as a secondary source of synchronization to hold the time for up to 72 hours. However, it should be noted that the PTP input is not necessarily intended to be used as the primary timing source unless GNSS goes down.

[0151] In some respects, there may be issues with conventional ways of selecting the PTP backup in APTS networks. As per the standards, in an APTS configuration, GNSS is also considered as the PTP virtual port and participates in the BTCA algorithm as a regular PTP clock source. Consider a case of APTS where multiple PTP sources are ready to provide a backup to the active GNSS source in case of failure, as described below.

[0152] FIG. 12 illustrates a diagram of an embodiment of a system 3030 for improving holdover in an APTS network. In this embodiment, the system 30 includes a first T-GM 3032-1 and a second T-GM 3032-2 connected to a first IP network 3034-1 and second IP network 3034-2, respectively. The system 3030 also includes a T-BC-A 3036 that includes a servo 3038, a local time reference 3040 (e.g., GNSS), and an end application 42. When the primary synchronization source, such as the local time reference 3040 isunavailable, the servo 3038 of the T-BC-A 3036 is configured to take the FTP source from the first IP network 3034-1 .

[0153] In this example, there are two PTP clock sources available to be used as the backup for the local (e.g., GNSS) source. The T-BC-A 3036 is configured to select the best PTP source as its backup to the local GNSS decided by a BTCA algorithm. When a PTP is decided to be used as the backup to the GNSS, it feeds the timestamp to the servo 3038. The servo 3038 keeps calculating the offset of the PTP with respect to the GNSS source of the local time reference 3040 and applies it when GNSS is failed or otherwise unavailable.

[0154] In an APTS network, it should be noted that asymmetry or offset from GNSS, as calculated by PTP, continues to vary due to the dynamic PDV introduced by the IP intermediate packet networks. With the current standards, BTCA selects the PTP source as the backup based upon a standard algorithm. However, current standards do not consider this asymmetry or offset variation, which are introduced by the systems and methods of the present disclosure, as described herein. Therefore, in the case of multiple PTP sources in the embodiment of FIG. 12, without consideration of the asymmetry variation of the PTP input in its selection algorithm, the system 3030 may select a backup PTP source that has a higher asymmetry or offset variation than others. Therefore, further improvements in synchronization are described herein.

[0155] FIG. 13 illustrates a diagram of an embodiment of a system 3050 for improving holdover in an APTS network. In this embodiment, the system 3050 includes a first T- GM 3052-1 and a second T-GM 3052-2 connected to a first IP network 3054-1 and second IP network 3054-2, respectively. The system 3050 also includes a T-BC-A 3056 which includes a first servo 3058-1 and a second servo 3058-2. The system 3050 also includes a local time reference 3060 (e.g., GNSS) and an end application 3062. When the primary synchronization source, such as the local time reference 3060 is unavailable, the servos 3058-1 , 3058-2 of the T-BC-A 3056 are configured to receive and analyze the PTP sources from the first and second IP networks 3054-1 , 3054-2, respectively. Based on current data (e.g., over the last 24 hours), the T-BC-A 3056 is configured to analyze the PTP sources to determine which demonstrates the best characteristics with respect minimal asymmetry or offset variation.

[0156] Thus, the T-BC-A 3056 in this system 3050 is configured to provide an additional step of comparing two or more available backup PTP sources and selectingone that exhibits the lowest offset variation. For example, the T-BC-A 3056 may be configured to operate as follows:

[0157] 1 ) In the APTS configuration, both the PTP sources (from IP networks 3054-1 , 3054-2, etc.) will provide the timestamps to their respective servo instances (e.g., servos 3058-1 , 3058-2, etc.) and both the servo instances can calculate its offset with respect to the local time reference 3060 (e.g., GNSS source) independently.

[0158] 2) Asymmetry values for the two (or more) PTP inputs can be measured on the runtime against the selected GNSS. For example, its peak-to-peak variation can be recorded over 24 hours.

[0159] 3) Even if both the servo instances are able to lock in monitor mode whenGNSS is active, the BTCA can be slightly changed. For example, according to the various embodiments of the present disclosure, the BTCA may be configured to consider which of the PTP backups would be the best one with respect to minimal offset. That is, the BTCA can select the PTP backup source that has the lower offset variation with respect to the local GNSS over a certain amount of time (e.g., the last 14 hours).

[0160] FIG. 14 is a graph 3070 illustrating an example of offset (in ns) from a primary time reference (e.g., local time reference 3060, GNSS time source, GPS time source, etc.) over time. It may be noted that the x-axis may represent the most current time measurements (e.g., over the last 24 hours), where values may be stored in a FIFO type of memory to only utilize the most recent offset values. A cutoff point 3072 shows a limit of 1100ns, which is an upper limit that indicates when an offset is too great and cannot be considered as reliable. In other words, the lower the offset value, the more accurate the backup source is and the exceeding or coming close to the cutoff point 3072 is undesirable.

[0161] The graph 3070 shows an example of two backup sources being compared. In other embodiments, more than two backup sources may be plotted on the graph 3070 and compared for consideration as a selected backup source. A first plot 3074 shows the offset characteristics of a first backup source (e.g., from the first IP network 3054-1 ) and a second plot 3076 shows the offset characteristics of a second backup source (e.g., from the second IP network 3054-2).

[0162] The graph 3070 gives a sense of the variation of the two PTP sources and how they vary with respect to the local GNSS for 24 hours. From this example shown in graph 3070, a comparison of the two plots 3074, 3076 would indicate that the second backup source (i.e. , associated with the second plot 3076 has a smaller offset from the primaryclock and could be selected for backup before selecting the first backup source. That is, the second backup source has a lower variation of offset with respect to the local GNSS and is therefore more stable than the first backup source. Also, the graph 3070 shows that the second backup source has less of a chance of crossing the cutoff point 1100ns when the system switches to the second backup source after failure of the local time reference 3060 (or GNSS).

[0163] Certain offset characteristics can be obtained from the graph 3070. For example, average values 3074a, 3076a of the first and second plots 3074, 3076, respectively, can be calculated. In some embodiments, peak-to-peak values 3074b, 3076b of the first and second plots 3074, 3076, respectively, can be calculated. For example, the peak-to-peak value 3074b for the first plot 3074 may be calculated by observing the last peak 3074c and the last valley 3074d, while the peak-to-peak value 3076b for the second plot 3076 may be calculated by observing the last peak 3076c and the last valley 3076d. Since the peak-to-peak value 3076b of the second plot 3076 is smaller than the peak-to-peak value 3074b of the first plot 3074, the second backup PTP source would be selected in this embodiment.

[0164] FIG. 15 illustrates a flow diagram of a process 3080 that represents an enhancement to the BTCA as described in various synchronization standards and protocols. For example, in addition to regular BTCA steps, the process 3080 further includes a step of comparing peak-to-peak offset values of one source versus another, which may involve analysis of the results of a graph, such as the graph 3070 of FIG. 4. The process 3080 may be implemented by any node in the networks 3010, 3030, 3050 when there is a need to select a new time transmitter. That is, the process 3080 contemplates implementation as a method with steps, via circuitry configured to implement the steps, and as a non-transitory computer-readable medium storing instructions that, when executed, enable or cause circuitry to implement the steps.

[0165] The process 3080 can be used by a node to select a time transmitter based on two (or more) data sets, referred to in this example as Data Set A and Data Set B, each of which corresponds to the attributes of two distinct clocks being compared to determine the Best Time Transmitter (BTT). These data sets may be constructed from parameters extracted from the PTP Announce messages exchanged between clocks in the network 3010, 3030, 3050. The algorithm ensures systematic evaluation of the two (or more) clocks to select the optimal timing source, essential for maintaining synchronization accuracy and stability.

[0166] The process 3080 may be configured to compare various points in the data sets A and B and selects either A (3100) or B (3098) at each step based on a comparison, or it can move to the next step if the values are equal (or substantially equal). First, the process 80 compares the grandmaster (GM) clockClass values of the data sets A and B, as indicated in decision block 3082 and selecting the lower value or moving to the next step if the values are equal. That is, the lower GM clockClass value indicates the better clock. The GM clockClass values indicate a clock's traceability and stability, reflecting its synchronization quality and reliability within the network 3010, 3030, 3050.

[0167] Next, the BTCA process 3030 compares the GM clockAccuracy values of the data sets A and B, as indicated in decision block 3084, selecting the lower value or moving to the next step. Also, the lower GM clockAccuracy value indicates the better clock. The GM clockAccuracy values specify the precision of a clock's timekeeping relative to a reference standard, indicating how closely the clock's time aligns with the true time. Next, the process 3080 compares the GM offsetScaled LogVariance values of the data sets A and B, as indicated in decision block 3086, selecting the lower value or moving to the next step. The GM offsetScaledLogVariance values quantify a clock's stability by measuring the variance of its time offset, providing insight into its precision and frequency consistency over time.

[0168] The present disclosure introduces a new step in the conventional BTCA. The process 3080, in this embodiment, includes a step of comparing the peak-to-peak offset variation values of the data sets A and B, as indicated in decision block 3088, and selecting the lower value or moving the next step. The step of comparing peak-to-peak offset variation values may be performed in the same or similar way as described with respect to the analysis of the graph 3070 of FIG. 14, or other similar graph showing offset variation values over a recent time period (e.g., most recent 24 hours). Again, the lower peak-to-peak variation indicates the better clock.

[0169] Next, the process 3080 compares the GM priority2 values of the data sets A and B, as indicated in block 3090, and selecting the lower value or moving to the next step. The GM priority2 values are a user-configurable parameter that provides a secondary level of priority for clock selection, allowing network administrators to influence the BTCA by assigning values between 0 and 255, where lower numbers indicate higher priority. Next, the process 3080 compares the GM localPriority values of the data sets A and B, as indicated in decision block 3092. The GM localPriority values are a per-portconfiguration setting used as a tie-breaker when selecting between clocks received on different ports within a single network element, with lower values indicating higher priority.

[0170] Next, the process 3080 checks if the GM clockClass of clock A is 127 or less, as indicated in decision block 94. If so, the process 3080 may end. This check can be crucial in some cases, because, in PTP, a clockClass value of 127 indicates that a clock is in holdover mode, meaning it has lost synchronization with its primary reference source and is relying on its internal oscillator to maintain time. Clocks with a clockClass less than 127 are considered to be synchronized to a valid time source and are therefore preferred over those in holdover mode. By performing this comparison, the BTCA ensures that clocks with active synchronization are prioritized as time sources, thereby enhancing the accuracy and stability of time distribution within the network.

[0171] Finally, the process 3080 compares the GM clockidentity values of the data sets A and B, as indicated in decision block 3096, selecting the lower value or not selecting either clock. The GM clockidentity is a unique 64-bit identifier assigned to each clock, typically derived from the device's MAC address by inserting the hexadecimal value OxFFFE in the middle, ensuring global uniqueness within the network.

[0172] By comparing the data sets A and B of two clocks, the process 3080 ensures the most stable and accurate clock is selected as the Best Time Transmitter (BTT). This selection may be critical in maintaining network synchronization, particularly during degraded scenarios such as holdover. The BTCA's structured evaluation process mitigates the risks of propagating timing errors by avoiding the selection of clocks with inferior attributes. Unlike the Best Master Clock Algorithm (BMCA), which uses similar parameters but focuses on selecting a grandmaster Clock (GMC) during normal operation, the BTCA is specifically designed for choosing between potential time sources, especially in scenarios where holdover or timing degradation occurs. The BTCA's emphasis on a thorough, parameter-driven comparison provides enhanced stability in complex networks such as those operating under PTS.

[0173] An advantage of the process 3080 is that it will work in the network 3010, 3030, 3050 where third party devices are connected without causing any interoperability issues. That is, the process 3080 works in the network 3010, 3030, 3050 where some of the devices do not support the process 3080. Here, those non-supportive devices can use the BTCA process in ITU-T Recommendation G.8275.2, Amendment 1 , Figure 3, omitting decision block 3088, allowing all nodes or devices in the networks 3010, 3030,3050 to provide a selection of the BTT. The devices that support the process 80 will advantageously make a better selection resulting in longer holdover support.

[0174] FIG. 16 illustrates a flow diagram of a process 3140 for selecting a backup clock source. As shown in this embodiment, the process 3140 includes a step of obtaining multiple data sets representing multiple backup clocks, as indicated in block 3142. As indicated in block 3144, the process 3140 further includes a step of analyzing offset characteristics of the multiple backup clocks in order to select a substitute clock source from the multiple backup clocks to operate as a temporary substitute when a primary source of synchronization for the communications network is unavailable. For each backup clock, the offset characteristics are configured to be related to a synchronization offset of the associated backup clock with respect to the primary source.

[0175] According to additional embodiments, each of the multiple data sets may include data points representing the synchronization offset of the associated backup clock with respect to the primary source over time. For example, the data points of each of the data sets may be plottable as a waveform (e.g., waveforms 3074, 3076). Also, a variability factor may be defined as a peak-to-peak value (e.g., 3074b, 3076b) of the associated waveform. In this case, it is compared with the variability factor of other data sets to select the substitute clock source from a backup clock of the multiple backup clocks having the lowest peak-to-peak value. In alternative embodiments, the variability factor may be defined as an average value (e.g., 3074a, 3076a) or median value of the associated waveform. In this case, it is compared with the variability factor of other data sets to select the substitute clock source from a backup clock of the multiple backup clocks having the lowest average value or median value.

[0176] In some embodiments, each of the multiple data sets may include data points representing the synchronization offset of the associated backup clock with respect to the primary source over a most recent time period of predetermined length. For example, the predetermined length may be about 24 hours. Before detecting that the primary source is unavailable, the process 3140 may further include a step of continuously calculating the offset characteristics to determine, substantially in real-time, a best clock source selection for operation as the substitute clock when the primary source is unavailable.

[0177] The multiple backup clocks, for example, may include two or more Precision Time Protocol over Internet Protocol (PTP over IP) sources. The communications network associated with the method 140 may include at least a mobile network havingradios, Base Band Units (BBUs), eNodeB components, towers, satellites, etc. The primary source of synchronization, as described herein, may be a clock reference from a Global Navigation Satellite System (GNSS). In some embodiments, selection of the substitute clock source may be an enhancement to one or more standards or protocols defined in IEEE 1588, Precision Time Protocol (PTP), ITU-T recommendations regarding clock synchronization, and / or ITU-T recommendations regarding Assisted Partial Timing Support (APTS). Also, in some cases, a network element that implements the method 140 may be a Telecom - Boundary Clock - Assisted (T-BC-A) device having multiple servos configured to receive the multiple data sets.

[0178] It may be noted that the novelty of the various embodiments of the present disclosure may be associated with calculation of asymmetry values, variation values, variability values, synchronization offset values, or the like, whereby an offset in clock synchronization of potential backup clocks are analyzed with respect to a grandmaster clock source or other suitable primary clock source. Two (or more) PTP sources may be compared via their respective servo instances running in parallel. Then, consideration of some variability factor (e.g., peak-to-peak asymmetry or variation) in the BTCA is used to select the best available backup at run time.

[0179] The systems and methods of the present disclosure may be based on a) two or more inputs that can be simultaneously fed to the BTCA, whereby the timestamps to their respective servo instances can be used to calculate their offset with respect to the local GNSS. In the case where both the PTP sources have the same clock quality parameters, the systems and methods of the present disclosure may further be based on b) the selection of the PTP backup based upon their offset variation with respect to the local GNSS over a certain time period (e.g., over the last 24 hours). This would lead to the selection of a more stable PTP as the backup to the GNSS.

[0180] Furthermore, the present disclosure has certain benefits with respect to traditional systems for providing synchronization source backups. For example, in some deployments, it has been noted that some of the PTP backups on the APTS nodes perform very poorly, such as in cases where their asymmetry variation was very close to the 1100ns threshold. In the conventional systems, there was a possibility of losing synchronization lock after they become active after the GNSS failure, leading to delays and other issues in the network. These backups, which may have otherwise been selected in conventional systems, are analyzed as described in the currentimplementations to position an APTS solution which selects the most stable PTP as the backup and remains reliable after the GNSS failure.

[0181] A Telecom grandmaster (T-GM) may be configured as a specialized grandmaster clock used in telecommunications networks that implement PTP. Specifically defined in recommendations like ITU-T G.8275.1 and G.8275.2, the T-GM serves as the primary source of precise time and phase synchronization for telecom networks requiring high levels of accuracy. In the context of PTP, the T-GM may be configured to distribute accurate timing information to downstream network elements, such as Telecom Boundary Clocks (T-BCs) and Telecom Time Slave Clocks (T-TSCs). The T-GM may be configured to interface with a highly accurate reference time source, typically a Global Navigation Satellite System (GNSS), such as GPS. The T-GM may then use PTP to propagate this timing information across the network, ensuring that all devices are synchronized to the same precise time. The T-GM is designed to meet the stringent synchronization requirements of modern telecom applications, such as 4G LTE- Advanced and 5G networks.

[0182] As mentioned previously, the BTCA in ITU-T G.8275.2 plays a vital role in ensuring robust time synchronization in networks with Partial Timing Support (PTS). Reference is made here to the previous discussion of BTCA.

[0183] In the network, the T-GMs and the T-BCs may be located at nodes or network elements and / or links interconnecting the nodes or network elements. The T-BCs may have a backup local Synchronous Ethernet (SyncE) clock other than its congruent primary PTP connection to the T-GM, thus if the T-BC loses the PTP connection (e.g., due to degradation or other cause), it still has its Primary Reference Clock (PRC) traceable to the SyncE clock. However, as mentioned throughout the present disclosure, the conventional BTCA does not normally check variability factors (e.g., peak-to-peak variability of a waveform created by data points over time).

[0184] It is also considered herein that selecting a best available PTP backup when a GNSS source is unavailable can involve the consideration of TTL values from clock sources, or other indicators, as discussed elsewhere herein. For example, in an embodiment, all other things being equal, a PTP backup source can be selected based on it being closer, in terms of number of hops, to the selecting node, as deteremined using TTL values.§4 Selecting a Best Available Clock for Synchronization Recovery

[0185] In a packet network, Network Elements (NEs) (e.g., switch, router, node, etc.) uses the Precision Time Protocol (PTP) to achieve timing synchronization by exchanging timestamped packets with PTP masters and slaves in the network. The protocol ensures accurate synchronization of clocks across NEs by compensating for delays introduced by packet transmission. An NE may act as either a PTP boundary clock or a PTP transparent clock, where boundary clocks synchronize with an upstream source and distribute timing downstream, while transparent clocks measure and correct for delay variations within the network. In particular, this precise timing is critical in 5G applications, where Ultra-Reliable Low-Latency Communication (URLLC), Time- Sensitive Networking (TSN), and massive Machine-Type Communications (mMTC) demand highly accurate synchronization to meet stringent latency and jitter requirements.

[0186] Timing in these networks originates from Primary Reference Clocks (PRCs), which are highly stable and accurate clock sources compliant with ITU-T standards, such as those described herein. PRCs typically derive their timing from atomic clocks or Global Positioning Satellite (GPS) systems, providing the foundation for network-wide synchronization. Secondary Synchronization Units (SSU-A clocks) act as intermediate timing sources that maintain synchronization during short interruptions in PRC availability. These clocks, designed with holdover capabilities, ensure continuity and accuracy of timing even in challenging scenarios, whereby “holdover” refers to a “recovery” time period between well-defined synchronization events. Together, PTP- enabled switches, PRCs, and SSU-A clocks enable the precise timing required for the seamless functioning of advanced 5G networks.

[0187] The duration that a node can remain in holdover is directly determined by the quality of its frequency source. A node with a clock traceable to a PRC will typically exhibit slower time deviation compared to one relying on an SSU-A clock, which is less stable. In scenarios where two interconnected nodes lose connectivity to the grandmaster Clock (GMC), the network protocol dictates that one node assumes the role of Master while the other becomes a Slave. The Slave node synchronizes with the Master and thus inherits the same rate of deviation as the Master. However, challenges arise when the node selected as the Master does not have a robust frequency backup and deviates rapidly. In such a case, even the Slave node, despite having a better frequency source, would deviate at the same accelerated rate as the Master, leading to suboptimal network synchronization. This issue is a direct consequence of the Best timeTransmitter Clock Algorithm (BTCA) defined in ITU-T G.8275.2, Amendment 1. The BTCA selects the Master based on predefined criteria, which may not always account for the quality of the frequency backup, potentially compromising the stability and accuracy of the overall network timing during holdover.

[0188] As mentioned previously, in mobile networking (e.g., Radio Access Networks (RANs), etc.), the Global Navigation Satellite System (GNSS) can be used as a primary source for synchronization, and reference is made here to that discussion.

[0189] In PTP and its associated telecom profiles (e.g., ITU-T Rees. G.8265.1 , G.8275.1 , G.8275.2, etc.), packets can be carried between a PTP Grand Master (GM) and PTP clients. Communications traffic can traverse over either 1 ) an Ethernet network, or 2) an Internet Protocol (IP) and / or Multiprotocol Label Switching (MPLS) network (e.g., referred to herein as an “IP / MPLS network”). That is, packets can be transmitted over Ethernet networks in a Fully Time Aware (FTA) manner with NEs having Full Timing Support (FTS). Alternatively, packets can be transmitted over IP / MPLS networks in a Partially Time Aware (PTA) manner with NEs having Partial Timing Support (PTS). Also, PTP clients can use timestamps received through PTP to recover accurate frequency, time, and phase for alignment with PTP GM clocks. ITU-T Rec. G.8265.1 defines recovery of frequency and Rees. G.8275.1 and G.8275.2 define recovery of phase and time. This process may be assisted by recovered frequency from electrical sources like Synchronous Ethernet (SyncE), Building Integrated Timing Supply (BITS), etc.

[0190] In some deployment scenarios, PTP can be used as a back up to some other time sources like GNSS as a measure of providing resilience to network timing architecture. ITU-T Rec. G.8275.1 describes this architecture, and Rec. G.8275.2 is referred to as an Assisted PTS (A-PTS) architecture. It allows a non PTP time source (e.g., GNSS) to be fed into PTP state machines as a logical PTP port (or virtual PTP port) so that a clock selection algorithm, such as Best time Transmitter Clock Algorithm (BTCA), can consider it as a recovery candidate while selecting the best available time clock sources.

[0191] FIG. 17 is a diagram illustrating an embodiment of a branched communication system 4010 in which a clock is selected from upstream Masters for synchronization recovery. As shown in FIG. 17, the branched communication system 4010 includes a first upstream branch comprising a first Telecom - Grand Master (T-GM) node 4012-1 , an IP / MPLS network 4014, a Telecom - Boundary Clock - Assisted (T-BC-A) node 4016, and an Inter-Working Function (ITW) module 4018. The branched communicationsystem 4010 includes a second upstream branch comprising a second T-GM node 4012- 2 and a first Telecom -Boundary Clock (T-BC) node 4020-1 . In addition, the two branches of the branched communication system 4010 are joined at a downstream branch comprising a second T-BC node 4020-2 having a clock selection unit 4022, a third T-BC node 4020-3, and a Telecom - Time Slave Clock (T-TSC) node 4024. The clock selection unit 4022 of the second T-BC node 4020-2 is configured to determine which upstream clock is to be selected to provide the best synchronization results for the downstream branch during a recovery process.

[0192] In the first (PTS) branch, the IP / MPLS network 4014 may provide a G.8275.2 (PTS) PTP backup clock to the T-BC node 4016 over line 4026. After processing by the IWF module 4018, output from the T-BC-A node 4016 may be configured to provide a SyncE output from the IWF module 4018 to the second T-BC node 4020-2 over line 4028. Thus, the second T-BC node 4020-2 is supplied with two SyncE clock sources from the two upstream branches. However, the second T-BC node 4020-2 would not know where these SyncE sources come from without using the strategies described herein.

[0193] In general, PTP-based network clocking is either driven by a Fully Time Aware (FTA) architecture with Full Timing Support (FTS) using a G.8275.1 profile or alternatively by a Partially Time Aware (PTA) architecture with Partial Timing Support (PTS) or Assisted PTS (A-PTS) using a G.8275.2 profile. However, selection of a best clock can become relatively complicated in systems when both these architectures are mixed using Inter-Working Functions (IWFs), such as in the scenario shown in the branched communication system 4010 in FIG. 1 where the first branch 4005 is configured for PTS over the IP / MPLS network 4014 and the second branch 4006 is configured for FTS over an Ethernet network. By utilizing the IWFs, the PTS of the first PTA branch can be translated from this PTS profile to the FTS profile.

[0194] Hence, the branched communication system 4010 includes one portion (i.e., the first branch 4005) that is based on the PTS architecture as described in G.8275.2 and another portion (i.e., the second branch 4006) that is based on the FTS architecture as described in G.8275.1. However, the T-BC-A node 4016 uses the IWF module 4018 to implement an IWF that is configured to essentially translate PTP profile from G.8275.2 to G.8275.1. This means that, for the downstream branch (i.e., starting with the second T-BC node 4020-2), both of the two upstream branches appear to be FTS-based since they both provide a clock source based on the G.8275.1 profile. It should be noted at this point, however, that the first branch 4005 originates as a PTS branch that iseventually converted to FTS, while the second branch 4006 includes FTS throughout the entire branch.

[0195] One problem that a conventional clock selection algorithm may have in such as network (e.g., the branched communication system 4010) is that a clock may be selected that is not actually the “best” clock. However, the clock selection unit 4022 of the second T-BC node 4020-2 is configured to use a strategy that has not been considered in conventional systems. In particular, a downstream node in a conventional system is not privy to where upstream clocks come from. According to the systems and methods of the present disclosure, the upstream branches are configured to communicate clock source information to the downstream branching node (e.g., the second T-BC node 4020-2). In response to receiving information about the upstream clocks, the clock selection unit 4022 is configured to prioritize various characteristics to better determine the best available clock for synchronization during a recovery process.

[0196] Again, a problem with conventional systems is that a branched node (e.g., second T-BC node 4020-2) might end up selecting a SyncE source from the first branch 4005 that is recovered via the IP / MPLS network 4014, which may typically be prone to high Packet Delay Variation (PDV). In this case, the SyncE clock from the first branch 4005 would not be ideal, especially since a better SyncE source may be available via the second FTS branch 6. Nevertheless, another clock source from the first branch 4005 may be better than clock sources from the second branch 6 in some scenarios. Therefore, selection of a clock, according to systems and methods of the present disclosure, are not merely dictated by which upstream branch the clock is coming from.

[0197] The following two cases may be applicable to the branched communication system 4010 for selecting a master clock source. To summarize the prioritization technique for selecting a clock, a first priority (i.e., shown by the circled “1” in FIG. 17) may be given to a clock source from the Global Navigation Satellite System (GNSS) supplying clock signals to the T-BC-A node 4016 in the first branch 4005. A second priority (i.e., shown by the circled “2” in FIG. 17) may be given to a clock source from the second branch 4006. And lastly, a third priority may be given to a clock source associated with transmission over the IP / MPLS network 4014 in the first branch 4005. Again, the present disclosure is configured to communicate the source of the clocks from the upstream branches to the second T-BC node 4020-2 in order that the clock selection unit 4022 can select an “optimal” clock (e.g., lowest time, frequency, or phase offset from an ideal clock) based on the prioritization strategy.

[0198] In Case #1 , suppose that (a) the T-BC-A node 4016 is locked to GNSS, and (b) the first T-BC node 4020-1 is locked to the second T-GM node 4012-2 directly without any hops in the FTS architecture. In this case, the clock selection unit 4022 of the second T-BC node 4020-2 can use a standard clock selection algorithm to select its best frequency clock source among two available SyncE sources. In conventional systems, the branched T-BC node 4020-2 would not select the PTS-based path in this case, even though it may be considered to be similar to or even better than the SyncE source from the first T-BC node 4020-1 . Since the better clock might depend on various otherfactors, the clock selection unit 4022 of the present disclosure is configured to use knowledge of clock sources provided by the master components to select the better clock. In this case, the T-BC-A node 4016 would have the frequency accuracy similar to a Grand Master and may be given first priority. In some embodiments, it may also be noted that, in the case where one of the sites uses GNSS as a FTP backup (e.g., using PTS or G.8275.2 clock) available over a third party PTP unaware network, while other sites are backed up with PTP from adjacent boundary clocks using G.8275.1 , the GNSS source may take priority.

[0199] In Case #2, suppose that (a) the T-BC-A node 4016 has lost the GNSS clock and is locked to the first T-GM node 4012-1 over the IP / MPLS network 4014 (e.g., PTS- based), and (b) the first T-BC node 4020-1 is locked to the second T-GM node 4012-2 without any hops (e.g., FTS-based). In this case, although the T-BC-A node 4016 will still be sending SyncE quality level clock signals similar to those sent by the first T-BC node 4020-1 to the second T-BC node 4020-2, it may be evident that the SyncE clock from the first T-BC node 4020-1 is a better choice considering that it uses the FTS network over the entirety of the branch. Although the Quality Level (QL) of the SyncE is the same, the FTS-based SyncE source would be a better selection because it is a hop- by-hop recovered “Physical” frequency source and can thereby reduce impact of the PDV over the IP / MPLS network 4014. Thus, the second priority clock takes priority over the third priority clock.

[0200] It may be noted that, for the T-BC-A node 4016, the IWF module 4018 function of converting to SyncE is practically hiding the details from the second T-BC node 4020- 2. Specifically, the IWF module 4018 is hiding the fact that it is recovering frequency over a PTS network. However, since the clock selection unit 4022 of the present disclosure is able to obtain additional information about the upstream clock sources, it is configured to use the background knowledge of the PTS nature of the first branch and can better select a clock. It can also be observed that the branched node in the conventionalsystems may achieve frequency lock but may fail to achieve phase lock due to high PDV through the PTS network. In this case, although the T-BC-A node 4016 is frequency- locked and sends PRC QL to the second T-BC node 4020-2, the clock selection unit 4022 may determine that it may not be desirable to choose this SyncE source over a more stable SyncE source from the first T-BC node 4020-1 .

[0201] Therefore, with the communication from the upstream master clocks, the second T-BC node 4020-2 is configured to use the prioritization scheme to determine the best available clock for downstream use. A user in the conventional system could potentially manually configure the first T-BC node 4020-1 as having a higher priority than the T-BC-A node 4016, but that would mean that even in Case #1 , the second T-BC node 4020-2 would need to be manually forced to select the SyncE from the first T-BC node 4020-1. The manual selection process of the conventional system would, of course, not be desired. Therefore, the clock selection unit 4022 of the present disclosure is configured to automatically receive the upstream information regarding clock source to select the best available clock based on prioritization strategies described herein.

[0202] FIG. 18 illustrates a diagram of another embodiment of a branched communication system 4030 in which a clock is selected for synchronization recovery. As shown in FIG. 18, the branched communication system 4030 includes a first upstream branch comprising a first T-GM node 4032-1 , an IP / MPLS network 4034, a G.8265.1 +SyncE node 4036, and an Ethernet Equipment Clock (EEC) module 4038. The branched communication system 4030 also includes a second upstream branch comprising a second T-GM node 4032-2, a first EEC node 4040-1 , a second EEC node 4040-2, and a third EEC node 4040-3. The SyncE node 4036 in the first upstream branch is configured to be synchronized based on a GNSS source connected through a third T-GM node 4032-3. The two upstream branches of the branched communication system 4030 are joined at a downstream branch comprising a fourth EEC node 4040-4 having a clock selection unit 4042, a fifth EEC node 4040-5, and an end application 4044.

[0203] In the first (PTS) branch, the IP / MPLS network 4034 may provide a G.8275.2 (PTS) PTP backup clock or G.8265.1 clock to the SyncE node 4036 over line 4046. The EEC module 4038 is configured to provide a SyncE output from the SyncE node 4036 to the fourth EEC node 4040-4 over line 4048. Thus, the fourth EEC node 4040-4 is supplied with two SyncE clock sources from the two upstream branches. However, the fourth EEC node 4040-4 would not know where these SyncE sources come from without using the strategies described herein.

[0204] The clock selection unit 4042 of the fourth EEC node 4040-4 is configured to determine which upstream clock is to be selected to provide the best synchronization results for the downstream branch during a recovery process. In addition, the clock selection unit 4042 may be configured with the same or similar functionality as the clock selection unit 4022 shown in FIG. 17 and may be configured to use specific prioritization strategies for determining which clock is the most accurate with respect to time, frequency, and phase. For example, a summarization of a priority scheme may include a first priority (i.e., indicated by the circled “1”) being given to a clock originating from the third T-GM node 4032-3. A second priority (i.e., indicated by the circled “2”) may be given to a clock originating from the third EEC node 4040-3. A third priority (i.e., indicated by the circled “3”) may be given to a clock originating from the IP / MPLS network 4034.

[0205] The branched communication system 4030 may be applicable to a Frequency Division Duplex (FDD) system, such as a Radio Access Network (RAN) used for wireless communication. For example, the branched communication system 4030 may be deployed using an ITU-T Rec. G.8265.1 PTP profile. The following scenario may be applicable in this system arrangement.

[0206] In a Case #3, the SyncE node 4036 of the first branch may include an Ordinary Clock (OC) having two frequency sources. A first frequency source may include a SyncE input from the third T-GM node 4032-3. A second frequency source may include a Rec. G.8265.1 input from the IP / MPLS network 4034 that may be prone to Packet Delay Variation (PDV), whereby the fourth EEC node 4040-4 would receive a “packet-based” SyncE input from the G.8265.1 OC via the PDV-prone PTS network. The fourth EEC node 4040-4 also receives a SyncE input via a “physical-based” path (e.g., the second branch or FTS branch) from the third EEC node 4040-3. The conventional systems may require that the clock be manually selected or may rely on preset assumptions about which branch may be optimal.

[0207] However, according to the embodiments described in the present disclosure, the fourth EEC node 4040-4 may utilize its clock selection unit 4042 to use unique clock selection strategies, as described herein, for prioritizing clocks based on certain criteria. Specifically, the clock selection unit 4042 may receive upstream data from master clocks to determine where the operating clocks have come from. Based on this origination information, the clock selection unit 4042 can optimally select a clock with desirable characteristics. Such characteristics can include the selected clock having less latency or offsets with respect to time, frequency, and phase. Such characteristics can includethe selected clock having consistently good performance over time, e.g. with respect to time, frequency and / or phase accuracy or stability.

[0208] For example, the clock selection unit 4042 may be configured to place a higher priority on (or prefer) the SyncE input from SyncE node 4036 (with OC) when the OC is locked to the SyncE input from the third T-GM node 4032-3 since the SyncE input from this source would be more stable than a G.8265.1 frequency input. Also, the clock selection unit 4042 may be configured to place a higher priority on (or prefer) the SyncE input from third EEC node 4040-3 when the OC of the first branch is locked to the G.8265.1 FTP input over the IP / MPLS network 4034 in the case of a SyncE failure from the third T-GM node 4032-3. Although both the G.8265.1 OC and the clock of the third EEC node 4040-3 would send the same Quality Level (QL) on ESMC packets, it may be evident that the SyncE input from first EEC node 4040-1 would be more stable and accurate than the OC. This cannot be achieved in the conventional systems by setting local priority on the fourth EEC node 4040-4 as the local priority will enable the fourth EEC node 4040-4 to select the SyncE input from OC instead of the clock from the second branch.

[0209] FIG. 19 illustrates a chart 4050 showing the Protocol Data Unit (PDU) designation for the Ethernet Synchronization Message Channel (ESMC) as defined in ITU-T Rec. G.8264. It should be noted that the chart 4050 includes, among other things, a Type / Length / Value (TLV) field containing four bytes. In addition to predefined TLV characteristics, the ESMC also includes any number of additional bytes that can be utilized in a field referred to as “Future enhancement TLV.” In this section, bits can be inserted in the ESMC by Master clock devices in the two upstream branches of a branched communications system (e.g., branched communications systems 4010, 4030). According to existing protocols, the ESMC message is transmitted from the upstream Masters for use by the downstream Slaves to help with the selection of available clocks. In the present disclosure, an extension of ITU-T Rec. G.8264 may include additional “prioritization” bits added to the ESMC message. The Slave devices, for example, may include the second T-BC node 4020-2 shown in FIG. 1 , the fourth EEC node 4040-4 shown in FIG. 18, or any other suitable branching nodes that receive multiple available clocks from upstream branches in any suitable communications systems. The Slave devices receives the ESMC message and can select clocks based on the prioritization strategies described in the present disclosure. It is noted that other messaging can be alternatively used.

[0210] FIG. 20 illustrates a table 4060 showing an embodiment a bit designation scheme whereby two bits (e.g., “bit x” and “bit y”) are used for indicating characteristics of a frequency recovery source of a Master node, according to various prioritization strategies described in the present disclosure. The Slave node can analyze the bit designation schemes from multiple upstream Master nodes to determine which clock might be selected. The bit designation scheme may be applicable within previously unused bits of the ESMC message of ITU-T Rec. G.8264.

[0211] The Slave node (e.g., the second T-BC node 4020-2, the fourth EEC node 4040-4, etc.) is configured to receive the information regarding the upstream frequency source of multiple Masters. In particular, the bit designation may be used to indicate whether the clock source for frequency recovery originates from a “packet” layer or a “physical” layer. For example, the packet layer may refer to a source that traverses through an IP / MPLS network (e.g., IP / MPLS network 4014, 4034) or PTS-based system. A physical layer may refer to a source that traverses through an Ethernet network (e.g., the second branch of the branched communications system 10, the second branch of the branched communications system 30, etc.).

[0212] As shown in FIG. 20, the table 4060 shows three bit designations, although additional designations with two or more bits may be used for communicating various Master clock scenarios. When bits x and y are both “0” (e.g., low, off, cleared, etc.), no frequency source indication is included. In this case, the selection priority would default to a QL-based selection procedure. For example, according to various embodiments, the QL-based selection may be performed before or after analyzing the bit designations described in the present disclosure. If bit x is “0” and bit y is “1” (e.g., high, on, set, etc.), the ESMC message is intended to indicate that the frequency clock source is recovered from a “physical” layer source over an Ethernet-based line. This would be viewed as having a higher priority (e.g., “first” priority). If bit x is “1 ” and bit y is “0,” the ESMC message is intended to indicate that the frequency clock source is recovered from a “packet” source over an IP / MPLS network. The Slave node can then use the frequency source indication information for selecting the appropriate frequency recovery clock.

[0213] In a first stage, the Master nodes are configured to set the respective x and y bits accordingly based on the clock source used for frequency recovery. This indication of the frequency in the upstream Master branch can be inserted into the two bits in the ESMC packet. For example, the ESMC PDU includes Quality Level (QL) information in the TLV field, which is used to convey quality level to downstream clocks. In someembodiments, two unused bits for frequency source indication may be inserted in the fourth octet of the ESMC message. Also, in some embodiments, the x bit may be the fifth bit in this octet, while the y bit may be the fourth bit (e.g., out of four bits 7, 6, 5, 4).

[0214] Again, when bits x, y are set to 00, this is a default setting, where downstream Slave nodes may ignore the bits and rely instead on QL characteristics as an alternative means for selection. When bits x, y are set to 01 , the frequency is recovered from a physical layer source (e.g., GNSS, SyncE, 10MHz, etc.). When bits x, y are set to 10, the frequency source is recovered from a packet source (e.g., G.8275.2 (PTS), G.8265.1 (RAN), etc.).

[0215] Other encodings are also possible. For example, one, two or more bits may be set to a particular value to indicate whether the frequency (or other relevant characteristic) is recovered from a physical layer source or from a packet source. Alternatively, such bits may be set to a particular value to indicate the frequency selection priority directly, where the priority is based at least in part on whether the frequency is recovered from a physical layer source or from a packet source.

[0216] The downstream Slave can then receive the x, y bit pair (or other indication) for aiding with clock selection techniques. In the case where the received QL is the same for two SyncE sources, the frequency selection priority may rely on the indication of physical frequency source or packet recovered frequency source. This can be used to choose a better SyncE source.

[0217] As per ITU G.781 , section 5.12.1 , SyncE selection is usually decided over received QL and user set priority. Received “quality level” has the highest priority. In some embodiments, the parameter of “frequency selection priority” (as described herein) can be considered as the second highest analysis step after a QL parameter analysis step. In other embodiments, however, the frequency selection priority may be performed first. If no clear “winner” is found, the strategy may involve using the QL parameter analysis step as the second highest analysis step. If a Slave clock receives the same QL from two different sources, based on the “frequency selection priority” stage, it may select the SyncE source from a Master which is locked to a physical frequency source compared to a Master having frequency source from a packet network.

[0218] In some embodiments, the prioritization strategy for selecting a Master clock signal from multiple candidates is governed by each clock’s source recovery indicator, which designates whether the clock is recovered from a higher-priority physical layer or from a lower-priority packet layer. As an example, when the source recovery indicator fora first Master clock signal points to a physical layer medium — such as Synchronous Ethernet (SyncE) or another Full Timing Support (FTS) mechanism — while the second Master clock signal’s indicator denotes a packet-based frequency recovery (e.g., PTP over IP / MPLS or Partial Timing Support (PTS)), the first Master clock signal may be prioritized. These source recovery indicators can be communicated to downstream nodes by embedding previously unused bits in the Ethernet Synchronization Message Channel (ESMC) Protocol Data Unit (PDU) defined by ITU-T Recommendation G.8264. If both upstream Master clocks share the same Quality Level (QL), the strategy then relies on the source recovery indicators to favor the physical layer source, thereby mitigating higher Packet Delay Variation (PDV) typically encountered in packet-based references. This prioritization can operate before or after a standard QL-based selection procedure, and it is especially beneficial in scenarios where Partial Timing Support (PTS) is converted to Full Timing Support (FTS) via an Inter-Working Function (IWF), but remains “hidden” from downstream elements without explicit source recovery indicators. By integrating these rules into existing selection processes, such as the Best time Transmitter Clock Algorithm (BTCA), the prioritization strategy improves holdover and synchronization recovery, ensuring that more reliable physical-based clock sources are chosen whenever possible.

[0219] FIG. 21 illustrates a flow diagram of an embodiment of a process 4090 for selecting a backup clock source. As shown, the process 4090 includes a step of receiving Master clock signals and source recovery indicators from upstream branches of a communications system, as indicated in block 4092, where each source recovery indicator corresponds to a respective Master clock signal. The process 4090 also includes a step of utilizing a prioritization strategy to prioritize the Master clock signals based on information derived from the source recovery indicators, as indicated in block 4094. During synchronization recovery, the process 4090 further includes a step of selecting one of the Master clock signals based on the prioritization strategy to act as a temporary synchronization source in a downstream branch of the communications system, as indicated in block 4096.

[0220] The process 4090 may be executed, for example, by a clock selection unit of a Network Element (NE) that is arranged between the upstream branches and downstream branch of the communications system. The NE, for example, may be a Telecom - Boundary Clock (T-BC) device, an Ethernet Equipment Clock (EEC) device, or another suitable type of branching network component.

[0221] In some embodiments, the source recovery indicators may be communicated from Master nodes in the upstream branches via an Ethernet Synchronization Message Channel (ESMC) defined in ITU-T Recommendation G.8264. The source recovery indicators, for example, may be inserted by Master nodes into previously unused Type, Length, Value (TLV) bits of a Protocol Data Unit (PDU) of the ESMC. In some embodiments, the source recovery indicators may include two bits in the PDU of the ESMC to designate a first state for indicating a deference to a Quality Lever (QL)-based selection, a second state indicating a frequency recovery from a higher-priority physical layer source, and a third state indicates a frequency recovery from a lower-priority packet source. The source recovery indicators may indicate at least whether the frequency recovery is from a physical layer source or from a packet source.

[0222] According to various implementations, the Master clock signals may be identified as being obtained from Synchronous Ethernet (SyncE) sources. The source recovery indicators, for example, may include information regarding a type of frequency source from which the corresponding Master clock signals originate, whereby the type of frequency source may be defined by a medium over which the frequency source is conveyed. The transportation medium, for example, may be a physical layer or a packet layer, where the physical layer may be defined by Ethernet communication according to ITU-T Recommendation G.8275.1 and the packet layer may be defined by Internet Protocol (IP) and / or Multiprotocol Label Switching (MPLS) communication according to ITU-T Recommendation G.8275.2.

[0223] The clock selection unit, in some embodiments, may be further configured to temporarily switch to a selected Master clock signal for recovery of clock synchronization when an original clock source between a grand master (GM) clock and a Precision Time Protocol (PTP) client is unavailable. The clock selection unit may be further configured to recover accurate frequency, time, and phase for alignment of the downstream branch with a Grand Master (GM) clock. The clock selection unit, in some embodiments, may further be configured to perform a frequency source recovery by prioritizing a physicalbased frequency source over a packet-based frequency source, wherein the physicalbased frequency source is communicated over a Full Timing Support (FTS) upstream branch, and wherein the packet-based frequency source is communicated over a Partial Timing Support (PTS) upstream branch. A first branch of the upstream branches, for example, may include an Inter-Working Function (IWF) component that converts Partial Timing Support (PTS) to Full Timing Support (FTS), where the first branch might be proneto high Packet Delay Variation (PDV), and where conversion from PTS to FTS is hidden from the downstream branch without knowledge of the source recovery indicators.

[0224] According to some embodiments, the clock selection unit may further be configured to default to a clock selection based on Quality Level (QL) before utilizing the prioritization strategy, where the clock selection unit may then perform the prioritization strategy when the QL of the upstream branches is the same. Alternatively, the clock selection unit may be configured to default to a clock selection based on QL after utilizing the prioritization strategy, where a QL analysis may be performed when execution of the prioritization strategy for the upstream branches results in equal priorities. In some embodiments, the process 4090 may be defined whereby the process of utilizing the prioritization strategy and selecting a Master clock signal may be configured as an enhancement to the Best time Transmitter Clock Algorithm (BTCA).

[0225] The systems and methods of the present disclosure include various points of novelty with respect to conventional systems. For example, various embodiments described herein are configured to utilize two bits in the ESMC PDU (FIG. 20) that are currently unused bits. These two bits may be inserted in the QL section of the TLV of the ESMC PDU to indicate the frequency source of a Master clock. Multiple upstream Master clocks may be configured to set the two bits accordingly to indicate their respective sources. A downstream Slave can then obtain the multiple source indication data (embedded in the previously unused spaces of ESMC message) and select a clock source based on which one would provide the best synchronization results. Corresponding modification to the functionality of the clock selection units 4022, 4042 in the Slave nodes can be made to help clients choose a better frequency source and to do so automatically. Clock Selection Algorithms (CSAs) of the clock selection units 4022, 4042 can be modified accordingly to assist with selecting a “better” clock (e.g., less frequency offset).

[0226] Conventional solutions would normally need manual user intervention to configure a fixed priority. This might be done at the client node for each available Master. Based on this priority, a specific Master can be selected. This might happen every time, wherever there is clock source change on the Master. Of course, these conventional systems are not dynamic and are unable to provide the benefits of the systems and methods of the present disclosure. That is, the conventional systems do not allow clients to choose frequency source based on upstream conditions to its available Masters. Clients using the conventional system may then end up selecting frequency sources fromhigh PDV-prone IP / MPLS network, instead of switching to a better “physical” recovered (e.g., Ethernet) frequency source as is made possible by the systems and methods of the present disclosure.

[0227] The current implementations described herein may use two (or more) bits in the QL TLV inside the ESMC PDU to indicate the Master's frequency reference source. Again, this may help downstream clients to choose a better SyncE reference dynamically via information coming from Master. The present disclosure therefore proposes a new clock parameter, which may be incorporated into the ESMC PDU standard and may be referred to as a “frequency selection priority” technique by using the two bits in ESMC PDU to designate various source conditions or characteristics. This new clock parameter may be considered in the clock selection criteria of NEs used throughout a communications network for selecting a highest prioritized clock source.

[0228] The systems and methods described herein may provide any number of benefits or advantages over traditional systems. The current embodiments may improve robustness of clocking in packet networks when used with various communications products and systems. It also can help network operators build clock resilient networks without needing detailed planning that would involve prior knowledge of different frequency sources that might be applicable in a network.

[0229] It may be noted that the novelty of the various embodiments of the present disclosure may be associated with prioritization of more reliable clock sources, which in turn may be based on the calculation of asymmetry values, variation values, variability values, synchronization offset values, or the like. An offset in clock synchronization of potential backup clocks may be analyzed with respect to a grandmaster clock source or other suitable primary clock source. Consideration of some variability factors (e.g., peak- to-peak asymmetry or variation) in the BTCA may be used to select the best available backup at run time.

[0230] As mentioned previously, a Telecom grandmaster (T-GM) may be configured as a specialized grandmaster clock used in telecommunications networks that implement PTP, and reference is made here to that discussion.

[0231] As also mentioned previously, the BTCA in ITU-T G.8275.2 plays a vital role in ensuring robust time synchronization in networks with Partial Timing Support (PTS) , and reference is made here to that discussion.

[0232] As also mentioned previously, with respect to the terms master and grandmaster, a grandmaster clock, e.g., the T-GM, is the primary source of time for the network, and reference is made here to that discussion.

[0233] In the network, the T-GMs and the T-BCs may be located at nodes or network elements, or links interconnecting the nodes or network elements, or a combination thereof. The T-BCs may have a backup local Synchronous Ethernet (SyncE) clock other than its congruent primary PTP connection to the T-GM, thus if the T-BC loses the PTP connection (e.g., due to degradation or other cause), it still has its Primary Reference Clock (PRC) traceable to the SyncE clock. However, as mentioned throughout the present disclosure, the conventional BTCA does not normally check variability factors (e.g., peak-to-peak variability of a waveform created by data points over time).

[0234] The Ethernet Synchronization Messaging Channel (ESMC) is a logical communication channel used in Synchronous Ethernet (SyncE) networks to exchange information about the quality level of a clock source, which may be known as "Synchronization Status Messages" (SSMs). The ESMC allows network devices to select the most reliable timing source across the network. Essentially, it is a dedicated channel within an Ethernet network for managing clock synchronization data between devices.

[0235] ESMC may allow the transmission of SSMs, which may contain QL values indicating the accuracy of a device's clock. ESMC, for example, is generally defined by the ITU-T G.8264 standard, but may be extended to include the upstream clock source origination information as described in the present disclosure. ESMC may use an Ethernet protocol to carry SSMs within the network and may help network devices to choose the best timing source by providing information about the quality of clocks throughout the network, preventing timing loops or other issues.§5$ Use of TTL Value to Select PTP Master

[0236] The foregoing discussion has described the use of criteria such as PTSF alarms for selection of a PTP master clock. In addition, or as an alternative, the Time-To- Live (TTL) value contained in the IP header of PTP packets can also be utilized for this purpose. In some embodiments, the IEEE 1588 Precision Time Protocol (PTP), or its associated telecom profiles (e.g., ITU-T G.8275.2 and G.8275.1 ), may be transported either (i) over IP / MPLS networks as partially time-aware (PTS) networks, or (ii) over Ethernet as fully time-aware (FTS) networks, between a PTP grandmaster (GM) and a PTP client. Under G.8275.2, PTP is carried over an IP network such that the PTP headerresides within IP packets, and the PTP client recovers accurate time and phase alignment to the PTP GM using the timestamps contained in those packets.

[0237] In a G.8275.2 PTS network, if multiple paths exist between a PTP client and a PTP master, it is desirable that PTP packets traverse the path with the fewest PTP- unaware hops. The number of PTP-unaware hops is significant in G.8275.2 because each such hop can introduce packet delay variation (PDV).

[0238] PDV may arise due to several factors, including:

[0239] (1) queuing, sharing, and scheduling in packet processing;

[0240] (2) inherent buffering delays within intermediate nodes; or

[0241] (3) congestion or packet re-ordering along the PTP path.

[0242] Current Alternate Best Time Clock Algorithms (A-BTCA) implemented at a time receiver do not consider the number of PTP-unaware hops, but instead rely solely on Announce message parameters when selecting the best time transmitter. However, if PDV is permitted to exceed permissible limits, the time receiver may fail to achieve lock, even when the Announce parameters indicate a seemingly high-quality master clock.

[0243] FIG. 22 illustrates a network diagram of a network 5000 having two grandmasters, T-GM-1 5002 and T-GM-2 5004, for illustrating the impact of hop counts on PTP master selection. A telecom boundary clock (T-BC-1 ) 5006 is shown receiving a primary PTP input from T-GM-1 5002 through an IP / MPLS network 5010 and a secondary PTP input from T-GM-2 5004 through an IP / MPLS network 5012. In this example, T-BC-1 5006 can reach T-GM-1 5002 through two alternative paths, 5020 and 5022. The first, primary path 5020, traverses only two PTP-unaware hops, while the second, alternate path 5022, traverses ten PTP-unaware hops. Under ideal conditions, T-BC-1 5006 selects the PTP reference from T-GM-1 5002 via the primary path 5020 with two PTP-unaware hops.

[0244] If the primary path 5020 fails, PTP packets may be rerouted through the secondary path 5022, which includes ten PTP-unaware hops, thereby still allowing T-BC- 1 5006 to maintain connectivity to T-GM-1 5002. In this case, T-BC-1 5006 will continue to select T-GM-1 5002 as its master via the longer path, even though the secondary PTP input from T-GM-2 5004 is more stable and traverses fewer hops. Ideally, a third path 5024 with fewer hops should be selected to minimize packet delay variation and improve stability of PTP synchronization.

[0245] The selection of master connected via a higher number of PTP unaware hops will further impact downstream clock in the T-BC chain. Following is an example wheredownstream clock (T-BC-3) receives a PTP clock from upstream G.8275.2 clock with IWF as defined G.8275.

[0246] FIG. 23 illustrates a network 5030 including ITU interworking functions (IWFs) 5032 and 5034 in G.8275 that translate between profiles, for example from G.8275.2 to G.8275.1. In this scenario, T-BC-1 5006 receives PTP input over two possible paths: a primary path 5050 traversing two IP / MPLS hops, and a secondary path 5052 traversing ten IP / MPLS hops. If the primary path 5050 fails, the PTP packets are rerouted through the secondary path 5052 with ten IP / MPLS hops. Both T-BC-1 5006 and T-BC-2 5006-2 implement the IWF functions 5032 and 5034 to translate PTP profile information from G.8275.2 to G.8275.1. As a result, for the downstream portion of the network 5030, beginning with T-BC-3 5006-3, both upstream networks appear as Full Timing Support (FTS) networks, since each provides a clock source expressed in the G.8275.1 profile.

[0247] In this example, T-BC-3 5006-3 receives two G.8275.1 PTP inputs: a primary input from T-BC-1 5006 and a secondary input from T-BC-2 5006-2. When T-BC-1 5006 is locked to its PTP source via the primary path 5050, T-BC-3 5006-3 also locks to T-BC- 1 5006. However, if the primary PTP path to T-BC-1 5006 fails, its PTP packets are rerouted through the secondary path 5052 with ten IP / MPLS hops. In this situation, it is not desirable for T-BC-35006-3 to continue using T-BC-1 5006 as its PTP input, because that input is more susceptible to packet delay variation (PDV). Instead, the PTP input from T-BC-2 5006-2 should be selected by T-BC-3 5006-3 as the preferable source.

[0248] This disclosure provides two solutions to address the foregoing problem, namely the consideration of Time-To-Live (TTL) values and the indication of the number of PTP-unaware hops. Incorporating the TTL value from the IP header of a received PTP Announce packet into the BTCA algorithm ensures that, in cases such as those described above, the PTP client preferentially selects the PTP source that is reachable via the fewer number of hops.

[0249] In the existing BTCA for G.8275.2, the number of intermediate PTP-unaware hops is not considered. According to the present disclosure, in G.8275.2 BTCA, when all Announce parameters are otherwise tied at the point of comparing localPriority, the TTL value in the IP header of the received Announce packet should be considered. As illustrated in the flow chart (see the newly introduced block marked in bold after the “compare localPriority” block), the system evaluates the TTL values of Announce packets received from multiple masters. If the Announce parameters remain tied after comparisonof local Priority, the master associated with the highest TTL value in the IP header is selected.

[0250] FIG. 24 illustrates a flowchart of a BTCA process 5080 that includes consideration of TTL values to overcome the deficiencies described with reference to FIGS. 22-23. The BTCA process 5080 is implemented by any node in the networks 5000, 5040, when there is a need to select a new time transmitter. It is contemplated that the BTCA process 5080 may be implemented as a method with steps, via circuitry configured to implement the steps, and as a non-transitory computer-readable medium storing instructions that, when executed, cause circuitry to implement the steps.

[0251] The BTCA process 5080 is an enhancement of the BTCA specified in ITU-T Recommendation G.8275.2 Amendment 1 , Figure 3. The BTCA process 5080 is used by a node, similarly to the BTCA processes 1030 and 3080, to select a time transmitter based on the data sets, referred to as data sets A and B each of which correspond to the attributes of two distinct clocks being compared to determine the Best Time Transmitter (BTT). These data sets are constructed from parameters extracted from the PTP Announce messages exchanged between clocks in the network. The algorithm ensures systematic evaluation of both clocks to select the optimal timing source, essential for maintaining synchronization accuracy and stability. For example, in FIG. 24, the data set A could correspond to the T-BC-1 5006 and the data set B could correspond to the T- BC-2 5006-2. Step 5082, 5084, 5086, 5088, 5090, 5094, 5096 are comparable to steps 1031 , 1032, 1033, 1035, 1036, 1037, 1038 respectively, of process 1030, within the context of the network 5000, 5030, and reference is made to process 1030 for the details of these steps and other overall characteristics of the process.

[0252] The BTCA process 5080 works by compared various points in the data sets A and B and selects either A (5100) or B (5098) at each step based on a comparison or moves to the next step if the values are equal. The present disclosure introduces a new check of a TTL values of the data sets A and B (step 5092, e.g. between steps 5090 and 5094), selecting the master with the higher TTL value. Here, the TTL value is read from the IP header of an Announce packet and can be used to infer the number of PTP- unaware hops the packet has taken. The Master with the higher TTL value (meaning it traversed fewer hops) is selected as the best clock. TTL works as a proxy for PDV risk.

[0253] By comparing the data sets A and B of two clocks, the BTCA process 5080 supports the most stable and accurate clock being selected as the Best Time Transmitter (BTT).

[0254] In the case of implementing an interworking function (IWF) that converts G.8275.2 to G.8275.1 (see FIG. 23), a G.8275.2 Master may indicate the number of PTP- unaware IP / MPLS transit hops to a downstream G.8275.1 time receiver clock by leveraging the TTL value contained in the I P header of a received PTP Announce packet from an upstream Master. The PTP Announce packet includes a reserved field of one octet. This proposal repurposes that 8-bit reserved field to carry a decimal value from 0 to 255 corresponding to the TTL value extracted from the IP header of the received Announce packet.

[0255] FIG. 25 illustrates the fields of an Announce packet, including the reserved field renamed as “ptpUnawareHopsTollpstreamTimeTransmitter.” A G.8275.2 Master generates a new Announce message in which this field is populated with the TTL value obtained from the IP header of the Announce packet received from its selected upstream Master. The Announce message is then forwarded toward the G.8275.1 time receiver clock. When the G.8275.1 time receiver clock receives Announce messages from multiple G.8275.2 TimeTransmitters, it evaluates the Announce parameters in the usual order. If all parameters up to and including local priority are tied, the receiver may use the “ptpUnawareHopsToUpstreamTimeTransmitter” field as a tie-breaker to select the better G.8275.2 Master. This approach is similar to the flow described with reference to FIG. 5, but in this case the TTL value is explicitly reported via the reserved field.

[0256] In the proposed approach, the TTL value in the IP packet is not modified, but the information is repurposed for use in PTP master selection. TTL is treated as an indicator of packet delay variation (PDV), since each PTP-unaware hop represents an opportunity for PDV to increase. Each unaware switch may add queuing delay, buffering delay, or re-ordering effects, particularly under network load, such that more hops typically result in higher and more unstable PDV. Accordingly, the TTL value provides a reliable proxy for the number of nodes or switches traversed: a higher TTL value indicates fewer hops, implying lower likelihood of PDV accumulation, while a lower TTL value indicates more hops and higher PDV risk. This principle is consistent with ITU-T Recommendations G.8271.2 and G.8261 , which describe the impact of network elements on PDV. In one embodiment, the TTL value serves as a tie-breaker metric in the Best Time Clock Algorithm (BTCA) when other Announce parameters (e.g., local Priority) are equal, ensuring that the path with the fewest PTP-unaware hops is preferred. The invention therefore considers hop count, derived from TTL, as part of master selection in G.8275.2, improving robustness in scenarios where multiple pathsare available. This also applies to interworking function (IWF) cases, enabling downstream G.8275.1 time receiver clocks to make improved decisions based on hopcount information carried forward in Announce messages. It is noted that embodiments that deduce hop count from TTL may rely on knowledge of the initialized TTL value at packet creation, and consistent setting or approximation of this initial value across the network may therefore be beneficial.

[0257] It should be noted that the BTCA processes 1030, 3080, and 5080 are not mutually exclusive. Rather, these processes can be used individually, sequentially, or in combination to achieve improved time selection results in different network conditions. For example, process 1030 enhances conventional BTCA operation by incorporating a frequency traceability flag, process 3080 extends BTCA by evaluating offset variability or peak-to-peak variation among candidate clocks, and process 5080 integrates hop-count awareness through TTL-based evaluation of RTF-unaware paths. In various embodiments, a network element may implement one or more of these processes concurrently, applying each criterion at the appropriate decision stage of the BTCA hierarchy. Such combinations enable more robust and intelligent clock source selection, ensuring that the best time transmitter is chosen not only on the basis of clock attributes, but also on the stability of the frequency source, the variability of the time offset, and the quality of the underlying transport path.Conclusion

[0258] The present disclosure enhances clock source selection in Precision Time Protocol, PTP, networks by improving both the Best Master Clock Algorithm, BMCA, and the Best Time Transmitter Clock Algorithm, BTCA. Conventional BMCA selects a grandmaster based on clock attributes announced under IEEE 1588 but does not consider link stability or error conditions, often causing unnecessary reselections and synchronization flapping. Similarly, BTCA as defined in ITU-T G.8275.2 selects a Best Time Transmitter during holdover in Partial Timing Support networks, yet lacks awareness of frequency traceability or stability, leading to suboptimal performance during degraded conditions.

[0259] The disclosed techniques introduce additional BMCA inputs such as link stability alarms, CRC errors, and clock class changes to ensure selection of a stable grandmaster. BTCA is extended to use a Frequency Traceable flag to prefer clocks backed by Synchronous Ethernet or Primary Reference Clocks, to compare offset variability against GNSS references, and to apply source recovery indicators in EthernetSynchronization Messaging Channel messages that favor physical-layer over packetlayer sources. These improvements yield more stable synchronization, longer holdover, and resilient recovery, enabling reliable performance in 5G and other time-sensitive networks.

[0260] Those skilled in the art will recognize that the various embodiments may include processing circuitry of various types. The processing circuitry might include, but are not limited to, general-purpose microprocessors; Central Processing Units (CPUs); Digital Signal Processors (DSPs); specialized processors such as Network Processors (NPs) or Network Processing Units (NPUs), Graphics Processing Units (GPUs); Field Programmable Gate Arrays (FPGAs); Programmable Logic Device (PLD), or similar devices. The processing circuitry may operate under the control of unique program instructions stored in their memory (software and / or firmware) to execute, in combination with certain non-processor circuits, either a portion or the entirety of the functionalities described for the methods and / or systems herein. Alternatively, these functions might be executed by a state machine devoid of stored program instructions, or through one or more Application-Specific Integrated Circuits (ASICs), where each function or a combination of functions is realized through dedicated logic or circuit designs. Naturally, a hybrid approach combining these methodologies may be employed. For certain disclosed embodiments, a hardware device, possibly integrated with software, firmware, or both, might be denominated as circuitry, logic, or circuits "configured to" or "adapted to" execute a series of operations, steps, methods, processes, algorithms, functions, or techniques as described herein for various implementations.

[0261] Additionally, some embodiments may incorporate a non-transitory computer- readable storage medium that stores computer-readable instructions for programming any combination of a computer, server, appliance, device, module, processor, or circuit (collectively “system”), each equipped with processing circuitry. These instructions, when executed, enable the system to perform the functions as delineated and claimed in this document. Such non-transitory computer-readable storage mediums can include, but are not limited to, hard disks, optical storage devices, magnetic storage devices, Read-Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory, etc. The software, once stored on these mediums, includes executable instructions that, upon execution by one or more processors or any programmable circuitry, instruct the processor or circuitry to undertake a series ofoperations, steps, methods, processes, algorithms, functions, or techniques as detailed herein for the various embodiments.

[0262] As used herein, including in the claims, the phrases “at least one of” or “one or more of” a list of items refer to any combination of those items, including single members. For example, “at least one of: A, B, or C” covers the possibilities of: A only, B only, C only, a combination of A and B, a combination of A and C, a combination of B and C, and a combination of A, B, and C. Additionally, the terms "comprise," "comprises," "comprising," "include," "includes," and "including" are intended to be non-limiting and open-ended. These terms specify essential elements or steps but do not exclude additional elements or steps, even when a claim or series of claims includes more than one of these terms.

[0263] While the present disclosure has been detailed and depicted through specific embodiments and examples, it is to be understood by those skilled in the art that numerous variations and modifications can perform equivalent functions or yield comparable results. Such alternative embodiments and variations, which may not be explicitly mentioned but achieve the objectives and adhere to the principles disclosed herein, fall within its spirit and scope. Accordingly, they are envisioned and encompassed by this disclosure, warranting protection under the claims associated herewith. That is, the present disclosure anticipates combinations and permutations of the described elements, operations, steps, methods, processes, algorithms, functions, techniques, modules, circuits, etc., in any manner conceivable, whether collectively, in subsets, or individually, further broadening the ambit of potential embodiments.

[0264] Although operations, steps, instructions, and the like are shown in the drawings in a particular order, this does not imply that they must be performed in that specific sequence or that all depicted operations are necessary to achieve desirable results. The drawings may schematically represent example processes as flowcharts or flow diagrams, but additional operations not depicted can be incorporated. For instance, extra operations can occur before, after, simultaneously with, or between any of the illustrated steps. In some cases, multitasking and parallel processing are contemplated. Furthermore, the separation of system components described should not be interpreted as mandatory for all implementations, as the program components and systems can be integrated into a single software product or distributed across multiple software products.

Claims

CLAIMSWhat is claimed is:1 . A method (300, 1030, 3080, 4090, 5080) for selecting and managing clock sources in a packet-based network (10, 1010, 3010, 4010), the method comprising: receiving, at a network element (100, 1016, 3036, 4020-2), timing information from a plurality of master clocks (12, 14, 1012, 3032, 4012); monitoring stability and quality of the timing information; and selecting a clock source to act as a synchronization reference based on the monitored stability and quality, thereby enhancing holdover, synchronization recovery, or both, in the network.

2. The method of claim 1 , wherein the selecting is performed by a Best Master Clock Algorithm, BMCA, (306) enhanced to consider operational state and physical link quality, ptsfjinkstability, in addition to clock attributes announced in Precision Time Protocol, PTP, Announce messages.

3. The method of claim 1 or 2, wherein the monitoring comprises detecting packet errors including Cyclic Redundancy Check, CRC, failures, ptsfjinkcrc, and wherein a PTP Telecom Synchronization Fail, PTSF, alarm is generated responsive to exceeding a CRC threshold.

4. The method of any preceding claim, wherein the monitoring further comprises detecting clock class fluctuations, ptsf_masterclkclass, of a master clock (12, 1012), and preventing selection of the clock when excessive fluctuations are present.

5. The method of any preceding claim, wherein the selecting comprises selecting not only a best master clock but a most stable master clock, thereby reducing flapping of grandmaster selection in the network (10).

6. The method of any preceding claim, wherein, upon a master entering holdover, the method comprises extending a Best Time Transmitter Clock Algorithm, BTCA, (1030,3080) to consider a Frequency Traceable flag, TRUE or FALSE, indicating whether a clock is traceable to a Synchronous Ethernet, SyncE, source (1018, 1020).

7. The method of claim 6, wherein the selecting prioritizes a master clock with the Frequency T raceable flag set to TRUE over a master clock with the Frequency T raceable flag set to FALSE.

8. The method of claim 6 or 7, wherein the Frequency Traceable flag is exchanged in PTP Announce messages and used in addition to parameters including clockClass, clockAccuracy, offsetScaledLogVariance, priority2, local Priority, and clockidentity (1031-1038).

9. The method of any preceding claim, wherein the monitoring comprises obtaining offset characteristics of multiple backup clocks (3074, 3076) relative to a primary reference such as a Global Navigation Satellite System, GNSS, source (20, 3040, 3060), and selecting a substitute backup clock based on a lowest variability factor.

10. The method of claim 9, wherein the variability factor is a peak-to-peak offset variation (3074b, 3076b), an average offset (3074a, 3076a), or a median offset over a predetermined window of time.

11. The method of any preceding claim, wherein the monitoring comprises continuously calculating offset characteristics of backup clocks in real time to enable immediate substitution upon loss of the primary reference.

12. The method of any preceding claim, wherein the selecting is performed in a branched communication system (4010, 4030) in which a downstream network element (4020-2, 4040-4) receives multiple upstream master clock signals (4026, 4028, 4046, 4048) and applies a prioritization strategy to select a temporary synchronization source.

13. The method of claim 12, wherein the prioritization strategy favors frequency sources conveyed over a physical layer, Full Timing Support, FTS, SyncE (4028, 4048), over packet-based sources, Partial Timing Support, PTS, Internet Protocol, IP, orMultiprotocol Label Switching, MPLS, (4014, 4034) when Quality Level, QL, indicators are otherwise equal.

14. The method of claim 12 or 13, wherein source recovery indicators of the master clocks are communicated using unused bits in an Ethernet Synchronization Messaging Channel, ESMC, Protocol Data Unit, PDU, (4060), the bits indicating whether the source is recovered from a physical layer or a packet layer.

15. The method of any preceding claim, further comprising operating a Best Time Transmitter Clock Algorithm, BTCA, (5080) based in part on an indication of time-to-live (TTL) value included in a packet transmitted by a clock source.

Images