 TS 38.133 in an O-RAN network, it is necessary to synchronize the O-DUs to each other (to meet TS 38.133) and to synchronize the O-RUs to their parent O-DU (to meet TS 38.104). Since the O-DUs are connected to both the backhaul and fronthaul network, there are three possible ways they can receive time synchronization: through a local GNSS receiver in the O-DU, via PTP from the backhaul network, and via PTP from the fronthaul network. The O-RUs on the other hand connect to just the fronthaul network so only have two options: through a local GNSS receiver in the O-RU and via PTP from the fronthaul network. However, if the O-RUs use PTP for their synchronization, there is an option of whether the PTP master is the O-DU itself, or another node on the fronthaul network-typically a fronthaul switch (FSH). To support the subset of these options that a network designer would most likely be inter- ested in using, O-RAN defines four so-called lower layer split control-plane architectures as shown in Fig. 8-24. Of these, LLS-C4 is the legacy "GNSS everywhere" approach and is probably the least likely to be used in an actual O-RAN network, because of the GNSS limitations discussed ear- lier, but it is provided for in case someone does want to deploy it for whatever reason. LLS- C1 and LLS-C2 cover the case where the O-RUs are synchronized to their parent O-DU, either through a direct connection or a FSH, and are likely to be the architectures most com- monly encountered. LLS-C3 uses a GNSS receiver within the FSH to provide synchronization to the O-RUs and, potentially, the O-DU. Which of the four topologies is used will depend on a number of factors, not all directly related to sync considerations. For example, LLS-C1 can only be used when the O-DU has enough downstream (fronthaul) ports to allow a direct connection to each O-RU, and even then it is only suitable if enough fiber links exist to support this. This may, for example, be the case when upgrading existing 4G infrastructure that previously used CPRI links. The Cha