 stringent in terms of throughput and latency requirements on the fronthaul transport network. The downside is that it offers little to no gains in terms of resource pooling and scheduling, as user plane functions are not centralized. Option 2 In this option, also referred to as PDCP-RLC split, the RRC and the PDCP protocol stack layers reside in the CU. The rest, that is, RLC, MAC, physical layer, and RF, reside in the DU. It has similar advantages (e.g. centralized RRM) and disadvantages (e.g. little to no per- formance and resource pooling gains) as option 2, with two additional benefits: 1. It becomes possible to realize some resource pooling gains, as PDCP processing is done in CU. 2. The PDCP-RLC functional split is very similar to the functional split supported in dual connectivity (see Section 4.3 for details), which allows a fair amount of reuse both in terms of standardization and implementation of both options. Note: this is the option that eventually was standardized in 3GPP, see Section 4.2. Option 3 In this option, also referred to as intra-RLC split, low-RLC (certain low-level/real-time functions of RLC), MAC, PHY, and RF reside in the DU. PDCP and high-RLC (the remain- ing parts of RLC) are in the CU. Two flavors of option 3 have been considered, specifically: Option 3-1 In this option, low-RLC implements the segmentation function, while high-RLC imple- ments the Automatic Repeat Request (ARQ) and other RLC functions. 4.1 Introduction In terms of benefits, it allows further resource pooling gains compared with option 2, as more functionality is centralized in the CU. Additionally, it offers better flow control and can tolerate failures in the fronthaul transport network, as ARQ (and retransmission) functionality is implemented in the CU. This comes at a cost of somewhat more stringent latency requirements for the fronthaul transport network. Option 3-2 In this option, the split is based on transmit and receive RLC entities. That is, low-RLC implements transmitting Transparent Mode (TM) RLC entity,