 |
1.1 |
1 |
(% class="row" %) |
|
|
2 |
((( |
|
|
3 |
(% class="col-xs-12 col-sm-8 test-report-content" %) |
|
|
4 |
((( |
|
|
5 |
---- |
|
|
6 |
|
|
|
7 |
Time synchronization in modern networks, such as 5G and the upcoming 6G, is facing increasing demands. Expectations for precision, system complexity, network size, and security are rising because 5G and 6G introduce new low-latency and coordinated radio use cases, along with more distributed architectures, all of which depend on highly precise and secure time synchronization; therefore, time synchronization solutions need to evolve to keep pace with these stricter requirements. |
|
|
8 |
To verify the evolution of time synchronization solutions to meet increasing requirements, such as timing accuracy and stability, security, support for higher bandwidths, and interoperability over long distances, we introduced new time synchronization test cases into the EANTC interoperability tests and reworked older ones. All test cases were developed in accordance with ITU-T and IEEE standards, as well as O-RAN Alliance specifications. |
|
|
9 |
|
|
|
10 |
This year, nine vendors participated in the time synchronization test area: Calnex Solutions, Ciena, Cisco, Ericsson, HPE, Keysight Technologies, Microchip Technology, Raisecom, and ZTE. |
|
|
11 |
|
|
|
12 |
=== ITU-T G.8275.2 Packet Forwarding === |
| |
1.1 |
14 |
In real-world synchronization setups, it's common to find multiple PTP profiles running in parallel, especially in mobile transport and xHaul networks. The choice of which profile to use often depends on the standard recommendation, network design, hardware in use, and the specific accuracy requirements of each segment. |
|
|
15 |
For example, access and fronthaul segments usually depend on meeting ITU-T G.8271.1 limits and using ITU-T G.8275.1 due to their need for high-accuracy phase and time delivery with Full Timing Support (ITU-T G.8275.1, FTS). On the other hand, aggregation or IP-based segments might use Partial Timing Support (ITU-T G.8275.2, PTS), as routers in these segments are often not FTS-compliant, leaving PTS as the only option for time synchronization using PTP. |
|
|
16 |
It’s not unusual for networks to implement each of these profiles in different network segments, traditionally using Interworking Functions (IWFs) to convert between FTS and PTS segments and vice versa. |
|
|
17 |
However, it should also be possible to make a PTS T-BC communicate directly with a Grandmaster that is providing both FTS and PTS PTP messaging, rather than having an intermediate FTS T-BC process and convert G.8275.1 to G.8275.2, which can introduce additional time error. |
|
|
18 |
This test verifies exactly that: the FTS T-BC-1 should operate as a boundary clock per G.8275.1 while simultaneously allowing G.8275.2 PTP packets to pass through like ordinary data traffic: forwarding them unchanged, without processing, modifying timestamps, or altering correction fields. |
|
|
19 |
|
| |
1.1 |
24 |
The International Earth Rotation and Reference Systems Service (IERS) is planning to remove the concept of leap seconds, including negative leap seconds, by 2035. A negative leap second, as the name suggests, is the opposite of a positive leap second; during a positive leap second, one extra second is added, e.g., instead of the time going from 23:59:59 to 00:00:00, it goes from 23:59:59 to 23:59:60 and then to 00:0:00. During a negative leap second, however, one second is skipped, meaning time jumps from 23:59:58 to 00:00:00. This is done to align the Coordinated Universal Time (UTC) with the Universal Time (UT1), which is based on earth's rotation. |
|
|
25 |
To date, there has been no recorded instance of a negative leap second, but there is still a chance of one occurring by 2035. |
|
|
26 |
Since only positive leap seconds have occurred to date, the impact of a negative leap second on various computer systems and networks is unproven in the real world. |
|
|
27 |
This test case is designed to test whether a time-synchronized network consisting of Telecom Boundary Clocks (T-BCs) using Precision Time Protocol (PTP) would correctly process a negative leap second and correctly propagate this information downstream. |
|
|
28 |
Since PTP itself is not affected by leap seconds, courtesy of using Temps Atomique International (TAI; eng. International Atomic Time), as leap seconds only affect UTC time, not TAI, our goal was to check whether the flags and the carried UTC offset value in the Announce messages were properly set and removed, as the T-BCs process the negative leap second information. |
|
|
29 |
|
| |
1.1 |
31 |
|
|
|
32 |
Additionally, we executed PTP over MACsec, PTP over coherent DWDM optics, APTS & delay asymmetry compensation up to 12 µs, Interworking Functions, and PTP over 800G, with almost all T-BCs used in testing being T-BC Clock Class D-compliant. In addition, we combined many of these features and test cases into a single test case, showcasing the culmination of this year's Time Synchronization testing in a single scenario, which will also be showcased at the Upperside World Congress in Paris. All of these tests and more can be viewed in the full version of the report. |
|
|
33 |
|
|
|
34 |
Please visit the link below or scan the QR code for additional information and details regarding the individual test cases and the vendors involved. |
|
|
35 |
|
|
|
36 |
The following test cases have been executed for this test area: |
|
|
37 |
|
|
|
38 |
{{container cssClass="toc-list"}} |
|
|
39 |
{{include reference=".Sidebar Nav"/}} |
|
|
40 |
{{/container}} |
|
|
41 |
|
|
|
42 |
(% id="prev-next-links" %) |
|
|
43 |
|[[< Previous>>doc:Main.EANTC Transport & Cloud Networks Interop Test Report 2026.SRv6.Static SRv6 policy with S-BFD]]|[[Next ~>>>doc:Telecom Boundary Clock Class CD Conformance]] |
|
|
44 |
))) |
|
|
45 |
|
|
|
46 |
(% class="col-xs-12 col-sm-4 test-report-sidebar" %) |
|
|
47 |
((( |
|
|
48 |
{{box}} |
|
|
49 |
{{include reference="Main.EANTC Transport & Cloud Networks Interop Test Report 2026.Sidebar Nav"/}} |
|
|
50 |
{{/box}} |
|
|
51 |
))) |
|
|
52 |
))) |
