I am in Seattle this week for FYUZ, opening the SMO and RIC panel. Ten years ago, at Telefonica, my team was trying to connect the unconnected in Latin America, and the traditional RAN was simply not affordable there, so we disaggregated it. We launched the TIP OpenRAN working group in 2017, co-authored the OpenRAN RFI with Vodafone in 2018 and presented the results at the TIP Summit, which has since become FYUZ (I still have the T-shirt). This conference is, in a way, where it started for me, and a good place to take stock of what ten years have delivered.
Open RAN set out to open the radio, with RU, DU and CU from different vendors on general purpose hardware. On the way, it created something else, a software layer for intelligence: the SMO, the Non-RT and Near-RT RIC (brothers from a different mother, as I called them in 2023), rApps and xApps, and more recently dApps inside the CU / DU. None of this came from nowhere, of course. Centralised SON is the ancestor of the rApp, distributed SON the ancestor of the xApp, and one vendor told me that 55% of its SON deployments are already multi-vendor. The promise was any vendor's app, on any vendor's controller, over any vendor's RAN.
For this session, I interviewed and surveyed the SMO, RIC and app vendors on where things really stand. rApps have won the application model and they are in production. The largest deployment I found runs about 12 rApps on roughly 150,000 cells, but vendor and operator sit in the same group. Third party rApps are live at US tier ones, including on AT&T's network, and one RAN vendor's energy rApp runs on a third party RIC at another tier one. What I could not find anywhere is the original promise, a third party app on another vendor's SMO over a different vendor's RAN. The leading directory lists 117 rApps, 94 of them from independent vendors, and only a handful are in public production.
Why? One independent vendor summed it up: the algorithm ports, the plumbing does not. Bringing a first app onto a new SMO costs around three FTE-months, about half for each one after, and R1 delivers standards-based portability, not plug-and-play. Every vendor I spoke to, large or small, named the same three gaps: data semantics (interfaces connect, but counters and models differ by vendor), conflicts between automation loops (in an EU testbed, two vendors' energy-saving xApps switched the same cells on and off against each other) and onboarding, certification and accountability. The industry's answer, unfortunately, is shifting from portability to certification per platform, curated catalogues rather than open marketplaces. I have seen this movie before, with MANO and then with the SMO itself: the barriers were never technical, they were commercial.
The biggest change since last year is that, of the three intelligence layers, the middle one did not survive. Regular readers know my feelings about the Near-RT RIC, and at MWC last year I called it a flawed proposition as a host for third party xApps. A tier-one SMO vendor has now discontinued investment in its Near-RT RIC and xApps, given limited industry demand, a second keeps time-critical AI inside its own RAN software, and independents bypass the RIC altogether, one of them delivering the same E2 code straight to the base station. A separate xApp server, and its power bill, broke operators' cost models, and the VMware and Juniper exits stranded the integrations app vendors had built. The use cases moved up to rApps for anything slower than a second, and down into dApps or the RAN software itself for real-time control.
Two surprises. The first commercial dApps are in space: beam weights and satellite handover are not native in the standards, so one vendor fills the gap with its own AI models running in the DU, in production on a GEO network with LEO targeted for 2027. And the US government is no longer just a buyer: the Pentagon's FutureG office funded OCUDU, an open source CU / DU now backed by a Linux Foundation ecosystem with AT&T, Verizon, Ericsson, Nokia and NVIDIA. Defence wants a programmable scheduler, and RAN vendors guard it as their crown jewel. In my mind, the three RIC tiers are collapsing into one AI plane, training central and inference placed wherever the loop latency requires, which I think starts at central offices rather than cell sites, whatever the GPU vendors and their partners say.
So where does this go by 2028? In a vendor's words, not simply more RIC. Tier-one vendors now describe SMO and RIC as the base for intent-driven, agentic operations, autonomy sits at level 2.5 to 3 today, and a reality check on energy: measured savings average 15 to 16%, while headlines quote 35 to 40% peaks. The test for 2027 is the first production rApp combining a third party app, another vendor's SMO and a different RAN. I left the panel with three questions: who pays for porting, who arbitrates conflicts between apps and who is liable, and will certification replace portability? It will be interesting to see whether Open RAN's tenth year is the one where the original promise is at last delivered, or quietly replaced.
No comments:
Post a Comment