# Open RAN--Radio Access Network Evolution, Benefits and Market Trends
## 2 Mobile Network Architecture Evolution
In 5G NR, two different splits are distinguished, where Higher Layer Split (HLS) is the interface in a midhaul link between CU and DU, and Lower Layer Split (LLS) is the interface in a fronthaul link between DU and RU. In the report [5], the overall functional split assessment and justification for 5G is presented. The report's conclusion on functional split between central and distributed unit states that Option 2 should be used for HLS; however, lower layer split (LLS) needs further study. It is also indicated that high performance transport connection (in terms of bandwidth and delay) between CU/DU can enable scheduling optimization, which is a particularly desirable feature where the cross cell coordination brings gains. According to [5], higher layer splits may be applied in transport networks with higher transport latency, whereas lower layer splits can be applied in transport networks with lower latencies to achieve enhanced performance (e.g., centralized scheduling, coordinated multi-point (CMP) transmission and reception, higher efficient resource pooling). In the case of LLS, the use of a lower split results in a less complex RU. Regarding Open RAN, a key factor is opening the fronthaul (FH) interface, which has never been common before. The O-RAN specification decided that the split called 7-2x will be standardised together with Control, User and Synchronization Plane (CUS-Plane), with the aim to separate transmission of control, user and synchronization data [18]. Figure 2: Review of functional splitting options with respect to 3 GPP 4G/5G RAN stack (above) and differences among Option 7 split from PHY layer perspective. Such an approach allowed to exploit the enhanced Common Public Radio Interface (eCPRI) protocol [8], used to transmit radio data encapsulated into Ethernet frames (as discussed in Section 5), in a multivendor environment both in LTE and NR Radio Access Technology (RAT). Three different versions of split Option 7 (shown in Figure 2) were evaluated and identified [19]: O-RAN selected split 7-2x, in which bandwidth demand scales according to the number of spatial layers, whereas splits 7-1 and 7-3 scale according to the number of antenna elements and coded bits, respectively [20]. Moreover, two categories of split 7-2x were defined by O-RAN, i.e., Category A and Category B. These categories differ in the placement of decoding function, namely, in DU for Category A and in RU for Category B, where the latter is supposed to support more complex mMIMO scenarios. The details of O-RAN fronthaul specification are described in [18]. The RAN architecture evolution towards splitting and node decomposition among different RAN stack protocol and layers is perceived as horizontal openness. Overall, Open RAN is related to disaggregation, which could be defined in at least four dimensions [21]--see Figure 3--(1) separation of control and user planes, which has been already performed in 5G/new radio (NR) systems; (2) horizontal disaggregation related to opening the interfaces; (3) vertical disaggregation related to decoupling hardware and software; (4) disaggregation of software and data pipe, by introduction of AI/ML techniques and connectivity to external contextual data sinks which are able to take a vital role in RRM (Radio Resource Management) optimization and performance. Open RAN does not mean the disaggregated dimensions mentioned above are deployed completely within a particular solution. In case of the vertical disaggregation, hardware and software are decomposed and allow to run network functions (NFs) on COTS solutions. A next step is a successive RAN virtualization (vRAN), where NFs are run as virtual network functions (VNF), and containerization, where NFs are run in containers as containerized network functions (CNFs). Such a cloudify approach allows for better orchestration and service management. CNFs are more flexible than VNFs, which are maintained by hypervisors [22], as VNFs tend to be single-purpose appliances, which are not enough scalable in cloud deployment, contrary to CNFs.