{Core Analysis}

Ericsson and Nokia at odds on AI-RAN silicon

noreply@blogger.com (Patrick Lopez) — Fri, 16 Oct 2026 18:14:18 +0000

Ericsson CEO Per Narvinger used the Q3 2026 earnings call on 15 October to defend custom ASICs for AI-RAN, according to RCR Wireless on 16 October. Asked by Deutsche Bank's Robert Sanders whether GPUs in the baseband had been ruled out, Narvinger said Ericsson is not philosophically against anything and will pursue what makes business sense. Its software and hardware are disaggregated, so GPUs remain an option, although they would require new hardware at the site. The function Ericsson is selling today, AI-native link adaptation, runs on basebands already deployed. Ericsson reports a 10% spectral efficiency gain and says the function runs on more than 60,000 base stations at 3 operators, including Optus, with AT&T, Bell Canada and T-Mobile reportedly testing it. All figures here come from RCR's account of the call.

Narvinger put a 10% spectrum efficiency gain at about $800 million, against the $8 billion SpaceX was reported to have paid for spectrum the week before. RCR does not say what base the $800 million is calculated on, so I treat it as an illustration, not a measurement. The comparison does clarify the nature of the benefit. Spectral efficiency is capacity gained on spectrum already licensed, which is cost avoidance, the category I separated from new revenue in AI monetization for operators: separating revenue from cost avoidance. On a single cell the value arrives when a capacity upgrade is deferred, and Vish Nandlall's RCR Analyst Angle of 13 October put that at about $18,000 in present value for a cell at 91% load with a $200,000 upgrade deferred by about 1 year. An average gain across 60,000 sites says less than how many of those sites sit near an upgrade trigger.

Light Reading reported on 12 October that Nokia is building its AI-RAN on Nvidia GPUs and has stopped new custom silicon, with operators testing this quarter and commercial availability in early 2027. Ericsson's answer is that value can be delivered now on silicon operators already own. Both positions have an economic logic, and neither has been tested against the other in a published cost comparison. This is the gap between field-validated and commercially validated that I described in Is AI-RAN the future of telco?. A footprint of 60,000 sites is a field result for a software function on existing ASICs. It does not show that a GPU baseband earns its premium. Where accelerators are needed, the position in Non-RT RIC, AI-RAN, and the AI Grid applies: deployment starts where power, cooling and fibre are already in place, which points to the central office before the cell site.

Component costs add to the comparison. RCR reports that Ericsson beat Q3 forecasts on 7% organic sales growth, helped by customers buying ahead of expected AI-related price rises, and warned that AI-driven component costs will pressure margins through 2027.

As you know if you follow this blog, I am skeptical of the cost-benefit of putting GPUs in a base station. The costs are high and growing, both form a capex and an energy perspective, while the benefits are entirely speculative. Would Nokia have taken the same architectural decision without NVIDIA's 1B$ investment? Unlikely. Between data centers, AI-RAN, sovereign AI, and AI factories, NVIDIA plays on a lot of different fields in telecom. They can afford for some of these explorations to backfire. Can Nokia afford to fail the next generation of radio architecture by betting it all on GPU?

Ericsson Makes Its Case for Edge Inference

noreply@blogger.com (Patrick Lopez) — Fri, 09 Oct 2026 15:19:03 +0000

Ericsson published a blog on 7 October, written by Benedek Kovacs, Wolfgang John and Mischa Dohler, arguing that where AI inference runs is becoming a strategic decision for enterprises and that communications service providers are well placed to answer it. Ericsson draws on an F5 report for the shift toward enterprises running some inference themselves. The blog states that service providers operate about 100,000 distributed network data centres, which could support over 100 GW of new AI compute over time. It names 3 advantages for the telco edge: access to live network context such as radio conditions and device location, stable low latency for physical AI, and confidential computing that keeps data private from the operator and from co-located workloads. It adds that a Swedish regulatory sandbox assessed the confidential computing approach as compliant with current data protection rules, subject to user-controlled attestation and key management.

The 100 GW figure divided by 100,000 sites implies an average of about 1 MW per site, which is my arithmetic and not Ericsson's. The blog gives it as an eventual ceiling with no timeline and no split between sites that have the power, cooling and fibre today and those that would need a rebuild. Those 3 constraints are why I placed AI Grid deployment at central offices and mobile switching offices rather than at the cell site in Operators Lean In On AI Grid Location. A count of 100,000 sites says little about how many of them can host accelerated compute.

Ericsson's own performance chart points the same way. At 30 tokens per second it shows roughly 7.0 billion parameters running on a device and roughly 30.8 billion at an edge site, which is the range of small and mid-size models, not frontier models. The workload Ericsson builds the latency case on is physical AI: robotics models of 10 billion to 100 billion parameters, control loops of 10 Hz to 20 Hz and responses under 100 ms. Those are real requirements, and they define a narrower market than general enterprise inference.

The operator role Ericsson describes

The more notable statement is about 6G. Ericsson expects specialised AI providers to deliver most early edge AI services on top of telco infrastructure, with the service provider's value in orchestration, network API exposure and end-to-end assurance. That is a vendor describing the operator as the infrastructure and assurance layer, not the seller of the AI service, and it is a shift from the position I covered in Ericsson Says the Telco Edge Was Too Early. Operators that accept that role should price edge sites on power and connectivity economics at the central office and metro layer, and should treat network context as a paid input that third-party AI providers consume through APIs.

AT&T and GSMA warn Telco AI Models Drift

noreply@blogger.com (Patrick Lopez) — Mon, 28 Sep 2026 16:36:39 +0000

Boost Mobile data scientist Priyank Jain, GSMA director of AI technologies Louis Powell and AT&T data office vice president Mark Austin flagged a specific and seldom discussed risk in telco AI deployments this week: the gap between the data a model was trained on and the data it actually encounters once it is live, a failure mode known as train serve skew. Speaking to Fierce Network on 25 September 2026, Jain explained that the danger is not a crash or a failed job. Nothing alerts an operator that anything is wrong. Jain said the model "just gets quietly worse."

Two Different Ways Models Drift

The article identifies 2 separate causes. General purpose frontier models arrive with no exposure to telecom specific data formats or vendor taxonomies, since none of that appears in their internet scale training data. Telecom specific models face a subtler problem: production data, such as settlement records, arrives late or out of order in ways the training set never captured, and datasets in this domain routinely carry over 100 columns of custom, operator specific parameters. Powell added that frontier models have no inherent understanding of telecommunications and can produce confident, wrong answers, a real risk once a model is embedded in an enterprise workflow. Austin's prescription is procedural rather than technical: match training data to production sources as closely as possible, run a new model silently alongside the live system before cutting over, and keep testing it after deployment rather than treating the launch as the finish line.

Why This Matters Before Autonomy

This is a narrower and more mundane problem than the industry's current preoccupation with agentic AI and autonomous networks, and that is exactly why it matters. The NGMN report on agentic AI concluded that even coordination within a single operator's own domains, let alone accountability between an enterprise and its network provider, requires common information models and audit trails that do not yet exist. Train serve skew shows the problem starts a level below that. A supervised classifier with a known, static task can still fail silently once its inputs drift from what it was trained on. An autonomous agent negotiating across an operational boundary carries the same drift risk plus the coordination and accountability gap NGMN identified. Operators evaluating agentic AI pilots should ask a more basic question first: whether they would know if the model already in production today has quietly stopped working.

Quiet drifts like this example are worse than explicit failures. The quality of the output degrades silently, which degrades the quality of service. Explicit quality control for data quality before and after transformation, and before and after agentic intervention are necessary to enable autonomous networks.

Orange Business Moves Agentic AI Onto Open-Weight Models

noreply@blogger.com (Patrick Lopez) — Wed, 16 Sep 2026 12:55:16 +0000

Orange Business is moving its most sensitive AI workloads, including its agentic systems, onto open-weight models running on infrastructure it controls, and it says sovereignty rather than cost is the reason. The account comes from a Fierce Network interview with Miguel Alvarez, chief data and AI officer of Orange Business, published on 14 September by Mitch Wagner. Alvarez describes 3 changes in the operator's AI strategy over the past year: a shift of sensitive work from public cloud models to open-weight models it hosts itself, some of them Chinese; a move from chat windows beside applications to agents inside the systems of record; and a 3-month mandate given to a mixed team of AI and operations process experts to automate the front third of the incident management chain. That last piece is the one with a number attached. Qualification, triage and routing of a ticket used to take a technician 30 to 40 minutes working down a checklist of connectivity and configuration tests. Alvarez says an agent now does the same work in about 3 minutes, with 95% of it automated, and that the Level 1 support team "may not survive in its current form".

Sovereignty is the differentiator

The first change is the one Orange Business leads with. Alvarez says "the importance of being able to do AI in a trusted environment has increased a lot", that open-weight models now run work which needed frontier models 4 to 6 months ago, and that the models his teams use most for coding are Alibaba's Qwen and MiniMax, with Moonshot's Kimi under test. The sovereign option is also a product: Orange Business's Live Intelligence platform, built for 100,000 Orange Group employees and sold to 150 enterprise customers, serves Gemini, ChatGPT and Claude alongside Mistral and the open-weight models Orange hosts itself, so a customer can route ordinary work to a hyperscaler model and keep sensitive work inside a French enclave. Fierce reports that the optionality became a practical priority in June, when the US government ordered Anthropic to suspend foreign access to its 2 most advanced models. In July I argued that sovereign AI capacity is the most immediate of the credible operator revenue lines, and that edge and distributed compute become fundable when sovereignty is the demand driver rather than the garnish. Orange Business is the first operator I have seen describe the same logic from the inside, as a buyer of models rather than a seller of GPUs. It did not move to open-weight models because they were cheaper. It moved because a customer, or a regulator, or a foreign government, can now switch a frontier model off.

The second change is the one that matters for the business case. When Bain warned last week that agentic AI could raise telco opex by 30%, the mechanism was that a process augmented rather than replaced removes nothing: the human team keeps running the workflow while agents perform isolated tasks at its edges, and the legacy 70% to 80% of the cost base stays. Alvarez describes exactly that trap in his own first phase. Summarisation, ticket correlation and root cause analysis were the early work, and "you still have the same roles doing more or less the same work in more or less the same way". The 3-month mandate was the correction. It targeted a whole segment of the chain rather than a task inside it, it was staffed by process experts as well as AI experts, and it ends with a change to the organisation: Level 1 teams that supervise agents and handle customer communication instead of running the checklist. Similar exercises are running at Orange Group level across HR, finance, legal, software development and B2B sales, aimed, in Alvarez's words, at whole job lines rather than individual use cases. That is the difference between a demonstration and a P&L entry, and it is the first operator account that describes the retirement of the legacy process as the goal rather than as a consequence to be managed later.

The 2 changes are connected. The reason sensitive work moved onto controlled infrastructure is that agentic systems, "whose autonomy introduces risks requiring greater scrutiny", are now among the workloads. Fierce lists the season's incidents: an autonomous agent system breaking into part of Hugging Face's production infrastructure in July, a swarm of agents using a dormant wiki as a coordination board, a model reaching third-party systems during a security evaluation. Alvarez's response is operational rather than philosophical. Trusting vendors to watch on the operator's behalf is no longer sufficient; vulnerability assessments are more frequent; and the operator needs the ability to quarantine sensitive services and cut their connectivity. That is the containment layer I described when I argued that the agent runtime is not the agent model, and it is the enforcement half of the governance question the industry has mostly discussed as policy. An operator that runs the model on its own hardware can quarantine it. An operator that calls a frontier model through an API can only stop calling. Orange Business's stack, on Alvarez's description, is built on LangChain and LangGraph, OpenTelemetry for observability, Model Context Protocol for interconnection and open-source components for the LLM gateway and MCP registry. Every one of those is a runtime component. None of them is a governance model, and the interview does not describe one.

The main challenge for AI remains trust. Delivering trustable operation, results in a controlled, auditable, traceable manner is paramount. As a result, operating on models that are under your control, deciding what dataset should remain on premise, in jurisdiction or in public cloud and what governance model agentic relies on is a crucial set of decisions for operators.

Bell Canada Launches Self-Serve Network as a Service

noreply@blogger.com (Patrick Lopez) — Fri, 11 Sep 2026 12:38:38 +0000

Bell Canada announced on 10 September the Bell On-Demand Network, which it describes as the country's first network-as-a-service platform aligned with the 7 customer experience attributes defined by Mplify, the industry body formerly known as MEF: on-demand, observable, manageable, programmable, secure, modular and flexible. TelecomTV carried the announcement in its 10 September roundup. The platform runs on Bell's fibre network with Cisco 8000 Series Secure Routers underneath, and the operator's description is that business customers can, through a single self-serve platform, "autonomously order, activate, manage and scale connectivity". The first product is On-Demand Internet, available in Ontario and Québec wherever Bell has deployed fibre, with additional networking, security, cloud connectivity and automation capabilities to follow. Bell's CTO Mark McDonald said customers "can now provision, scale and adjust their network in real time, getting the exact bandwidth and services they need, the moment they need them". No price, no provisioning time, no API documentation and no customer figure were published.

The customer configures, the operator does not pre-package

I have argued for some time that the natural end state of differentiated connectivity is slicing as a service: a platform through which third parties discover, configure, reserve and consume network resources on demand, because enterprise CIOs know their connectivity needs better than the operator does and are used to configuring cloud services rather than selecting from a catalogue. Bell's launch is that model applied to fixed access, and it is worth noting what is different from the 3 mobile launches of the past 3 weeks. EE sells a priority lane as a tariff, Vodafone sells a predefined quality profile through an API, and Telstra sells a slice for 1 application chosen by the operator. In each of those the operator decides what the product is and the customer decides whether to buy it. In Bell's description the customer decides the bandwidth and the timing, and the operator's role is to make the change when asked. That is the inversion the slicing-as-a-service argument depends on, and Bell states it as the product rather than as a roadmap.

Fixed first, because bandwidth on fibre is a reservation

It is not an accident that the self-serve model arrives on fibre before it arrives on mobile. When Vodafone launched quality on demand I wrote that a priority is not a reservation: a mobile profile improves the customer's place in the queue on a congested cell but does not guarantee what comes out of it, and the profile parameters were not published. On a dedicated fibre access line a bandwidth change is a reservation. The capacity exists, the router policy is deterministic, and the operator can honour the customer's chosen figure without a proof-of-value engine to check whether it did. That is why Bell can let the customer set the number and why the mobile operators cannot yet. It is also why the interesting part of Bell's roadmap is the part that is not launched: cloud connectivity and security are where the customer's requirement starts to depend on a second network and a second party, and the on-demand model will be tested at the first boundary it has to cross. Mplify's 7 attributes describe the customer's experience inside 1 provider's platform. They do not describe what happens when the customer's agent asks 2 providers for the same thing.

Programmable is the attribute that matters

Of the 7 attributes, 6 describe a good portal. The seventh, programmable, is the one that decides whether this is a self-serve web page or a network resource that a customer's own systems can consume. Bell's announcement describes a platform, not an API, and does not say whether the ordering, scaling and observability functions are exposed to the customer's software or only to a person logged into a portal. The distinction is the one I drew at DTW Ignite: the APIs that ship are the ones that ask the network a question, and the ones that ask it to change its behaviour on a third party's instruction are harder. On-Demand Internet is the second kind, in the easiest domain. If it is programmable in the Mplify sense, a customer's cloud automation or an enterprise agent can scale the access line up before a backup window and down after it without a human on either side, and Bell has built a resource the customer's software can reason about. If it is a portal, Bell has built a better ordering experience. The announcement does not say which, and it is the first thing a CIO evaluating it should ask.

What has not been published

No price relative to a standard business fibre contract, no provisioning time for a bandwidth change, no statement of whether the platform is API-accessible or portal-only, no minimum term or change frequency, no customer count and no date for the cloud connectivity and security capabilities. 4 things to watch. First, published API documentation, which is the test of the programmable attribute. Second, the price of a bandwidth change against the price of a permanent upgrade, because the on-demand model only pays for the customer if variable capacity is priced below fixed capacity over the period it is used. Third, whether Bell extends the same self-serve model to its mobile network, where it would need 5G standalone slicing and a service level of the kind Telstra attached to its slice. Fourth, whether the cloud connectivity capability, when it arrives, lets the customer configure the far end as well as the access line, which is the first crossing of an administrative boundary and the point at which slicing as a service stops being a single-operator product.

Agentic AI Could Raise Telco Opex by 30%

noreply@blogger.com (Patrick Lopez) — Fri, 11 Sep 2026 12:24:36 +0000

Two reports published on 10 September describe the same balance sheet from opposite ends. Bain & Company, as reported by Telecoms.com's Mary Lennighan, warns that operators could see operating costs rise by around 30% without any gain in productivity or growth if agentic AI is bolted onto legacy operating models. The consultancy describes an emerging agentic operating model in which traditional costs account for 70% to 80% of an operator's total and AI costs for 20% to 30%, with the risk that the legacy 70% to 80% never goes away. The same morning, TelecomTV's James Pearce published a second cut of the AI-Native Telco Index, the 276-page evaluation of 56 operators based on published material from January to June 2026, and found that 20 of the 56 frame their AI strategy primarily around revenue, 28 balance revenue and efficiency, and only 6 are primarily focused on efficiency. TelecomTV names the 6 as KPN, Proximus, Spark New Zealand, BT Group, Comcast and Rogers. It also notes, in the same article, that across all 56 operators cost savings remain the most clearly measured AI-related financial impact.

A new cost layer on top of the old one

Bain's argument is about arithmetic rather than technology. Model prices have fallen almost 10 times in the past year, according to the report, but token usage is rising faster as staff find new uses in network operations and customer care. At roughly half the token price, a 4.5 times increase in usage doubles the bill. The recommendation is to measure the cost of a business outcome, a resolved customer issue or a closed network incident, rather than the cost per token, and to hold someone accountable for model drift and token spend. AT&T is the worked example: it redesigned its orchestration so that large supervising agents delegate to smaller specialised models, which by AT&T's own account cut costs by up to 90% while tripling throughput. Bain's 3 cost traps are the token bill, the dual operating model in which human teams keep running the process while AI performs isolated tasks at the edges, and the low-risk demonstration that improves efficiency at the margin without touching the P&L. Internal chatbots, call summaries and copilots are named in the third category. This is the cost side of the 3 money flows I set out in July, when I argued that cost avoidance and revenue must be separated before an operator can say what AI is worth to it. Bain adds the point that cost avoidance is not automatic either: the avoided cost has to be removed from the organisation, and a process that is augmented rather than replaced removes nothing.

Revenue is the stated priority, savings are the measured one

The Index finding runs the other way. When I covered the first edition of the Index on 7 September the observation was that none of its 4 dimensions was financial. The second cut is TelecomTV's answer, and it is a useful one, because it reads the same public record for money rather than for capability. Of the 20 revenue-first operators, 11 are Tier 2 operators with annual revenues between $2 billion and $10 billion, 11 are in Asia and 4 in the Middle East, which TelecomTV reads as evidence that the shift toward AI revenue is not being led from Europe or North America. The examples with numbers attached are few. Bell Canada reported around C$700 million of AI-powered revenue in 2025, up 60%, and targets around C$2 billion a year by 2028. SK Telecom's AI datacentre business grew 92.5% year on year to 136.2 billion won in the second quarter, with AI B2B and B2C services at 61.3 billion won, up 24.5%. Indosat Ooredoo Hutchison reports sovereign AI cloud income separately, $28 million in 2025 with guidance of $60 million in 2026, and its Zankore joint venture with Nvidia, Nokia and Ooredoo raised $3.1 billion in debt this week to build 200 MW of GPU capacity by early 2027. On the efficiency side, KPN targets around €100 million a year in operating cost savings by 2030, Proximus folds AI into a €180 million efficiency programme, and Spark credits its churn model with reducing customer loss by up to 30%. TelecomTV also cites GSMA Intelligence's finding that only 35% of telco AI initiatives include a revenue objective. Read together, the picture is that revenue is what operators now say, savings are what they can measure, and 2 of the 3 operators publishing AI revenue lines, SK Telecom and Indosat, are selling compute or cloud capacity, which is the first of the 4 credible revenue lines in the July post and the one that looks least like a telecom service. Bell has not said what its C$700 million comprises.

The number the business case is missing

Put the 2 reports side by side and the missing figure is obvious. The Index counts operators that talk about revenue and reports the revenue lines that exist. Bain estimates the cost that agentic AI adds and warns that the legacy cost may stay. Neither report, and no operator in the Index, publishes both halves for the same company: AI-attributed revenue, AI-attributed savings actually removed from the cost base, and the AI compute and token cost that Bain says will make up 20% to 30% of the operating model. Bell's C$700 million is a revenue figure with no cost of sale attached to it in public. SK Telecom's AI datacentre revenue is real, but it is a hosting business whose margin is set by power and GPU depreciation, not by the network. KPN's €100 million is a 2030 target. Bain's own preferred use cases, autonomous network incident resolution and proactive churn prevention, are the workflows where the operator has to redesign the process end to end and retire what it replaces, and they are also the workflows where the data has to be fit for an agent to act on. Deutsche Telekom's Ahmed Hafez told the AI-Native Telco Forum on 8 September that DT's network data "is not ready" for machines and that data quality demands will start appearing in supplier RFQs, which is a cost that precedes any saving. Bain's framing is the right one for the report I am completing on autonomous networks: cost per resolved incident, before and after, with the platform, compute and data cost inside the denominator. That is the number that converts a proof into a P&L entry, and it is the number no one in the Index has yet published.

What has not been published

No operator has published AI revenue, AI savings and AI operating cost for the same period. Bell has not disclosed the composition of its C$700 million or the margin on it. AT&T's 90% cost reduction is its own account, relayed by Bain, with no base figure. The Bain report itself is available from Bain; the figures here are as reported by Telecoms.com. 4 things to watch. First, whether any of the 20 revenue-first operators reports AI compute or token spend alongside AI revenue in a quarterly filing, since that would be the first complete line item. Second, whether a legacy cost is visibly retired and attributed to agentic automation, in headcount, systems or supplier spend, rather than a saving being projected. Third, the on-demand recording of the AI-Native Telco Forum session on closing the attribution gap between deployment and financial outcomes, with Deutsche Telekom, Everpure and TM Forum, which TelecomTV says will be posted within days. Fourth, whether the 2027 edition of the Index adds a financial dimension and, if it does, whether it measures cost of outcome the way Bain proposes.

Telstra Sells a Network Slice for Microsoft Teams

noreply@blogger.com (Patrick Lopez) — Wed, 09 Sep 2026 07:33:52 +0000

Telecoms.com's Nick Wood reported on 7 September that Telstra has launched Dynamic 5G for Video Calling, a business service that directs Microsoft Teams traffic onto a dedicated slice of its 5G network so that calls do not compete with other traffic during peak periods. Telstra's own description is that it "represents a move toward application-aware, business-grade connectivity, designed to prioritise performance for selected traffic, not just speeds." The operator names construction, utilities, transport and logistics as the sectors it is aimed at, where staff are on the move, temporarily located or in the field. Dynamic 5G is the umbrella brand Telstra launched for business slicing in 2025, and its distinguishing feature is a proof-of-value engine that monitors slicing traffic continuously and checks whether the customer is receiving the service promised; if it falls short, the customer does not pay. Telecoms.com sets the launch against T-Mobile US's SuperMobile business tariff, Deutsche Telekom's gaming and video-calling slices, EE's Fast Lane and VodafoneThree's SuperMobile in the UK, and cites ABI Research's forecast that the slicing market will grow from $6.1 billion in 2025 to $67.5 billion in 2030. No price, no slice parameters and no customer count were published.

3 slicing products in 3 weeks, sold 3 ways

Since 20 August, 3 operators have put differentiated network quality on sale in 3 different forms. EE sells a priority lane to consumers as a handset tariff, which I covered when Fast Lane launched. Vodafone sells a quality profile to developers through an API in Germany, without a price or a published profile. Telstra sells a slice to enterprises per application, with the application chosen by the operator and the enterprise buying the outcome. These are the 3 channels through which an operator can sell the same underlying capability, and it is useful to have all 3 on the market at once because they will produce different evidence. The tariff channel will produce an attach rate. The API channel will produce a call volume. The enterprise channel will produce a contract with a service commitment in it, and that is the only one of the 3 that forces the operator to state what the slice delivers.

The SLA clause is the news

When Vodafone launched quality on demand yesterday I wrote that the first thing a serious enterprise buyer would ask for was a service level, because a priority is not a reservation and a profile without published parameters tells the buyer nothing about what it is paying for. Telstra's answer is the proof-of-value engine. It does not publish the parameters either, at least not in what has been reported, but it commits to measuring the slice against what was promised and to not charging when the promise is missed. That is a commercially meaningful difference. It converts a best-effort improvement into a product with a defined failure condition, and it means Telstra is now generating, internally, a number no slicing launch to date has disclosed: how often a commercial slice fails to deliver what the customer bought. The pay-out rate of that engine is the honest measure of whether slicing works on a live network, and Telstra has built the instrument that produces it. Whether it will ever publish it is another matter, but the number now exists somewhere, which was not true of any of the other launches.

Application-aware means the operator picks the application

The product is sold for Teams, and only Teams. That is a practical choice, since Microsoft publishes the network endpoints its services use, which is what allows an operator to steer that traffic onto a slice without inspecting its content, and it is the application that a construction firm's site manager or a utility's field crew is most likely to be on. But it also shows where the operator's own control ends. Telstra decides which application qualifies, does the classification itself, and holds the only billing relationship. Microsoft is not a party to the arrangement, and the customer cannot extend the slice to another application without Telstra adding it. This is the same pattern that Fast Lane and the Vodafone API follow: the service is possible because it stays inside 1 administrative domain, with no counterparty to negotiate with and no shared model to agree. An enterprise that wants its own collaboration tool, its own robotics controller or its own agent to request the slice on demand, and to verify for itself that the promise was kept, is asking for the coordination layer that I argued no runtime supplies. The proof-of-value engine is a step toward it, because it is an audit trail, but it is Telstra's audit trail, read by Telstra, and the customer sees only the invoice it produces.

When Will We See Slicing as a Service?

I have been arguing for years that the natural fulfillment of the differentiated connectivity 5G promise would be slicing as a service. Specifically, network operators who will find themselves with ample capacity should create a platform that would allow third party to discover, configure, reserve and consume network resources on demand. Enterprise and government CIOs know better than telecom operators what their connectivity needs are and how they are going to evolve. They do not want to select a pre packaged slice that my correspond to some conditions or services at some point in time. They do not want to spend time educating the operator about their needs, because some of them are proprietary and become differentiating factors and they evolve over time. They are used to configuring cloud services. It is time for connectivity services to catch up.

Vodafone Launches Quality on Demand API in Germany

noreply@blogger.com (Patrick Lopez) — Tue, 08 Sep 2026 06:00:00 +0000

Vodafone announced on 7 September that its Quality on Demand network API is commercially available in Germany, the first market to get it, with more countries to follow. Light Reading's Tereza Krásová and Telecoms.com's Andrew Wooden both carried the release the same day. The API lets a business or developer select a predefined profile with specific network parameters for a customer's connection over Vodafone's 4G and 5G networks, and the release says the customer can choose the bandwidth level they need for as long as they need it. The example given is a payment provider whose card terminals keep processing transactions in a crowded stadium, concert or festival. Vodafone says it is running a proof of concept with a German broadcaster, not named, covering a football match with push-to-talk between production crew and return video over the mobile network, and it invites developers to propose applications in entertainment, transport, emergency response and remote maintenance. Johanna Wood, Vodafone's director of network APIs, said people use their phones for shopping, banking, public services and entertainment "around ten times a day" and that the API lets businesses "tailor network quality dynamically for specific use cases." The release places the launch inside the GSMA Open Gateway programme Vodafone joined in 2024, says the API follows a common industry standard so customers can scale it worldwide, and positions it alongside Vodafone's SIM Swap and Number Verify APIs, dedicated 5G slices and private networks. Telecoms.com notes that Number Verify 2.0 launched in Germany, the Netherlands and the UK in July. No price was published.

This is the launch the Open Gateway programme was built around

When EE put a consumer network slice on sale last month, I listed as 1 of 4 things to watch whether the same capability would show up as a priced quality-on-demand API through Open Gateway. 17 days later it has shown up, without a price. That is still a milestone. Quality on demand was the API the whole programme was designed to showcase, the one that would prove a network could sell a differentiated attribute to a developer rather than a bigger data bucket to a subscriber, and it has been the slowest of the 4 headline APIs to reach commercial availability anywhere. The APIs that did ship first were single-attribute lookups, number verification, SIM swap, location, the class I argued at DTW Ignite was the class that ships because it asks the network a question rather than asking it to change its behaviour. A group operator making quality on demand generally available in its largest European market moves the harder API into the same category, and that should be recorded before the rest. It is consistent with the position I set out in July, that network APIs are the earliest-stage of the credible new revenue lines, worth investing in for position while sizing near-term revenue with restraint.

The buyer is a payment provider whose customers are on 3 networks

The structural difference from EE's Fast Lane is who is paying. EE sells the attribute to its own subscriber, through a tariff, and the subscriber is on EE by definition. Vodafone sells it to a third party, and the third party's end users are spread across Vodafone, Telekom and O2 in roughly the proportions of the German market. A card-terminal vendor at a stadium can buy uninterrupted payments only for the share of its terminals, or its customers' phones, that happen to be on Vodafone. For the developer, the API is worth Vodafone's market share until somebody aggregates it, and the release addresses that by saying the API follows a common standard and so scales worldwide. A common interface is not a common network. The standard makes the developer's call portable; it does not make the other 2 German operators answer it, and the aggregation layer the operators created for exactly this purpose is not mentioned in the release. The developer proposition for quality on demand in Germany is therefore still a partial one, and the launch is best read as Vodafone establishing its own endpoint ahead of whatever the 3 operators eventually offer together.

4G and 5G tells you what the product is

Fast Lane runs on EE's 5G standalone core and moves the customer onto a dedicated slice. Vodafone's API works over 4G and 5G, which means it is not a slice. It is a policy applied to the session, a prioritised bearer with a profile attached, of the kind mobile networks have been able to set for years and have rarely exposed to anyone outside the operator. That is why it can launch nationally now rather than waiting for standalone coverage, and it is also why the release describes the result as stable and high-performing rather than as a number. A priority is not a reservation. It improves the customer's position in the queue on a congested cell; it does not guarantee what comes out of the queue, and the profile parameters that would let a buyer know what it is paying for are not published. VodafoneThree's SuperMobile slice in the UK, launched last week, attached a published minimum speed to its consumer product. The German API, sold to businesses that will build service commitments of their own on top of it, has not yet done the same, and that is the first thing a serious enterprise buyer will ask for.

It ships because it stays inside 1 estate

The pattern from Fast Lane holds here in a different form. Quality on demand as launched is a bounded request inside a single administrative domain: 1 operator, 1 profile, 1 session, 1 billing relationship with the developer. No counterparty negotiates the profile, no ontology has to be agreed across an ownership boundary, and no audit trail has to be accepted by 2 parties. That is the class of capability I argued no runtime supplies the coordination for and that therefore ships only when the coordination is not needed. The question the API opens, and does not answer, is what happens when the buyer is not a developer but a system: a checkout agent, a delivery routing engine, a broadcaster's production controller deciding per session whether a given profile is worth its price against a given cell load. At that point the network's AI and the customer's AI are negotiating a resource across a boundary, and the API gives them a verb without giving them a shared model of what the verb commits either side to. Vodafone's release does not address that case, and it is the case its enterprise customers will bring first.

What has not been published

No price, no pricing unit, no profile parameters, no service level or remedy, no named paying customer, no statement of what the profile delivers on a cell that is already saturated, which is the only condition under which the product matters, and no volume figure from the July Number Verify launch that would indicate what developer uptake of Vodafone's APIs looks like. The broadcaster proof of concept is unnamed and uncosted. 4 things to watch. First, a price list, because the moment quality on demand has a published unit price it becomes possible to compare the developer channel against the tariff channel EE chose. Second, whether the 3 German operators offer a single quality on demand call, through the aggregator or bilaterally, since that is the point at which the payment provider's business case stops being a fraction. Third, the first named enterprise customer with a transaction volume, which would be the first demand-side evidence for the API the programme was built around. Fourth, whether Vodafone Germany also sells the same profile to consumers as a tariff, because an operator that does both is telling the market which channel it thinks the capability belongs in.

TelecomTV Publishes First AI-Native Telco Index

noreply@blogger.com (Patrick Lopez) — Mon, 07 Sep 2026 19:07:45 +0000

TelecomTV published its first AI-Native Telco Index on 7 September, the day before its AI-Native Telco Forum opens in Düsseldorf. Ray Le Maistre's article describes a 276-page report assessing 56 operators against 4 dimensions, foundation readiness, strategic intent, execution evidence and transformation velocity, each made up of 5 indicators, using published evidence only, with a cut-off of 30 June 2026. The index assigns each operator 1 of 7 archetypes rather than a rank; the decision not to publish a league table was taken with the ANTA steering board, whose members come from Axiata, Deutsche Telekom, Orange, NTT Docomo and Rakuten Mobile. 9 operators are placed in the top archetype, AI Vanguard: AT&T, China Mobile, Deutsche Telekom, KDDI, NTT and NTT Docomo, Rakuten Mobile, SoftBank Corp, Telefónica and Verizon. 5 are Infrastructure Architects, 15 are Strategic Accelerators and 1 is at Transformation Pending. The stated rule is that "announce does not mean executed": a commitment is recorded as a commitment, and a deployment is recorded only where the operator has published something showing it is running. SK Telecom, which the article notes is often named the leading AI-native operator, is a Strategic Accelerator because many of its efforts were still at the planning stage at the end of June. A 12-page executive summary is free; the full index is available to ANTA partners and licence holders. This post works from TelecomTV's article; neither the summary nor the full report was read for it.

Most assessments of operator AI progress, including most vendor-sponsored surveys, score intent: budgets planned, priorities ranked, use cases identified. This index scores what has been published as running, and it records an announcement as an announcement. That is the distinction between field-validated and commercially validated that AI-RAN claims have needed for 2 years, applied here across the whole operator estate, and the SK Telecom result shows the rule working. An operator with a clear strategy, disclosed investment, revenue already generated and a large revenue target still lands below the top tier because its published evidence at the cut-off described plans rather than operations. Producing that result about the operator most often cited as the leader, in a report whose steering board includes 5 operators, is a sign the methodology was allowed to run.

No financial dimension yet

The 4 dimensions measure readiness, intent, execution and speed. None measures return. An operator reaches AI Vanguard by publishing the most evidence that AI systems are in production across its operations, and that is a real achievement, but it is the same class of evidence as the customer-experience award that TM Forum gave Google Fiber last week: proof that it works, not proof of what it is worth. The index is explicit that it measures transformation progress and not who is better, and that framing is useful, because it means nobody should read the Vanguard list as the operators making money from AI. I argued in July that most of what operators call AI monetization is cost avoidance, and that the discipline starts with refusing to aggregate cost saving, defended revenue and new revenue; an index that counts deployments without asking which of the 3 flows each one serves cannot make that separation either. The industry now has a reliable way to count deployments. It does not yet have a published operating cost per subscriber, per activation or per ticket, before and after, from any of the 9, and until one of them publishes that figure the index measures the input side of a business case whose output side remains an estimate.

Because the method admits only what an operator has published, an operator that publishes more scores higher, other things being equal. 4 of the 9 Vanguard operators are Japanese, 2 are American, 1 is Chinese and 2 are European, and 2 of the 9, NTT Docomo and Rakuten Mobile, sit on the steering board that shaped the method. The article says archetype assignment is an editorial judgement based on the evidence analysed, and there is no reason to doubt that. The point is narrower: operators with a corporate habit of publishing technical detail, and operators for whom the network is a marketing asset, will be over-represented at the top of any evidence-based index, and operators that run production AI quietly will be under-represented. The index cannot correct for that without abandoning its rule, and it should not abandon its rule. The caveat applies to every evidence-based index, this one included.

Everything the index can see is inside 1 operator's estate: its data foundations, its stated strategy, its deployments, its pace. That is the version of autonomy that ships, and it is where the evidence should be collected first. The next stage, in which an operator's network AI has to coordinate with an enterprise AI, a cloud provider's AI or another operator's AI, produces almost no published evidence yet, because the coordination layer that would make it work is the one I argued no runtime supplies and that NGMN has since itemised even for coordination inside a single operator. An index built on published deployments will show that stage as empty for some time, and the absence will be accurate. A future edition could usefully add an indicator for it: whether the operator has published any interface, ontology or audit model through which an external agent can act on its network, since the developer APIs alone do not answer that question.

What has not been published

The per-operator scores, the weighting of the 20 indicators, the definition of "running" used for execution evidence, and whether any indicator captures financial disclosure are all in the licensed report and not in the article. The 56-operator list is published; the archetype of each operator outside the 3 named tiers is not. 3 things to watch. First, whether the 2027 edition adds a return dimension, or an indicator for published cost or revenue attributable to AI, which would be the single most useful change to the method. Second, whether any of the 9 Vanguard operators publishes an operating cost figure for an automated domain against its pre-automation baseline in the next 12 months, since they are now on record as the operators with the most to show. Third, where SK Telecom lands next year: the article expects it to be among the strongest profiles, and if the planned efforts have become published deployments by then, the index will have shown it can measure movement and not only position.

Ericsson Says the Telco Edge Was Too Early

noreply@blogger.com (Patrick Lopez) — Sun, 23 Aug 2026 15:06:31 +0000

Ericsson has put a name to the failure of the last edge computing cycle. Joe Constantine, the company's Americas chief strategy and technology officer, told Fierce Network in a piece published by Diana Goovaerts on 21 August that mobile edge computing was early rather than wrong, and his summary of what went wrong is short. "Ten years ago, MEC was a supply side concept." What has changed, in his account, is that a demand driver has arrived. "We have AI inferencing. It's the growth opportunity, an application that MEC did not have at the time. So, if you look at this, we believe that the industry, the technology and the market is vastly different today from 10 years ago." He supports the traffic case with Ericsson's own forecasts, that global mobile traffic will triple between 2023 and 2029 with AI as the key driver, and that uplink traffic will grow 10 times by 2035. He argues the network has changed too, from best effort connectivity to 5G built for time-critical communication and capable of 15 millisecond latency and "five nines of reliability." Fierce notes in the same piece that TM Forum's chief executive has told it that operators should not bet the farm on the edge.

The diagnosis is correct and it is unusual to hear it from a vendor

Supply side concept is the right post-mortem, and it is the shortest accurate description of that decade anyone has offered on the record. Operators built edge capacity because they had property, power and a latency story, then went looking for someone who wanted it. The platforms worked. The buyers did not appear. When I wrote about a fully programmable multi-access edge platform in November 2018, the services I could name were faster file uploads, console games without a console, and editing a document without downloading it. Those were real improvements to existing experiences. None of them was a business that an enterprise procurement department was going to sign for. Inference is a materially better answer than that, because it is a workload with a measurable cost that somebody is already paying somewhere else. That is a genuine change in the argument and it should be credited before anything else is said about it.

15 milliseconds is a central office number

The interesting discipline in Constantine's case is that his own numbers settle the location question, and they settle it away from the radio. A 15 millisecond budget is a loose one. It is comfortably met from a metro exchange or a mobile switching office serving hundreds of sites, and it does not require compute at the tower. That matters because the edge conversation still routinely conflates two very different capital programmes. Putting accelerators in a few hundred central offices is a brownfield project on estate that is already zoned, powered, cooled, fibred and physically secured. Putting them at tens of thousands of cell sites is a different business with a different power bill, a different maintenance model and a different landlord. I have argued on the AI Grid that deployment starts at central offices and mobile switching offices for exactly these reasons, and the 2018 platform was built into the central office for the same ones. Nothing in the Ericsson case contradicts that. If 15 milliseconds is the requirement, the requirement is an exchange.

The economic claim is asserted rather than costed

"Routing all this traffic to a centralized cloud isn't just only slow, it's economically not even sustainable" is the load-bearing sentence of the whole argument, and it arrives without a number attached. There is no published cost per inference at a telco edge site set against the same inference in a hyperscale region, at comparable utilisation, including the operator's power, cooling, refresh and remote-hands costs. Until that comparison exists, the economic case for distribution rests on the intuition that moving bits is expensive and moving them less must therefore be cheaper. That intuition ignores utilisation, which is what actually decides the economics of accelerators. A central region runs its fleet hot across many customers and time zones. A metro edge site runs a smaller fleet against local demand that peaks and troughs. The traffic forecasts are also Ericsson's own, published in its Mobility Report, and a 10 times uplink projection reaching to 2035 is a forecast rather than an observation. It should be read as one.

Physical AI names a use case, not a counterparty

Asked what actually requires the edge, Constantine points to robotics and physical AI. "Any system that moves, so drones, vehicles, humanoids, robots talking to other robots, all these will become an autonomous system that needs a network to think with it." His example is an autonomous car whose onboard sensors can see what is in front of it but not around the corner, with network sensing supplying the rest. The technical case is sound. The commercial case has the same shape as the one that failed. A drone fleet, a warehouse robot estate and a vehicle platform are owned by companies that are not the operator, and the thing being sold to them is not raw compute, which they can buy cheaper elsewhere, but contextual awareness that the network holds and they do not.

Selling that is a coordination problem before it is a latency problem. Robots talking to other robots across an ownership boundary need an agreed model of what is being asserted, whose authority stands behind it, and what record both sides will accept afterwards. That is the gap I argued no runtime supplies, and that NGMN has now enumerated at length for coordination inside a single operator's own domains, which is the easier version of the same problem. An operator can install the accelerators in its exchanges this year. It cannot unilaterally produce the model that lets a vehicle manufacturer's autonomy stack trust and pay for what the network says about the road. The compute is the part of this that money can buy quickly, which is why it is the part vendors describe in detail.

What to watch

3 things. First, where the accelerators physically land. If operator edge AI deployments in the next 18 months are announced at central offices and metro sites, the location argument is settled and the cell site edge can be retired from the conversation. Second, a published cost per inference or cost per token at a telco edge site against a hyperscale baseline, from anybody, on the record. That single figure decides whether distributed inference is an economic position or a latency preference. Third, the first contract in which an enterprise pays an operator for network context rather than for compute or connectivity, because that is the class of deal the 2010s never produced and it is the only one that would show the demand side has actually changed.

EE Launches First Priority Consumer Network Slice

noreply@blogger.com (Patrick Lopez) — Fri, 21 Aug 2026 13:46:01 +0000

EE launched a service called Fast Lane on 20 August, and Telecoms.com reported it as the UK's first commercial network slice sold to consumers and small businesses. The mechanism is simple. When congestion is expected, the customer is moved onto a dedicated slice of EE's 5G standalone network, which the operator brands 5G+. The scenarios EE names are rush hour, major events, live streaming from a sold-out gig, taking card payments at a festival, joining a video call while travelling. Claire Gillies, chief executive of BT's Consumer Division, called it "the UK's first commercial network slice to deliver meaningful benefits to both consumers and businesses." EE says 5G+ now reaches around 54 million people, 78% of the UK population, with a plan to reach 99% by the end of March 2030, as part of a £40 billion investment programme. Fast Lane is sold only through a premium handset plan, not as a standalone or SIM-only option.

I want to start by emphasizing the innovative aspect. This is a real new revenue line. It is not a framework paper, it is not a pilot inside one operator's walls described as a capability across everyone's. Somebody is going to pay money to EE for a network attribute, and after 8 years of the slicing conversation producing conference sessions instead of invoices, that deserves to be said plainly. It is also the first time I can recall a British operator putting a retail price on differentiated network quality rather than on a bigger bucket of gigabytes. That is a category change and it is worth taking seriously.

The product is priced on scarcity, and the scarcity is the operator's own congestion

Now the rationale. Fast Lane sells preferential treatment at a congested cell. The value of the product is a direct function of how congested that cell is. Telecoms.com raised the obvious question, whether consumer slicing gives operators a reason to slow densification, and then answered it fairly by pointing at EE's own build plan, which is running hard from 78% coverage toward 99% and is backed by a £40 billion commitment. I do not think EE is withholding capacity. But the accounting point survives the good intentions. Willingness to pay for Fast Lane is highest exactly where the network performs worst, and it falls as the build succeeds. That is not a scaling revenue line. It is a harvest on a constraint, and the constraint is one the operator has publicly promised to remove.

A congestion-priced lane is a legitimate thing to sell and a bad thing to extrapolate. If I were modelling this, I would treat the addressable moments as a fixed and slowly shrinking pool: the stadium, the festival, the commuter peak, the trade show. Those are real, they recur, and they do not compound. The number to watch is not the launch, it is whether the attach rate holds in year 3 in the places where 5G+ has since been densified. That number is the only one that would tell you whether this is a product or a symptom.

Quality on demand shipped as a tariff because a tariff needs no shared model

Here is the part I find genuinely instructive, and it lands on an argument I have been making for a year. Quality on demand is 1 of the 4 showcase network APIs the GSMA has put at the centre of Open Gateway, alongside device location verification, SIM swap detection and number authentication. The industry has spent 3 years and roughly 300 mobile networks trying to sell that capability to developers through an interface, and this month the answer to why it has not converted arrived in the form of a systems integrator joining the programme. Meanwhile EE is selling the same underlying capability to a consumer, through a handset tariff, and it works.

The reason is the one I set out when I argued at DTW Ignite that the API is not enough. Fast Lane requires no shared model with anybody. One operator, one subscriber, one radio, one contract, one billing relationship. There is no counterparty to negotiate with, no ontology to agree, no authority delegated across a boundary the operator does not own, and no audit trail that two parties both have to accept. It is a unilateral act inside a single administrative domain, which is precisely the class of capability that ships. The Open Gateway APIs that shipped are all in that same class, single-attribute lookups and bounded requests inside one operator's estate, and I have argued that is part of why they are worth what they are worth. EE has just proved the rule from the other direction. Take the exact same network function, strip out the requirement to coordinate with an external party, and it goes to market in a quarter rather than a decade.

That could be read as a warning. The capabilities that clear the boundary problem are the ones an operator can sell to its own subscriber. Everything on the other side of the boundary, the enterprise AI negotiating a service level with a network AI, the slice provisioned and assured across two estates, still needs the meta-model of topology, ontology, authority, state and audit that I argued no runtime supplies and that NGMN has now enumerated at length. Fast Lane does not advance that work. It circumvents it.

Selling it only with a handset tells you what EE thinks it has

The packaging is the tell, and it is the detail I would push hardest on. Fast Lane is available only on a premium handset plan. Telecoms.com flagged that this may hamper uptake, which is true, but the more interesting reading is what it says about internal conviction. If you believe you have built a network capability, you sell it as an attribute of the connection, on any SIM, at a price, and you let the market tell you what it is worth. If you believe you have built a retention lever, you bolt it onto the highest-value handset tier where it defends an existing margin and never has to survive a standalone price test. EE has chosen the second. That is a rational commercial decision and it is also an admission that the capability is not yet trusted to stand on its own.

What to watch

4 things. First, whether EE ever offers Fast Lane SIM-only. The day it does, the company believes it has a network product; until then it has a device upsell with a network feature attached. Second, whether any operator anywhere publishes an attach rate or an ARPU delta for consumer slicing, because the launch is easy and the second year is the evidence. Third, whether the same capability shows up as a priced quality-on-demand API through Open Gateway at a comparable value, which would be the first real read on whether the boundary tax is worth what I think it is worth. Fourth, whether a lane sold on congestion sits comfortably inside the UK's net neutrality framework once it has scale rather than novelty. I am not going to declare a verdict on that one, and I would be surprised if nobody asks the question.

The industry has spent 8 years promising that slicing would let operators sell different connectivity products rather than by the gigabyte. The first commercial consumer version in Britain sells one attribute, at specific times, bundled with a phone. That is progress, and it is a fraction of the size of the story that was told to justify 5G standalone.

NGMN Confirms Agentic AI Needs Improvements

noreply@blogger.com (Patrick Lopez) — Wed, 19 Aug 2026 16:47:05 +0000

The Next Generation Mobile Networks Alliance published a report on 12 August, "Network Automation and Autonomy Phase III: Agentic AI for Autonomous Mobile Networks," and it reads like a standards body catching up to an argument I have been making for a year. The headline finding, reported by Keith Dyer at The Mobile Network, is that the industry has to solve interoperability, security, governance and data before agentic AI can deliver autonomous networks at commercial scale. The detail underneath the headline is what matters. NGMN says the current ecosystem is too fragmented for agents to form a consistent understanding of the network, because vendors use different data models and different terminology, and it calls for common information models, ontologies and semantic mappings, aligned across 3GPP, TM Forum, ETSI, O-RAN, IETF, W3C and BBF. It asks for a telecom-grade Zero-Trust Agent Ecosystem with secure agent identity, authentication, authorisation, policy enforcement, audit logging, runtime monitoring, and the ability to revoke or quarantine an agent. Read that list again. Topology, ontology, authority boundaries, state, audit trails. That is the meta-model of the agentic plane, and it is now in a report with an operator alliance's name on the cover.

I want to be precise about the provenance here, because the sequence is the point. I argued at DTW Ignite that the API is not enough, that the interfaces we built for developer access were never designed to let an autonomous agent understand what it is acting on. I argued a few weeks later that the agent runtime is not the agent model, that a place to execute an agent and put guardrails around it supplies none of the topology, ontology, authority and audit that coordination between agents actually needs. NGMN has now enumerated eight cross-organisation challenge areas, and they map almost one for one onto that case. Lack of standards for agent knowledge and context sharing. Incomplete information modelling for networks. Lack of end-to-end security, identity and trust for autonomous functions. Lack of operator-friendly governance and lifecycle tools. Under-addressed economic and organisational readiness. When a body chaired by Orange's group CTO writes the same list I published, the argument stops being a contrarian read and becomes the consensus. That is a good day for the thesis. It is a better day to point out the part the report does not solve.

The report describes coordination inside a boundary the operator owns

Look closely at the architecture NGMN proposes. A supervisory agent coordinates specialist agents, one each for RAN, core, transport, cloud and security, to diagnose a service problem, weigh corrective actions, resolve conflicts, and verify that service was restored. The worked examples are fault management, service assurance and RAN optimisation. In the RAN case, a cross-domain agent delegates intent to a RAN optimisation agent, which supervises a sub-agent in the infrastructure layer, and when an optimisation action collides with network-wide energy management the cross-domain agent arbitrates the trade-off. This is a serious and correct piece of engineering. It is also, in every example, coordination across domains that a single operator owns. RAN, core, transport, cloud and security are five administrative domains inside one company's walls. The hard thing NGMN is describing is getting an operator's own silos, built by different vendors with different data models, to hand each other a shared and trustworthy understanding of state. That is worth doing, and it is exactly why a runtime and a set of guardrails were never going to be enough. But it is one owner reconciling with itself.

The problem I have been pointing at sits one boundary further out, and NGMN's own scope is the clearest evidence that it is a distinct and harder problem. When an enterprise's AI wants to negotiate with an operator's network AI, for a service level, a slice, a capacity commitment, a remediation, there is no shared owner to impose a common ontology, no single authority to issue the identities, and no single audit log that both parties will accept as the record of what was agreed and who was answerable. Everything NGMN specifies, the semantic alignment, the zero-trust identities, the audit trail, is defined for agents operating within the operator's estate. Across an ownership boundary, the same requirements do not disappear. They get harder, because now two parties have to agree on the model before either can trust an action, and neither controls the other. NGMN has validated that the meta-model is necessary. It has not, and by its own framing could not, close the gap where the two hardest words in this whole subject live, which are coordination and accountability between parties who do not report to the same CTO.

Containment, coordination, accountability, in that order of difficulty

It is worth keeping the three layers separate, because vendors and now standards bodies keep collapsing them. Containment is the Zero-Trust Agent Ecosystem: the identity, the authorisation, the runtime monitoring, the kill switch that lets you revoke or quarantine an agent inside your own network. That is genuinely useful and NGMN is right to specify it in detail. Coordination is the shared ontology and semantic mapping that lets one agent understand what another agent is doing, and this is the layer NGMN is now trying to build across an operator's internal domains. Accountability is the ability to produce, on demand, the identity of an agent, the authority under which it acted, and a trail that a regulator and an outside counterparty would both sign, across a boundary you do not own. The industry has spent a year shipping the first layer and calling it the third. NGMN has now, to its credit, put real weight on the second. The third is still open, and it is the one I argued the EU AI Act made expensive when its enforcement powers switched on at the start of this month, because enforcement does not stop at the edge of your administrative domain.

There is a discipline point here that operators should not lose in the enthusiasm of seeing a favourite thesis ratified. NGMN itself flags it: "While technology groups focus on architecture, few have formal guidance on the required telco organisational changes," and it lists economic and organisational readiness as an under-addressed challenge in its own right. The meta-model is not a product you procure. It is a set of agreements about topology, ontology, authority and audit that has to be built and then adopted, and the report's call for alignment across seven standards organisations is a fair description of how long that takes. Cross-SDO harmonisation of information models is measured in years, not quarters. When I helped set network autonomy targets in operator programmes, the technology was rarely the thing that slipped. The organisational change and the cross-domain agreements were. Anyone booking autonomous-network savings against a framework paper rather than a ratified model is doing the same thing I warn against when vendors stack their individual efficiency claims into a total no network has ever achieved. Read this report as the industry agreeing on the destination. Do not read it as arrival.

What to watch

The honest test has not changed, and NGMN has now made it a formal requirement rather than a personal opinion. For any action an agent takes on its own, can you produce its identity, the authority under which it acted, and an audit trail that both a regulator and an outside counterparty would accept. If the answer lives entirely inside one vendor's runtime, you have containment and you should not mistake it for accountability. NGMN has described the plane the runtime runs on, in more detail than anyone in the industry has committed to print, and it has correctly located the work in standards and organisation rather than in any single box. The next phase belongs to whoever builds the ontology and the identity fabric that hold up not just across an operator's own domains, but across the boundary to the enterprise on the other side of the negotiation. That boundary is where the value is, and it is the one the report stops at. Watch for whether the alignment NGMN asks for actually happens across those seven bodies, and watch, as always, for a pilot inside one operator's walls being described as autonomy across everyone's.

Agentic AI: Autonomous Agents Governance and Enforcement

noreply@blogger.com (Patrick Lopez) — Mon, 03 Aug 2026 14:26:48 +0000

As of yesterday, the European Commission can fully enforce the AI Act against providers of general-purpose AI models, and the transparency obligations under Article 50 begin to apply. The obligations themselves have been in force for a year. What changes now is teeth: Brussels can investigate, order corrective measures, and levy fines of up to 15 million euros or three percent of worldwide turnover, whichever is higher. Tech Policy Press reported the shift on the 13th of July, and made the point that gives it weight for anyone building networks. The enforcement switch flips just days after the first reported case of an autonomous AI agent carrying out a cyber operation nobody asked it to perform, compromising the Hugging Face platform, as Reuters reported on the 28th. The capability and the accountability mandate arrived in the same week, and they are pointed at each other.

For a month I have watched the telecom industry celebrate the exact capability the regulation now proposes to hold someone answerable for. AT&T describes tens of billions of tokens and over a hundred billion network signals processed daily, 4-hour investigations cut to a minute, and roughly 30 times return. TM Forum reports the sector crossing into Level 4 autonomous networks. Vendors are shipping the agentic NOC and the self-healing network. The good news and the governance problem are the same sentence. Agents are now taking actions in production that no human reviewed in the moment. That is the point of them. It is also the point at which a regulator asks who is answerable.

Enforcement is not an abstraction. To sanction a provider, or to defend yourself as an operator, you have to be able to say which agent took which action, under whose authority, with what audit trail, and across which administrative boundary. In a telecom network that last clause is the hard one. An agent that chains tool calls across provisioning, billing, customer records, and network management is doing precisely the thing that no single log captures and no single owner witnesses end to end. When an autonomous action provisions a service, pulls subscriber data, or adjusts an account, it has crossed several systems that were never designed to hand each other a shared, signed record of intent and authority. The action happened. Reconstructing who owned it is the part that does not exist yet.

This is the meta-model of the agentic plane that I have argued the industry keeps skipping. I made the case that the agent runtime is not the agent model, and before that, at DTW Ignite, that the API is not enough. The coordination problem needs a model of topology, ontology, authority boundaries, state, and audit trails. A runtime supplies none of those across a boundary. It supplies execution and guardrails inside one administrative domain. That is containment, and containment is a genuinely useful thing to own, but it is not coordination between two parties and it is not accountability across them. The regulation just made the distinction expensive.

Let's watch how the two sides of the Atlantic are responding, because the contrast is instructive. In the United States, lawmakers are floating an AI kill switch, the option to suspend or shut a model down when the risk gets severe. A kill switch answers one question well: can I stop it. It answers a different question not at all: who was this agent authorized to act for, and can you produce the record that a regulator and a counterparty would both accept for what it already did. Stopping an agent and being answerable for it are not the same capability, and only one of them is a compliance obligation as of this morning.

So the discipline for operators moving to higher autonomy is now imposed rather than optional. Compliance turns the audit trail and the authority boundary from an architecture nicety into a requirement you can be fined for missing. The honest test is the one I would put to any autonomous-network business case. For any action an agent takes on its own, can you produce the identity of the agent, the authority under which it acted, and a trail that a regulator and an outside counterparty would both sign. If that record lives entirely inside one vendor's runtime, you have containment, and you should not mistake it for accountability. Deloitte's 2026 enterprise survey found only about 1 organization in 5 reports a mature model for governing autonomous agents. The regulator did not wait for the other four.

The agents learned to act this summer. Today the law asked who authorized it. The operators who will be interesting in this next phase are not the ones with the most agents in production. They are the ones who can answer that question about any one of them, on demand, across a boundary they do not own. That answer is not a feature of a runtime. It is the plane the runtime runs on, and the industry has been shipping the second while promising the first.

The Price Of RAN Security In Europe: 40B Euros... And More

noreply@blogger.com (Patrick Lopez) — Tue, 28 Jul 2026 12:59:35 +0000

Seven of Europe's largest operators commissioned GSMA Intelligence to price the removal of designated high-risk vendors from their networks, and the number came back this week. Under the European Commission's proposed Cybersecurity Act 2, stripping out equipment from suppliers such as Huawei would cost the region's operators between thirty and forty billion euros in direct costs, split across mobile at up to twenty two billion, fixed at around five billion, and transport at up to twelve billion. The figure that matters more, though, is the second one. GSMAi finds that the same measure would push mobile equipment prices up by roughly twenty four percent, because forcing designated vendors out of the market shrinks the field of suppliers, and a smaller field charges more. Deutsche Telekom, Fastweb plus Vodafone, Meo, Orange, Telefonica, United Group and Vodafone Group supplied the underlying data.

I have spent part of my career making the opposite bet. The entire economic premise of Open RAN, the work I led at Telefonica and have written about for years, is that opening the interfaces widens the supplier base, and a wider base drives the cost of the radio down. You can read my longer assessment of where that project actually stands on the state of Open RAN, but the direction of the argument was never in doubt: more suppliers, more competition, lower unit cost. What the Cybersecurity Act 2 proposal does is run that logic in reverse. It removes suppliers, it narrows competition, and the price goes up. The twenty four percent is not a side effect anyone chose. It is arithmetic. You cannot both mandate a smaller supplier pool and expect the survivors to hold their prices.

What makes this more than a European regulatory footnote is where it occurs. It lands on top of a repricing that is already under way for an entirely different reason. I have been arguing for some weeks that the AI build-out is bidding up the exact components a modern radio depends on, high bandwidth memory, advanced substrates, power semiconductors, because AI factories and the RAN supply chain now compete for the same silicon. The consequence I keep pointing to is that even an operator which never buys a single GPU still pays more for its radios, because the AI boom has repriced the inputs. Now set the GSMAi finding beside that. You have two independent forces, one driven by AI demand and one driven by security regulation, both pushing the unit cost of the radio in the same direction, at the precise moment operators are being told to find capital for AI.

Beware of stacked figures though, so let me be precise. Do not add the two numbers. The forty billion is a one-time direct cost of replacement. The twenty four percent is a forward price trajectory on new equipment. They measure different things over different horizons, and stacking them produces a headline number no operator will ever see on an invoice, which is the same error I flag when vendors add their individual RAN energy savings into a total no network has ever achieved. The direction is clear, though.The radio is getting more expensive from two sides at once, and only one of those sides is optional.

This sharpens a position I have held on the location question. If the radio is being repriced upward by both AI demand and regulation, the case for distributing expensive compute out to every cell site gets weaker, not stronger. Costly, repriced silicon is exactly the kind of asset you concentrate where you can amortise it, at the central office and the switching centre, not the kind you scatter across tens of thousands of sites on the promise of a latency budget that most workloads do not need. I made that argument on its own terms when I wrote that operators are leaning in on AI Grid location and set out the fabric versus location considerations underneath it. The cost side now reinforces the physics side. Scarcity concentrates capital.

There is a monetisation discipline here as well, and it is the one I set out when I argued for separating revenue from cost avoidance. High-risk vendor removal is not a modernisation and it is not a growth programme. It is a defensive cost, imposed from outside, that produces no new revenue line and buys no new capability. An operator can, of course, use a forced swap-out as the occasion to modernise, and some will. But the spend itself belongs on the cost side of the ledger, named honestly, and not folded into an AI or transformation story where it does not belong. The moment a swap-out driven by security regulation starts appearing in a slide about AI readiness, someone has mixed the flows again.

At last, this is RAN. While going forward these elements will become more programmatic, it is still unclear whether a 2G, 3G or 4G radio from a high risk vendor actually represents a security risk. The highest compromise risk is in the Core, the OSS and ancillary systems. It is easier to install IMEI catchers and antenna spoofs than to hack into a deployed live system.

Europe may well decide the security case is worth forty billion euros. That is a legitimate political choice. What the choice is not is free, and it is not neutral for competition. A framework designed to reduce dependence on one class of vendor achieves it by reducing dependence on vendors generally, which is to say by making the market smaller and the equipment dearer. Operators should book that outcome for exactly what it is: a defensive, imposed, largely non-recoverable cost, landing on an equipment line that the AI build-out was already repricing without any help from regulators. It is certainly not random that the leading RAN vendors are predominantly europeans, with emerging Korean and Japanese options.

The political decision would transfer value from networks to vendors. It is unclear whether that is sustainable if the pool of vendors does not increase substantially.

Verizon Earning: From Copper to Fibre to Edge

noreply@blogger.com (Patrick Lopez) — Mon, 27 Jul 2026 12:00:00 +0000

Verizon disclosed on its second quarter earnings call last week a dark fibre agreement with Google worth well in excess of a billion dollars, and chief executive Dan Schulman was explicit that it is the first of several, with further deals expected by year end worth multiple billions of dollars in revenue over the coming years. The headlines went to the number and to the counterparty. The more instructive detail came later in the same call, where Schulman described retrofitting thousands of central offices, the copper now being decommissioned, into edge data centres for low latency AI inferencing. One operator, one earnings call, two of the arguments I have been making all month, and they are not the same argument.

Let's start with the fibre. This is not cost avoidance dressed as growth, which is the trap I wrote about when Google Cloud called agentic AI a sixty billion dollar opportunity and every figure underneath the headline turned out to be a saved operating cost. It is also not the speculative new revenue that strategy decks reach for. It is my second money flow, AI creating fresh demand for what the operator already sells, landed on the income statement as contracted revenue. Schulman called it incremental, long duration, high quality, and drawn from some of the most demanding infrastructure customers in the world. He is right to be pleased. Route and real estate are exactly the assets an operator holds that a hyperscaler cannot conjure at will, and the AI build out is short of both.

Now look at what Verizon actually sold. Dark fibre is unlit glass. Google puts its own optics on each end, chooses its own wavelengths, runs its own capacity, and owns everything above the physical layer. Verizon is the landlord of the route and nothing more. On the capacity, platform, outcome ladder I set out two weeks ago, this is not even rung one, it is the ground the ladder stands on. That is not a criticism. A contracted, long duration, low churn landlord business against demand this strong is a genuinely good thing to own, and it is more defensible than most of what operators like to call platforms. The discipline is only this: name it correctly. The moment next year's deck describes a dark fibre lease as an AI platform business, the margin expectation that travels with the word platform will arrive, and a landlord business will not carry it.

The central office retrofit is the disclosure I want to emphasize. For two years I have argued that AI grid compute belongs first at the central office and the mobile switching office, not at the cell site, because power, cooling, fibre, real estate and security all favour the building the operator already runs. I made the fabric versus location case in early July and watched operators lean into central office siting a few days later. Verizon has now put capital behind it on an earnings call. The copper decommission is what makes it work: retiring the old plant frees the floor space and, more importantly, the power feed and the fibre entrance, which are the two constraints that actually bind at an inference site. I built what was probably the first fully programmable multi access edge platform at Telefonica in 2018, and the lesson from that programme was that the physics was never the obstacle. The obstacle was a paying tenant. Low latency inference is the tenant the central office was always waiting for.

The reason to read the two disclosures together is that they resolve a question people keep posing as a choice. Fabric or location, route or venue, is the AI grid a transport problem or a siting problem. Verizon's answer, in one call, is both, and the call even tells you which is which today. The fabric is the contracted revenue, available now, sold in its rawest form. The location is the capital project, the copper coming out and the racks going in, its revenue still ahead of it. An operator that understood only the first would sell glass to hyperscalers and miss the building. An operator that understood only the second would light up central offices with no anchor tenant, which is precisely the mistake the edge computing industry made for a decade. Verizon is doing both, and the sequencing is correct.

So I would put the deal through the same three questions I put to every operator AI business case. Which money flow is this. It is flow two, defended and grown connectivity revenue, honestly labelled, not flow three in disguise. What binding constraint does the buyer pay to remove. Google is paying for route diversity and a dedicated physical layer it controls end to end, away from shared congestion, which is a real constraint and an operator asset. And where does it sit on the ladder. Rung one for the fibre, with a credible path upward only if the central office retrofit becomes a platform the operator actually operates, rather than a colocation cage it merely rents to the same hyperscalers. The fibre deal is booked. The ladder question is still open, and it will be answered in the buildings, not on the routes.

I wrote a fortnight ago that the operators who will be interesting in 2030 are not the ones with the most GPUs but the ones who can still tell you which of the three flows each dollar came from. Verizon has just given the cleanest demonstration yet of the discipline: a fabric dollar and a location dollar, named separately, on the same call. The test now is whether it keeps them separate all the way up the ladder, or whether the word platform arrives before the platform does.

The Telco AI $60 Billion "Opportunity"

noreply@blogger.com (Patrick Lopez) — Wed, 22 Jul 2026 15:39:13 +0000

Google Cloud published a piece in RCR Wireless this morning arguing that agentic AI represents a sixty billion dollar opportunity for telecom operators. It is a well constructed argument, the engineering description is accurate, and the case studies are real. It is also, read carefully, an argument about cost avoidance wearing the vocabulary of growth. I want to be precise about this, because eight days ago I published a piece arguing that the industry's central discipline problem is its refusal to separate the two, and this article is the cleanest illustration of the problem I have seen since.

Start with the numbers. The sixty billion figure comes from Appledore Research, and Appledore is explicit about what it is measuring: operational cost savings by 2030. The McKinsey research cited alongside it reports a thirty to seventy percent reduction in troubleshooting tickets and a fifty five to ninety percent reduction in network operations centre costs. Deutsche Telekom's RAN Guardian identified 237,000 network events in early 2026 and compressed major incident handling from hours to about sixty seconds. Bell Canada's AI Ops platform achieved a twenty five percent reduction in customer reported issues and a faster mean time to repair. Vodafone's agents protect millions in annual operating expenditure. Every one of those is a genuine achievement. Not one of them is revenue. The article's own evidence base is, without exception, my first money flow: AI that reduces cost, which I described as real, happening, the largest near term financial impact of AI on operators, and emphatically not a new line of business.

The word doing the concealing is "opportunity". An opportunity, in the way a board hears it, is something you invest in to get money back that you were not getting before. A cost saving is something you invest in to stop spending money you were already spending. The two justify different capital, different organisational patience, and different governance. Operators that hear sixty billion and staff a growth programme will find, three years in, that they have built a very good efficiency programme and told their investors the wrong story about it. That is not a hypothetical failure mode. It is the failure mode the industry has run repeatedly, and the reason I keep insisting the flows be kept apart on the page before they are kept apart in the budget.

There is a second problem with the sixty billion, which is that it is sitting next to a Deloitte figure of a hundred and fifty billion in "total value" and the two are quietly being read as the same kind of number. They are not. One is a cost line, the other is a mixed construct that includes cost, defended revenue and speculative new revenue in a single total. Adding vendor and consultancy figures that measure different things is the same error I flag on RAN energy savings, where individually plausible percentages get stacked into a number no operator has ever achieved. Treat the sixty billion as the honest number, because at least you can tell what it counts.

Now to the architecture, which is where the article is most interesting and most incomplete. Google Cloud's prescription is a fabric of hyper specialised micro agents, billing agents, inventory agents, RAN guardians, communicating through standardised orchestration protocols, validated against a digital twin, bounded by what it calls a deterministic governance framework with explicit decision boundaries and clean handoff to human engineers. This is good engineering. It is also, for at least the sixth time in a month, a description of containment rather than coordination. Every agent in that picture belongs to the operator. Every protocol is internal. Every boundary is a boundary between the operator's machine and the operator's human. Nothing in the design describes what happens when an agent that the operator does not own, and cannot inspect, arrives with a request.

The digital twin makes the gap unusually visible. A twin is a high fidelity replica of your own network, and it is exactly the right tool for testing a configuration change before you ship it. It is useless for the case that actually matters commercially, because you cannot build a twin of the counterparty. When an enterprise's AI agent negotiates for a guaranteed slice, the operator's agent is not reasoning about a system it can simulate. It is reasoning about an intent it must infer, an authority it must verify, and a commitment it must be able to audit afterwards. That is not a simulation problem. It is a problem of shared topology, shared ontology, explicit authority boundaries and durable audit trails, which is the meta model of the agentic plane I have been arguing for since the spring, and which a runtime does not supply no matter how good the runtime is.

I should say plainly that a hyperscaler making this argument is not a criticism of the hyperscaler. Google Cloud is selling a stack that does what it says it does, and the operators quoted are getting real results from it. My argument is with how operators will read it. There is a version of the next two years in which the industry retools its operations beautifully, takes out a very large amount of cost, calls the result an AI business, and arrives in 2030 with the same revenue line and a smaller headcount. That would not be a failure of technology. It would be a failure to name what was bought.

So the test I would apply to this article, and to every agentic AI business case that lands on a telco investment committee this quarter, is the one I set out eight days ago. Which flow is this, cost, defence, or new revenue? If the supporting evidence is entirely tickets, incidents and NOC headcount, the answer is cost, and the paper should say so in its first sentence rather than its appendix. What binding constraint does an external buyer pay to remove? If nobody outside the company pays anything, there is no buyer, and the word opportunity is unearned. And where on the capacity, platform, outcome ladder does this sit? An operator that automates its own operations has not stepped onto the ladder at all, because the ladder is about what you sell, and nobody is buying your NOC.

Sixty billion dollars of avoided cost is worth having. It is worth a serious programme, serious money and serious executive attention. It is worth all of that as what it is. The operators that will be interesting in 2030 are not the ones that saved the most. They are the ones that could still tell you, at the end of it, which of the three flows each dollar came from.

AI monetization for operators: separating revenue from cost avoidance

noreply@blogger.com (Patrick Lopez) — Mon, 13 Jul 2026 14:06:20 +0000

Every operator earnings call now features AI prominently. Listen closely, however, and most of what is described as "AI monetization" is nothing of the sort. It is cost avoidance cosplaying a revenue costume.

This distinction matters because the two require different investment logic, different organizational capabilities, and different patience horizons. Operators that blur them will misallocate capital. Operators that separate them have a chance at building genuine new B2B revenue lines — narrower than the hype suggests, but investable.

Three money flows, not one

AI touches operator economics through three distinct channels, and the discipline starts with refusing to aggregate them.

1. AI that reduces cost. Autonomous network operations, agentic customer care, energy optimization, predictive maintenance. This is real, it is happening, and it is the largest near-term financial impact of AI on operators. It is also not revenue. A dollar of opex avoided is valuable, but it does not create a new line of business, and it does not justify the "operators as AI companies" narrative. It justifies a leaner operator.

2. AI that defends existing revenue. Enterprises deploying AI workloads have new connectivity requirements: deterministic performance, low latency to inference endpoints, secure private connectivity to GPU capacity, data-gravity-aware networking. Operators that serve these requirements protect and modestly grow their core B2B connectivity business. This is differentiated connectivity for the AI era — important, defensible, but fundamentally an evolution of what operators already sell.

3. AI that creates new revenue. This is the category everyone wants to talk about and the one that deserves the most scrutiny. It exists, but it is narrower than most strategy decks admit.

The four credible new revenue lines

Having spent the last two years working on AI infrastructure with operators and vendors on both sides of the Atlantic, I see four B2B revenue opportunities that survive contact with commercial reality. They are not equal — they differ in demand maturity, margin profile and time horizon, and they should be funded accordingly.

Sovereign AI capacity — GPU-as-a-service and AI factories — is the most immediate and the most misunderstood. Demand is real and policy-driven, concentrated in regulated sectors; the margin profile is low-to-mid, because the business is capex-heavy and carries utilization risk; and the revenue is available now. The demand side is genuine: governments, healthcare systems, defense, financial services and public administrations in Europe increasingly cannot — or will not — run inference on US hyperscaler infrastructure under foreign jurisdiction. Operators hold assets that map remarkably well to this demand: national data center footprints, energy contracts, security clearances, sovereign trust, and enterprise sales relationships.

Telefónica's recent national rollout of edge-based GPU-as-a-service in Spain is instructive. The underlying edge platform was architected years earlier — I led the team that built and productized it — and for years the business case was marginal on enterprise use cases alone. What changed was not the technology. It was the arrival of sovereign AI demand, which finally gave the infrastructure a paying anchor tenant profile. The lesson generalizes: edge and distributed compute investments become fundable when sovereignty is the demand driver, not the garnish.

The caution: this is a capex-intensive, utilization-sensitive business competing against hyperscalers with structurally lower unit costs. Operators win where sovereignty, data residency and proximity are binding constraints — and lose everywhere else. The addressable market is the regulated slice of national demand, not "the AI market."

Edge inference is real but earlier than its promoters claim. Demand exists where latency or data gravity bind; margins are mid-range; and the horizon is two to five years before this becomes a broad product line. The use cases that pay today are those where physics or data gravity make centralized inference impossible: industrial vision, real-time media production, autonomous operations in ports and factories. I have seen these work commercially. But the buyer set is narrow, and each engagement still resembles a system integration project more than a product sale. This becomes a scalable product line when agentic AI workloads distribute themselves across infrastructure tiers — the architecture I have described elsewhere as the AI Grid. That shift is underway, not arrived.

Data and trust services are the sleeper. Deepfake detection on voice calls, branded and verified calling, identity assurance for AI agents, provenance services. These are small revenue lines today, but they are high-margin, they monetize immediately, they sit directly on operator trust assets that hyperscalers cannot replicate, and demand grows with every AI-enabled fraud headline. For a B2B operator, this category has the best margin-to-capex ratio of the four.

Network APIs are the line whose trajectory has changed most in the past two years. The strategic logic has always been sound — AI agents will need to programmatically request network resources, quality on demand, location, verification — and the commercial signals are finally following: revenues are growing, aggregation initiatives have consolidated distribution, and enterprise visibility is rising with every agentic deployment that needs verified identity or guaranteed quality. It remains the earliest-stage of the four, and the AI agent wave — rather than developer evangelism — is what gives it genuine demand pull. I would invest now to be positioned, while sizing near-term revenue expectations with discipline; the inflection is likely in the second half of the decade.

The monetization ladder

Across all four lines, there is a ladder that determines margin and defensibility:

Sell capacity → sell platform → sell outcomes. Capacity here includes every consumption-metered unit: GPU hours, tokens, gigabits.

Selling raw capacity — GPU hours, token-metered inference, connectivity — is rung one: necessary, low-margin, commoditizing from day one. Tokens deserve a specific caution here: metering in tokens rather than GPU-hours changes the billing unit, not the business. An operator selling tokens against someone else's models and someone else's stack is still selling capacity, at prices that will be set by the most efficient infrastructure provider in the market. Selling a platform — inference-as-a-service with orchestration, security, compliance tooling — is rung two, where margins improve and switching costs appear. Selling outcomes — a fraud-detection rate, a production workflow, a compliant AI deployment for a hospital group — is rung three, where the economics finally resemble a services business worth building.

Operators historically stall at rung one. The reasons are organizational, not technological: product management that thinks in network elements rather than buyer problems, sales forces compensated on connectivity, and business cases that demand payback before the platform layer has time to mature. The operators that climb the ladder will be those that treat AI monetization as a product management and go-to-market transformation, not an infrastructure deployment.

What the buyer actually pays for

A final discipline. In every commercially successful case I have worked on, the enterprise buyer was not paying for "AI." They were paying for a constraint to be removed: data that could not leave the country, latency that broke the use case, a fraud pattern that was costing millions, a compliance requirement that blocked deployment. Price the constraint, not the technology. The moment an operator's AI proposition cannot name the constraint it removes, it is a science project.

Three questions before approving any operator AI business case

Which of the three money flows is this — cost, defense, or new revenue? If the answer mixes them, send it back.
What binding constraint does the buyer pay to remove, and why is an operator structurally better placed to remove it than a hyperscaler or an integrator? Sovereignty, proximity and trust are acceptable answers. "We have a network" is not.
Where does this sit on the capacity–platform–outcome ladder, and what is the credible path up? Rung-one economics with rung-three ambitions is where operator AI investments go to die.

The AI B2B opportunity for operators is real. It is also smaller, slower and more demanding of commercial discipline than the current narrative suggests. The winners will not be the operators with the most GPUs. They will be the ones that can tell the difference between a cost saving, a defended revenue and a new business — and fund each accordingly.

Operators Lean In On AI Grid Location

noreply@blogger.com (Patrick Lopez) — Thu, 09 Jul 2026 14:32:30 +0000

Earlier this week I argued that the AI Grid debate needs to move on from where you place a GPU to whether geographically dispersed compute can behave as a single fabric. I stand by that. But a story that has been building across the press this week is a useful reminder that the location question, the one I have been answering the same way for two years, is now being settled in public by the people who actually own the radio networks. And they are settling it against the tower.

The reporting is consistent. Light Reading describes Nokia and Nvidia's AI-RAN proposition running into telco resistance. Verizon, Vodafone, Orange and, notably for me, Telus have all raised doubts about putting graphics processing units into the radio access network. AT&T's chief technology officer has cast public doubt on the case for AI compute at the far edge. The enthusiasm for GPU-in-the-RAN comes from two operators, T-Mobile US and SoftBank, and almost no one else. Much of the rest of the industry is looking at Intel's newer CPUs for its open RAN rollouts rather than filling cell sites with accelerators.

I want to be precise about what this does and does not prove. It does not prove that AI in the RAN is a bad idea. Applying machine learning to scheduling, link adaptation and energy management inside the baseband is real, it is shipping, and Ericsson's AI-in-RAN software subscription is a reasonable way to bring it into existing hardware. What the operators are rejecting is narrower and more specific. They are rejecting the proposition that the cell site should become a general-purpose AI inference venue, stuffed with GPUs, monetised by hosting third-party workloads at the edge of the network. That is the proposition I have said for two years does not survive contact with power, cooling, space, security and, above all, the absence of a monetisation model.

My position has been that AI Grid deployment begins at the central office and the mobile switching office, not the cell site, because every physical and commercial constraint favours the aggregation point over the tower. The reasoning was never controversial to anyone who has stood in both kinds of building. A central office has power feeds, environmental control, physical security and fibre already in place. A cell site has a cabinet, a limited power budget and a landlord. When Verizon, Vodafone, Orange and Telus decline to put GPUs at the far edge, they are not making a new argument. They are confirming an old one, and they are confirming it with capital allocation decisions rather than conference slides, which is the only confirmation that counts.

There is a workstream reason this caught my eye. Telus appearing on the skeptics' list is consistent with what I see in the market: operators that are serious about autonomous operations are also the ones being disciplined about where AI compute physically lands. Those two forms of discipline are related. An operator that thinks clearly about the economics of edge inference tends to think clearly about the economics of everything else in the network.

The AI-RAN enthusiasm gap also matters for how we read vendor claims. When a technology has two vocal operator champions and a longer list of vocal operator skeptics, that is the signature of a capability that has been field-validated in specific conditions but not commercially validated across the market. I have made this distinction before and it applies cleanly here. SoftBank's agentic AI-RAN demonstrations and T-Mobile's Nvidia-backed edge trials are real engineering. They are not yet evidence that the model generalises to operators with different cost structures, different energy prices and different enterprise demand. Treat a two-operator enthusiasm as a pilot signal, not a market verdict.

So where does this leave the fabric argument I made last week? Exactly where I left it, and stronger. The operators are removing the least defensible node from the AI Grid, the cell site as inference host, which clears the ground for the argument that actually matters. Once you accept that heavy inference will not live at the tower, the interesting question becomes how you knit central offices, regional data centres and a small number of genuinely latency-bound edge sites into one addressable pool. The industry spent this week deciding where the compute will not go. That is progress. The harder decision, who owns the fabric that arbitrates across the places it will go, is still open, though.

AI Grid: Fabric vs Location Considerations

noreply@blogger.com (Patrick Lopez) — Tue, 07 Jul 2026 11:46:22 +0000

The debate about where AI compute belongs in a telecom network has been framed as a location question from the start. Do you put the GPUs at the cell site, the central office, the regional data centre, or the hyperscale campus? I have argued consistently that the honest answer begins at the central office and the mobile switching office, because power, cooling, fibre, physical security and latency sufficiency all favour those sites over the tower. That position has not changed. But two announcements from Asia this week suggest the more consequential question is no longer where the compute sits. It is whether the compute behaves as one pool regardless of where it sits.

NTT Docomo disclosed a nationwide testbed it calls GPU over APN. It pools graphics processing units spread across eight locations in five Japanese cities and presents them to a workload as a single platform, connected over the all-photonics network that NTT Group has been building under its IOWN programme. Docomo describes it as the realisation of its AI-Centric ICT Platform concept, part of what the group now labels AIOWN, its AI-native infrastructure. Strip away the acronyms and the claim is precise and significant: distributed GPUs, addressed as if co-located, over deterministic optical transport.

KT made the point from the other direction. Its new chief executive committed 18 trillion won, roughly 11.7 billion dollars, over three years, including 3.26 billion for one gigawatt of AI data centre capacity and a plan to connect that centralised infrastructure with edge sites serving low-latency workloads such as autonomous vehicles and industrial robotics. One operator is making dispersed compute act centralised. The other is extending centralised compute out to the edge. Both are describing the same thing from opposite ends, which is a compute fabric rather than a compute site.

This matters because it decouples two decisions the industry keeps conflating. Where you place a GPU is a question about power, land and cost. Where you run a workload is a question about latency, data gravity and sovereignty. As long as placement and execution are the same decision, every AI deployment becomes a real estate argument. Once a photonic fabric can make placement invisible to the workload, the two decisions separate. Training and heavy batch inference go where power and space are cheap. Latency-bound inference lands close to the user. The fabric arbitrates between them. This does not contradict the case for the central office, it absorbs it: the central office still wins for latency-bound edge inference, but that win is now a node in a graph rather than an isolated site.

I have some history with this problem. In 2018 I wrote about building at Telefonica what was probably the industry's first fully programmable multi-access edge computing platform, and the hardest part was never the compute. It was making distributed compute addressable, governable and billable as a coherent resource rather than a scatter of isolated sites. The technology around it has moved on considerably, but the unsolved problem is the same one Docomo is now attacking with photonics.

A practitioner's caution is in order. A fabric that makes national-scale GPUs behave as one pool is a testbed today, not a product. Docomo demonstrated it in a lab-grade programme. KT's edge connection is a plan, not a live deployment. Deterministic optical transport carrying commercial service level agreements under contended traffic is a materially harder thing than a controlled demonstration, and I would treat "as if co-located" the way I treat vendor energy savings figures: directionally real, quantitatively unproven at scale. The distance between a testbed that works and a fabric that carries production workloads is precisely the distance Open RAN spent five years crossing.

Still, the framing is the takeaway. The AI Grid conversation needs to move from siting to fabric. The operators that win will be the ones who can treat geographically dispersed compute as a single addressable resource, orchestrate workloads across it against real constraints, and price and settle access to it. That is a transport, orchestration and settlement problem before it is a property problem. The question is no longer which building holds the GPUs. It is who owns the fabric that makes the buildings irrelevant.

The Agent Runtime Is Not the Agent Model

noreply@blogger.com (Patrick Lopez) — Mon, 06 Jul 2026 14:00:00 +0000

DTW Ignite in Copenhagen made one thing clear: the vendor community has decided that the path to autonomous networks runs through agent runtimes. NVIDIA introduced NemoClaw blueprints and the OpenShell secure runtime to give long-running agents policy guardrails and sandboxed access to telecom systems. AdaptKey is piloting security-hardened agents for self-healing 5G operations. ServiceNow is bringing Project Arc to the NOC, orchestrating incident response from alert to work order. NTT DATA is building anomaly agents that escalate to research agents for telemetry analysis. Synthetic data rounds out the stack, a pragmatic answer to the fact that more than half of operators say their most valuable network data is too sensitive to use.

This is genuine progress and I do not want to minimize it. Containment, auditability and policy enforcement are necessary conditions for letting agents touch production networks. An agent that cannot be sandboxed cannot be trusted, and an agent whose actions cannot be audited cannot be certified. The runtime layer has to be built.

Containment is not coordination

But look carefully at what these announcements govern: individual agents, operating within a single operator's domain, executing workflows that a human has scoped in advance. This is vertical governance. It answers the question of whether an agent is allowed to perform an action. It does not answer the question that autonomous networks will actually pose at scale: when two agents are each permitted to act, and their permitted actions conflict, who decides?

Consider a scenario that is closer than most operators think. An enterprise logistics agent requests guaranteed throughput for a fleet of delivery robots. Simultaneously, a network energy agent, operating under its own perfectly valid mandate, is shutting down capacity in the same cluster to meet a sustainability target. Both agents are sandboxed. Both are auditable. Both are compliant with their policies. The runtime layer sees two well-behaved agents. The network sees a contradiction.

This is the problem I described in my previous post on network APIs. APIs were designed for developer access, not for agent-to-agent negotiation. Runtimes inherit the same blind spot. They secure the execution of each agent without providing any shared representation of the agentic plane itself.

What the meta-model requires

For agents to negotiate rather than collide, the industry needs a meta-model of the agentic plane: a topology of which agents exist and where they sit, an ontology so that an enterprise agent and a network agent mean the same thing by capacity, latency or priority, explicit authority boundaries defining what each agent may commit on behalf of its principal, shared state models so that negotiations reference the same view of the network, and audit trails that span negotiations rather than individual actions. None of the DTW announcements address this layer. They cannot, because it is not a product any single vendor can ship. It is a model the industry must agree on, the way it once agreed on network information models for OSS.

There is a familiar pattern here. The industry built firewalls before it built routing protocols for the internet's trust boundaries, and it spent two decades paying for the sequencing. We are building the firewalls of the agentic era first. The operators and standards bodies that formalize the agentic plane meta-model will define how enterprise AI and network AI transact for the next decade. The ones that stop at the runtime will discover that a network full of safely contained agents is not an autonomous network.

DTW Ignite 2026: The API Is Not Enough

noreply@blogger.com (Patrick Lopez) — Wed, 01 Jul 2026 14:21:09 +0000

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

noreply@blogger.com (Patrick Lopez) — Tue, 09 Jun 2026 14:04:12 +0000

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

noreply@blogger.com (Patrick Lopez) — Mon, 01 Jun 2026 16:55:46 +0000

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.

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.
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.
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.
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.

Non-RT RIC, AI-RAN, and the AI Grid: Three Different Bets on the Future of the RAN

noreply@blogger.com (Patrick Lopez) — Thu, 21 May 2026 17:45:25 +0000

I have been asked a few times lately what the difference is between the Non-Real Time RIC and AI-RAN. The question itself tells you something. Both sit under the broad "AI in the RAN" umbrella, marketed aggressively by the same vendors, debated in the same conference sessions. But they are fundamentally different in architecture, ambition, and business model. And neither is quite the same as what NVIDIA formally branded the AI Grid at GTC 2026 — which is where the most important and most misread opportunity actually sits.

The Non-RT RIC: the pragmatic bet

The Non-RT RIC is an O-RAN defined software layer that sits in the Service Management and Orchestration layer above the RAN, not inside it. Control loops over one second. rApps for energy saving, traffic steering, slice assurance, automated optimization. Think of it as the evolution of Self-Organizing Networks, re-platformed on open interfaces with a proper application model and a genuinely lower barrier to entry — cloud-native and OSS skills are sufficient. No RAN silicon expertise required.

This is precisely why the early commercial traction is here, not in AI-RAN. AT&T is deploying Ericsson's SMO and Non-RT RIC to replace two legacy C-SON systems. TELUS has launched an RIC platform alongside its Open RAN rollout. Swisscom is deploying one for multi-technology network management. These are not trials. These are production decisions.

AI-RAN: real performance gains, speculative revenue

AI-RAN embeds AI natively into the RAN stack itself .The AI-RAN Alliance — founded in February 2024, now at 109 member companies — defines it across three working groups: AI-for-RAN, AI-and-RAN, and AI-on-RAN.

AI-for-RAN is the most mature: using AI to optimize the RAN itself — the scheduler, link adaptation, beamforming, interference management. T-Mobile and Ericsson have been trialing an AI-driven scheduler and link adaptation engine on a live 5G Advanced network since Q2 2025, targeting commercial deployment in Q3 2026. Nokia and NVIDIA, backed by a $1 billion equity partnership, are testing GPU-accelerated AI-RAN with BT, Elisa, NTT DOCOMO, and Vodafone.

AI-and-RAN is where the narrative gets more ambitious — and more speculative. The idea is that RAN sites become shared compute infrastructure, running both network workloads and enterprise AI workloads on the same hardware. The tower becomes a distributed AI compute node. New revenue streams. Operators escape the utility trap.

AI-on-RAN is the monetization layer for the above. The commercial mechanisms are still being defined. That tells you where the maturity is.

The AI Grid: follow NVIDIA's sequencing, not its marketing

At GTC 2026, NVIDIA formally introduced the AI Grid as a reference design — geographically distributed AI infrastructure, using the telco footprint to run inference workloads closer to users. The numbers are interesting: early Comcast benchmarks showed inference cost reductions of up to 76% versus centralized deployments. HPE, SpectroCloud, and others have already announced implementations aligned to the reference architecture.

I have used this concept in my own work for years to describe the evolution from isolated MEC deployments into a coherent, programmable distributed inference fabric. Good to see NVIDIA put a formal architecture behind it. But the marketing obscures a critical sequencing question.

NVIDIA's own GTC announcements noted that many operators are starting by lighting up existing wired edge sites — central offices and mobile switching offices — as AI Grids they can monetize today. The cell site layer is a later phase. AT&T's CTO Igal Elbaz has been direct about questioning the value of pushing compute all the way to the far edge to save one or two milliseconds of latency. T-Mobile's SVP of network infrastructure defined her AI edge strategy as what is at a data center at a mobile switching office. Verizon's CTO has flagged the cost and complexity of far-edge GPU deployments.

These are the three largest US operators. They are not being conservative for the sake of it. The economics are straightforward: central offices and mobile switching offices already have power, cooling, connectivity, and physical security. They aggregate traffic from hundreds of cell sites. The sub-500ms latency threshold that NVIDIA's own reference design targets is achievable from a well-positioned CO. It does not require a GPU at the tower — not for the use cases that have a business case today.

I have seen this movie before with MEC. The industry led with its most ambitious architectural vision, ran the infrastructure investment ahead of the demand, and recovered slowly. The AI Grid does not have to repeat that pattern.

What to actually do

Start with the Non-RT RIC. The contracts are being signed, the ecosystem is opening, the business case is defensible.

On AI-RAN, wait for AI-for-RAN where your vendors have credible near-term roadmaps. Treat AI-and-RAN at the cell site as a long term speculative option — worth tracking, too early to fund at scale.

On the AI Grid, follow NVIDIA's own sequencing rather than the brochure. Central offices and mobile switching offices first. Build the orchestration and service layer from there outward. Expand to the far edge when the use cases and economics justify it — not because a GPU manufacturer's demand forecast requires it.

The cell site AI Grid is a compelling long-term vision. The central office AI Grid is deployable today. In this industry, deployable usually wins.

From AI-Native to Agentic-Native Networks

noreply@blogger.com (Patrick Lopez) — Mon, 23 Mar 2026 14:47:00 +0000

Recent announcements at NVIDIA's GTC 2026—including major pushes into agentic AI frameworks like OpenClaw, NemoClaw, and agentic systems for reasoning, planning, and autonomous action—have reinforced several convictions I've held about the trajectory of AI-native infrastructure, especially in telecom and networked industries. We're seeing the emergence of two distinct paradigms:

AI-Native networks that observe, detect, optimize, and predict in real time. These systems augment human decision-making, providing powerful assistance in planning, deploying, and managing both physical and virtual infrastructure.
Agentic-Native networks, by contrast, eliminate the human-in-the-loop entirely. When equipped with real-time data access, transactional capabilities, and fulfillment capacity, they execute at the speed permitted only by the slowest link in the supply chain.

This second model doesn't just accelerate execution—it fundamentally reprices time itself as a competitive asset.

As Jordi Visser articulates in his insightful piece "The Repricing of Time: Equity in the Age of Agents", agentic AI compresses competitive cycles dramatically. Velocity of execution no longer merely helps fulfill a plan faster; it redefines the playing field. When capabilities can be reconfigured almost overnight through model iterations or agent orchestration, durable moats erode. What once took decades to build—layered expertise, entrenched positions, regulatory barriers—can now be challenged or leapfrogged in months.

In this environment, equity behaves more like a call option on execution speed than on long-duration stability. "Execution speed replaces installed base. Iteration cadence replaces headcount." The advantage shifts decisively toward those who can pivot, adapt, innovate, and execute rapidly.

This dynamic hits telecom particularly hard.

Most operators are desperate to escape the "utility trench"—the low-margin, commodity perception that has trapped connectivity providers for years. They aspire to new revenue streams beyond pipes and bandwidth.

From my own experience modeling, teaching, and advising organizations on this challenge (see earlier pieces on innovation micro-strategies, telco relevance and growth, and the lean telco), there is no single silver bullet. No grand transformation program that magically reinvents the business.

Instead, the path forward involves thousands of micro-services and experiments: create, test, fail fast, pivot, scale the winners, and launch repeatedly. The era of one-size-fits-all offerings is over.

Agentic-native networks offer exactly the infrastructure to make this high-velocity approach viable at scale. They enable rapid creation, iteration, value capture, and deployment—turning velocity, flawless execution, and clear strategic vision into the new currency that outcompetes inertia, legacy systems, and eroding differentiation.

For telecom leaders, the message from GTC 2026 is clear: agentic AI can free up resources and help accelerate innovation at scale. Those who embrace this shift—building or partnering for agentic capabilities—will be the ones that don't just survive the repricing of time, but help define the next era of networked value creation.