First, the split between the CU and the DU is one that follows the functional split we saw between the Macro Base Station Line Card and NICs in traditional implementations. Telecommunication Distributed Unit (DU) Specialized Radio Unit Cloud (CU) High- High- High- Option 1 Option 2 Option 3 Option 4 Option 5 Option 6 Option Option 8 High- High- High- FIGURE 1-28 Central, distributed, and radio unit splits. Chapter 1 Open radio access network overview 31 The CU main function is the PDCP function (user plane or UP), but with this function typically comes IP/IPSec backhaul tunneling and of course support for the GTP to transport packets to/from the core network and other CUs over the X2 interface as we show next. This PDCP function is envisioned as a software-centric function (with ciphering being a conve- niently forgotten CPU intensive component as we will show) running on generic server platforms. CU functionality is not strictly correlated to physical time: the is no reliance on real-time software components and specific operating system/hardware support to achieve real-time deadlines (e.g., PREEMPT_RT features in Linux). Also, the CU scaling is not corre- lated to number of deployed radios, sectors, antennas, or other physical components. This makes the CU a component that naturally migrates to a server/software-centric solution that scales performance (throughput in Gbps) by adding CPU cores and IO interfaces, leveraging Moore's law. The DU does scale with the number of deployed radios as each radio requires its own MAC/RLC and high-physical layer stack implementation. Each radio is transmitting and receiving aligned to physical time which imposes real-time deadlines on both MAC and physical layer. Both these aspects (1:1 relation between DU/RU and real-time requirements) force the DU implementation to be more embedded in its implementation-tighter coupling between functionality and resources the functionality is running on, even when it is a software-centric implementation. This explains why the DU is separat