whether PTP was even an option or not, the choice is likely moot since a legacy network will be used and all it depends on the services that network can support. Typically, in such a case, unless the backhaul Table 8-2 O-DU sync functions. LLS architecture O-DU sync source O-DU sync functionality as seen by fronthaul network LLS-C1 and LLS-C2 Local GNSS Grandmaster LLS-C1 and LLS-C2 Backhaul PTP Boundary clock LLS-C3 Local GNSS or backhaul PTP Passive LLS-C3 Fronthaul PTP Slave LLS-C4 Local GNSS PTP, Precision Time Protocol; GNSS, Global Navigation by Satellite Systems. Table 8-3 SyncE and Precision Time Protocol (PTP) profile combinations. PTP profile SyncE? Expected performance ITU-T stance O-RAN stance Supported Allowed Mentioned but not characterized Allowed Not SO good Supported Allowed but with caveats Worst Supported Allowed but with caveats FTS, Full-timing support; O-RAN, open radio access networks; PTS, partial-timing support. Chapter 8 Synchronization in open radio access networks network is operated by the O-RAN provider then PTP, if available, is likely to be provided in the form of "sync as a service." In other words, the network operator says our network will give you time via PTP, but we get to decide which profiles we provide and whether SyncE is available or not. For the fronthaul network, the choice is likely to be more flexible since this network will often be designed from scratch just for the specific application. Clearly, FTS with SyncE is the gold-standard and should always be the option of choice if there is such a choice. However, one stumbling block to this is what seems to be a growing interest in implement- ing the O-DU function on standard, data center-type, hardware, such as rack-mounted ser- vers with plug-in NIC cards to provide the network connectivity. The majority of such equipment available today does not include SyncE as an option, meaning that it is likely that a significant number of O-RAN deployments will be required to operate without SyncE. We shall see later what additi