O-RAN Deployment Scenarios
Marcin Dryjanski
Telecom Professional - Ph.D. ? Wireless Research ? Technical Trainer & Consultant ? System Architect ? Team Leader
Deployment scenarios that the?O-RAN?ALLIANCE?specifies, define how to compose the elements of O-RAN architecture (O-RU, O-DU, O-CU, Near-RT RIC) in the actual network deployment within the cloud and physical locations. Those are defined in O-RAN Work Group 6 (WG6).
One of the key aspects from the deployment perspective is the Open Fronthaul (O-FH), where there’s the split between Virtual Network Functions (VNFs) deployed at O-Cloud (e.g., virtualized O-CU/O-DU), and the Physical Network Function (PNF, e.g., O-RU/RRH). O-Cloud is a cloud computing platform comprising physical infrastructure nodes to host O-RAN functions, like Near RT-RIC, O-DU, etc.; supporting software components (e.g., Operating System, Virtual Machine monitoring, container runtime), management, and orchestration functions.
In this blog post, we provide an overview of different scenarios and deployment options for O-RAN functions and the related implications, like processing and transmission latency and applicable use cases.
Note: If you are interested in the Open RAN concept, check?this post. If you are interested in the details of O-RAN (including all the abbreviations, like O-CU, O-DU, O-RU, etc.), here is the?relevant post.
Points of Presence (PoP) and Latency
Fig. 1 shows an example, of hierarchical infrastructure with cloud computing resources at various locations along with cell sites. The Regional Cloud is placed at a central location, typically in a regional Data Center (DC) for an operator with a large computing capacity. Edge Cloud is located close to the network edge, to assure cloud computing resources at a low distant place to decrease latency for data processing. The Cell Site is a location where the radio transmission is conducted to provide coverage for the desired area.
The typical distances (see e.g.,?Edge Cloud (OpenNFV), or?Edge Computing Group/Edge Reference Architectures (OpenStack), and specifically for O-RAN as provided in [1]) between the elements provided in Fig. 1 are:
Taking into account the above, we will now discuss the deployment of the O-RAN Base Station (BS) components, namely O-CU, O-DU, O-RU, and Near-RT RIC. (Note, the details about the mentioned components and the logical architecture can be found in?this post.)
For the BS, where we put all the entities at the cell site (i.e., O-CU, O-DU, O-RU, Near-RT RIC), we achieve the lowest possible latency for processing, and the services (e.g., video) are, most likely, processed at the edge. However, this deployment is the most expensive one – every Cell Site requires that all the functionality of the Base Station is placed there.
When we move the control of the BS (i.e., Near-RT RIC) and the connection anchor (i.e., O-CU-CP) towards the edge cloud, i.e., a more centralized PoP, we can gather/collectively manage the resources from the connected cell sites. Here, we still want to process the data including the User Plane traffic at the cell sites, thus they are kept there to ensure low latency.
Furthermore, we only leave the O-RU at the cell site by bringing other parts of the processing, including O-CU-UP and O-DU to the edge cloud. This increases the latency for data processing but implements a cheaper deployment with less processing power needed at each cell site location. For the non-latency-critical services, we can bring the Near-RT RIC and O-CU even more centrally, i.e., to the regional cloud. This gives the possibility to have a single Near-RT RIC and resource optimization gathering processing from more cell sites while only keeping the necessary processing units closer to the user.
One of the most important topic related to where to place the particular function of a Base Station is the required latency.
... to find out more about example service requirements and their relation with the deployment, reach out to the full blog post: O-RAN Deployment Scenarios - RIMEDO Labs
Note: Those requirements, when taken jointly, may be fulfilled utilizing the network slicing concept (see the accompanying?blog post here), where on a single physical network, the logical functions can be deployed on different PoPs per dedicated service.
O-RAN Cloud Deployment Scenarios
Fig. 2 below shows the considered deployment scenarios as provided in O-RAN ALLIANCE documents [1].
In scenario A, the whole BS is deployed at the edge as VNFs in the O-Cloud, while O-RUs are distributed to cell sites as PNFs. This minimizes the delay, but the cost of such deployment can be the largest compared to other scenarios below.
领英推荐
In scenario B, the actual processing of the BS (i.e., O-CU and O-DU) is deployed at the edge, so we keep low latency, but the Near-RT RIC is put centrally to the regional cloud DC to capture a broader view of the network. This is the initial use case as selected by the O-RAN ALLIANCE.
In scenario C, only the O-DU is at the edge, while we move O-CU to the regional DC to save cost and decrease energy consumption at the edge location. O-CU, in general, is working on a similar time scale as Near-RT RIC and thus they can be put together. Only the O-FH has stringent latency requirements, while E2/F1 interfaces can be more relaxed.
... to find out more about other scenarios and example mapping of O-RAN functions to cell, edge, cloud locations, reach out to the full blog post: O-RAN Deployment Scenarios - RIMEDO Labs
Summary
To summarize, the presented different deployment scenarios vary in the following terms:
Depending on the scenario, use case, services, and application requirements that are there in the network, the configuration and deployment may be different. For example, for mMTC type of services, the centralized option is feasible, while for the low-latency cases or private networking, localized deployment is required (see more elaboration on this aspect in the?following post).
It is important that there is this flexibility provided by the O-RAN ALLIANCE specifications, which enables those different options to realize various use cases and fulfilling varying application requirements.
To read the complete article including service requirements and relation to O-RAN deployment scenarios, along with various deployment scenarios themselves and example mapping of those from O-RAN functions, check the blog post @?O-RAN Deployment Scenarios - RIMEDO Labs
To check all our posts on 5G and OpenRAN-related topics see:?Blog - RIMEDO Labs
References
[1] O-RAN.WG6.CADS-v04.00,??Cloud Architecture and Deployment Scenarios for O-RAN Virtualized RAN”, O-RAN ALLIANCE, WG6, Technical Report, 10.2022
[2]??O-RAN Use Cases and Deployment Scenarios”, O-RAN ALLIANCE, Whitepaper, 02.2020
Rimedo Resources
Acknowledgment
Many thanks to?Marcin Hoffmann?and?Pawel Kryszkiewicz?for their valuable comments and suggestions for improvements to this post.
Independent Telecoms Consultant | Seasoned Telecommunications expert passionate with business process development, continuous improvement, technical solutioning and strategy development.
1 年Interesting read????