In a bit of circularity, the Open RAN promise of full optionality between hardware and software components is also an overarching difficulty in deploying Open RAN at scale. How do you unify management of a disaggregated system? How do you procedurally run through the essentially open-ended number of test cases and interoperability validations? And, at a higher-level, is there such as a thing as too much optionality?
Picocom specializes in silicon for small cells which company President Peter Claydon acknowledged as “very specific.” He cited the challenge of plugging an inline accelerator card into a server; it sounds simple but it isn’t. “You look at all the different varieties with servers and the people we’re integrating with, different versions of operating systems, completely different methodologies…That is one of the challenges. Not really so much the software integration…but actually the servers.”
Testing the RIC—every problem is an opportunity in disguise
In theory Open RAN specifications as defined by the O-RAN Alliance should be implemented in a consistent, uniform manner. But there’s obviously deviations that come to light in the test process, O’Donnell of Viavi Solutions said. “Sometimes companies or product developers do misinterpret the specs…and they will join up with another product where they just won’t interoperate.” But, he said, that’s to degrees the point of plugfests and rigorous interoperability testing.
Beyond straight interoperability, O’Donnell honed in on the RAN Intelligent Controller, along with attendant xApps and rApps, as “one of the most complicated of the Open RAN systems because it’s handling intelligence.”
He continued: “It uses AI, it uses ML, and then it’s supposed to send back instructions to the RAN. And the RAN has to assume these instructions will actually improve things. And that’s a lot of trust being put into something which could be xApps from different companies.” This has led to a focus on RIC conformance testing. “But secondly,” O’Donnell elaborated, “[customers] want a lot of RAN scenarios that can be generated for them to train their xApps. And then the third point of RIC testing is making sure that the instructions back to the RAN do, in fact, improve this situation and they don’t undo something that another xApp has done. Each one is a new challenge. Each one gets resolved. And for us it’s a huge learning curve, but we’re getting there.
The Open RAN menu—á la carte or prix fixe?
Historically telecom infrastructure is a consolidated sector given the high barrier to entry and the sheer global scale necessary to make money. In many ways Open RAN is pushing back on the status quo in that regard but, at the same time, there are early signs of another consolidation wave (e.g. Rakuten’s acquisition of Altiostar and Robin.io, and the firm’s bundling of the Rakuten Mobile approach–hardware, software and integration–into the Rakuten Symphony product. This speaks to how operators are accustomed to procuring network technologies.
Disruptive Analysis Founder Dean Bubley likened this to a prix fixe menu rather than complete mixing and matching. This would potentially include pre-integrated reference designs and pre-integrated component combinations. A vendor could offer an operator a “menu of three DUs, three CUs, whatever,” he said. “You can imagine that maybe a Rakuten Symphony…it could be an IBM, it could be NEC, there’s a bunch of companies that might end up looking as not purveyors of fully-integrated RANs, but with sort of moderate levels of mix and match with like 80% of the work done.”
Bubley also pointed out the link between Open RAN as a vector for programmability and automation and larger operator cloud strategies. “Is it public cloud, private cloud, and for what parts of the infrastructure…So to some extent, Open RAN might get sort of pulled into that much bigger discussion about the cloud and virtualization strategy. And then you’re on a sort of completely different trajectory there.”
BT’s Open RAN philosophy: “Build and discover”
For Chris Simcoe, BT’s director of Network Applications Architecture, Open RAN is all about building and discovering. “We use the technology where we can, discover how we can move it into adjacent areas and address the concerns we have there, or find places where it’s not applicable to be used. There’s a lot of talk about TCO. It’s not really where we’re focused. I want to reduce the cost of running the network, but that might be through automation and things like the RIC rather than really running everything on COTS hardware or something like that.”
In addition to some of the aforementioned obstacles the industry is in process of working through, Simcoe noted nuances like optical interfaces between distributed and radio units as a trouble area. While this doesn’t rise to some of perhaps more interesting aspects of disaggregation and virtualization, it does align with core Open RAN principals in terms of opening up physical interfaces. “Base practicality factors that come up as you’re putting these things together with all these combinations, you end up with combinations that have to be lined up,” he said. “And before you know it, you’re kind of stuck, once again, in a silo…And we need to kind of break out of that reality.”
The post Three Open RAN obstacles: Servers, RIC testing and optionality appeared first on RCR Wireless News.