onal requirements this imposes on the actual equip- ment design. What about using PTS in the fronthaul network? Please don't. Just don't! It is not clear why O-RAN even entertains the option of PTS for fronthaul since it is very unlikely to be able to achieve the performance levels needed for many applications. Specifically, when ITU-T defined PTS, they did it with a view of providing microsecond level accuracy across a net- work, which clearly would not meet the requirements of intraband carrier aggregation out- lined earlier. One exception to this warning would be in the case of an LLS-C1 or LLS-C3 architecture with no other switches in the fronthaul network. In such cases, the physical net- work is actually identical between full and PTS since there are no intermediate nodes between the master and slave that may or may not be boundary clocks. In this case, the only difference between the two profiles will not be performance, but rather the format of the PTP messages. Details of these differences can be found in the ITU-T definitions of the two profiles, but, for example, FTS uses raw Ethernet frames, whereas PTS S used UDP/IP datagrams. The previous discussion begs a question. What happens in an LLS-C1 or LLS-C2 configu- ration that uses PTP to synchronize both the O-DU and the O-RUs, but in the specific config- uration, the backhaul and fronthaul networks use different PTP profiles-typically PTS on the backhaul side, since that is what the network operator provides, and FTS on the fronthaul side, since as we've shown that will offer the best performance? This scenario is shown in Fig. 8-25. The issue here is, what sync role is the O-DU now performing? It might appear to still be a boundary clock, because it is certainly performing the same function as if it was, say, FTS on both sides-taking time from the backhaul and passing it on to the fronthaul net- work, as well as using it locally for its own synchronization. However, there is subtlety here, in that all the ports of a boundary clock have to use the same