h partial timing support from the network (SyncE optional). Use a combination of the preceding two methods with interworking between them. The GNSS-only (or GNSS-mostly) case is covered in the upcoming section "GNSS Everywhere," although some of the benefits and drawbacks of using only a GNSS solution are covered in multiple places throughout the book, most recently in the section "Redundancy" earlier in this chapter. 11.3.1 Network Topology/Architecture for Phase (G.8271.1 Versus G.8271.2) There are two basic network topologies available when building a timing distribution network, and each of the cases is covered by an ITU-T recommendation: G.8271.1: The MSP owns its own transport infrastructure and has the possibility to build and support a fully aware PTP and SyncE network. G.8271.2: The MSP is leasing CE and other third-party circuits and for that reason (or some other constraint) is not able to build a fully aware timing network. The first topology, using PTP and SyncE carried over an FTS network, is the best option because it delivers best-in-class performance and is being widely deployed and supported by the timing in- dustry. The second case, using PTP over a PTS network, is the second-best option and requires careful engineering to be able to meet the timing performance requirements. See Chapter 9 for the details of these reasons. The first case requires the use of the ITU-T G.8275.1 telecom profile (PTPoE) in combination with SyncE. Of course, every node between the GM and the final slave device must be timing-aware for it to be an FTS network. This means that every active network element must be either a Telecom Boundary Clock (T-BC) or a Telecom Transparent Clock (T-TC). The second topology is implemented with the ITU-T G.8275.2 telecom profile (PTPoIP), with SyncE being an optional assistance to carry the frequency. It is very important that every node in the PTS network that can support being a T-BC or a T-TC is configured as such. The more unaware nodes in the chain between the master and the slav