RAN Disaggregation is expected to remove vendor lock-in and help to renew the supplier ecosystem. RAN disaggregation breaks-up the monolithic network approach to optimize the TCO, drive flexibility, and accelerate innovation. Disaggregation of 5G RAN involving functional decomposition, multi-vendor operation over open interfaces and decoupling of SW and HW has always been an essential part of 5G network vision.
Early deployments of 5G, however, have not adequately met the expectations in this respect. The key objective for the deployment of disaggregated RAN is the freedom to select RU (including AAS) supplier independently from the BBU supplier, enabling independent selection of equipment for these primary components of the RAN. This is based on the RAN ecosystem’s extension by introducing new vendors for RUs and BBUs, taking advantage of the Open Fronthaul (FH) interface between those network elements specified by O-RAN. Disaggregated RAN offers the ability to deploy more cost-efficient and better performing macro and small cell radio equipment from new vendors. It will allow Operators to re-use deployed RUs from incumbent vendors in an O-RAN environment.
Furthermore, introducing a centralized RAN element to act as an inter-site anchor and coordinator will improve network performance. Simultaneously, virtualization will cater to cost reductions for BBUs (vBBU with inter-site pooling gains). Advanced automation tools can further reduce operational costs using a single Service Management & Orchestration (SMO) framework to manage Networks Elements (NEs) of different vendors. Finally, the 5G network will benefit from increased flexibility regarding the deployment of new network functions and support of 5G service-related features like URLLC.
Disaggregated infrastructure
The MNOs must have a concrete description of the logical architecture in its disaggregated components and a structured proposal of different deployment alternatives. This way, a commercially deployable disaggregated RAN infrastructure will be achieved. These various deployment aspects range from HW/SW requirements for the different NFs to end-to-end (E2E) integration, including transport, OAM, and security. The methodology for total cost of ownership (TCO) analysis and preliminary results must be based on these deployment alternatives to assess their economic viability. Existing 3GPP specifications must be considered and extended by O-RAN specifications. This will enhance programmability and multi-vendor interoperability for the RAN and support service management and orchestration (SMO) functionalities to enable the implementation of the logical RAN nodes/functions in a highly virtualized and “cloudified” environment.
O-RAN
O-RAN is extending 3GPP’s logical architecture by new network elements and interfaces. 3GPP’s gNB/eNB-DU functionality is split into O-DU and O-RU with an open FH interface between O-DU and O-RU introduced as a novel standardized interface for low layer split (LLS). Near-RT RIC is presented as a new logical RAN node for enhanced RRM optimization. This will, in turn, provide a higher degree of flexibility and programmability in the RAN domain. A cloud-native platform where 3rd party applications, named “xApps” can be onboarded, where the O-RAN E2 interface will connect Near-RT RIC with the other logical RAN nodes, except the O-RU. Non-RT RIC is defined as part of the SMO framework connected to Near-RT RIC via the O-RAN A1 interface and controls RAN behavior via declarative policies. Four key OAM interfaces are defined by O-RAN: A1, O1, Open FH M-Plane (MP), and O2, connecting SMO framework to O-RAN network functions and O-Cloud (O-RAN Cloud).
O-RAN current limitations
O-RAN architecture is seen as the baseline for 5G long-term perspective. However, it covers a high number of possible functional blocks/nodes and related interfaces with some of those still at an initial or intermediate stage of their standardization work, such as Near-/Non-RT RICs and their A1 and E2 interfaces. Furthermore, unified O1/O2 interfaces with network elements (NEs) data models are yet to be defined. A stable and reliable implementation for deployment in the 2023 time frame requires a certain maturity level of the corresponding specifications. It also demands a specific period to prepare and perform interoperability testing (IOT) in the targeted multi-vendor environment.
Mid-term target architecture
The mid-term target architecture’s primary focus is on the proper implementation of the Open FH interface between O-DU and O-RU. This has already today a high level of maturity according to O-RAN specifications, covering CP, UP, and synchronization plane (SP) as well as MP and IOT profiles. Further splits like the CU-DU split can be considered from a functional point of view. Still, its usability over different network aggregation points will be dependent on the deployment strategy. Near-RT and Non-RT RIC, as well as AI/ML workflow, are envisioned from the current perspective as an integral part of disaggregated RAN architecture in the longer term. Still, they are not considered part of mid-term architecture due to their present immature level.
A1 interface related policy guidance procedures may be handled via OAM as in today’s systems.
The initial NETCONF/YANG based SMO should support an O-RAN-compliant MP for the O-RU based on Open FH specifications. Other nodes should be managed via the O-RAN compliant O1 interface, although some legacy equipment might be managed over NETCONF/YANG via a proprietary MP model. Some evolution of the Open FH MP specification to align with O1 specifications may be necessary.
The deployment strategy for a disaggregated RAN is generally strongly dependent on several factors, such as the HW capabilities of the underlying infrastructure layer and the possibility to decouple the implementation-specific SW layer from that HW layer. For example, using VNFs instead of PNFs where possible and using COTS processing HW instead of purpose-specific one, extensions by HW accelerators to be power-efficient, etc.
Furthermore, on the available set-up and cost of infrastructure at the different sites of an operator with opportunities to apply cloud-based RAN processing SW approaches and the x-haul transport network between the sites, since O-DU centralization goes in line with higher transport capacity requirements.
Deployment alternatives
Distributed vRAN: This type of implementation, with Open FH compared to CPRI, will require reduced transport capacity within one radio site, resulting in lower capacity in transport compared to other alternatives and with minimum RAN latency. However, only minor BBU pooling gains are expected, just intra-site, with a high demand for inter-site transport traffic (via X2/Xn) such as in the case of CoMP and inter-site MIMO/CA. Furthermore, there will be a need for IPsec to protect the S1 UP, and a more complex cell site DC management due to the high number of sites.
Centralized vBBU: This alternative will provide the highest BBU pooling efficiency due to incorporating several radio sites with many cells. The BBU will act as a coordinating node for centralized RRM optimization across an increased number of cells, including a centralized real-time scheduler. A slightly simplified radio site design will be required with only O-RUs, while more there will be flexible BBU resilience (N+1) in case of virtualization. On the downside, there will be a highly increased transport demand regarding capacity and latency, from aggregation to radio site due to Open FH compared to the distributed approach. Furthermore, there will be a potential need for geo-redundant implementation of vBBU and DC deployment at the aggregation site.
Centralized vO-CU at Aggregation Site: This alternative will provide a further extension of the vendor ecosystem (O-RU, O-DU, O-CU), but fewer benefits than the removal of O-RU – BBU vendor lock-in. O-CU will act as a coordinating node for non-delay-sensitive control functions, such as handover, dual connectivity, load balancing, and other features, across a high number of cells. It will provide higher flexibility for transport latencies and a reduced transport traffic capacity compared to a centralized vBBU approach. However, the pooling gain will be less, with increased IOT testing efforts in some multi-vendor scenarios due to additional open interface. There will be a potential need for geo-redundant implementation of vO-CU and a need for DC deployment at the aggregation site, lacking support for W1 with proprietary W1 from some vendors.
Mixture of Centralized vBBU & vO-CU: This mixture of the two deployment scenarios will have the highest flexibility with regards to O-DU placement according to service needs, deployment area, and infrastructure capabilities. This means centralized O-DU processing for FR1 cells and on-site processing for FR2 cells under the same O-CU coordination node. However, a more complex planning and implementation procedure is expected due to the heterogeneous infrastructure set-up of radio and aggregation sites. Alternatives with v-O-CU at the core site could also be considered. However, it is expected to have a possible negative latency impact on some of the RAN procedures.
