Event Report: Mplify Global NaaS Event, Dallas
NaaS shifting to AI connectivity, agentic security & aligning with mobile network APIs
Last week I attended the Mplify Global NaaS Event (GNE2025) in Arlington, near Dallas. I did a write up of Day 1 on LinkedIn and also a couple of threads on X, but I wanted to bring out the key themes here in a little more detail.
The event covered not just the use-cases for Network-as-a-Service (NaaS) - and especially AI-driven growth - but also the way those are accessed, especially via APIs, or where agents act as the “customer”.
It was a very useful reminder that much of the real action around AI and cloud isn’t on the massmarket, retail broadband / mobile RAN access side, but “behind the scenes” between datacentres, or between enterprise IT workloads and data storage.
And while the mobile industry has been loudly hyping its API initiatives like Project CAMARA and GSMA Open Gateway, Mplify (in its former guise as MEF) has been quietly using its own network APIs, called LSO - Lifecycle Service Orchestration, for fixed B2B and transport networks for years.
Introduction
The term “Network as a Service” is not the most intuitive telecoms term to grasp, especially for people more familiar with consumer broadband services or mobile RAN.
There’s no strict definition, but it generally refers to B2B or wholesale connectivity services that can be set up “on demand” with a high degree of automation, flexibility, and incorporating multiple elements such as extra security and backup options.
These networks are used to connect enterprise sites (HQs, branches, overseas offices, factories - and datacentres), but also get consumed by by service providers and cloud platforms internally and between each other.
The useful intro chart below (from an AT&T speaker) gives a sense of the evolutionary path that enterprise WAN services have taken over the last 30 years or so.
The main focus is on fixed connections - typically ethernet-based or optical “wavelength” services, but also with some based around wireless, satellite or basic broadband lines.
More recently, NaaS language has started to appear in more 5G contexts, either linked to “quality on demand” Network APIs, or for more integrated solutions for enterprise wireless users such as vehicle fleets, which might want to combine both a wide-area “slice” of some type, with connections to cloud/edge resources or links direct to enterprise IT resources. But the roots of NaaS lie solidly in the ethernet and fixed domain.
Indeed, the evolution of hybrid fixed/mobile NaaS (and alignment on APIs between Mplify and GSMA) was certainly an element of the Mplify event, but it got rather overshadowed by the larger story about NaaS for AI.
NaaS for AI
The huge AI boom has changed the NaaS market overnight. It was already evolving with the ongoing shift of enterprise IT to the cloud, but the sudden emergence of AI has catalysed multiple additional elements:
Need to connect up new datacentres, often in unusual areas, away from traditional fibre “corridors”.
Scale-across connections, where large DC zones are split over multiple campuses and buildings, perhaps across a metro area, reflecting physical constraints on power or property at any single site.
Emergence of a huge number of “neo-cloud” players that specialise in GPU-aaS or other key components of the AI industry.
Enterprises needing to do huge data uploads of existing data, for training of custom models and for RAG purposes. This requires temporary (and often quite localised) access to very-high capacity connections, which might then be repeated at a future point.
A growing need for connecting to various classes of edge compute resources, especially for inferencing and (see below) agentic operations.
Extension of the multi-cloud concept to multi-model
More awareness of cloud/AI sovereignty and security issues, which is driving the need for network connections in-country, or via preferred routes.
Telcos trying to work out their own AI on-ramps, either for internal use in the network, or as they want to build and launch their own AI services.
A good line I heard at the event was “You can’t let GPUs sit idle” - and so getting data to and from them as fast as possible is essential.
Although it wasn’t explicitly mentioned much, I also suspect that Voice + AI will require NaaS to hit realtime latency needs in many contexts.
I was very struck by some of the observations made by a presenter from Lumen, who said that an enterprise might end up needing connections to 40-50 different DCs or cloud locations, even in a single geographic region. The term “fabric” was used quite a lot to describe this. Coming back to the voice point, I noticed that the chart below also includes AI Call Centres.
NaaS and Agentic AI
Another learning from the Mplify conference was that the next phase of NaaS and AI relates to the rise of Agentic AI. There are three angles here:
There is a belief that the ad-hoc, unpredictable nature of agents will mean much greater need for on-demand network connections within and across the cloud/AI domain, with low latency and high reliability. That could directly drive NaaS use.
Agents will be used to invoke and consume NaaS (see below, AI for NaaS section)
Agents will need some sort of “identity” to prove who/what they represent, and to log where/what they connected to, with which permissions and other configurations.
One of the event themes was that potentially that last category could be another network-derived service, with telcos’ NaaS units acting as Agentic Identity Providers. This seems interesting, but agent identity may be a broader problem that extends beyond the network. Lots of agent interactions will be invisible to telcos (eg inside enterprise IT systems, or direct device-to-device, or inside the home), so it’s unclear how any telco would try to authenticate them.
Some of the sessions and panels also noted that while there is clearly a huge focus on NaaS for AI use-cases as a revenue driver for almost everyone, there is also still a lot of mileage in “normal” NaaS for enterprise sites, as well as non-AI cloud workloads. This aligns with ongoing trends around SD-WAN and security-enriched SASE offers. Another theme covered by a couple of speakers (including from Arqit, a UK company I’ve met before) was about ensuring that NaaS connectivity is quantum-safe..
AI for NaaS
As well as NaaS for AI infrastructure and workloads, some of the sessions flipped the theme the other way around, looking at AI-for-NaaS. There were two main aspects covered:
Automation & analytics for the network platform itself (basically AIops for the NaaS operator)
Use of AI as a mechanism for buying and managing NaaS services
It was the second of these that led to the conference’s frequent references to MCP, which I’ve been writing about since the depths of history (July). At the time I said it was likely to be important for telecoms and that the industry should pay attention - and now it’s mentioned everywhere.
The way that Mplify frames it is that the specific instructions or actions in LSO are called “payload” - add a new connection, increase the throughput, switch on security, check the maintenance status etc.
And these payloads are accessed via a “transport” mechanism - APIs, or now MCP as a more AI-friendly front end, for people or processes that can’t directly write to those APIs.
The idea is that with agentic AI, “Buyers don’t need to be WAN experts to buy NaaS”. Instead, they can just use natural language to “add a backup circuit” and get shown the options, the price, and the ability to order and activate.
In that scenario, the MCP server sits in front of the API layer, with the “model context” essentially acting as an AI-to-NaaS translation layer. In future there may be some features that are “AI-native” and then it could evolve to agent-to-agent links. (I’m massively simplifying here, but I hope that readers get the general point - Mplify has a white paper on all of the detail).
Fixed / Mobile convergence & NaaS
There was an announcement at the event about Mplify collaborating with GSMA Open Gateway and the CAMARA mobile APIs. There was also a presentation from GSMA at the event.
I didn’t get the sense that there was full mutual understanding here, to be honest, but I think there are some synergies, only maybe not the obvious ones. There was a superficial narrative that “Mobile QoD & slicing & edge discovery APIs are types of NaaS, therefore it all makes sense together”.
That’s sort-of true, and indeed I created the chart below about 18 months ago to illustrate the point.
But the reality is that most of the current CAMARA focus (and the actual activities of GSMA OGW and aggregators like Aduna) is around anti-fraud and identity APIs, such as SIM-swap. Other capabilities such as QoD and location are difficult because of variable radio conditions, consent requirements - and especially a lack of 5G SA adoption so far.
To the GSMA’s credit, it actually now acknowledges that issues such as indoor wireless and devices spending lots of time on Wi-Fi are now limiting factors here. The candour was welcome.
My thoughts on where the actual synergies may lie:
MNOs are actually stereotypical enterprise customers for LSO and NaaS, for backhaul, fronthaul or connecting their own datacentres & VNFs & AI agents
Slicing needs to be end-to-end, and the transport domain is part of that. In particular, any future dynamic slicing models (as opposed to ealry fixed slices) will need the agility of NaaS as an ingredient. Still doesn’t fix the radio unpredictability though, so I’m sticking to my “slicing skeptic” stance.
5G FWA is a “payload” for NaaS APIs or MCP, especially as companies (eg RAD, an exhibitor) enable ethernet-over-5G. This could be useful for remote sites, or adding a backup to existing WAN connections. It’s also possible to use CAMARA QoD to offer prioritised access for that 5G connection.
Neutral hosts could use NaaS for managing the wide-area connections for in-building or densification of mobile access.
Given the focus of both organisations on identity, I wonder if there’s a way to align the mobile “Know Your Customer” KYC and anti-fraud APIs to the Mplify vision around “Know Your Agent” and agentic identity. Would make a lot of sense for both general Agentic AI interactions, and especially the B2AI personal-agent concept I’ve talked about recently
Orange was talking about a possible 5G SA “core network as a service” proposition, hosting cores for smaller MNOs (or I guess MVNOs), which would obviously need fixed cloud connectivity behind the scenes. I should note that despite its claim on stage, Orange isn’t the first telco I’ve heard suggest this - the Pacific Islands operator Palau National Communications mentioned it to me a few months back.
Finally, I suppose that any future GPU-based RAN trying to offer AI services in the RAN could use a combination of CAMARA and Mplify APIs to give easier access to distributed compute resources.
The GSMA’s own vision of fixed-line integration is shown below. But my sense is that for it to get its own NaaS APIs to align with end-user network access, it also needs to be talking to BBF and WBA about getting closer to residential broadband and Wi-Fi APIs.
Conclusions
I found the Mplify NaaS event to be a very useful sanity-check on the real world of AI connectivity. It follows on from the Optical event I went to recently in Copenhagen as a critical part of the patchwork for understanding Telecoms + AI, this time with a good amount of API / MCP in addition.
Clearly, NaaS is being driven by the AI boom, but there is also evidence that AI is itself changing NaaS.
I think that the fixed and mobile worlds are slowly converging on a shared vision of API and agentic access, but it’s less of a two-bubble Venn diagram, and more of two combs slowly meshing at multiple points. There’s a lot more work to do.
Thanks to the Mplify folk for hosting me - and listening to my utterances from the stage on the final analyst panel.
On a final note, mark the date 15th January 2026 in your diaries. I’m running the next Unthinkable Lab workshop, on Telecom APIs + Agentic AI + MCP, in London. More details coming soon - or message me here or on LinkedIn to get involved.