Open Radio Access Networks pose both an opportunity—for new flexibility and agility within the RAN and the ability for network operators to re-set vendor relationships—and a challenge of interoperability among freshly disaggregated network elements.
But making sure that new features and functions actually work as anticipated, and play well with solutions from other vendors, is a challenging task, one that test and measurement vendors have been particularly deeply involved with as Open RAN has evolved. “I think one of the differences with O-RAN is that from the very beginning, test and measurement companies have been involved with the standards. And that’s important, because test and measurement companies tend to be third party arbiters, especially in regard to the question of interoperability,” said James Kimery, VP at Spirent Communications, who leads the product management organization in Spirent’s Lifecycle Service Assurance business unit, during a session at the virtual Test and Measurement Forum event. He added, “The outcome that operators and consumers and businesses need is that the O-RAN networks operate in the same way as single vendor networks. And that’s really a critical challenge and that’s where testing measurement companies have a big opportunity.”
What are some of the specific challenges? Here are four that came up during the in-depth panel discussion (available to watch here).
–Complexity. Open RAN covers multiple network domains, Kimery pointed out, and the need to validate for conformance and interoperability as well as performance across those domains. “You are dealing with protocols, but you’re also dealing with RF, and if you want to validate those network for conformance, for interoperability, you need to make cross-domain measurements, because some implications of protocol issues will only be visible on the RF side,” Kimery said, later adding: “Conformance is table stakes. You have to make sure that you have performance, but you also have to really understand how it operates in the field.”
–Potential for wider variation across operators or deployments. One of the cornerstones of scale and success for the mobile industry has been standardization. While the implementation of standards has always involved vendors making choices about how those standards are implements to establish their own unique “flavors”, and MNOs ultimately establishing what features and functions will be live in their networks and at what cadence, Open RAN provides a standardized foundation but with a far wider variety of potential implementation points. “When it comes to Open RAN, we actually opened up everything. Operators can test RU separately, DU separately, and CU separately and then integrate it together to make it a complete ecosystem which is best suited for the use cases that networks deploy,” said Sandeep Sharma, VP and global head of Tech Mahindra’s 5G/RAN/O-RAN portfolio. “For example, for enterprises there might be different set of requirements, for cellular networks there might be different set of requirements.”
“If you have different RAN elements that are constructed or developed for a particular deployment, each vendor will have different firmware updates, different software updates,” Kimery pointed out. “And if you think about the pace of those updates, it really means that operators [and] system integrators actually have to have a different approach. … Automation is really the only way that you can build a multi-vendor network and keep up with all of those different firmware updates, updates from different vendors, and then also be able to ensure that the previous updates and changes and bug fixes, that they were addressed … and then being able to accommodate new features and functions … that also accelerates the delivery and realization of new features and functions in the network.
“It is quite different than traditional approaches, but the benefits are clear,” he concluded.
–Energy efficiency has emerged as one of the driving reasons that mobile network operators are interested in applying O-RAN to their network, because it offers potentially faster realization of energy savings.
“We have talked with many operators in the different regions and [energy efficiency] is becoming one of the main priorities that we see in the O-RAN Alliance,” said Jean Manuel Dassonville, strategic planner at Keysight Technologies. The best way to save energy within the network, he explained, is to add elasticity: Turn resources off when they are not needed. “From a test point and measurement point of view, what’s interesting is, that one of the first challenges is the metrics,” he continued. “At the system level it’s pretty straightforward to characterize the energy efficiency of the network. … But as you zoom into the different components of the network, the metrics becomes a little bit more challenging. How do you test the energy efficiency of a virtual network function? How do you test a radio’s energy efficiency? Is it data per energy or is it data per distance per energy? How do you incorporate the spectral efficiency there? We realize that there are a lot of interesting challenges to properly characterize each component of the network for energy efficiency.” Additional layers of complexity are added in figuring out how to categorize and validate if the RAN Intelligent Controller (RIC) is making the “right” choices on energy efficiency and if the RIC’s commands are being received and followed, as well as to understand what is happening at the device level and the impacts of different sleep modes. Again, this means still more cross-domain testing by adding measurement of the energy domain.
–RIC-specific testing. While there are numerous aspects of O-RAN that have to be tested, one of the most challenging is that of the RIC. Dassonville pointed out a few of the issues: Due to the nature of how O-RAN has been built, there have to be different testing solutions for the non-real-time RIC and then the near-real-time RIC, with emulation both from devices to the RIC and from the RIC to devices to see if the loop between them is properly operating, and the need for emulating different traffic models to see if the AI/ML at work in the RIC is “able to come back with some policies and recommendations that are coherent, consistent for the traffic model.” Beyond that, testing also has to establish that the RIC can work at scale and won’t be overwhelmed when the number of devices start to multiply.
Sharma also noted that when the RIC comes into play, so do different interfaces that are providing data feeds, and the compliance of those interfaces as well as the need to simulate different scenarios with AI models and validating and verifying whether the results of different system changes align with expectations of the RIC. Kimery emphasized the need for end-to-end testing when it comes to getting the full picture of RIC operations. “If you have end-to-end testing and all of the functional elements of RAN … [disaggregated but emulated in real time], then you can get a really good picture of your algorithms,” he said. “You can do your initial training and get your initial training data integrated into your Rick, and then you can test them in a full emulation environment. And then you can add real elements, real CU/DUs, [and[ core network functions independently, and you can effectively test it all the way to number of UEs, et cetera. … This concept of end-to-end testing is quite significant and important.”
To view the entire discussion, on-demand video is available here.
