contigu- ous (or no) carrier aggregation (Category B). From Table 8-1, this imposes O-RU to O-RU air interface synchronization requirements of 130 and 260 ns, respectively. Now, this is a rel- ative requirement between the two O-RUs, but each O-RU does not synchronize to the other O-RUs-instead, they all synchronize to the associated O-DU. Therefore the synchronization limit between the O-DU and any one O-RU is half of this number, since one O-RU could be off by a certain amount in one direction, while another one is off by the same amount in the opposite direction, meaning that the error between the two is twice whatever the error of each one is, as shown in Fig. 8-26. However, this does not mean that the network connection between the O-DU and O-RU can use up all of this synchronization budget because the O-RU itself will introduce addi- tional errors between its input, the fronthaul network connection, and its output, the antenna connector. Therefore some of the sync budgets have to be assigned to this error, eating into the error that the network itself can add. What causes this additional error? Well, there can be a number of sources but the biggest factor is how well the PTP slave function in the O-RU can recover time from the network, in other words, the error between the packets on the network a subsequent physical clock output, such as a 1PPS signal, that drives the radio functionality of the O-RU. Additionally, the radio itself will add some further errors due to data buffering, clock domain crossing, etc. In reality, O-RAN assumes that the PTP slave function is fully integrated into the O-RU SO it will often be impossible to identify how much of the overall error can be attributed to each function. O-RU clock fast Relative error by 85ns which is what we care about Same time provided to both O-RUs O-RU clock slow by 65ns FIGURE 8-26 O-DU to O-RU limits. 298 Open Radio Access Network (O-RAN) Systems Architecture and Design In order to allow some flexibility in simplifying system design in architectures t