ifference when compared to a T- Local primary timing source PTP and PTP and PTP and SyncE from PTP and SyncE SyncE remote SyncE secondary source T-BC with virtual port Master port Slave port Figure 9-4 T-GM with Embedded GNSS and T-BC with Virtual Port One small but important detail is that a T-GM can never have a remote backup because one of the cast-iron rules in 1588 is that the T-GM can never take a clock input from another clock source. It can take frequency, phase, and time in from a local source, but it can never have a slave port syn- chronized to another PTP clock. For that reason, if you have a clock that uses GNSS as its primary source, but you require a form of backup from another (remote) PTP T-GM, then you must configure the device as a T-BC with a vir- tual port. Making it a T-BC allows you to configure a slave port to use as a backup in case of an out- age in the local GNSS. For details of the virtual port, please refer to Annex B of ITU-T G.8275. Chapter 11 offers a lot more details on the use of GNSS-based systems to build a distributed timing solution for 5G synchronization, SO refer to that chapter for a discussion of the overall solution design alternatives. The following section covers several implementation considerations for GNSS deployments. The source of the signal for a T-BC with a virtual port (and T-GM) can be an embedded GNSS re- ceiver with some internal connectors to route the frequency and phase/time signals to the timing subsystem. It can also be an external GNSS receiver (a separate device) and connected to the T- GM/T-BC by external physical cables (1PPS, ToD, and 10 MHz/2 MHz/SyncE). Either way works, although the embedded (single box) solution allows for a much tighter integra- tion between the two functions, especially for maintenance and operational reasons. Using separate systems works better if the operator wants to choose a more "full-featured" GNSS receiver than one that might be embedded in a router. That would allow the operator to select a receiver that offers option