5G ORAN Deployment: Field Insights and Best Practices for Automated and Orchestrated Provisioning White Paper

 

Abstract

The success of 5G deployment for a service provider hinges on the strategic architectural planning of the infrastructure. In the contemporary landscape, automation is favoured across complex and repeatable business processes. In the case of Open Radio Access Network (ORAN) deployment, automation plays a pivotal role in expediting processes that would otherwise demand days, reducing them to mere hours. Although routers used in network transport offer Zero-Touch Provisioning (ZTP) capabilities, the creation of an entire network, encompassing cell sites, necessitates extensive effort and orchestration across multiple components. In this context, we delve into the important considerations of cell-site provisioning through automation and orchestration.

Introduction to ORAN and its components

The O-RAN Alliance^[1] organizes its collaborative efforts into specialized Work Groups (WGs). These groups cover architecture and use cases (WG1), which defines open and standardized RAN interfaces; RAN Intelligent Controller (RIC) (WG2), focusing on the development of intelligent and programmable RANs; use cases and deployment scenarios (WG3), identifying practical deployment scenarios; OAM (operations, administration, and maintenance) (WG4), addressing O-RAN network management; security (WG5), ensuring network security; integration and testing (WG6), managing interoperability; and The White-Box Hardware Work Group (WG7), which specifies standardized hardware components. These groups collectively contribute to the O-RAN Alliance's goal of fostering open, intelligent, and interoperable RAN architectures for enhanced wireless network efficiency.

The 5G Radio Access Network (RAN) consists of three fundamental components:^[2] the Radio Unit (RU), Distributed Unit (DU), and Centralized Unit (CU). These components can be hosted on Commercial-Off-The-Shelf (COTS) hardware or cloud-based servers. Consequently, a 5G transport network comprises fronthaul, midhaul, and backhaul networks, with the CU connected to the core through the backhaul network. Deployment scenarios vary among operators based on transport availability and specific requirements. Typically, four RAN deployment scenarios are considered:

●     Independent RU, DU, and CU (Fig. 1, Type 1): RU connects through fronthaul to a cloud-hosted (or remotely hosted) DU, which is linked through midhaul to the remotely hosted CU.

●     Independent RU, co-located DU and CU (Fig.1, Type 2): in this scenario, only the midhaul network is absent.

●     Co-located RU and DU (Fig.1, Type 3): the DU is hosted on the cell site and connects to the CU through the midhaul network.

●     Integrated RU, DU, and CU (Fig.1, Type 4): This configuration is typically employed for small cells and hotspots, connecting directly to the core network through the backhaul network.

RAN deployment models

Hybrid configurations are also possible, enabling cell sites with only RU to connect to another site, which subsequently links to an aggregator DU, facilitating diverse deployment options.

Different service providers choose their own flavors of this architecture. For example, Rakuten uses type 2 ‒ that is, independent RU and co-hosted DU, CU^[3] ‒ for its network while Dish seems to use type 3.^[4] A service provider is not expected to have only a single type of this architecture; usually a mix of these can be found. A service provider may choose type 1 as the first preference for most regions and type 4 for congested regions. These deployment scenarios are dependent on the requirements and technical constraints of the service provider; accordingly, a combination of these may be used. The multitude of deployment models, such as Cloud RAN, C-RAN, CU/DU split, and D-RAN, open many options to choose from^[5].

Background

This white paper covers learnings from an automation solution developed for an emerging U.S. 5G service provider. In the case discussed, the cell sites comprise a Cell Site Router (CSR), a bare-metal server, and radio units, among others. The bare-metal server hosts the DU on the cell site, connecting to a CU through a transport established between a CSR and Provider-Edge (PE) routers. The CU is hosted on the cloud.

Because this was a greenfield deployment, the scale to provision was in the thousands, multiple vendors were involved in the lifecycle of each cell site, and a cloud-native deployment was required. While the routers supported ZTP, extended configurations – such as IPAM reservations, transport establishment, bare-metal server provisioning, and other such tasks – needed to be addressed. Automation becomes necessary to provision cell sites at this massive scale. With this under consideration, the solution needed to be scalable, to be cloud-hosted, and able to support multi-vendor integrations and software-defined networking.

The designated solution is a microservices-based, cloud-native primary orchestrator i.e. macro-orchestrator, that delegates tasks across different micro-orchestrators and integrates with multiple vendors for inventory, IPAM, RAN management, etc. Figure 2 reflects the architecture of the solution and its components.

Components of the solution

Components of the solution: being a microservices-based architecture, the API Gateway acts as the entry point to the respective microservices and allows easy integration of authentication and authorization. The Workflow Engine acts as the core of the macro-orchestrator and is responsible for following defined business processes while orchestrating the micro-orchestrators. The micro-orchestrators are use case specific and capable of interacting directly with the infrastructure to provision or configure as per given requirements. Other microservices (shaded yellow in the figure) enable modularization, reusability, milestone management, etc. The Integrator microservice provides a unified API to interact with external entities so that, if the external entity changes, the microservices are not affected. A User Interface (UI) with custom dashboards enables lifecycle management and monitoring of business processes and the infrastructure. Built with an API-first approach, the orchestrator enables third-party systems to easily trigger tasks and monitor processes. One item of interest, but out of the scope of this document, is the Catalog Manager. The Catalog Manager ties business use cases together to workflow, UI components, and milestones, providing a single pane of view to trigger, override, and monitor solution processes.

This white paper documents best practices and lessons learned in the automation journey of this 5G cell-site deployment solution.

Automation and orchestration opportunities in ORAN

The landscape of 5G deployment offers a wealth of opportunities for automation, spanning various facets of network architecture and operations. One significant area of automation lies in the deployment of the transport network. Automation can streamline the setup of fronthaul, midhaul, and backhaul networks, ensuring efficient allocation of resources, optimization of routing paths, and rapid response to network demands. It enables operators to dynamically adjust bandwidth and routing configurations to accommodate varying traffic patterns, thus optimizing network performance.

Furthermore, automation plays a pivotal role in the deployment of cell sites, especially in the context of diverse RAN deployment scenarios. For instance, in the case of independent RU, DU, and CU setups, automation can orchestrate the entire process, from configuring an RU's connection to a cloud-hosted DU through fronthaul and midhaul networks to establishing a link with a remotely hosted CU over the backhaul. Similarly, for colocated RU and DU configurations, automation simplifies the process of hosting a DU on a cell site and setting up a midhaul connection to a CU.

While the choice of strategy and architecture might differ for different opportunities, the following is suggested for the automation of cell-site deployments and the setup of associated transport.

Automation is as good as the data fed into it

Businesses rely on a source of truth for all data-driven decisions, and the same is true for automation. The data would generally include the identification information about the devices, the properties that determine the configuration of the device, and the properties that reflect the relationship of the device with other devices in the network, thus establishing a source of truth for the whole network and its architecture.

The effectiveness of automation relies on the accuracy and completeness of the data provided. Establishing a source of truth, such as an Inventory Management System (IMS), is imperative. This IMS should encompass comprehensive information related to the infrastructure and all components influencing the automation lifecycle. Flexibility is key, because the IMS should adapt to evolving schemas during the automation development journey. Any changes to the IMS should be swift, preventing it from becoming a bottleneck. Moreover, the IMS should be independently deployed and securely hosted and should maintain clean, well-organized data that caters to automation requirements.

Data-centric and model-driven automation

The automation pipeline should be data-centric and preferably model driven. If your automation relies on hard-coded decisions, payloads, configurations, etc., failure is imminent. Such a solution will not be scalable and will turn out to be costly for changes and enhancements that might be required over time. Hence, making sure that automation leverages the right data for making decisions, generating payloads, applying configurations, and interacting with other systems is necessary. This will allow modularity, and, in an ideal scenario, the data will determine the processes that allow changes to happen on the fly.

This will also enable representation of the desired state of the network as a data model, and the automation pipelines will be responsible to achieve that state, enabling more flexibility and declarative, model-driven automation.

Design based on macro and micro-orchestrators

Automation's foundation lies in the orchestrators that are employed. It is essential to define macro-milestones and micro-milestones. Macro-milestones pertain to high-level business objectives that executives may monitor, while micro-milestones constitute the incremental steps necessary to attain macro-milestones. These micro-milestones, collectively, contribute to achieving macro-milestones, thereby facilitating the deployment of a cell site. When selecting orchestrators, careful consideration is required. Ideally, a Macro-Orchestrator (Ma-O), overseeing the entire business process and cell site deployment journey, should be paired with a set of Micro-Orchestrators (Mi-O) responsible for provisioning and configuring the discrete steps within each macro-milestone. For instance, setting up the transport for a cell site is a macro-milestone, whereas configuring intermediate routers, initializing the cell- site router, and configuring external systems (for example, IPAM and identity services) represent the micro-milestones within that macro-milestone). This may require a centralized milestone manager to monitor overall status.

An example of sequence of calls involving the macro-orchestrator, micro-orchestrators, milestone manager, and network components involved in an automation process represented by a macro-milestone named “Establish Transport”.

Validation and verification of milestones

Each milestone should have well-defined success criteria and dependencies. Prior to initiating a milestone, a precheck should be executed to validate the availability of all prerequisites. This may encompass verifying the completion of the previous milestone, confirming connectivity to specific systems or devices, and inspecting data within the IMS.

For example: before initiating a hypervisor installation onto the compute host, a precheck will involve the following:

●     Validate that the previous milestone has been completed.

●     Verify that the compute host is powered on.

●     Verify that the interface over which the configuration will be pushed is accessible, such as the Redfish API.

●     Hypervisors require specific settings to be enabled. Confirm that those BIOS or UEFI settings are enabled, such as the virtualization features.

●     Verify that the compute host has network connectivity to download installation packages and updates from the hypervisor's repository or update servers.

●     Verify that the OSS systems are in an expected state for this compute host, such as checking IP reservations in IPAM for the network interfaces on the compute host.

Similarly, a post-check should be conducted to confirm the successful completion of a milestone. For example:

●     Validate that the hypervisor installation micro-milestone has been completed.

●     Validate that the compute host is up and running.

●     Validate that the hypervisor is accessible.

●     Validate that SSH is enabled, or anything over which you plan to configure the host further.

●     Validate the health of the compute host for any anomalies such as high CPU usage or temperature.

These rules should be independent of the automation cycle, ensuring thorough validation of the expected state down to the finest detail.

Additional considerations

As automation matures, opportunities arise to further automate manual activities that occur between specific events and automation life cycles. For instance, when a precheck fails due to missing data, a separate automation pipeline may be triggered to rectify the data issue. Identifying and capitalizing on closed-loop automation opportunities enhances team productivity and increases business agility.

The ORAN network and the automation software will most probably co-exist within the same network. There have been times when a container inside a virtual machine had the same IP as that of a network node. A software hosted inside another container (in the same deployment) had to connect with the network node and would incorrectly attempt to connect to its counterpart container. Such incidents can be avoided either by planning for IP subnets to be reserved for software deployments and not used for networks, or by making sure that the automation software is developed to respect proxy settings, due to which a proxy server can be set up anywhere, allowing the opportunity to avoid such scenarios.

Summary

In designing automation solutions for ORAN deployments, it is imperative to consider the entire business process. The solutions and components selected must exhibit flexibility to accommodate last-minute alterations. Flexibility is crucial, as sub-processes may need to be adjusted. Identifying and defining major and minor milestones, associating independent pre- and post-checks to those milestones, and then effectively choosing the right orchestrators play a vital role in this automation lifecycle. Embracing one automation solution lays the groundwork for further automation within the business; hence, being observant of the opportunities for closed-loop automation further enhances business processes.

Author

Huzaib Shafi Shah

Customer Delivery Software Architect

Karuna Nevatia

Leader, Customer Delivery

Acknowledgement

Vivek Madan - Leader, Regional Sales

Arghya Mukherjee - Principal Architect

Vinay Saini – Principal Architect

Vijay Kataria - Leader, Customer Delivery