As communications service providers (CSPs) introduce open radio access networks (RAN) and prepare for new 5G network use cases, the vendor landscape is transforming to offer greater choice and meet their specific needs. However, this is not without complexity and the expanded ecosystem must consider both new and legacy networks as well as breed confidence that systems will work. At the heart of this new era are service management and orchestration (SMO) frameworks and RAN intelligent controllers (RICs) that enable control, communication, and optimisation of disaggregated and Open RAN projects.
Here, Per Kangru, a technologist in the VIAVI Corporate Strategy Office, and Chris Murphy, the regional chief technology officer at VIAVI, tell VanillaPlus managing editor, George Malim, how the company is helping to support and develop solutions that power the new networking ecosystem.
George Malim: Why are the SMO framework and RICs so important for the success of the disaggregated and Open RAN projects?
Per Kangru: The key here is to understand these are components that allow the disaggregated network to function in a structured and ordered manner. By doing so, we’re able to create an ecosystem where not everyone needs to provide a complete solution, but they can focus on their specialties.
From a market perspective, focusing only on Open RAN gives you a tiny portion of the addressable global market initially, but optimisation of all the functions on all the macro networks is an ongoing activity. As CSPs build-out capacity and make additions to existing networks, a vendor that can only touch things based upon an Open RAN architecture is limited to a small percentage of the global market. As a result, we are seeing some vendors of SMO frameworks – and CSPs – providing an infrastructure to target not only Open RAN but also legacy networks, which are sometimes called purpose-built networks. An architecture like an SMO means you can deliver services not only against Open RAN architectures, but against all legacy environments, and you can create and foster that ecosystem on a much wider engagement level.
Chris Murphy: I think what this all focuses on is the desire for 5G to be as flexible as possible and to support many use cases in as wide a range of deployment scenarios as possible – including those we’ve not actually thought of yet. That need for flexibility is reflected in the way that Open RAN is progressing. We want to be able to place networks in factories with different form factors at the radios, and to address the site acquisition pressures that face public networks. Having form factors for different environments to support everything from commercial smartphones to fixed wireless access using this technology is critical in this case. But it is unreasonable to expect that a vendor of a purpose-built network can address all these options for deployment scenarios and use cases. That’s why the Open RAN vision is needed.
Network slicing means that the different network functions must adapt in new ways to deliver services with the right mix of key performance indicators (KPIs). In this way, CSPs can ensure customer satisfaction for different network slices and meet service level agreements (SLAs), all on the same infrastructure. Maximum flexibility is vital because it breaks down the network into components and allows different players to compete in different spaces within it.
GM: Is Open RAN increasing opportunities for vendors to compete because CSP customers want more choice and the ability to choose the vendors they want?
PK: There are two aspects of this. One is a desire for multiple ecosystem players to foster and increase the velocity of innovation. This is, for example, what the Telecom Infrastructure Project (TIP) wants to achieve by enabling CSPs to be much swifter in delivery of new technologies and new networks and services at home. The other aspect boils down to large portions of the CSP ecosystem being located in a world where there are vendor selection limitations.
Practically speaking, due to various political situations, some CSPs are unable to include the Chinese vendors in their network equipment sourcing. From a legacy perspective, that leaves CSPs only two vendors from which to choose. No one in the procurement process of buying network equipment thinks that’s enough for effective price negotiations. This limitation then presents a whole discussion on what is needed to add a new horse to the race. Fostering a completely new, non Chinese vendor that can provide a purpose-built RAN type of solution is unrealistic at this point. Therefore, openness becomes a way to create a new supply ecosystem if it can execute.
It doesn’t matter which of the traditional vendors are selected. They all have an extremely diligent process for integrating their RAN nodes, optimising them, and making sure they’re delivering excellent performance. In their lab environment, they have made considerable investments in facilities, people and test automation. The question here is whether the Open RAN vendors or integrators will be able to provide a sufficient solution, at least one that is as good as what the traditional vendors provide.
The Open RAN ecosystem cannot realistically outspend the traditional vendors on their RAN integration expertise. However, their approach could be via a different path, such as using artificial intelligence (AI) and machine learning in the RIC and SMO, delivering solutions on par with the traditional vendors. There is a precedent for this approach, similar to how hyperscale providers have been able to outsmart the legacy datacentre industry.
CM: CSPs have been trying to regain power back from the vendors for a very long time, and now they’re seeing that their wish is within reach. We shouldn’t expect that suddenly the purpose-built network vendors will be able to optimise their systems for every possible scenario. When a CSP has selected its mix of components and vendors for the different network functions, radio units, the RIC, and the applications on the RIC and SMO, they may be the only one to have selected that particular blend of components and vendors. The CSP needs to be confident that these will be functional in their network and consequently, that their network will operate optimally. To mitigate against some possible risks of fragmentation, TIP is advocating for specific blueprints to be validated and tested.
GM: What key technologies are required to build a viable solution?
PK: This is really where you need the perfect mix of platform, RIC and/or the SMO provided by various companies across the industry. The platform needs to speak to the apps that communicate and control the various parts of the infrastructure. Some platforms support not only the Open RAN interfaces but legacy purpose-built networks as well, thus enabling expanded use cases.
The platform becomes the first element that a CSP must have in place, and inside that platform is where they can start building different use cases from components with various capabilities.
Analysing the various use cases, one can clearly see that many of them will rely on a set of capabilities – foundational capabilities, that can be used by multiple use cases inside the platform. One example of this is our NITRO Mobility geolocation capability which enables CSPs to receive trace information from the infrastructure and identify where the subscriber is located, what performance they receive, on what service type, on what device and with beam-based 5G, at what elevation, at that point in time. Taken at an aggregated and anonymised level, the data can be very valuable for a multitude of use cases. Moreover, this generates overall subscriber-based performance understanding in the whole network, broken down as granularly as needed depending upon the use case. The granularity relates to physical spaces and is not tied to specific cells. This rich subscriber-centric and performance based data can be used precisely to inform the rest of the applications within the platform about performance and service usage, which in turn allows them to perform the proper setup or optimisation, taking into account all of the relevant parameters such as location, the coverage and capacity layers, and the specific application usage.
CM: The term I like to use is foundational capabilities because you’re trying to deliver use cases or capabilities on the RIC, to achieve certain objectives. Foundational capabilities include geolocation, which tells you where your subscribers are, and where there’s demand on the network for which services, along with how well the network is delivering these. It can also include identifying changing patterns or new behaviours which are anomalous, for example. This may trigger responses or certain use cases to be carried out to make sure that the performance is maintained despite the anomaly. This in-depth visibility can extend to instances of intensive utilisation of applications or network slices, where the foundational capabilities enable the platform to detect, troubleshoot, diagnose, and then mitigate them. This will be an important capability that extends to responding to impairments in the network infrastructure itself.
GM: How is VIAVI engaging with the industry on RIC/SMO at the moment?
PK: CSPs will select components in the Open RAN area and, on the RIC and SMO side, they will choose a platform to meet their needs. We see that many CSPs are making platform selections without necessarily selecting the applications to run within it at the same time, so they’re making two separate decisions: one for the platform and another for the applications.
Our geolocation capability is already used today by a large footprint of CSPs around the world for purpose-built networks where we support automated site verification and optimisation use cases, troubleshooting, analytics or use cases where we feed external third party applications. We know that we must adapt to the environment of the customer and ensure that our platform and capabilities can effectively operate in any possible compute or hosting environment.
Regarding our geolocation capability, we can’t work with only one platform vendor in this space, we must work with the vendors selected by the CSPs. This means we’re engaging with the relevant parties out there in a model where we basically embed our capability into that platform. We make sure that it works effectively and that it can be delivered to meet the needs of CSPs.
We’ve ensured that our capabilities can run within the available frameworks established by the CSPs, and that we can deliver value to them regardless of their choices. Furthermore, we have further nurtured our traditional customer partnerships, but we are also collaborating in a very agile manner with some smaller players in the Open RAN ecosystem.
We’ve been involved in a TIP project with British Telecom and Accelleran. This engagement has expanded and recently attracted funding from the UK government. There have been other activities announced at the TIP Forum. We are engaged with different vendors today, and we are anticipating there will be many more in the near future.
We are also working on the standardisation side and closely support the O-RAN Alliance’s Open Software Community (OSC). Across the board, we have tried to work with companies that are ready for the market inflection. We don’t necessarily have an opinion about who is likely to win or not, or what one should prefer. It’s likely that this ecosystem will continue to shape itself over the next couple of years, and we want to clarify that we are a strong partner within it. There will be many players in the race, and we are happy to partner with them.
CM: We’re working on selected projects which will expand the number of delivered use cases. This isn’t only for the RIC, but also for network emulation for use cases which aren’t yet supported in the infrastructure that we’re using. We’re also working with Ericsson on its SMO framework, Intelligent Automation Platform, to deliver some of the foundational capabilities that we’ve been doing with TIP. What we are doing in the Open RAN space also applies to the more traditional, purpose-built networks.
We’re contributing to a wide range of O-RAN Alliance working groups including those where the non-real-time and near-real-time RICs are defined, to make sure that the data for these foundational and optimisation capabilities are exposed to the appropriate interfaces, and that they are available on the right timescales to support the required optimisations. We are also members of the minimum viable products (MVP) committee, to work on prioritising the efforts made across the working groups, and to demonstrate our use cases.
PK: We are truly focused on helping this ecosystem to materialise from the standardisation side, and through development, validation and sourcing, as well as in the operational stages, with the right apps. CSPs can then drive great operational performance both on a real-time basis and in terms of how they can optimise their operations in the future.
Comment on this article below or via Twitter: @ VanillaPlusMag
