DU gets its synchronization from. Whether this is achieved using a local GNSS receiver or PTP (generally from the backhaul network, but potentially from the fronthaul in the case of LLS-C3) will frequently be determined by the capabilities of the backhaul network since for many O-RAN installations, this will be existing network and likely provided by a third party. If the backhaul network already supports PTP, it probably makes sense to use this to avoid 294 Open Radio Access Network (O-RAN) Systems Architecture and Design the limitations of local GNSS. However, it is expected that the majority of backhaul networks will not be architected to support PTP, at least for the first wave of O-RAN deployment, SO a local GNSS receiver at the O-DU is likely to be the preferred solution initially. Depending on the chosen LLS architecture and the O-DU sync source, the O-DU can per- form different synchronization roles as shown in Table 8-2. FTS or PTS? SyncE or no SyncE Having settled on the overall synchronization topology, the next question to answer for the network segments that will use PTP is should they support full or PTS and should they use just PTP or PTP + SyncE. Table 8-3 shows the options along with the ITU-T and O-RAN stance on each and the expected performance. There are a couple of points to note from the table. First, that ITU-T, the creators of all the standards relating to both SyncE and FTS, do not really address using FTS without SyncE. Specifically, they do not disallow it and even acknowledge the possibility of it, but critically they do not provide any performance numbers that can be expected. This leaves O- RAN on its own a bit since, as we shall see shortly, there is a clear reason for wanting to use this option, yet there is not really any guidance as to what to expect from it. Second, the per- formance of FTS will always be better than that of PTS. Considering the backhaul and fronthaul networks separately, what is the correct choice to make for each? For the backhaul network, as was the case for 