re directly relevant to O-RAN. The IEEE 1588 standard is architected in such a way as to provide a framework that is flexible enough to be used for many applications with different synchronization require- ments and different network types, including non-Ethernet networks. However, this flexibility is a double-edged sword as it makes designing equipment that is fully compliant to the stan- dard unnecessarily complex. Therefore the standard allows for a layer of customization to be applied in the form of a PTP profile. The idea of a profile is that it defines an acceptable subset of the flexibility offered by PTP targeted at a specific application. IEEE itself, or another standards body, or indeed any other interested party, can create such a pro- file and a number of profiles have been defined to date. However, only two of these are rele- vant to O-RAN, both defined by ITU-T: Full-timing support (FTS)-Defined in G.8275.1 and designed to support the highest accuracy time transport over specially architected networks Partial-timing support (PTS) - Defined in G.8275.2 and designed to transport less-precise time (but still of the microsecond level) over more general network The difference between these two profiles and their uses will be addressed shortly. The operational details of PTP are very extensive, and it would take too long to give a full explanation, so what follows is an overview that is sufficient to understand how PTP can be used for O-RAN synchronization. Fig. 8-14 shows the general topology of a PTP network. There are one or more Grandmasters, which take time from, typically, GNSS and provide this to the network. The end nodes-the devices that require time, such as the individual Grandmaster Slave Grandmaster Slave BC = Boundary Clock Non-PTP Dataflow FIGURE 8-14 PTP network topology. PTP, Precision Time Protocol. Chapter 8 Synchronization in open radio access networks 281 O-RUs-are the slave and ultimately receive time from the Grandmasters. In between, there could be a number of so-called boundary cl