|
|
1 |
(% class="row" %) |
|
|
2 |
((( |
|
|
3 |
(% class="col-xs-12 col-sm-8 test-report-content" %) |
|
|
4 |
((( |
|
|
5 |
---- |
|
|
6 |
|
|
|
7 |
Asymmetric delay on links carrying PTP messages is critical and one of the most difficult issues for network time synchronization because PTP assumes the travel time is equal in both directions; if it isn't, the averaging calculation used to estimate the master clock's offset will be skewed by exactly half the asymmetry, introducing a systematic timing error that no amount of message exchange can self-correct. |
|
|
8 |
One way to combat this issue is Assisted Partial Timing Support (APTS). |
|
|
9 |
APTS is the functionality of a node/Telecom Boundary Clock (T-BC) that obtains its primary time reference directly from a GNSS source, essentially acting as a Telecom Grandmaster (T-GM) for its local segment. This node is referred to as an “Telecom Boundary Clock for Assisted partial timing support (T-BC-A)”. |
|
|
10 |
The "Assisted" feature operates in two main phases: During the calibration phase, which is the normal mode of operation, the node uses the active GNSS signal to constantly monitor and calculate the offset (constant Time Error; cTE) of the backup PTP path sourced from a Telecom Grandmaster (T-GM) and passing through one or more PTP-unaware network nodes. |
|
|
11 |
During the compensation phase, when the GNSS signal is lost, the node should seamlessly switch to using the backup PTP path as its primary time source. By applying previously recorded correction values, the APTS node automatically compensates for an average network asymmetry value (offset) and maintains phase accuracy, minimising phase jumps during the transition and reducing propagated time error. |
|
|
12 |
In our testing, we evaluated both phases using two separate test scenarios; first, we assessed T-BC-1's ability to correctly measure the asymmetric delay. Second, we verified T-BC-1’s ability to correctly compensate for the asymmetric delay following a GNSS signal loss. For this, we first applied an asymmetric delay of 1100 ns, then 2000 ns, and even 8000 ns. |
|
|
13 |
|
|
|
14 |
[[~[~[Figure 94: Assisted Partial Timing Support - Delay asymmetry detection/measurement and compensation - general test bed setup~>~>image:487251633567170561_APTS.png~|~|alt="Figure 94"~]~]>>attach:487251633567170561_APTS.png||target="_blank"]] |
|
|
15 |
|
|
|
16 |
The test-bed setup for both test scenarios consisted of one T-GM providing ITU-T G.8275.2 PTP (Partial Timing Support; PTS) to T-BC-1 over an impaired link as the backup PTP path. T-BC-1, acting as the T-BC-A, had a direct GNSS connection and used it as its primary reference, providing PTP downstream to T-BC-2. To assess the whole chain's performance, T-BC-2's output was measured by either the Calnex Paragon neo, Calnex Paragon neo-A, or the Keysight Time Sync Analyzer. If the T-GM was a real T-GM, then the Microchip TimeProvider 4500 was used in combination with the Calnex SNE Ignite as the impairment generator to impair the link towards T-BC-1. If an emulated T-GM was used, such as the Calnex Paragon neo, Paragon neo-A, or the Keysight Time Sync Analyzer, the impairment was generated directly by the emulated T-GM. |
|
|
17 |
Eight total combinations were performed for asymmetric delay detection and measurement, and all T-BC-1s successfully demonstrated their capabilities by measuring the 550-, 1000-, and 4000ns time offsets introduced by asymmetric delays of 1100, 2000, and 8000 ns, respectively, relative to their primary GNSS reference and the backup PTP path. |
|
|
18 |
For the asymmetric delay compensation, all seven participating combinations were successfully executed and tested. All T-BC-1s seamlessly switched from their GNSS reference to the backup PTP after the GNSS connection was cut. |
|
|
19 |
At first, an asymmetric delay of 1100 ns was set. Once the T-BC-1s had successfully finished their compensation calculations, their GNSS signal was cut. We observed a seamless switch to the backup PTP, meaning that the advertised clock class from T-BC-1 remained 6 throughout the switch, and therefore the downstream T-BC-2s never lost their phase lock to T-BC-1. |
|
|
20 |
Then, the GNSS connection to T-BC-1 was reestablished, and the asymmetric delay impairment was increased to 2000 ns. Once all compensation calculations were complete again, the GNSS connection was cut. The observation during the switch was the same as with 1100 ns; therefore, the compensation and switchover were once again successful. |
|
|
21 |
For the Ciena 5164, we also repeated the same steps once more, but this time with 8000 ns of delay asymmetry. Even then, there were no issues or abnormalities, as it still properly compensated for the 4000 ns time offset during the switchover to its backup PTP after the GNSS disconnection; the advertised clock class remained 6 throughout the switch, so T-BC-2s never lost their lock. |
|
|
22 |
All combinations and iterations were within the limits of class-level accuracy 6, as per ITU-T G.8271, demonstrating that delay asymmetries can be handled very well within a network, even up to 8 µs. |
|
|
23 |
|
|
|
24 |
{{container cssClass="tc-role-table"}} |
|
|
25 |
(% class="table-bordered" %) |
|
|
26 |
|=Telecom Grandmaster|=Telecom Boundary Clock - 1 - APTS node|=Telecom Boundary Clock - 2|=Impairment Emulator|=Frequency/Phase Analyzer |
|
|
27 |
|Calnex Paragon neo-A|Ciena 5164|ZTE ZXCTN 6120H-S|Calnex Paragon neo-A|Calnex Paragon neo-A |
|
|
28 |
|Calnex Paragon neo-A|Ciena 5164|Ericsson RAN Connect 6682|Calnex Paragon neo-A|Keysight Time Sync Analyzer |
|
|
29 |
|Calnex Paragon neo-A|Ciena 5164|HPE PTX10002-36QDD|Calnex Paragon neo-A|Calnex Paragon neo-A |
|
|
30 |
|Calnex Paragon neo-A|Ciena 5164|Raisecom iTN8800-A|Calnex Paragon neo-A|Keysight Time Sync Analyzer |
|
|
31 |
|Microchip Time Provider 4500|HPE ACX 7024 with GNSS-TMG-KIT|Ciena 5164|Calnex SNE Ignite|Keysight Time Sync Analyzer |
|
|
32 |
|Keysight Time Sync Analyzer|Ericsson RAN Connect 6682|ZTE ZXR10 M6000-4SE|Keysight Time Sync Analyzer|Keysight Time Sync Analyzer |
|
|
33 |
|Microchip Time Provider 4500|Microchip Time Provider 4500|ZTE ZXCTN 6120H-E|Calnex SNE Ignite|Keysight Time Sync Analyzer |
|
|
34 |
|Calnex Paragon neo-A|Ericsson Router 6676|Ciena 5164|Calnex Paragon neo-A|Keysight Time Sync Analyzer |
|
|
35 |
|
|
|
36 |
{{/container}} |
|
|
37 |
|
|
|
38 |
Table 73: APTS - Asymmetric Delay Detection/Measurement based on GNSS input |
|
|
39 |
|
|
|
40 |
{{container cssClass="tc-role-table"}} |
|
|
41 |
(% class="table-bordered" %) |
|
|
42 |
|=Telecom Grandmaster|=Telecom Boundary Clock - 1 - APTS node|=Telecom Boundary Clock - 2|=Impairment Emulator|=Frequency/Phase Analyzer |
|
|
43 |
|Calnex Paragon neo-A|Ciena 5164|ZTE ZXCTN 6120H-S|Calnex Paragon neo-A|Calnex Paragon neo-A |
|
|
44 |
|Calnex Paragon neo-A|Ciena 5164|Ericsson RAN Connect 6682|Calnex Paragon neo-A|Keysight Time Sync Analyzer |
|
|
45 |
|Calnex Paragon neo-A|Ciena 5164|HPE PTX10002-36QDD|Calnex Paragon neo-A|Calnex Paragon neo-A |
|
|
46 |
|Calnex Paragon neo-A|Ciena 5164|Raisecom iTN8800-A|Calnex Paragon neo-A|Keysight Time Sync Analyzer |
|
|
47 |
|Microchip Time Provider 4500|HPE ACX 7024 with GNSS-TMG-KIT|Ciena 5164|Calnex SNE Ignite|Keysight Time Sync Analyzer |
|
|
48 |
|Keysight Time Sync Analyzer|Ericsson RAN Connect 6682|ZTE ZXR10 M6000-4SE|Keysight Time Sync Analyzer|Keysight Time Sync Analyzer |
|
|
49 |
|Calnex Paragon neo-A|Ericsson Router 6676|Ciena 5164|Calnex Paragon neo-A|Keysight Time Sync Analyzer |
|
|
50 |
|
|
|
51 |
Table 74: APTS - Asymmetric Delay Compensation |
|
|
52 |
{{/container}} |
|
|
53 |
|
|
|
54 |
(% id="prev-next-links" %) |
|
|
55 |
|[[< Previous>>doc:Passive Port Monitoring]]|[[Next ~>>>doc:Time Synchronization Source Failover]] |
|
|
56 |
))) |
|
|
57 |
|
|
|
58 |
(% class="col-xs-12 col-sm-4 test-report-sidebar" %) |
|
|
59 |
((( |
|
|
60 |
{{box}} |
|
|
61 |
{{include reference="Main.EANTC Transport & Cloud Networks Interop Test Report 2026.Sidebar Nav"/}} |
|
|
62 |
{{/box}} |
|
|
63 |
))) |
|
|
64 |
))) |