t necessarily require strict lower layer synchronization. It is also suitable for mobility and handover as it enables reducing handover failure probability. As in the case of split option 1, FH data rate scales relative to user traffic. Option 3: The split is performed within RLC sublayer. From 3GPP point of view, two options are defined in this split. The first option centralizes RLC automatic repeat request (ARQ), which can help recover from FH interface failure using ARQ recovery 11.1 Flexible Functional Split Toward RAN Slicing High- High- Option 1 Option 2 Option 3 Option 4 Option 5 Option 8 Option 7 Option 6 High- Figure 11.1 Options for functional splits for Cloud-RAN [4]. mechanism. However, since ARQ is responsible for end-to-end re-transmission, this option is more sensible to latency than split option 2. The second option separates transmit and receive RLC where transmit RLC is in DU whereas receive RLC is in CU. There is, thus, no constraint on downlink (DL) data transmission. However, placing transmit RLC in DU increases processing and buffer requirements in DU. Option 4: RRC, PDCP, and RLC are in CU. MAC, PHY, and RF are located in DU. The FH interface transports RLC packet data units (PDUs). Thus, the data rate of the interface is dependent on user activity. The drawback is that the split is not simple to implement and might be impractical because of the tight interaction between MAC and RLC. For example in DL, RLC considers its buffer size along with the scheduling decisions of MAC in terms of resource blocks to generate the RLC PDUs. This mechanism should not take a long time. Option 5: The split is within MAC, where part of the MAC functionality, for instance scheduling decision, is in CU whereas the time critical MAC processing is located in Option 6: For this option, the split is between MAC and PHY wherein only PHY and RF are in DU. The split offers a high level of centralization and pooling gain compared to the options above. Transport blocks are transmitted over the FH interface, and hence 