t shown for brevity. Eventually, this architecture was generalized even further, when control- and user-plane functions have been separated into their own logical network nodes. Eventually, 3GPP have standardized the option 2 (PDCP-RLC split) in the CU/DU split architecture with fronthaul interface between a CU and a DU called F1 - this is described in detail in Section 4.2. Even though this option provides little to no gain in terms of scheduling and resource pooling, it was considered a relatively "low-hanging fruit" as it uses similar functional split to the multi-connectivity architecture (described in Section 4.1), which has also been standardized in 3GPP. Additionally, this option becomes more appealing and can provide significant resource pooling gains if an operator deploys a CU in a virtualized envi- ronment (described in Section 6.2), potentially together with the Mobile Edge Compute system (described in Section 6.4) running on the same hardware platform. Furthermore, a variant of split option 1, in which the control plane (e.g. RRC) is separated from the user plane, has also been standardized in 3GPP and is supported by the E1 interface - this is described in detail in Section 4.4. Figure 4.1.11 Generalized gNB functional split architecture with CU, DU, and RU. 4 NG-RAN Architecture Despite significant interest in a low-level functional split option, 3GPP could not reach the consensus required to standardize it. While nobody challenged the technical benefits of the low-level split, some companies argued that providing a truly multi-vendor interoperable standardized interface to support it is not feasible. As it was not possible to conduct this work in 3GPP, some companies turned to O-RAN Alliance, which produced the low-level functional split specification (a variant of option 7-2). For more details see Section 4.5. 4.1.5 Conclusions In this introductory section we defined the "monolithic" gNB architecture, in which all (but the RF and the antenna) parts are implemented in a single network node. We the