e PTP + SyncE implementation. It can be seen that the PLL function is still present to handle the SyncE physical-layer clock noise filtering. However, this is supplemented with multiple other blocks to handle the PTP function: Timestamper-This is responsible for timestamping incoming and outgoing PTP packets on the data-plane. One of the biggest considerations when designing a PTP sync solution, with or without SyncE, is where the timestamping of the PTP message packets is done. In general, to achieve the best accuracy, the timestamping should be done as close to the physical network connector as possible. This ensures that any additional delays that are introduced within the equipment itself are minimized. Such delays are effectively the same as network PDV and need to be filtered out by the servo to achieve time recovery. These errors result from things such as clock domain crossings and rate-matching FIFOs within the design of the data path. As shown in Fig. 8-30, there are three places where timestamping can typically be performed. In general, for fronthaul applications, SO the ports on an O-RU or the downstream ports on an O-DU, the timestamping needs to be performed at the PHY level to achieve the required accuracy. For backhaul connections, SO the upstream ports on an O-DU or the ports on an integrated small cell, MAC level timestamping will be acceptable. Software-based timestamping in the network driver really should be avoided for any telecom- grade application-the accuracy will in general simply not be good enough. Network driver-A software function that is responsible for sending and receiving PTP packets on the network. This is typically part of the same driver that handles other, nondata plane, packets such as the actual O-DU to O-RU data transport. In many cases, this driver will be part of CPU operating systems, for example, Linux. PTP stack-Another software function that implements the crux of the PTP solution. This portion of the software generates and processes the PTP packets and handles all t