Here we go again: The Killer App syndrome, featuring ISAC in 6G

I am in Seattle this week for FYUZ, the TIP event and if there is one acronym on every 6G slide from the vendors and the US operators, it is ISAC. AT&T called integrated sensing and communication "the big shiny object in 6G" from the stage, as Mobile World Live reported on November 4, and Samsung, Ericsson and the rest of the usual suspects have a keynote, a demo or a birds of a feather session on it before the show closes on Thursday. Having spent a career watching each generation of cellular get designed around one headline use case, I have seen this movie before.

ISAC, in plain terms, is the use of the signals a base station already radiates to detect objects that are not connected to the network, the way a radar does. The echoes of the downlink reference signals, received by the same base station (monostatic) or by a neighbouring one (bistatic), are processed to extract the range, speed and direction of a drone, a vehicle, a crowd, etc... 3GPP added a sensing channel model in Release 19 and published in June 2026 the Release 20 study (TR 38.765) on base station sensing of drones in FR1, reusing the CP-OFDM waveform, while SA2 drafted the architecture in TR 23.700-14. Full ISAC is a 6G affair, Release 21 and later, which is why AT&T wants a limited version on 5G Advanced rather than wait, and why Ericsson told Fierce Network in July it expects small scale deployments within two years, the Los Angeles Olympics of 2028 being the stated target.

This is where my skepticism comes from. 2G was designed for digital voice, and texting, an afterthought squeezed into the signalling channel, became the killer app and the most profitable bits the industry has ever carried. 3G was sold on video calling and push to talk, and what actually paid, modestly, was MMS (I ran the product team that shipped the first commercial MMSC at Logica, so I remember how modestly). 4G was architected around IMS and VoLTE, and the application that filled the pipes was video from YouTube and Netflix, which no operator designed for and none monetized. 5G was built around network slicing and the enterprise connectivity products it was supposed to enable, and seven years in, the only 5G product with a revenue line of its own is fixed wireless access, a service that was in nobody's keynote in 2018, as I wrote here and here. In each generation, the standard was optimized for the use case the industry wanted, and the market picked another one that the standard merely tolerated.

What is different this time is who is doing the pushing. The US Department of Defense's FutureG office calls ISAC a "mission-first priority" against drone swarms (Tom Rondeau, July 2026) and awarded Cohere Technologies 28 million dollars to turn commercial cell sites into drone detectors, Ericsson Federal demonstrated drone detection in Plano in February with the same office on the press release, and Verizon's trial with Samsung at a soccer fan event in Dallas and its FCC experimental licence in 4.8 to 4.9 GHz, reported by Light Reading in September, both point at NTIA's Mission 6G 28 showcase at the Los Angeles Olympics, an initiative NTIA describes as industry led, industry planned and industry funded. Ericsson Federal's CEO put it plainly to Mobile World Live in October: sensing gives the US military a reason to invest in commercial cellular infrastructure beyond connectivity.

In my mind, read backwards, that sentence describes a national air defence sensor layer built on operator capex, with the requirements set in Washington and the bill presented to the operators and, eventually, their subscribers. The industry is not naive about it; AT&T's own speaker said on stage that some assume defence money will fly in through the window, and asked the right question, which is, outside defence and public safety, who pays the bill? Nobody at FYUZ had an answer beyond "new revenue streams", which is the same answer slicing got in 2018.

Because ISAC reuses the radio, the pitch is that sensing comes almost for free. It does not. Monostatic sensing means listening for an echo while the base station is transmitting, which today's TDD massive MIMO radios do not do; it requires a separate, isolated receive panel or self interference cancellation, in other words new hardware at the cell site, and the Release 20 work on base station monostatic sensing exists precisely because that architecture is not in the field. Second, every resource given to sensing is taken from communication: beam time swept across empty sky instead of pointed at subscribers, denser reference signals, wider bandwidth and longer integration windows to resolve speed, and transmissions in idle periods where energy saving would have switched the carrier off. The ISAC panel at FYUZ said as much; the test vendor on stage described sensing as blanking out resource blocks stolen from the operator, and the operator's own 3GPP delegate explained that the exposure layer needs checks and balances on every request precisely because sensing is resource intensive and cannot be an always-on API. Third, processing: the sensed data runs to terabytes, the result is worthless unless the processing sits close enough to the radio to make a decision in time, and one panelist expects purpose-built analog silicon at the cell site because the sensing runs continuously across a lot of spectrum, which he conceded will require a lot of additional money. ABI Research makes the same point, sensing is a continuous processing workload, unlike connectivity, with no revenue model to cover it. Fourth, everything above the radio is new: an exposure layer with its northbound API, about 75% specified and due in March 2027 according to the delegate, a new sensing function in the packet core to translate an external request (area, time window, detection or tracking) into the right set of base stations, the RAN procedures to go with it, roaming between networks when the requested area crosses them, and consent, since the delegate conceded that people who are not the operator's subscribers get sensed. Fifth, the one that gets no slide time, liability: a network that tracks objects that never attached to it, "operationally invisible" in Cohere's words, will be treated by regulators, courts and customers as a surveillance system, in Europe before anywhere else.

The comparison the ISAC slides never show is with what already exists. Drone detection is a market of 2 billion dollars in 2026 growing to 6 billion by 2034 according to Fortune Business Insights, radar being the largest segment, RF detection the cheapest and optical the fastest growing, and products like Dedrone's fuse all three with recognition models that tell a drone from a bird or a balloon, which an echo at 3.5 GHz cannot. Cameras with facial, scene and object recognition are deployed at scale in stadiums, airports, ports and borders, and the EU has a 250 million euro border management call for exactly this. These sensors are purpose built, mature, specialized, and what they lack, connectivity, backhaul and compute for inference, is what operators are good at providing. The operator opportunity in my mind is to connect, backhaul and host these sensors at the edge, not to rebuild a mediocre radar out of a radio designed for throughput.

In my opinion, the technology works, the AT&T and Verizon trials show it, and for a stadium, a port or a military base with a federal customer paying, a few hundred sites will carry sensing. That is a managed service for a handful of government buyers, which ABI Research itself now frames as ISAC sold inside a private network or edge platform rather than as a mainstream 6G feature, with commercialization after 2030. It is not a reason to design the 6G air interface, the radios and the baseband around sensing, and it is certainly not a reason for operators to fund national security infrastructure on their balance sheets while the government keeps the spectrum and sets the requirements. If the killer app of 6G follows the pattern of the last four generations, it will be something the standard tolerates rather than something it was designed for, and the sensing hardware will sit at the cell site the way the IMS cores sat in the data centres, waiting for a use case. Will the Pentagon pay the full price of the sensor network it is asking for, or will it, as is now customary, leave the bill with the subscribers?

Open RAN at 10: Who Killed the Near-RT RIC?

 I am in Seattle this week for FYUZ, opening the SMO and RIC panel. Ten years ago, at Telefonica, my team was trying to connect the unconnected in Latin America, and the traditional RAN was simply not affordable there, so we disaggregated it. We launched the TIP OpenRAN working group in 2017, co-authored the OpenRAN RFI with Vodafone in 2018 and presented the results at the TIP Summit, which has since become FYUZ (I still have the T-shirt). This conference is, in a way, where it started for me, and a good place to take stock of what ten years have delivered.

Open RAN set out to open the radio, with RU, DU and CU from different vendors on general purpose hardware. On the way, it created something else, a software layer for intelligence: the SMO, the Non-RT and Near-RT RIC (brothers from a different mother, as I called them in 2023), rApps and xApps, and more recently dApps inside the CU / DU. None of this came from nowhere, of course. Centralised SON is the ancestor of the rApp, distributed SON the ancestor of the xApp, and one vendor told me that 55% of its SON deployments are already multi-vendor. The promise was any vendor's app, on any vendor's controller, over any vendor's RAN.

For this session, I interviewed and surveyed the SMO, RIC and app vendors on where things really stand. rApps have won the application model and they are in production. The largest deployment I found runs about 12 rApps on roughly 150,000 cells, but vendor and operator sit in the same group. Third party rApps are live at US tier ones, including on AT&T's network, and one RAN vendor's energy rApp runs on a third party RIC at another tier one. What I could not find anywhere is the original promise, a third party app on another vendor's SMO over a different vendor's RAN. The leading directory lists 117 rApps, 94 of them from independent vendors, and only a handful are in public production.

Why? One independent vendor summed it up: the algorithm ports, the plumbing does not. Bringing a first app onto a new SMO costs around three FTE-months, about half for each one after, and R1 delivers standards-based portability, not plug-and-play. Every vendor I spoke to, large or small, named the same three gaps: data semantics (interfaces connect, but counters and models differ by vendor), conflicts between automation loops (in an EU testbed, two vendors' energy-saving xApps switched the same cells on and off against each other) and onboarding, certification and accountability. The industry's answer, unfortunately, is shifting from portability to certification per platform, curated catalogues rather than open marketplaces. I have seen this movie before, with MANO and then with the SMO itself: the barriers were never technical, they were commercial.

The biggest change since last year is that, of the three intelligence layers, the middle one did not survive. Regular readers know my feelings about the Near-RT RIC, and at MWC last year I called it a flawed proposition as a host for third party xApps. A tier-one SMO vendor has now discontinued investment in its Near-RT RIC and xApps, given limited industry demand, a second keeps time-critical AI inside its own RAN software, and independents bypass the RIC altogether, one of them delivering the same E2 code straight to the base station. A separate xApp server, and its power bill, broke operators' cost models, and the VMware and Juniper exits stranded the integrations app vendors had built. The use cases moved up to rApps for anything slower than a second, and down into dApps or the RAN software itself for real-time control.

Two surprises. The first commercial dApps are in space: beam weights and satellite handover are not native in the standards, so one vendor fills the gap with its own AI models running in the DU, in production on a GEO network with LEO targeted for 2027. And the US government is no longer just a buyer: the Pentagon's FutureG office funded OCUDU, an open source CU / DU now backed by a Linux Foundation ecosystem with AT&T, Verizon, Ericsson, Nokia and NVIDIA. Defence wants a programmable scheduler, and RAN vendors guard it as their crown jewel. In my mind, the three RIC tiers are collapsing into one AI plane, training central and inference placed wherever the loop latency requires, which I think starts at central offices rather than cell sites, whatever the GPU vendors and their partners say.

So where does this go by 2028? In a vendor's words, not simply more RIC. Tier-one vendors now describe SMO and RIC as the base for intent-driven, agentic operations, autonomy sits at level 2.5 to 3 today, and a reality check on energy: measured savings average 15 to 16%, while headlines quote 35 to 40% peaks. The test for 2027 is the first production rApp combining a third party app, another vendor's SMO and a different RAN. I left the panel with three questions: who pays for porting, who arbitrates conflicts between apps and who is liable, and will certification replace portability? It will be interesting to see whether Open RAN's tenth year is the one where the original promise is at last delivered, or quietly replaced.

VMO2 AI-RAN Trial Used Custom Silicon, Not GPUs

Light Reading reported on 2 November that Virgin Media O2's AI-RAN trial at Paddington, central London, did not use an Nvidia GPU. Nokia told the publication that the site ran its AI-RAN software on existing Marvell custom silicon, a Layer 1 chip Nokia calls ABIP, and Light Reading withdrew its original story. My post VMO2 Finds AI-RAN Does Not Need GPUs said the trial ran on a GPU, following that original report, and that detail was wrong, it has been corrected since. The result VMO2 described is unchanged: AI-based channel quality estimation raised spectral efficiency by 20%, and he said a GPU is not required to do it.

Nokia relies exclusively on Marvell silicon for Layer 1 in its RAN products today, and ABIP is the last custom chip it plans to develop. Its successor, ABIG, is built on Nvidia technology. The 20% at Paddington equals the figure Nokia gave in the summer for AI-RAN on GPUs, when it projected 50% in 2027 and a doubling by 2028. A white paper from Chetan Sharma Consulting that Nokia endorsed was more cautious, noting that a site already close to its theoretical spectral efficiency has less headroom for AI gains. Neither the Paddington result nor the GPU figures come with a baseline.

This is the position I took in Ericsson and Nokia at odds on AI-RAN silicon and in Is AI-RAN the future of telco?: using AI in the RAN and buying GPUs are separate decisions. The evidence now covers both vendors. Ericsson reports about 10% from an AI successor to link adaptation on about 60,000 deployed base stations, and Nokia's trial reached 20% on installed silicon. Nokia's argument for GPUs is that they receive years of software upgrades while custom silicon is replaced more often. That is the case to be tested, and it depends on how much AI headroom each generation of ASIC has, which neither vendor has published. Operators weighing ABIG against ABIP-class hardware need that figure, together with a baseline and a cost per site, before they commit to the upgrade.

VMO2 Finds AI-RAN Does Not Need GPUs

Virgin Media O2 has trialled AI-based channel quality estimation on a Nokia RAN at a busy site in Paddington, central London. Light Reading reported on 2 November, after withdrawing its earlier story, that the site ran on Nokia's existing Marvell custom silicon and not on an Nvidia GPU. Rob Joyce, VMO2's director of mobile access engineering, said the AI raised spectral efficiency by 20%. He also said a GPU is not required to do this and described Ericsson's silicon as very good. Ericsson CEO Per Narvinger has said about 60,000 base stations operated by its customers already run an AI successor to link adaptation on existing ASICs, with a gain of around 10%.

VMO2 has no GPU RAN in the £700 million tranche of network spending announced earlier this year, and Joyce favours a distributed RAN. Centralising GPU baseband would require CPRI or eCPRI links of 25 Gbit/s each, about 3 of them or 75 Gbit/s, to a site that has 10 Gbit/s of fibre today. In his words, a distributed deployment means putting additional baseband GPU resources at each site, which is the cost that has to be weighed against the gain.

The 20% and the 10% cannot be compared. They come from different vendors, different algorithms and different scales: 1 trial site against a deployed base of 60,000. Light Reading's report gives no baseline, test duration or site count for the 20%. I made the case in Ericsson and Nokia at odds on AI-RAN silicon that the decision to use AI in the RAN is separate from the decision to buy GPUs, and VMO2's engineering lead now says the same. That keeps the position from Is AI-RAN the future of telco? intact: the commercial case for GPU RAN depends on benefits beyond radio algorithms that ASICs can also run, and no operator has published a baseline or a cost per site to show it. For Nokia customers the choice is narrower than the technology case suggests, because Nokia's last custom silicon product is the one VMO2 trialled and its roadmap runs through GPUs.

Ericsson Says Autonomy Does Not Need Perfect Data - I disagree

Lucky La Riccia, head of cloud software and services for EMEA at Ericsson, told Fierce Network at Ericsson's OSS/BSS Summit in Zurich that operators do not have to wait for clean data before pursuing autonomous networks. In Fierce's report of 22 October, his advice is to understand the limits of the data, put controls around how autonomous systems use it, and accept some imperfection: "Maybe it's okay to have some unstructured data." Ericsson favours a manager-in-the-loop model in which a person can oversee an AI agent, halt or review its actions, and approve them to continue. Autonomy should be pursued domain by domain, starting where business value is highest, and La Riccia said no customer will reach Level 4 across a network within the next year. The operator examples are Telia, which is starting with a common network inventory view for orchestration and provisioning, and Swisscom, which is starting with a cloud-native core and an intelligent automation platform that includes closed-loop automation in the radio access network.

Probabilistic models, deterministic networks

I read the data question differently. AI is a probabilistic process: a model returns the most likely answer with a degree of confidence, not a determined result. A telecom network is operated to deterministic outcomes. A handover completes or it drops, a slice meets its service level or it does not, a configuration change succeeds or it fails. A closed automation loop connects the two, because a probabilistic output triggers a deterministic action on a live network.

Imperfect data widens that gap at every stage. It produces inaccurate readings of network state, weaker predictions built on those readings, and lower confidence in the recommended action. In an automated loop the errors compound, because each action changes the network state that the next prediction reads. The value of the AI falls, a human has to stay in the loop to catch the errors, and the operator ends up further from Level 4. On this reading, manager-in-the-loop is the control that compensates for data quality. It is not a stage on the way to autonomy. It is the same pattern as Deutsche Telekom's RAN Guardian in Deutsche Telekom Extends Agentic AI Beyond RAN: autonomous action on routine events, with a human approving every critical change.

The way to narrow the gap between probabilistic and deterministic outcomes is data. Full-fidelity data, meaning complete counters, traces and state records and not sampled aggregates, lets a model read the network as it is. Long time windows let the operator measure how often predictions were right across seasonal cycles, faults and rare events, and calibrate confidence against outcomes. That measured accuracy is the evidence for deciding which actions can run without approval, so human intervention in the loop falls as the track record builds. Without it, the approval step has no basis for being removed.

Cross-domain loops raise the requirement further, because one agent's output becomes another's input. They need an agreed definition of state, a statement of who is authorised to change what, and a record of what was done, which is the argument in Agentic AI: Autonomous Agents Governance and Enforcement and in DTW Ignite 2026: The API Is Not Enough. Domain-by-domain sequencing is sensible for delivery, and it points to a rule for choosing the first domains: those where the operator already holds full-fidelity data over long windows. A common inventory view such as Telia's is in effect a data quality investment, and it is the kind that moves an operator toward Level 4.

AT&T Pitches AI Grid as Connectivity, Not Compute

AT&T used its third-quarter call on 21 October to describe how it intends to take part in the AI grid, and RCR Wireless's report on 22 October shows that the answer is connectivity. CEO John Stankey said more than 90% of US data centres are within 10 miles of AT&T's fibre network and more than 80% are within 1 mile. The product is managed links across metro networks, business endpoints and cloud on-ramps, which Stankey described as building the "right expressways in and out of their clouds" with end-to-end visibility and performance. RCR reports that AT&T sees itself as a fibre and connectivity provider and not a GPU landlord, and expects managed connectivity to earn higher margins than renting out AI capacity.

Stankey said edge inference, the in-between part of the grid, will take a while to work out, and that robotics and industrial autonomy will bring more demanding requirements and likely another level of investment. The capital behind the stated position is in fibre: AT&T is buying Lumen's consumer fibre assets for $5.75 billion and has signed a $3 billion multi-year fibre supply agreement with Corning.

Fibre first, compute later

This is consistent with the location argument in Operators Lean In On AI Grid Location: where AI grid compute sits is decided by power, cooling, fibre and security, and the operator's structural advantage is the fibre. It also matches the operator role described in Ericsson Makes Its Case for Edge Inference, where the operator provides infrastructure and assurance to AI providers and does not sell the AI service itself. The 90% and 80% figures measure how close data centres are to AT&T fibre, which is a statement about data centre interconnect demand. They are not a measure of demand for inference at the network edge.

The practical consequence is where AI grid revenue will first be reported. If AT&T's plan holds, the first income arrives as managed network services and cloud connectivity at the metro and data centre layer. Edge compute at central offices becomes a later investment that follows customer commitments, with robotics and industrial workloads as the stated trigger.

Deutsche Telekom Extends Agentic AI Beyond RAN

Deutsche Telekom is extending agentic AI from the radio network to network-wide operations, according to RCR Wireless on 21 October, reporting on DT's AI Investor Day. RAN Guardian, live in Germany since November 2025, uses 3 agents: one scans public and social media and other sources for events, one categorizes events and assesses their network impact, and one remediates ahead of the event through carrier aggregation, uplink adjustments and antenna tilt changes. A cross-domain platform called MINDR is in development, with an initial MVP in Germany by the end of 2026.

Capacity against realised results

Chief network officer Armin Sumesgutner said the agentic approach can analyze and remediate 100,000 events, against about 1,000 handled manually before, with a goal of avoiding 24 million minutes of poor customer experience. RAN Guardian triggered more than 100 remediation actions autonomously in its first month. That is a long way from the 100,000 events of capacity, and RCR does not report actions since. MINDR targets more than 90% automated ticket handling, issue qualification in under 15 minutes, incident resolution in under 1 hour and a 30% productivity improvement.

Level 4 with a human approver

DT states the goal as Level 4 autonomous networks. Group technology officer Arash Ashouriha said that for every critical change there will always be a human in the loop. In the TM Forum framework, Level 3 is conditional autonomy with human oversight, and Level 4 is intent-driven, closed-loop operation with minimal human intervention for routine tasks. Autonomous fixing of low-impact issues with human approval of critical ones fits that wording, but it means the level describes the routine tail and not the changes that carry risk. The approval boundary is therefore the design object: which changes count as critical, who holds the authority to make them, and what record is kept. That is the authority-boundary and audit-trail question in Agentic AI: Autonomous Agents Governance and Enforcement, and the reason I argued in DTW Ignite 2026: The API Is Not Enough that the API layer alone does not supply it.

Ericsson's Mats Karlsson told Fierce Network at the OSS/BSS Summit in Zurich on 20 October that AI automation is not network autonomy and that autonomy levels should not be treated as a numbers game. His example was that a Level 4 investment for a task performed twice a year may never pay back, while automating a task run 1,000 times a day changes the equation. DT's numbers fit that frame, since RAN Guardian earns on event volume. The figures still to be published are the actions executed to date, the share needing human involvement, and the minutes avoided measured against the 24 million goal.

Ericsson and Nokia at odds on AI-RAN silicon

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

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

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

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

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%

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

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

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.