articularly in North America), with many deployed GPS receivers to have a backup in case of localized GPS out- ages. MSPs were also handicapped by the fact that many relied on third-party SP circuits to provide the majority of their back-haul links between the cell site and mobile core. This meant that they wanted to be able to have a transport solution for timing but had no opportunity to use on-path PTP support. So, the operators, working with the ITU-T, agreed upon an option to carry PTP over the third-party circuit using IPv4 (with IPv6 optional) without any on-path assistance. Another motivation is that operators prefer to have IP-based negotiation because they like control over the configuration of devices on their networks. The PTPoIP model offers that, whereas the G.8275.1 profile is based more on an approach that automatically determines the best topology. The downside to this approach was that any third-party circuit likely to be leased by the operator had no on-path timing support and yet probably contained a significant but unknown amount of asymmetry. The solution to this case was the assisted partial timing support (APTS). Figure 9-13 illustrates the major elements of this approach. PTP uses GNSS to measure and correct network asymmetry Assisted Partial Timing Support PTP-unware PTP-unware network #2 network #1 PRTC/T-GM G.8273.4 G.8275.2 T-BC-A boundary clock Figure 9-13 Architecture of an Assisted Partial Timing Support Solution At the end of the third-party network segments, there is a BC or perhaps even a slave clock embed- ded in the end application (in this example, a cell site radio). By this point, there could be a signific- ant amount of accumulated asymmetry because of the PTP messages have crossed numerous PTP- unaware network elements. The final slave or BC has a local source of time (likely a GPS receiver in this case) that it uses as its primary source of synchronization. However, this clock also contains a slave port that is recovering time from a PTP time signal from a remote PRTC an