A New Open RAN System Integration Model

 

Summary

Currently, traditional RAN vendors are delivering to operators a ready for deployment RAN solution, which is already fully tested and pre-integrated in their own facilities. Each vendor manages its own lab and testing resources, so that the associated overhead in integration complexity is transparent to the operator. Hardware and software are tied, and product roadmap is built according to 3GPP specifications for radio functionalities. Logical interfaces between subsystems of the radio site are proprietary defined, so no interoperability between different vendors is possible.

OPEN RAN provides increased flexibility and potential by enabling the selection of “best of breed” network components from a multivendor ecosystem, meaning a significant TCO reduction for operators. For the open ecosystem to foster innovation and new technology developments, whilst also driving costs down, it is necessary that the product development efforts are shared by all stakeholders. A coordinated community will ensure the full interoperability of the disaggregated solution. This coordination addresses the full interoperability of the multivendor solution. System Integration is one of the key areas to consider, as there is no longer a unique entity responsible for the complete E2E , including software life cycle management, KPI assurance, service management, etc. A new approach to system integration during the deployment phase is also required to efficiently manage the supply chain disaggregation and fully capture the TCO savings.

This document outlines our vision of the system integration processes needed to deliver a truly interoperable RAN solution, ready for massive deployment, into a mobile operator network. The main aim is to promote the industry conversation on how system integration should evolve, based on our views and experiences. The traditional system integration model is considered, showing its limitations when applied to OPEN RAN. Finally, a new proposal for the industry is presented, explaining how the innovative change of direction implies a significant improvement in economic and operational efficiency.

What happens if traditional model is applied to OPEN RAN system integration

The product integration of the OPEN RAN solution is considered according to 5 different phases, from product development to network operations. These stages are named as follows: system integration in lab, acceptance testing in lab, acceptance field testing, remote integration, and network operations. Continuing working across these steps with the system integration traditional approach, is not efficient nor sustainable for the industry. Our vision promotes processes redefinition in the following areas: System Integration in lab, Remote Integration and Network Operations.

Figure 1. Different phases of the system integration process, form lab to network operations. We envision a change in business as usual for system integration in lab, remote integration, and network operations.

System Integration in lab

Traditional RAN vendors carry out system integration activities in their lab facilities and most of the testing is performed in a central lab, where the RAN radio site is verified to be ready for rollout. During all integration phases, hardware and software components are designed and built according to a unique vendor proprietary product specification.

OPEN RAN radio solution is compiled from several vendors, each of them delivering a different hardware and software segment: radio units, COTS servers for base band, chipsets components, RAN software, software abstraction layer and RAN orchestrator. For each combination, integration will require extensive testing of individual RAN functions (subsystems), interoperability between network functions and E2E testing, conducted in a DevTest environment. Apart of the functional, performance and interoperability tests, the system integration process demands the delivery of product blueprints, consisting in HLD and LLD documentation on technical solution and the testing strategy, including specific site templating and design clustering guidelines to define a manageable number of configurations for vCU/vDU/Mobile Site.

Following the traditional system integration model, each vendor contributing to the RAN solution needs to set up a central lab to perform conformance and interoperability verification; and these shall be completed for each multivendor combination. For each supplier, this means a significant amount of financial investment in terms of infrastructure, software tools and specialized human resources. This scenario will generate duplication in verification activities, each stakeholder repeating same testing activities for same multivendor combinations. This inefficiency applies also for operators building new labs and repeating validation activities.

Our proposal for the future model of system integration considers a multivendor distributed and collaborative effort, meaning that instead of each of vendor setting up a centralized lab, our model promotes a coordinated multivendor lab network. This network will act as a consortium, delivering the RAN product roadmap under supervision by operator. The operator will govern the testing network, addressing the growing complexity due to massive number of product specifications, suppliers, and configurations, compared to the traditional system integration model.

Figure 2. Distributed system integration model. Multivendor lab network is delivering a pre-integrated radio solution, under the coordination of Operator.

To make this model work smoothly, the operator needs to establish a delivery framework joining all involved parties. Previously to any OPEN RAN rollout, the scope of the system integration process shall be clearly defined. Vendors will perform the hardware and software release management according to this distributed model. We envision the lab network acting as a unique lab, delivering a pre-integrated solution ready for rollout.

The future model implies an improvement in terms of costs, timing, and flexibility. A reduction of 40% is estimated for the industry, when moving from a centralized system integration lab to a distributed one. This gain is based in the reduction of investment required by vendors and the introduction of automation under a Devtest environment, reducing delivery times in lab testing and remote integration. Key improvement points are summarized below.

  • Increase in flexibility for new product development and integration.
    • Each vendor can scale up and dimension labs as required, independently from the rest.
    • Labs are not statically assigned for a single operator, so a high level of synergy is feasible.
    • Wider equipment is available for testing, in a hardware and software pool of resources approach, as different operators may have different hardware models
  • Costs can be distributed among involved vendors, in a consortium type organization.
  • Faster lab readiness as each vendor will be doing its own.
    • Minimum HW delivery: each vendor has a lab with a different set of HW equipment
    • Expertise stays on each vendor lab facilities.
    • Know-how and best practices are shared.
    • Can reduce manual effort and efficiency
  • Full automation and remote access improve efficiency and reduce time to market. Following are some examples of current system integration times, under a not complete automation approach.
    • Single band RU integration: 24 weeks.
    • Dual band RU integration: 26 weeks.
    • MaMIMO RU integration: 32 weeks.
    • Software/firmware upgrades 6 weeks.
    • New COTS server 24 weeks.

As a part of the OPEN RAN site build, our proposal for the future system integration model considers a factory pre-staging HUB. Once the solution is verified in vendors labs and E2E certified in operator´s premises, it will be delivered to this pre-staging facility. Each vendor will contribute to the product delivery, providing the already verified segment under its responsibility: RU Hardware and software, COTS servers, RAN software, CaaS layer and Orchestrator. Hardware parts will be assembled and firmware/software pre-commissioned, under a CI/CD framework. The ready for deployment solution will be then sent to the local market according to rollout milestones.

Figure 3. Factory pre-staging hub activities.

Factory pre-staging reduces on-site integration steps and mitigates the risk of failure and limits downtime at site due to software installation. Figure 4 shows a visual comparation between traditional approach with vendors delivering different parts of the RAN solution to local markets and future model with factory pre-staging. Number of hops is reduced by 50%.

Figure 4. Comparation between traditional model and proposed distributed model with factory pre-staging for lab system integration.

We are evolving towards the future model in partnership with Dell, NEC, Samsung and Wind River, which are building the OPEN RAN solution ready for massive deployment in our UK market. Preliminary activities include alignment in testing strategy, hardware/software transfer coordination between companies and trials for remote distribute tests. First phase is trialling a distributed / hybrid lab with the likes of Dell, NEC, Samsung and Wind River, in their own labs, and bring to our central lab for final security and core testing.

In this new system integration model, each operator coordinates the multivendor lab network with specific ad-hoc product requirements according to their network strategy. We envisage complementary coordinators for the global scenario (e.g., the Telecom Infra Project organization, ORAN Alliance and others), providing a RAN roadmap of multivendor solutions, tested, and verified in their open labs hosted worldwide. Operators could then leverage the work of these organisations for availability of commercial OPEN RAN solutions ready to deploy in their networks.

Remote System Integration

To reduce visits to physical sites during deployment and operations, the future model for rollout integration considers to pre-commission all software images on the pre-staging hub. All common configurations will be prepared and loaded in advance. Once the radio site reaches its final location, few left steps will be needed. We see the operator playing a key role in coordinating the multivendor network in the site acceptance gating process. Operator’s KPIs shall be met by the integrated solution, so a cross functional support is needed by all suppliers involved in the product integration phase. Figure 5. shows an estimation of continuous improvement in remote site integration times when moving from the traditional model to the future model.

Figure 5. Estimated improvements in network integration times when automation is applied

Network Operations

After the site acceptance gating process, the radio site is transferred to the operator´s network operations team. OPEN RAN operations and maintenance consists of traditional operations which shall be adapted for management of cloud native RAN functions, through a RAN domain orchestrator. The following operational processes shall be carried out: provisioning management, fault supervision, performance assurance, trace management, file management and heartbeat management. L1 and L2 operations include activities related to performance monitoring, ticket and alarm handling, troubleshooting, fault management and configuration management. L3 and L4 are focused on solution support, SW lifecycle management and product engineering.

The integrated OPEN RAN solution presents important challenges due to its multivendor composition. When an unexpected alarm or KPI degradation occurs, troubleshooting needs to be coordinated among all suppliers for root cause analysis. If processes related with engineering support and escalation are not well defined, this may result in a stale mate between operator and vendors.

We see the operator playing a key role with two system integration teams working together with OPEN RAN vendors and local NOC. E2E Solution Development is coordinating the multivendor lab network to reproduce problems related with engineering solution, while Product Performance Team ensures that vendors are delivering a unique RAN roadmap meeting operator’s KPIs.

Figure 6. Processes map for OPEN RAN network operations.

Figure 7. depicts the future architecture for cloud native network functions management within the multivendor RAN solution. The evolution path from legacy to OPEN is a great opportunity for software developers to provide tools for universal OSS, service management, orchestration, and RIC.

Figure 7. Functional diagram for cloud native network functions management.

Call to Action

The purpose of publishing this document is to present the Open RAN future system integration model that Vodafone considers the best option for the industry. We hope that all members of the Open RAN ecosystem will analyze the content of this white paper and work collaboratively, in conversation with each other, to reach practical conclusions on how the model can be successfully implemented. Vodafone remains open to operators and vendors feedback and is willing to reinforce the key importance of vendors aligning their testing and integration efforts in a distributed lab network, targeted to deliver a pre-integrated Open RAN solution ready for massive rollout.

Download PDF
Return to Resource Center