The disintermediated nature of open virtualized radio access networks (Open vRANs) is the key to the flexibility, cost savings and innovation that have made it a part of the plan for many mobile network operators (MNOs) that are expanding a 4G network or embarking on a new 5G network.
Some people have suggested this multivendor approach is creating a systems integration burden for MNOs. But in reality, the concept of system integration has always been a part of RAN networks. With a legacy network, it came bundled into the whole solution. But it was never performed solely by one vendor. With Open vRANs, there’s a more transparent process with the MNO selecting best of breed integration firm or firms to deploy the network.
System integration for legacy RAN vendors
To understand what is changing in open RAN, we first need to peek behind the curtains to see what the steps are in building the RAN of yesteryear.
Legacy vendors have different teams running in silos that look after hardware manufacturing, software development, system integration, system test and deployment. Integration of each of these technologies is carried out by system integration and system test teams.
The perception is that deploying a multi-vendor Open vRAN solution will result in added complexity from an operations point of view in the areas of mobility, interoperability and network management. The reality, even for legacy traditional RAN vendors, is that there is a fair degree of network integration required during deployment.
System integration for Open vRAN vendors
With Open vRAN, system integration is one of the flexible elements of an overall system – contributing to the modularity, cost effectiveness and flexibility of Open vRAN solutions.
However, due to this flexibility, often times there is a misconception that integration of Open vRAN could potentially be complex and would ultimately be not be feasible. MNOs are led to believe that they will need to take baseband hardware, radios and software from different vendors and integrate it all together.
The root of this worry is primarily due to the fact that this Open vRAN concept is being introduced for the first time for RAN systems. However this integration model is fairly established in the IT world where a transformation took place from traditional mainframe systems to the new web-scale cloud-based approach where there are a plethora of choices for hardware, software platforms and software applications and they all inter-work due to well established mechanisms set up for interoperability.
MNOs need to know more about how this integration benefits them and the process that they will undertake for building such software integration. However, to explore the complexity we have to approach the problem from a similar approach that legacy vendors undertake. The two major elements of Open vRAN system integration are the same as in legacy RAN systems: product integration, which entails the integration of multiple modules to create an open RAN solution, and network integration, which entails the deployment aspects of RAN.
Product Integration
Product integration is ensuring different vendors who are bringing their respective portfolio of products (e.g. radio units (RU), baseband hardware and software solutions) can interoperate in a seamless way. This integration for Open vRAN is generally done using open interfaces. In this stage, the MNO plays the role of putting together the requirements of their deployment. This is a very different approach compared to the traditional RAN vendors where an MNO retrofits its network to the availability of product portfolio of the vendor.
This is where standards bodies such as the 3GPP, O-RAN Alliance, the Small Cell Forum (SCF), etc., can put to rest any worries an operator has about product integration. The different vendors agree upon a profile of specifications that will govern the parameters, configuration, fault management, counters and KPIs that will be used for interoperability. To put that in context, let’s consider the example of the O-RAN Alliance, which has defined a comprehensive RAN architecture and within that they define specifications for different interfaces as shown in Figure 1.Â
These specifications ensure interoperability between vendors and components at each level for the RAN. However, prior to integration there will be an opportunity for the vendors to agree upon an O-RAN profile based on the operator requirements. Thus there is more emphasis given on creating the most optimum solution, rather than putting a pre-defined scenario and asking the MNO to retrofit accordingly. This approach thus emulates a similar structure as compared to the traditional vendors, but where there were different teams there are now different vendors collaborating together for integration to tie everything together.
System integration thus becomes open RAN integration. The MNO gets a front row seat and visibility into interface details, test results, gaps or missing features, limitations as well as benefits of the solution. In this model, the operator facilitates the best solution possible because it is controlling the handshake between vendors, which leads to transparency and auditability.
In a real world example, an MNO engages an Open vRAN vendor for a new network. The engagement starts with a study of the operator’s needs and then the development of a system blueprint. This blueprint includes the Open vRAN software, a hardware platform for running the baseband software and a virtualization infrastructure (e.g. A COTS server, remote radio head (RRH), network functions virtualization (NFV) software, orchestration and management systems). It also entails the north bound interfaces to integrate with the operator’s OSS, BSS and CRM systems.Â
The approach is consultative and collaborative toward the operator and the requirements driven by the MNO govern the blueprint. Interface definitions, specifications, use cases, logging, operational aspects and product architecture are all well established and made available to the MNO, giving them more control of how to optimize their network.
Finally, a significant part of what goes into building the blueprint is the testing and quality assurance that is undertaken to ensure that all elements work together. This testing involves bringing the different elements together and testing them for different aspects including functional, performance, call model and traffic profile based testing. Test tools, processes and criteria are well established in the RAN industry and are generally well established and well understood by MNO’s.
However in the case of Open vRAN, a second level of testing happens, i.e. interface level testing. Prior to integration, there is testing done by each of the vendors to ensure that all the integration checks are being met. These integration checks include verifying the product specifications, verifying 3GPP / ORAN RCT results, verifying management plane compliance, security, timing/synchronization testing requirements, etc. This level of testing provides a degree of robustness and assurance that was not previously available in the industry.
Network Integration
Next comes the solution deployment stage. As seen in Figure 2, the RAN product integration is represented in the bottom three layers, but the operator may have its own operating support system / billing support system (OSS/BSS), network orchestration, NFV infrastructure and self-organizing network (SON) systems in place. Or they will need to add or expand these components. Network integration involves implementing APIs and other interfaces from the RAN into these systems and then assisting with the rollout.Â
Other critical aspects of network integration include logistics, procurement, installation, deployment, maintenance / KPI monitoring, program management and continuous monitoring and technical support.
Prior to open RAN, the network integration was managed by the legacy vendors. These vendors typically would offer network services along with the product. To the MNO it would appear to make sense since they could get both the product as well as deployment from a single sourced vendor. However, in the telecom industry, the vendors are establishing single and sole source practices where they establish themselves as the only vendor for the region. The goal is to first win the right to deploy the product in a particular region by offering low entry prices and then pivot to higher prices for services.
The majority of deployments globally are managed by contractors and consulting companies. This leads to margin stacking and often times the cost of deploying a basestation is actually several orders the cost of purchasing a basestation. Some MNOs, such as those in North America, have recognized the high costs and are now determining what services they can undertake themselves versus what they outsource to the traditional RAN vendors. Still others are looking toward a trusted system integrator or a RAN as a Service offering, where MNOs are afforded a turnkey cloud-native solution.
Conclusion
The revolutionary aspect of Open vRAN is not the functionality, per se, but rather the disintermediation of the solution so MNOs can pick and choose the best of all the solutions, opening up a new ecosystem of vendor innovation to the RAN. In the same way, operators have more freedom of choice when it comes to their system integration needs. This choice is no different or riskier than what an operator might face in choosing a more traditional RAN supplier. In the end, there are no new integration requirements for Open vRAN, but there are new options for MNOs allowing them to tailor the integration for the optimal mobile network solution.
