e higher packet rates available when using PTP. The reality is that PTP has much wider support in the timing and networking communities and much better hardware support. This deployment option is mentioned here only for completeness because it might be an option that you come across, particularly in a pre-5G mobile network with Ericsson equipment. Otherwise, there is no reason to expect you would have to deal with it because the rest of the industry prefers other methods, most particularly PTP. PTP for Frequency The most popular alternative to carrying frequency over a network using packet methods is to use PTP technologies. For most scenarios, this will mean using the ITU-T G.8265.1 telecom profile for frequency synchronization. There are two main reasons: It has strong support from industry and network elements. It is designed to interoperate with the timing aspects of SyncE, PDH, and SDH/SONET. Figure 9-8 illustrates the same CEM application as shown previously, but in this case all the CEM nodes are timed using a PTP clock rather than SyncE (compare it to Figure 9-5 where SyncE is used). The operator positions a PRC/PRS somewhere in the network combined with a GM running the G.8265.1 profile. Each of the nodes in the network that requires frequency runs as a PTP slave to recover the clock. The transport uses IPv4 (optionally IPv6), and there are no transparent or boundary clocks because on-path support is expressly forbidden in the defining standard. Customer CEM packets Customer premises premises Network Network clock Ethernet/IP clock TDM attachment TDM attachment circuit circuit Clock recovered Clock recovered from line from line Dejitter buffer PRC/PRS & PTP G.8265.1 GM Figure 9-8 TDM Circuit Emulation, Timed with PTP Telecom Profile G.8265.1 Note that because G.8265.1 is a method to transfer only frequency, it does not need to be a two-way protocol, meaning that only the messages from the master to the slave are required-namely the Sync and optional Follow_Up messages. For more details, see the sections 