 to use a lower stability oscillator. This is shown in Fig. 8-33. Table 8-4 summarizes the typical oscillator requirements that might be expected for an O-RAN application. The second part of the equation is what is required of the local oscillator when the net- work time source itself is lost. There are a couple of reasons that such a loss could occur: The time source on the network, for example, the PTP Grandmaster or the GNSS receiver driving it, could go offline. The network connections between the time source and the slave device could fail. 304 Open Radio Access Network (O-RAN) Systems Architecture and Design No SyncE SyncE Local Local Oscillator Oscillator SyncE 1000s Timescale 1000s Timescale With SyncE, the noise contribution between about 10s and 1000sis Without SyncE, local oscillator noise dominates for observation from the SyncE source instead relaxed local oscillator intervals up to around 1000s requirement FIGURE 8-33 SyncE + PTP oscillator requirements. PTP, Precision Time Protocol. Table 8-4 Required oscillator stability. PTP profile SyncE? PTP servo bandwidth (mHz) SyncE bandwidth (Hz) Typical local oscillator 50-100 50-100 FTS, Full-timing support; PTP, Precision Time Protocol; PTS, partial-timing support. Traditionally, in legacy frequency-only systems such as SONET, which relied on syn- chronization of all nodes for the network itself to work, it was customary to require each individual node to remain within the synchronization limits for 24, or even 72, hours in the event of a failure. This, of course, requires a very stable local clock source, since there is no longer anything to lock to so it is free-running, but 24 hours holdover could be achieved with a TCXO normally, with an OCXO only being needed for the extended 72 hour require- ment. However, in a time-synchronization system, the situation is considerably different since any error in the local oscillator frequency will accumulate in the time domain. It is not necessary to go into the details of the calculations here, but the conclusio