Figure 11-13 illustrates relative versus absolute timing within pieces of equipment clustered closely together. Synchronization chain Requirement 2: max|TE| < 260 ns inside synchronization Time error accumulation along the cluster timing chain up to hop 5 Requirement 1: max|TE| < 1.5 us for the entire chain, such as needed for mobile 5G TDD PRTC/T-GM T-TSC (in eNB) No of Hops Figure 11-13 Relative and Absolute Timing-Based on Figure VII.1 of ITU-T G.8271.1 As previously mentioned, the absolute requirement (requirement one) still applies, but the figure shows the additional relative requirement (requirement two) within the cluster of devices coordinat- ing with each other (sites 9, 7b, and 8b). In this topology, the timing signal is coming from a PRTC/T-GM located seven to nine hops away from the edge devices. Given what you have read about the accuracy of time degrading after transiting numerous boundary clocks, delivering requirement two over that many hops might seem to be very challenging. How- ever, note that the sites numbered 9, 7b, and 8b all source their timing signals via a common source, node 5. Since that common reference source is only two to four hops away, the error introduced between the PRTC/T-GM and node 5 can be discounted because it is common to the three devices in this cluster. The relative requirement is not quite SO onerous as it sounds, but it is still difficult. Given the difficultly with transporting highly accurate phase/time across many hops, could this use case support a "GNSS everywhere" style of solution, where both the RU and DU are synchronized using their own GNSS receivers? The performance for a PRTC Class A device is that it should be accurate to within 100 ns or better when verified against the applicable primary time standard (UTC). This is basically the level of accuracy guaranteed by the GPS system with a basic receiver. That means that the time recovered by a GPS receiver at the RU site could be up to 200 ns off when compared to the signal recovered from another receiver a