mutexes that support priority inheri- tance, as well as moving all interrupt and software interrupts to kernel threads. Note that O-RAN WG6 defines the worst case benchmarked (with cyclic test, 4 the industry standard benchmark) PREEMPT_RT wakeup time to be better than 20 us (with proposals to bring this down to 10 us) for the DU application. This includes hypervisor overhead in the case of Virtual Machine deployment. In the CU application, PREEMPT_RT is optional, with proposals to define a maximum response time of 20 us. The wireless system often (such as in 3GPP systems) needs to be both frequency- and time-synchronous across physical units, which implies a requirement for a board level clock that is kept synchronous across the network. Time and frequency alignment are achieved through a combination of Synchronous Ethernet, GPS and/or IEEE1588 (Precision Time Protocol (PTP), Fig. 5-3) or similar protocols, or potentially from a (different) 3GPP network for which timing information is decoded over-the-air. Most 3GPP systems incorpo- rate a board-level oscillator (e.g., running at 122.88 MHz) as well as a Pulse Per Second source to perform both time and frequency synchronization functions. Time and frequency synchronization details are covered in a separate chapter. To allow the application software to function independent of any hardware timer func- tionality and to provide good (and bounded) application software performance, user plane modules have been designed to use a software timer which is based on a slot or frame timer, which is incremented once per frame or slot. Software timers can be implemented in many ways, for example, as an array of linked lists (Fig. 5-4), where each entry in the array repre- sents a frame time interval, and each entry contains a linked list of nodes. Reference5 provides an overview of timing wheel functionality (Fig. 5-4). The presence of a node in the linked list represents a timeout at that time. As different timeout cases (e.g., packet retransmission timeout for ARQ implementa