Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Assisted Full Timing Support (AFTS)

Assisted Full Timing Support (AFTS) is an advanced timing solution designed to enhance network synchronization reliability. It combines GNSS, PTP, and synchronous Ethernet to provide robust phase and frequency synchronization in scenarios where GNSS alone might be vulnerable to disruptions.

Assisted Full Timing Support (AFTS) is an advanced synchronization solution that enhances the Full Timing Support (FTS) profile by combining GNSS, PTP, and synchronous Ethernet. In a typical configuration, GNSS serves as the primary source of synchronization for the node, ensuring accurate phase and frequency alignment. However, GNSS can be vulnerable to issues such as spoofing, jamming, or atmospheric distortion. Without a backup source, these failures would force the system into an expensive holdover state until GNSS is restored.

AFTS addresses this challenge by using G.8275.1 (PTP with synchronous Ethernet) as a backup timing source. Under normal operation, the node (T-BC-AF) locks to GNSS and operates as a grandmaster, while PTP and synchronous Ethernet run in the background. If GNSS fails, the system seamlessly switches to G.8275.1, leveraging PTP for time synchronization and synchronous Ethernet for frequency synchronization. This hybrid approach ensures continuity of service and minimizes timing degradation.

The solution supports multiple fallback scenarios. If both PTP and synchronous Ethernet are available, the system transitions to a hybrid clock mode, applying phase corrections based on previously calibrated offsets. If only synchronous Ethernet is available, the node maintains frequency synchronization and enters an indefinite holdover state for phase. If only PTP is available, it becomes the primary source for phase alignment. In cases where all sources fail, the system enters holdover mode if eligible, with a configurable holdover timer (default 240 minutes). Configure the Holdover-in-spec-duration parameter to configure the holdover timer. See, ptp.

When GNSS is restored, the system reverts to GNSS as the primary source, re-aligns synchronous Ethernet and PTP servos, and resets the last known base offset. This design ensures smooth recovery and consistent timing accuracy.

By combining GNSS with PTP and synchronous Ethernet, AFTS delivers a resilient synchronization architecture for mobile backhaul and other critical networks, reducing reliance on GNSS alone and mitigating risks associated with GNSS outages.

Note:

AFTS supports PTP over LAG.

AFTS States

  • GNSS active—GNSS is the primary timing source and the node operates as a T-GM. PTP and Synchronous Ethernet run in the background for redundancy. Backup phase offset between GNSS and PTP is calculated for seamless failover.

  • GNSS failure—The system behaves differently based on the following conditions:

    • PTP and synchronous Ethernet available—The system switches to hybrid mode using PTP for time and synchronous Ethernet for frequency. The system re-aligns to maintain phase accuracy.
    • Only synchronous Ethernet available—The system enters Holdover-in-spec state.
    • Only PTP available—Phase is maintained using PTP and the system re-aligns using PTP as primary.
    • No backup sources—The system enters the holdover state if eligible, else switches to the FREERUN state.

  • GNSS restored—The node switches back to GNSS as the primary source, and synchronous Ethernet and PTP servos re-align.

  • GNSS, PTP and synchronous Ethernet failure—The system moves to Holdover-in-spec state. After the timer expires, the system state moves to Holdover-out-of-spec.

  • Startup without GNSS—The system remains in FREERUN state until GNSS becomes available.

Holdover and State Transitions in AFTS

When GNSS loses lock and backup sources are unavailable or partially available, the system enters the HOLDOVER mode to maintain timing accuracy using the last known phase alignment. Holdover is triggered in scenarios such as GNSS failure combined with synchronous Ethernet down, PTP inactive, or complete loss of GNSS, PTP, and synchronous Ethernet. Upon entering holdover, the system resets the last known GNSS offset to zero. If only synchronous Ethernet is available, the system remains in Holdover-in-spec indefinitely without starting a timer. In all other cases, a configurable holdover timer (default 240 minutes) determines how long the system stays in-specification before transitioning to Holdover-out-of-spec.

From Holdover-in-spec, recovery depends on source availability:

  • If GNSS returns, the system switches back to GNSS as the primary source, re-aligns synchronous Ethernet and PTP, and resumes normal operation.
  • If PTP and synchronous Ethernet are restored without GNSS, the system uses PTP for phase and synchronous Ethernet for frequency, moving back to Phase Aligned state.
  • If only synchronous Ethernet returns, the system remains in Holdover-in-spec indefinitely.
  • If only PTP returns, the system re-aligns using PTP as the active source.
  • If no sources return, the system stays in Holdover-in-spec until the timer expires, then moves to Holdover-out-of-spec.

In Holdover-out-of-spec, the system continues degraded operation until recovery:

  • GNSS restoration triggers a return to GNSS as the primary source.
  • PTP and synchronous Ethernet restoration allows re-alignment to Phase Aligned state.
  • If only synchronous Ethernet returns, the system remains out-of-specification.
  • If only PTP returns, the system re-aligns using PTP.
  • If no sources return, the system stays in Holdover-out-of-spec.

This mechanism ensures graceful degradation and recovery, maintaining synchronization as long as possible while prioritizing GNSS when available.

Limitations

The following limitations are applicable:

  • PTP over IRB is not supported.

  • PTP over IPv4 timeTransmitter with G.8275.2 profile is not supported for AFTS.

  • G.8275.1 enhanced profile with AFTS is not supported.

  • AFTS mode is allowed only when GNSS configuration, boundary clock with G.8275.1 profile and synchronous Ethernet source are configured.

Activating and Deactivating AFTS

Use the set protocols ptp afts CLI command to activate the feature on the supported platform. Similarly, use the deactivate protocols ptp afts CLI command to deactivate the feature.

Sample Configuration

See the sample configuration of AFTS on ACX7348 and ACX7332 (with internal GNSS receivers) below:

See the sample configuration of AFTS on ACX7024 and ACX7024X (with external GNSS receivers) below:

Monitoring AFTS

Run the show ptp lock-status CLI command to know the current state of timing and synchronization when AFTS is activated. The following fields are of importance:

  • Lock State

  • Holdover State

  • Phase offset

  • Current Source

  • Primary Source

  • Secondary Source

Read through the Output Fields of the show ptp lock-status topic to learn more.

Platform-Specific AFTS Behavior

Use Feature Explorer to confirm platform and release support for specific features.

Use the following table to review platform-specific behaviors for your platform:

Table 1: Platform-Specific Behavior

Platform

Difference

ACX Series

AFTS is supported on ACX7348 and ACX7332 platforms with internal GNSS receivers (GF8801) and on ACX7024 and ACX7024X with external GNSS receivers (TB-1). All these platforms act as T-BC-AF nodes, locking to GNSS when available and using G.8275.1 as backup. The base profile remains G.8275.1, ensuring downstream timeReceivers maintain synchronization through PTP and synchronous Ethernet.