O-RAN PlugFest Spring 2026: Smaller, Sharper, More Ambitious

The O-RAN ALLIANCE published results from its Global PlugFest Spring 2026 on June 4. Conducted from February to May 2026, it brought together 31 companies and institutions across 9 labs worldwide, co-hosted by 13 operators, OTICs and independent institutions. Those numbers will look like a step backward to anyone tracking PlugFest participation over time — and they are, deliberately.

For comparison: the Fall 2024 PlugFest ran across 28 labs with 115 participants. Spring 2025 had 19 labs and 69 participants. Spring 2026 cut the footprint by more than half again. This is not a loss of momentum. It is a deliberate shift from ecosystem-building to integration hardening. Getting everyone in the tent was the objective of the first five years. Making what exists actually work together is the objective now.

Massive MIMO — finally the main act

The centrepiece of Spring 2026 was multi-vendor end-to-end integration of massive MIMO O-RAN components, including mMIMO beamforming. This matters more than it might appear. Massive MIMO has always been the credibility gap for Open RAN. Traditional vendors have proprietary beamforming pipelines refined over a decade of commercial deployment. High-band, high-capacity urban coverage — stadiums, CBDs, transport hubs — has been essentially off-limits for disaggregated RAN. Demonstrating that multi-vendor mMIMO beamforming can be integrated in a structured, neutral lab environment is the first necessary step toward closing that gap.

AmpliTech's O-RAN CAT-B 64T64R Massive MIMO radio was the only radio of that configuration at the event — the only American-designed and commercialized O-RU at that specification level — and it demonstrated multi-vendor interoperability alongside operators including AT&T, Deutsche Telekom, Korea Telecom, LG Uplus, Orange and Rakuten Mobile. That combination — 64 transmit, 64 receive antennas, multi-vendor integration, neutral lab, named Tier-1 operator validation — is the kind of result that shifts a proof of concept into a procurement conversation.

Commercial-grade performance parity with incumbent vendors is a separate question, and a longer road. But you cannot get there without first doing what was done here.

AI-RAN — directionally consistent, details deferred

Several labs focused on AI-RAN solutions targeting network performance improvements and energy savings. The press release did not publish quantified results — a contrast with Spring 2025, which reported 25–30% intelligent RAN energy savings delivered by rApps on Non-Real-Time RICs. Detailed results will follow in technical session readouts. The direction is not in question. AI-driven energy efficiency via the RIC architecture has been the dominant AI-RAN use case in structured testing for two years running, and the logic is clear: energy is the largest controllable operating cost in RAN, the levers are cell on/off switching and power scaling, and the RIC is the right control point. What the Alliance needs to demonstrate next is that these savings hold at scale, under real traffic conditions, not just in lab scenarios with predictable load profiles.

The open-source stack is growing up

Four open-source frameworks were deployed at the PlugFest: Open Air Interface, OCUDU, O-RAN SC, and Sylva. Each represents a different layer of the stack, and their simultaneous presence in integration testing is worth noting.

OAI has become the de facto open-source O-CU/O-DU choice in lab settings — widely trusted, well-documented, increasingly operator-deployed in production pilots. O-RAN SC provides the RIC and SMO components from the Alliance's own software community. OCUDU is a combined CU/DU implementation targeting simplified deployment at the edge. And Sylva — the Linux Foundation's cloud-native telco infrastructure framework — is where the container orchestration and lifecycle management work happens. Carrier-grade Kubernetes for RAN workloads, in plain language.

The intersection of Sylva and O-RAN SC is the one to watch. Cloud infrastructure meeting RAN software — not as a research experiment, but as a jointly validated integration — is where operator confidence in virtualized open RAN will be won or lost operationally. It is still early. But it is no longer theoretical.

ISAC — a 6G signal in a 5G event

Initial tests were performed on Integrated Sensing and Communication, or ISAC — using the RAN simultaneously for wireless communications and environmental sensing. Object detection, positioning, radar-like environmental awareness, all from the same radio infrastructure. This is a 6G-era capability appearing in 5G Advanced specifications, and its inclusion in a 2026 PlugFest is a deliberate statement by the Alliance. They are not waiting for a new standards cycle to begin building the interoperability baseline. Given how long it took Open RAN to move from specification to commercial deployment, starting ISAC integration work in 2026 is not premature. It is probably necessary.

Who was there, and who wasn't

The full participant list is a useful read. Operators present included Korea Telecom, LG Uplus, Orange and Rakuten Mobile, with AT&T represented at the governance level through Brian Daly's TSC co-chairmanship. Academic institutions — Virginia Tech's Commonwealth Cyber Initiative, Iowa State University, North Carolina State University, ETRI and Fraunhofer HHI via the i14y Lab — signal that the research-to-commercialisation pipeline is being built at the institutional level, not just the vendor level. Software Radio Systems, the team behind srsRAN, continues to appear — their open-source 5G stack is quietly becoming a reference DU/CU implementation in operator testbeds.

What is absent is equally notable. No traditional vendors. The large incumbents engage with the Alliance at the specification level; they do not typically show up at PlugFest lab level. This is not surprising, but it is a structural tension. The integration maturity of disaggregated RAN will ultimately be measured in Tier-1 operator deployments, and those operators currently run incumbent infrastructure. The path from PlugFest to procurement runs through a comparison the incumbents are not participating in on neutral terms.

What this PlugFest actually means

The O-RAN Alliance has always faced a version of the same challenge: translating credible lab results into commercial deployments at scale. PlugFests prove interoperability in controlled conditions. Operators need it in live networks, under real traffic, with real SLAs and real interference environments. That gap has not closed. But the Spring 2026 agenda — massive MIMO beamforming, AI-RAN energy efficiency, integrated open-source stacks, ISAC first tests — reflects an ecosystem that knows precisely where it needs to focus to close it. That is not a small thing. Three years ago, the conversation was still largely about whether disaggregated RAN could work at all. That question has been answered. The question now is how fast it can reach performance and cost parity with incumbent solutions in high-capacity, high-stakes deployments. Spring 2026 moved that needle. Not dramatically. But in the right direction, on the right problems.

Innovating and Monetizing in Telecom: The Lean Telco

 

As alluded to in my previous posts, I have integrated the Lean Startup methodology, the design thinking framework and the Wardley Map model to create value in a telco environment.

Value is a subjective topic but in a Telco context, my efforts have been aimed at creating sustainable growth strategies. Very simply, sustainable growth comes from sustainable differentiation, which stems from the creation and evolution of technological, commercial and operational characteristics that become difficult, expensive and time consuming to emulate from your competition.

Sustainable growth comes from sustainable cost reduction and revenue growth (Duh!).

Sustainable cost reduction can be achieved through drastic cost structure changes. In 2026 Telco, it can be attained through the implementation of a cloud native architecture and principles, underpinned by strategies of network disaggregation, extensive use of open APIs and open network topologies; control / user plane separation and systematic automation. While these goals are challenging by themselves, particularly in a brownfield legacy telco environment, they are the bare necessary changes for survival. The challenges associated with the organization, skill sets and methodologies to evaluate, test, deploy, purchase and maintain these technologies are even larger.

Every telco is extremely skilled at managing technological and operational risk, through iterative, waterfall evaluation and tests, resulting in deployment of high availability and capacity networks. This methodology has also led to lengthy evaluation periods and deployments. Most vendor will recognize that the sales cycles in telco are over 2 years long and that making any change in a commercial network takes several million of dollars or euros. This has led to an oligopoly where only a handful of specialized vendors are able to sustain economically these drastic processes.

Lately, telcos have been trying to diversify the pool of vendors to increase competition and innovation by promoting open source and open API projects such as open RAN.

While these projects have shown interesting progress, the real cost reduction comes from the change in methodology and processes to take advantage of these more nimble vendors offering.

What I am proposing with Lean Telco is a methodological framework for identifying, evaluating, testing, sourcing, deploying telco products and services that will provide sustainable differentiation with drastically different cost structure than the incumbent versions.

Once you have successfully changed the cost structure of evaluating, buying, deploying and managing telco infrastructure and capacity, you can survive as a high capacity, low overhead provider of connectivity. But if you want to strive and grow, you need to attack the revenue part of the equation. Actually, one would argue should start with growth objectives, and look at cost structure as an optimization challenge.

Growing revenue sustainably, in a telco environment comes from either having more people using your existing services, or using more of them, connect new people or create new services. I have prototyped, tested and launched projects in each of these categories in my role at Telefonica.

1. Having more people use your existing products is difficult for telcos, because those products (residential and enterprise mobility, internet, telephony, TV...) are poorly differentiated, since they rely on the same technology from the same vendors. As a result most telcos end up trying to deploy first (5G, SDWAN...) or to claim a performance advantage, usually derived from a superior spectrum or infrastructure investment. The only real differentiation ends up being pricing. This is very expensive and not sustainable.
2. Having your customers using more of your service does not necessarily lead to more revenue, as bundles and unlimited plans are periodically rolled out to counter internet hyperscalers offering who rely on a different cost structure and revenue model. Again, since these services are mostly the same from one operator to another, differentiation comes from bundling and pricing. This is not sustainable.
3. Connecting new people / clients is a worthy endeavour, but the last unconnected live mostly in rural, low density areas and selling services to new corporate clients usually mean competing against public cloud offering that are more cost effective and flexible than what most telcos can offer. There are possibility of growth there, but it requires breaking out from the current telco technological framework and a willingness to assemble new value chains.
4. Creating new services is certainly where there is the most value, if we look at the growth of telephony over internet, video streaming services, social media and social messaging, SDWAN, cloud security, SASE, AIaaS... it is also the area with the most uncertainty and risk.

Telcos are not well equipped to manage the risk and uncertainty inherent in the discovery and creation of new services. The methodologies, organization and processes they use is to deliver with absolute certainty a product or utility with zero default to a mass market without variation. This model works well for mature, disciplined technology and vendors, not at all for exploration and innovation.

Too often, some Telcos build an extremely detailed plan, with contingencies. They budget it, staff it, resource it to execute it within a given timeframe, only to discover that the client didn't really want / need / value what was proposed (cf. push to talk, IMS/VoLTE, RCS, private networks...).

Just like in Lean Startup, the methodology I propose allows the progressive liberation of resource and funds as commercial uncertainty is shed by direct client interaction, testing and feedback. In a typical telco environment, the client interaction is at the very end of the process, here we are going to intersperse it throughout the development process to allow pivots, or early termination if the hypothesis are not met.

Trained, mentored and helped by many, I have adapted a few methodologies to enable Telcos to identify, validate, and deploy new services in an agile and cost effective fashion. I call it the Lean Telco Methodology.

How do I create a Lean Telco?

I use Wadley Maps for situational awareness and create a topographical representation of the current environment, which in my area of interest range from AI (sovereign, factories, grid, agentic, physical...), telco network cloud, orchestration, cloud native distribution and orchestration (K8, micro services) and hybrid cloud / edge computing (telco private stacks, AWS outpost, MS Azure, AI grid...). This is not a map until we apply the level of maturity (Genesis / handmade, Custom / solution, Product, Utility) to each of them, as well as their direction and barriers on the horizontal axis. On the vertical axis, instead of using Wardley's traditional visibility method, I use technology stacks such as access, transport, core network, OSS /BSS, orchestration... The purpose of the map is not to be precise or even right, it is to share and compare understanding of the environment, the players, their direction, velocity and the barriers. This visualization enables a level of shared understanding necessary to strategic discussions and gameplay around permutations and what-if? scenarios.

Once identified priorities and areas of risks / opportunities to investigate, I use the Lean UX framework and Lean Startup methodology to systematically identify potential current problems needing solving, unmet customer needs, unsatisfactory experiences and potential new products / services that customer wouldn't even know or have an opinion about. A series of workshop is usually best to crystalize the ideas. Once identified, they need to be refined into customer centric objectives. Design thinking frameworks help, but contrary to popular belief, customer centricity is not necessarily going to ask prospective customers about what they think. Most wouldn't have any idea about what to do with 6G, physical AI or a token exchange if you asked them. This is where lean UX and empathetic composite models are useful.

Each idea is reviewed by a jury and graded, the jury defines which ideas can make it to the next stage. The ideas are shaped and staffed as independent projects, with dedicated resource, budget and time box. Each project lead has the overall responsibility for moving the project to the next phase and to deliver the results of the current phase to justify additional resource and budget for the next one.

At a high level, the phases are:

• Ideation - ($5k-10k /1 - 3 months) -the idea is shaped into a project, with central opportunities, areas of innovation, right to play for the company, sustainable differentiating factor, commercial high level opportunity and cost / timing for the next phase.
• Prototyping - ($20k - 50k / 2 - 6 months) - In this phase a prototype is built, that might or might not incorporate any development or use of technology for the target invention. The idea is just to emulate the resolution of the problem and put it into customers hands as early as possible to identify whether the objectives, assumptions are framed properly and whether the client would value the resolution.
• Beta - ($300k - $600k / 3 - 6 months) -  once the central problems are identified, and we know the client values their resolution, it is time to create a MVP to prove that it is technically, commercially, organizationally possible to solve that problem and that the value created exceeds the costs.
• Product - ($1m - $3m / 3 - 6 months) - In this phase, once proven that the solution is possible, it is necessary to prove that the solution will scale and will be deployable with a mature operational and commercial model.
• Growth - (TBD) This is the phase where the project needs to be commercially and economically sustainable.

Each phase require client interactions, in the form of actual tests in conditions as close as possible to commercial network. Within each phase, we decompose the project into customer centric objectives. Each objective into hypothesis. Each hypothesis into series of experiments that will validate or invalidate the hypothesis. It helps to set clear expectations and success criteria for each of these.Wardley maps helps again, within each phase understanding what tasks, experiments are more suited for pioneers, settlers or town planners and indeed whether the project lead can adopt this mental posture in this phase or whether someone else needs to take the lead.

The result is a portfolio of new revenue making projects, that are systematically validated by customer feedback, capacity and propensity to pay; together with a robust operational and commercial model. Each project is periodically reviewed and graded, all projects must pass a gate review before the next phase and liberation of funds, which allow a nimble, measured, progressive investment plan, as risks and uncertainty decrease throughout the life of the project.