DTW Ignite 2026: The API Is Not Enough

I returned from DTW Ignite in Copenhagen with one conviction: the interface between enterprise applications and network infrastructure is about to change in a way the industry has not yet designed for.

Network APIs were never really about autonomous networks. That framing conflates two separate problems. APIs — CAMARA, GSMA Open Gateway, the decades of network exposure work that preceded them — were designed to let developers discover and consume network resources from outside the operator domain. Quality on Demand, location services, device status, number verification: clean REST interfaces exposed through a developer portal so that a programmer writing a B2B application could request a network capability and pay for it. Real progress on a real problem. But the problem was developer access, not network autonomy.

What is coming next is different in kind, not degree.

Enterprise AI agents are beginning to consume network infrastructure directly — not through a developer writing an integration, but autonomously, in real time, as part of executing a business objective. An industrial automation agent that needs guaranteed low-latency connectivity for a robotics fleet. A financial services agent that needs to provision a secure, isolated network path for a time-sensitive transaction. A logistics agent that needs to dynamically reserve bandwidth across multiple carrier domains as a shipment moves between jurisdictions. In none of these cases is there a developer in the loop. The agent has an intent, it needs network resources to fulfil it, and it needs to negotiate those resources with the network — now, at machine speed, without human mediation.

That negotiation cannot happen through a developer portal. It cannot happen through a static API catalogue with a PDF explaining what each endpoint does. The enterprise agent and the network need to speak to each other, and neither CAMARA nor MCP — whatever their respective merits — were designed for that conversation.

The network side of this exchange needs to be represented by network AI agents of its own: agents that can expose available capacity in real time, understand the constraints and commitments already in place, reason over competing demands, and negotiate resource allocation in a way that respects the network's operating boundaries. That is not a developer API. That is an autonomous counterparty.

And for those network agents to function — to negotiate reliably, to be governed, to be audited, to avoid conflicting with each other across RAN, transport, core, and the operational layers of OSS and BSS — they need something the industry is not yet building: a meta-model of the agentic plane itself.

Operators building autonomous networks are doing the right foundational work. Network topology models. Data ontologies. Decision layers. Closed-loop control architectures. These give the automation layer a complete and current picture of the environment it is operating in. But agents operating on that network need an equivalent model of themselves. Every agent with an identity, a capability scope, an authority boundary, a state, a dependency graph, and an audit trail. An abstract topology and ontology of agents, sitting alongside the topology and ontology of the network.

Without that model, what looks like autonomous negotiation between enterprise AI and network AI is actually uncontrolled interaction between systems that cannot see each other. An enterprise agent requesting bandwidth does not know what the network agent is authorised to commit. The network agent does not know what other network agents have already promised. No shared representation, no conflict detection, no governance.

The developer exposure problem is largely solved, or at least well understood. The agent-to-agent negotiation problem has barely been framed. That is the conversation the industry needs to have, and Copenhagen convinced me we are not having it yet.

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.