Show last authors
1 (% class="row" %)
2 (((
3 (% class="col-xs-12 col-sm-7 test-report-content" %)
4 (((
5 ----
6
7 As per ITU-T J.211, Bridging mode is the behavior of a Data-Over-Cable Service Interface Specification (DOCSIS) Timing Interface (DTI) that loses its controlling input. In this case, the DTI can use its stored data to control its output without changing into the holdover state if the clock performance is within normal/acceptable limits. Should this bridging go on for too long, the DTI should transition into holdover, indicating to the clocks downstream that the clock quality might have degraded.
8 Now, as applicable to our scenario, this means that we have a Telecom Grandmaster (T-GM) that loses its GNSS input. Rather than entering holdover immediately, it can, for a certain time period, enter the so-called "Bridging Mode." This means that the T-GM can be configured to advertise clockClass 6 rather than clockClass 7 as long as its timing performance is still within acceptable limits. This ultimately means that the downstream clocks will not know that the T-GM has lost its GNSS input during the bridging period.
9 While the definition for Bridging Mode does not yet exist for T-GMs/telecom clocks, it will be requested to be standardized in a future ITU-T G.82xx standard.
10
11 This feature is enabled by this test's T-GM, the Microchip TimeProvider® 4500, which has an internal rubidium oscillator. Using this rubidium oscillator, the T-GM will keep providing PTP and SyncE to the downstream BCs while advertising clockClass 6, even after losing its GNSS reference.
12 This test evaluates the T-GM 's ability to uphold acceptable time error values/timing performance during the bridging mode after losing its GNSS input.
13
14 [[Figure 129: Bridging Mode with Simulated Telecom Grandmaster GNSS disruption - Setup>>image:434720496056008705_5.24.png||alt="Figure 129" width="550"]]
15
16 For this test, seven Boundary Clocks (BCs) were directly locked onto the T-GM while it still had its GNSS input. After around 100s, the GNSS connection to the T-GM was cut, and the test was left running to reach one hour. Throughout the whole hour, the Telecom Grandmaster kept advertising clockClass 6. The measured PTP MTIE of all BCs was lower than the limit defined by "G.8272 Wander Gen. PRTC-B" (ITU-T G.8272, table 2/figure 1) mask and the SyncE TIE was at all times within the thresholds of the "G.8262 Long-Term Holdover with constant temperature EEC1" (ITU-T G.8262, section 11.2.1/figure 13) mask.
17
18 This test case gave us great insight into the capabilities of a T-GM with a high-quality oscillator, in this case the Microchip TimeProvider® 4500. It showed that even without the GNSS input, a highly accurate PTP and SyncE stream can be provided, and therefore, it does not need to immediately switch into holdover, causing all downstream clocks to re-evaluate their Time Synchronization path.
19 This feature can prevent rapid transitions between clockClass 6 and 7 in case of brief GNSS signal disruptions. Constant re-evaluation of the Time Synchronization path by the downstream clocks could lead to network instabilities.
20
21 (% id="prev-next-links" %)
22 |[[< Previous>>doc:Delay Asymmetry DetectionMeasurement]]|
23 )))
24
25 (% class="col-xs-12 col-sm-5 test-report-sidebar" %)
26 (((
27 {{box}}
28 {{include reference="Main.Multi-Vendor MPLS & SDN Interoperability Test Report 2025.Sidebar Nav"/}}
29 {{/box}}
30 )))
31 )))