In real-world synchronization environments, it is common to encounter multiple PTP profiles operating side by side, particularly in mobile transport and xHaul networks.
The decision on which profile to deploy typically depends on the network’s design, the hardware used, and the specific accuracy requirements of each segment.
For instance, access and fronthaul segments often rely on ITU-T G.8275.1, since these areas require high-precision phase and time delivery with Full Timing Support (FTS). In contrast, aggregation or IP-based segments may utilize Partial Timing Support (PTS), as routers in these parts of the network frequently lack FTS compliance, making PTS the only viable option for time synchronization with PTP.
Running both profiles at the same time in a single network is not unusual, and, traditionally, Profile Interworking Functions (IWFs) are implemented: one T-BC accepts ITU-T G.8275.1 input, translates it to ITU-T G.8275.2, and sends it downstream to its client(s).
However, it is also feasible for a PTS T-BC to communicate directly with the Grandmaster and receive PTP packets, rather than requiring FTS T-BCs to convert from G.8275.1 to G.8275.2, which can introduce additional time error.
This test was designed to confirm that T-BCs can function as boundary clocks according to G.8275.1 while, at the same time, transparently forwarding G.8275.2 PTP packets as regular data traffic, without processing them, changing timestamps, or altering correction fields.

The setup consisted of one Telecom Grandmaster (T-GM), one Full Timing Support (ITU-T G.8275.1; FTS) Telecom Boundary Clock (T-BC-1), and one Partial Timing Support (ITU-T G.8275.2; PTS) T-BC-2, with both T-BCs being connected to a Frequency/Phase Analyzer.
To allow T-BC-2 to communicate with the T-GM through T-BC-1, either ISIS or static routes were configured. The T-GM would then send both FTS and PTS PTP packets downstream over a single link; T-BC-1 would process its own FTS PTP packets while transparently forwarding the PTS packets to T-BC-2.
We verified transparent forwarding of the PTS packets by checking the StepsRemoved counter on T-BC-2. Since T-BC-1 should not have processed the PTS packets, T-BC-2 should see StepsRemoved = 1, as it is logically the first T-BC to receive them. This functionality was executed and verified in 11 different vendor combinations.
Additionally, we applied the Network limits at reference point C at the end of the chain, as per ITU-T G.8271.1 for the max|TE_L| (1100 ns) and the dynamic Time Error (dTE) Maximum Time Interval Error (MTIE) low-pass filtered. Unsurprisingly, every test combination was well within those limits, with all combinations within the class-level accuracy 6C (+/- 65 ns), as per ITU-T G.8271.
Verifying this functionality was important because it means that IWFs may not be required in certain cases, thereby avoiding the time error and operational complexity they could introduce.

Table 78: ITU-T G.8275.2 Packet Forwarding - Test combinations