tions, initial packet transmission timeout for QoS, etc.) are supported through the single common timeout function described here, a common API is used to check for any timed-out items inside the linked list for a given frame number. This API is assumed to be called once per frame time, for example at the start of each frame. By keeping track of a node type field, the code can differentiate between different actions to be taken for different node timeouts. O-RAN clock_gettime() Fronthaul SW ptp4l phc2sys Ethernet H/W System Clock Ethernet H/W ORAN Fronthaul S1/F1 C/U Plane FIGURE 5-3 Time synchronization features in Linux. 190 Open Radio Access Network (O-RAN) Systems Architecture and Design Each entry in the array represents a new frame time. When end of array is reached, start at the start again. (array size effectively defines maximum timeout) Timeout Timeout Node B Node A Timeout Timeout Node C Node D position) Timeout Node C (being moved) FIGURE 5-4 Timeout array. The code assumes that all nodes that are not timed out (e.g., for ARQ: acknowledge received in-time for a transmitted payload) are removed before the timeout would take place. This means that if the linked list for the current array entry is nonempty, a timeout related action needs to take place. This saves processing power, as the code doesn't need to walk through any lists in order to check for any timeout to have happened. It is assumed here that the timeout case is less common than the nontimeout case. Challenge 2: Low overhead peripheral and accelerator access from the os A layer-1 application relies on hardware acceleration (e.g., access to an on- or off-chip Forward Error Correction decoder) and peripheral (e.g., Radio Over Ethernet packet IO) for key real time and performance critical components. However, typical Linux drivers rely on a vendor provided kernel space driver that can be obscure in its implementation and has little understood determinism and performance. This challenge is solved by moving to the con- cept of user-space drivers.