FPGA) on the master side generates a timestamp that captures the difference in frequency between the network clock and the (customer) service clock. It includes that timestamp in the RTP header along with the data from the attachment circuit. On the (right-hand) slave side, the CEM node uses the timestamps to re-create the TDM clock fre- quency from the master end by replaying the timestamps against its own network clock reference. The major difference of DCR compared to ACR is that both ends of the emulated circuit must have traceability to a shared source of frequency for DCR to work. Operators and service providers tend to prefer DCR over ACR because it scales better for large, carrier-scale deployments. Additionally, DCR is not sensitive to PDV, certainly when compared to ACR. NTP for Frequency Most network engineers use NTP only to keep the system clocks of nodes in the network roughly aligned with each other, most of the time for use in operational tasks such as fault isolation and event correlation. When network alarms and syslog messages are captured with inaccurate timestamps, it becomes very difficult to try and determine the order of events in a complex situ- ation. However, in some specific circumstances, NTP has been deployed to transmit accurate fre- quency across a packet network. The most common case that the authors are aware of is Ericsson using NTP to give frequency syn- chronization to its base stations (eNodeB/eNB), mostly for 3G/LTE mobile networks. Mobile radio requires 50-ppb stability at the air interface, and engineers accept that this maps to a requirement of 16 ppb at the input to the radio equipment. For small cells (see Chapter 11), it might be somewhat looser. In theory, NTP and PTP provide basically the same performance, assuming that one is using the same algorithm, same clock, and the same network conditions. Also, both implementations must be supported by hardware timestamping (not SO common for NTP). One difference in performance comes from the fact that NTP does not support th