Architectural Considerations for Open RAN Deployments

With the introduction of Open RAN solutions, communication service providers (CSPs) now have much more flexibility in architecting and deploying their RAN systems. Traditionally, RAN systems are built by a single vendor and feature all the functionality in a single base station unit. With Open RAN, however, CSPs now have the option of choosing best-of-breed RAN solutions from multiple vendors and deploying those RAN functions—specifically, the centralized unit (CU), distributed unit (DU) and radio unit (RU)—in a disaggregated fashion across their network.

Open RAN is a positive development for the industry because it brings more vendors into the field, which drives faster innovation and lower prices. For example, RAN vendors can now sell their solutions as software running on a cloud-native environment. Yet, as with any innovation, Open RAN requires a thoughtful approach to get the most value from it, particularly as it now intersects the previously disparate worlds of server, cloud and mobile network technologies.

When Does it Make Sense to Separate RAN Functions?

Although Open RAN allows for geographically separating the CU, DU and RU functions, CSPs don’t have to take this route. They can deploy Open RAN as they would a traditional base station, with all the RAN functions located at the cell site. In this case, the RU is co-located at the cell tower along with the CU and DU at the tower’s base in a server rack configuration. The deciding factor of where the CU, DU and RU belong depends on various considerations, including timing, bandwidth, fiber availability and latency.

In many cases, operators will deploy the CU in a centralized site using a mid-haul connection, such as the mobile cloud core. So long as there is enough bandwidth available between the CU and DU, a centralized CU configuration works well and enables operators to consolidate CU functions on fewer servers, which reduces costs and power consumption. In some cases, the operator may also wish to centralize the DU functions to reduce the footprint at the cell tower site. However, the strict latency and phase timing requirements of the DU-to-RU front-haul connection and the high costs of access transmission resources tend to preclude operators from placing the DU in the mobile core network itself.

Bringing O-RAN to the Edge

Open RAN systems need management for automation, operation and optimization. The O-RAN Alliance has opened these interfaces to allow for the creation of a Radio Intelligent Controller (RIC) that can be delivered in near-real time or non-real-time versions with their supporting applications to improve performance. Non-real-time RICs and their associated r.Apps have a less stringent latency limit, which supports their deployment in the centralized telecom cloud. Meanwhile, near-real-time RICs and their x.Apps must be located within 10ms (round trip) from the RU/DU radio systems. Therefore, they are better deployed wherever they can serve multiple cell sites. For many operators, this will mean creating small “edge” data centers (e.g., a few racks of servers) to run the near-real time RIC and its applications, some of which will also require local storage.

The operational requirements of the RAN have renewed interest in building edge data centers for automation, operation and optimization solutions. These can also host the CU functions of the Open RAN, as well as MEC capabilities and/or 5G standalone user plane functions (UPFs) and N6 firewalls. This setup can support many 5G applications, from augmented/virtual reality gaming services for consumers to a wide area, low-latency solutions for the enterprise. To date, operators have primarily deployed multi-access edge computing (MEC) for their wide area network, as services in the core network telecom cloud. As O-RAN is deployed, these smaller edge sites are needed to optimize the overall network architecture and to support functions like the Ran Intelligent Controller.

Source: dell.com