{Core Analysis}

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.

The philosophical problem with agentic AI

noreply@blogger.com (Patrick Lopez) — Tue, 17 Mar 2026 01:09:00 +0000

Jensen Huang’s address at GTC gave me a lot to think about. So much so that I decided to drive to Sana Cruz for a taste of the ocean. I had to wait 30 minutes to get the table I wanted, just by the beach, in the sun but with a little shade… as I mistype table on my iPad, I am thankful for the autocorrect to sanitize my somewhat boozy prose, while mostly appreciating the elegantly subtle blue underlying of the word batle, prompting me to consider “is that really what you meant to write, or do you meant table”?

I like that. I like that more than the blue pencil with the little star that insistently offers an AI assisted rewrite. Oh, sure, I am not a native English writer, so my grammar is somewhat tainted by the other 3 languages I might think in at any point in time. If I compound St Patrick and this weekend’s VI nations rugby results for France, you will understand if my writing is not the usual corporate polish.

Having said that, I was at GTC for the first time, I listen to Jensen’s performance and I was left enlightened and a bit worried. By now, the headline and the sound bite out there must be the $1 Trillion line of sight on chip revenues for Nvidia over the next couple of years. Obviously, it is an extraordinary number. Unfathomable. Impossible to imagine for most of us. Almost impossible to think that we, collectively would spend 125$ ( at 8 billion people) of Nvidia stuff over the next couple of years. Surely that’s impossible.

Unless this is not about need, but about demand. Unless that demand is accelerated, compounded, exponentially nurtured beyond its natural curve.

Essentially, what I retained from the presentation was that the larger the model, the more the interactions, the larger the demand, the faster and more the tokens have to be created to satisfy it. (I am sure AI could rewrite this sentence more elegantly, but screw it). The measurement unit becomes token per Watt,as it is a limiting factor for a given data center and tokens per second as it is the limiting factor for a given service. Jensen even alluded to the fact that they will factor in token per month grants in engineering packages as it becomes a productivity factor.

The thesis for the 1T$ revenue relies on demand exploding and the emergence of low latency, high I/O token market. Low latency, high I/O is understandable. Multimodal, video models, requiring real time inferencing from vehicles, robots and generally physical AI will drive it. The demand explosion, though, even factoring in the integration of compute and AI in to its, devices, edges… if we look at adoption curves and industrial capacity is decades away, not in 2 years. Unless…

Unless we are not the demand. Us, consumers, enterprises, industries, governments… Agentic AI and Clawdbot are just showing how, beyond automation, agency becomes a compounding factor. Agents, that you create, for specific purpose are understandable, useful controllable.

Agents, that interpret your intent, create other agents to enact their interpretation, have access to your digital life, credit card, HR, accounts receivables, invoices, orders, security cameras, GPS movements better be accountable, auditable, controllable. Agents that create fleets of agents to parcel out their workload is where I have doubts. The d’explosion in demand relies on the hypothesis that we will let agents create agents consume tokens to satisfy our needs.

No doubt, we will have agents to control, audit, police agents, but it feels wrong to delegate tasks just because you can or for the concept of efficiency.

This is where the the philosophical debate clashes with the economic model. I learned that hard times create hard men. Hard men create easy times. Easy times create easy men. Easy men create hard times. We might have evolved from this adage, but I feel that, being a kinetic, rather than a literal learner, I’ve learned from trying. I’ve learned from friction. To this day, I write on my notebook with a pen. I don’t forget anything I write. I forget most of what I type. It feels to me that friction is an integral part of the learning experience. More, it is an integral part of the human experience. The taste for effort, trying the hard things, failing is not only what most mankind experience on a daily basis, it is also, at least for me a great condition to happiness. I am infinitely happier labouring and succeeding than an automated, frictionless, efficient experience. Even with a better result.

As my children are about to enter the workforce, I am confronted daily to the question “what is a safe, fulfilling carrer?”. It used to be that medicine, law, engineering guaranteed a safe economic path. Nowadays, it looks like most entry level intellectual effort can easily, efficiently be replaced, and that agentic AI will only accelerate that trend. How are they supposed to master a domain they won’t be able to tinker and stumble? Maybe I am just an old fart and just like calculators and computers did not replace engineers, a higher level of abstraction will necessitate higher levels of intellectual efforts ? But this feels different.

Particularly if compute keeps accelerating and artificial intelligence surpasses human intelligence, then what? What is the imperative to learn, labour, try, suffer, if is not necessary? Where do you draw the line between agents that help and augment and agents that enable and replace?

Until then, I’ll keep labouring and burdening you with poorly written posts, but somewhat original or at least unique, because they’re mine. I enjoy this table, i waited 30 minutes for because I chose it and waited for it. I am not sure it would have tasted better should my personal AI butler had booked it for me on my way there.

AI is a new G

noreply@blogger.com (Patrick Lopez) — Wed, 11 Mar 2026 18:02:00 +0000

I returned from MWC 2026 with an uneasy feeling.

The telecommunications industry has long been defined by its generational leaps—each "G" marking a profound shift in capabilities, use cases, and societal impact.

2G brought reliable digital voice and SMS, enabling mass mobile communication. 3G introduced mobile data and picture messaging, laying the foundation for internet on the go. 4G powered the explosion of social media, apps, and always-on connectivity. 5G delivered massive bandwidth, fueling high-definition video streaming.

These evolutions followed a predictable cadence governed by 3GPP standards, with operators methodically upgrading infrastructure, spectrum, and devices in multi-year cycles. Parallel to this, the network itself transformed through virtualization: from SDN separating control and data planes, to disaggregating hardware from software, and evolving VNFs (Virtual Network Functions) into cloud-native CNFs (Cloud-native Network Functions). These shifts improved flexibility, scalability, and cost efficiency but remained incremental within the familiar "G" framework.

AI is entering telecom in silos—AI-RAN for spectrum and energy optimization, agentic AI in OSS for autonomous operations and predictive assurance, customer service copilots for intent-based support—delivering proven cost savings (e.g., 25-40% OPEX reductions in network ops, up to 35% energy efficiency). Yet these domain-specific wins rarely connect into a unified, end-to-end intelligence layer. Data stays fragmented across RAN, core, edge, OSS/BSS, leading to duplicated efforts, incomplete visibility, and "agent sprawl" risks. Industry sources highlight how silos impede multi-agent ecosystems and true autonomous networks.

This misconception manifests in several ways:

Viewing AI as incremental tech add-ons — Operators often pursue isolated pilots (e.g., AI-RAN trials, genAI copilots, or agentic OSS agents) expecting quick wins without addressing deeper structural issues.

Underplaying organizational and cultural complexity — AI demands far more than engineering upgrades. It requires breaking down legacy silos (RAN/IT/OSS/BSS), fostering cross-functional agility, upskilling thousands in ML ops/data governance, and driving cultural shifts to trust agentic systems. Cultural resistance, job security fears, and fragmented skills often stall progress, with many projects failing to move beyond pilots (only ~30% of genAI use cases reach production in some analyses). Organizational challenges—including change management and silo-breaking—as top barriers, yet leadership frequently delegates AI to a separate function rather than owning it as a CEO imperative.

Misjudging the scale of change needed — Unlike past "G" evolutions (hardware/spectrum-driven, standardized via 3GPP), AI is a software-defined, data-hungry, adaptive intelligence layer that reshapes workflows, decision-making, operating models, and even business identity (from connectivity provider to intelligent platform). Treating it as "just tech" ignores the need for unified data fabrics, intent-based orchestration, governed multi-agent ecosystems, and radical process redesign—efforts that can take years, not quarters, and demand massive internal rewiring.

New vendors (hyperscalers, specialized AI-RAN players, agentic platforms) disrupt legacy supplier models, while operating models evolve toward intent-driven, cloud-native, agent-orchestrated environments requiring cross-functional agility and new skills. Massive CAPEX uncertainty surrounds compute (GPUs, accelerators), high-bandwidth memory, power, and cooling—often in the hundreds of billions globally—amid unclear ROI timelines and risks like underutilization. AI excels at cost management through optimization, but revenue-generating services (e.g., enterprise AI platforms, GPUaaS, network APIs for AI workloads, personalized offerings) remain nascent for most operators. This imbalance—cost wins without broad revenue upside, vendor shifts, and compute investment risks—demands an AI strategy that starts with organization and operational models, not technology.

This underestimation risks turning AI from a greenfield opportunity into added complexity: persistent silos, agent sprawl, duplicated investments, and missed revenue potential. Proven cost optimizations are real, but without holistic transformation, operators may achieve efficiency gains while remaining commoditized pipes in an AI-driven world. Warning to operators: AI is not "plug-and-play." Underestimating its demands—starting with organization, leadership alignment, operating model redesign, and cultural renewal before heavy technology scaling—will lead to stalled initiatives, wasted CAPEX (especially on compute/infra), and competitive disadvantage. Frontrunners recognize AI as a radical reinvention requiring bold, enterprise-wide commitment; the rest risk being left behind as the intelligence generation unfolds.

Where Do Network Operators Go From Here? A View Ahead of MWC 2026

noreply@blogger.com (Patrick Lopez) — Tue, 10 Feb 2026 13:53:00 +0000

With Mobile World Congress just around the corner in Barcelona, the telecom sector finds itself at another inflection point. The headlines are familiar: ongoing layoffs across major operators, C-level reshuffles, persistent ARPU erosion, and debt structures that constrain organic investment. Vendors are already talking up 6G roadmaps while AI dominates conversations—both for aggressive OPEX reduction and tentative new revenue paths. Yet the near-term reality feels more evolutionary than revolutionary.

The recent wave of workforce reductions is not, in my view, primarily an AI story—at least not yet. It reflects the long tail of a structural shift that began over a decade ago: the gradual but relentless transition from proprietary telco platforms to cloud-native architectures. We are finally seeing the full operational benefits of user/control-plane separation, hardware/software disaggregation, widespread network virtualization, and centralized policy orchestration. These changes deliver greater automation, elastic scaling, and dramatically shorter development and validation cycles. The outcome is clear: managing a modern mobile network no longer requires the headcount levels of the previous era. Painful as the adjustment is, it is the inevitable consequence of borrowing proven cloud-native principles. Cost discipline is essential, but it is not a growth strategy. The more pressing question is how operators convert more reliable, elastic, and automated networks into sustainable revenue expansion.

Private Networks: Successes Exist, but They Remain Hard-Won

Private cellular networks continue to polarize opinion. Some portray them as a commercial disappointment; others point to hundreds of documented use cases. The reality sits firmly in between. Genuine deployments delivering positive returns do exist, particularly in verticals with high-value connectivity requirements and tolerance for tailored solutions. Energy (smart grids and remote monitoring), healthcare (indoor coverage in hospitals and clinics), large venues (stadiums and event spaces), mining (autonomous haulage and safety systems), and ports (crane automation and terminal logistics) stand out as segments where demand is tangible and economics can work. The common thread in successful cases is not technology alone but deployment philosophy: cloud-native designs that run on commodity hardware, leverage centralized intelligence, and minimize site-specific customization. When executed this way, private networks become scalable and margin-accretive rather than bespoke projects that drain resources. Operators who treat private 5G as an extension of their public edge and orchestration capabilities—rather than isolated silos—are better positioned to capture repeatable value.

Data: The Next Realistic Monetization Frontier

Beyond connectivity and private networks, operators sit on an underutilized asset: vast quantities of network-derived and network-transported data. Until recently most of this information has been siloed for internal analytics, dashboards, and regulatory reporting. That picture is beginning to change. Monetization remains nascent compared with the advertising-driven models of social platforms, yet the opportunity is material. API gateways that expose selected network and user context (location aggregates, mobility patterns, congestion signals, roaming events) represent only the surface layer. Consider a few practical illustrations:

Ride-hailing platforms could benefit from near-real-time insight into clusters of international roamers converging in a city district—an indicator of an upcoming conference, trade show, or major event. Pre-positioning drivers becomes more efficient, improving service levels and reducing wait times.
eSIM and travel-focused virtual operators could package value-added bundles—discounted car rentals, hotel reservations, restaurant bookings, or attraction tickets—targeted at detected travelers arriving in high-demand locations.
Navigation services (Google Maps, Waze, and equivalents) could gain from telco-sourced, fine-grained congestion and flow data that augments probe-vehicle inputs, especially in areas with sparse device coverage or during atypical events. Privacy and regulatory compliance are non-negotiable hurdles, as are competitive dynamics with hyperscalers and data aggregators. Success will depend on responsible data handling, anonymization at scale, clear value propositions for enterprise partners, and commercial models that avoid commoditization. Operators that can evolve from pure connectivity providers toward curated data intermediaries—leveraging their unique position across physical infrastructure, subscriber scale, and real-time network telemetry—stand to capture incremental revenue without requiring entirely new network builds. As we head to MWC 2026, the conversation will likely revolve around AI acceleration, 6G timelines, and edge monetization. Beneath the buzz, though, the fundamentals remain: disciplined cost management, selective private-network wins, and thoughtful exploration of data opportunities. What are you seeing in your markets? Are private networks crossing the chasm in specific verticals? And where do you place data monetization on the priority list for the next 18–24 months? I welcome your perspectives in the comments.

Physical AI: How Network Operators Could Leverage Edge Computing for Smarter Robotics

noreply@blogger.com (Patrick Lopez) — Thu, 29 Jan 2026 18:27:00 +0000

As the telecom landscape evolves, one emerging trend that's catching my eye is Physical AI—the integration of advanced AI into physical devices like robots, enabling them to interact intelligently with the real world. With my background in telco-cloud strategy, I'm particularly intrigued by how network operators could position themselves as key enablers in this space. By providing low-latency edge infrastructure, telcos might unlock new revenue streams while supporting innovative applications that blend robotics, computer vision, and conversational AI.

In a recent analysis, I've been exploring how robots equipped with cameras and speakers could benefit from distributed AI processing at the network edge. This setup allows for real-time scene analysis, object detection, facial recognition, and natural language interactions with humans—all without relying solely on centralized clouds that introduce delays or high costs.

What is Physical AI?

Physical AI refers to AI systems embodied in hardware that perceive, reason, and act in physical environments. Unlike traditional AI that's confined to software, this involves robots or devices that use sensors (like cameras) to understand their surroundings and actuators (like speakers) to respond. The key challenge? Processing massive data streams in real time while maintaining privacy, efficiency, and low latency. This is where telco networks shine, with their distributed edge nodes offering compute power closer to the action.

Edge AI Inference: Powering Perception in Robotics

Operators could facilitate edge-based AI inference, where robots offload complex tasks like scene recognition, object identification, and facial analysis to nearby network edges. For instance, a service robot in a retail store uses its camera to scan the environment: edge inference quickly identifies products on shelves, detects customer faces for personalized greetings (with privacy safeguards), or recognizes obstacles to navigate safely. This sub-10ms processing avoids the pitfalls of cloud round-trips, reducing bandwidth usage and enabling seamless, responsive interactions.

Techniques like federated learning could further enhance this, allowing robots to fine-tune models collaboratively across distributed edges without sharing raw data—ideal for maintaining user privacy in sensitive scenarios.

Generative AI for Natural Language Conversations

Pair that with generative AI models running at the edge for conversational capabilities. Robots with speakers could engage in fluid, context-aware dialogues: a healthcare assistant bot recognizes a patient's face, infers emotional state from scene cues, and generates empathetic responses using natural language processing. Or in manufacturing, a collaborative robot converses with workers in real time—"Hand me the red tool"—while using object recognition to confirm and act.

By offering "AI-as-a-Service" at the edge, operators could provide scalable, usage-based access to these capabilities. Enterprises get high-performance AI without massive capex on private infrastructure, while telcos monetize their pervasive networks.

Real-World Opportunities and Examples

Consider verticals ripe for this:

Retail and hospitality: Robots greeting customers by name (via facial rec), recommending items based on scene analysis, and chatting naturally to assist.
Healthcare: Companion bots in hospitals using edge inference to monitor patient environments, detect falls, and converse to provide reminders or emotional support.
Logistics and manufacturing: Autonomous robots navigating warehouses, identifying inventory via objects/scenes, and collaborating verbally with human teams.
Smart cities: Public service bots patrolling areas, recognizing incidents (e.g., litter or crowds), and interacting with citizens through voice.

These use cases could drive B2B partnerships, where operators bundle connectivity with edge AI compute—potentially adding 10-20% to ARPU through premium services.

Considerations for Carriers

To capitalize, carriers might assess their edge footprints for AI readiness, pilot federated models for privacy, and collaborate with robot vendors or AI platforms. Challenges like energy efficiency and standardization remain, but the rewards in a growing Physical AI market make it worth exploring.

Distributed AI at the Edge: Opportunities for Telecom Networks in an Evolving AI Landscape

noreply@blogger.com (Patrick Lopez) — Wed, 28 Jan 2026 15:12:00 +0000

The rapid growth of AI applications is creating new demands on network infrastructure, particularly for low-latency, distributed processing close to end-users and devices. Rather than remaining focused solely on connectivity, telecom networks are increasingly positioning themselves to support distributed AI capabilities—where inference and even lightweight training can occur at the edge. This shift opens interesting possibilities for operators to play a more central role in the broader AI ecosystem. In a recent interview at FYUZ 2025 ( Telecom Infra Project's flagship event in Dublin), I had the opportunity to discuss these dynamics with TelecomTV . The conversation centered on a practical question: How might telco networks evolve from traditional mobile broadband platforms to ones that can meaningfully support distributed AI workloads?

The Emerging Demands on Networks for Distributed AI

AI inference, and in some cases lightweight training at the edge, benefits significantly from response times below 10 milliseconds and access to distributed parallel processing. Centralized cloud architectures face inherent limitations in these scenarios—issues such as data gravity, backhaul congestion, and rising energy requirements often make proximity to the data source or user essential. AI workloads tend to be compute- and power-intensive, and telecom networks already manage substantial energy footprints; integrating AI processing without thoughtful optimization could increase both costs and environmental impact. At the same time, the limitations of static resource allocation become more apparent—networks increasingly need mechanisms for dynamic, policy-aware traffic prioritization, capacity allocation, and workload steering.

How AI-Integrated RAN Can Support Distributed AI Capabilities

One approach carriers are exploring involves integrating AI capabilities directly into the Radio Access Network (AI RAN). This embeds intelligence into the radio layer, enabling distributed inference and lightweight training to take place across the network's existing footprint of base stations, central offices or MSOs, edge nodes, and fiber backhaul. The result is a pervasive mesh of compute resources located close to users and devices.

Distributed inference allows models to be partitioned and processed in parallel at multiple edge points, significantly reducing latency by keeping data local rather than sending it to distant centralized facilities. Where models need fine-tuning based on fresh, real-time data, techniques such as federated learning offer a way to train collaboratively across distributed locations while maintaining data privacy and avoiding the need to aggregate sensitive information centrally.

Internal Opportunities for Carriers

Carriers could apply these distributed AI capabilities to improve their own network operations. For example, predictive maintenance can become more effective when AI models analyze real-time sensor data from base stations to anticipate equipment issues, enabling proactive interventions that help reduce unplanned downtime.

Traffic management stands to benefit as well—distributed inference at the edge can forecast congestion patterns and dynamically adjust routing to preserve service quality during high-demand periods.

Energy optimization is another area of potential gain, with AI learning from usage patterns to make real-time decisions, such as reducing power to underutilized radio resources during quieter hours. In many cases, these internal improvements could deliver operational cost reductions of 20-30% while enhancing overall network reliability, often without requiring large-scale new investments in specialized AI hardware.

Enterprise Potential: The promise of AIaaS

From a business-to-business perspective, distributed AI at the edge could allow operators to offer "AI-as-a-Service" models to enterprises that require low-latency inference but lack the capital or desire to build their own edge infrastructure. Small and medium-sized enterprises across sectors such as manufacturing, retail, logistics, and others often face this constraint. By leveraging the operator's distributed edge, inference tasks can be offloaded on a usage-based basis, making high-performance AI more accessible without heavy upfront expenditure.

Real-world examples help illustrate the potential.

In manufacturing, autonomous robotics depend on real-time object detection and path planning; inference performed at the nearest base station can deliver sub-10ms decisions, avoiding production interruptions without the facility needing to deploy its own compute resources.
Field technicians in utilities or construction working with augmented reality tools can receive AI-generated diagnostics overlaid on live video feeds—processed at the edge for instant fault identification, such as detecting structural cracks, supporting faster decisions in remote settings.
Retail operations can use edge-based smart analytics to interpret camera feeds for customer behavior insights or immediate security alerts, generating millisecond-level responses without on-site servers.
In healthcare, wearables transmitting vital signs for anomaly detection (for instance, flagging potential cardiac events) can benefit from low-latency edge processing to deliver timely alerts, particularly valuable in rural or resource-constrained clinics.
Cloud gaming environments can also gain from edge-handled AI upscaling of graphics or intelligent NPC behavior, substantially reducing perceived lag for players and smaller studios that lack powerful local hardware.

By structuring these capabilities as on-demand, sliced services, operators could create additional revenue streams while enabling enterprises to adopt AI more broadly without prohibitive capital requirements.

Considerations for Moving Forward

Operators interested in these opportunities might begin by assessing their current latency profiles, edge compute footprint, and level of AI integration. From there, they could prioritize pilot deployments focused on inference before exploring federated training approaches for stronger privacy controls. Partnerships with cloud providers could help develop hybrid models that combine telco edge strengths with broader AI ecosystems. Early monetization might involve introducing "AI-Ready Connectivity" services—low-latency slices, edge GPU access, and intelligent routing designed for enterprises building AI-driven applications.

Telecom networks already offer a distinctive advantage: widespread, low-latency reach to millions of endpoints. Carriers that thoughtfully explore distributed AI capabilities could position themselves as important contributors to the evolving AI infrastructure landscape, potentially unlocking meaningful new value in a growing market.

Adapting telecom networks for AI

noreply@blogger.com (Patrick Lopez) — Fri, 21 Nov 2025 14:26:00 +0000

This interview was recorded by TelecomTV at FYUZ, the Telecom Infra Project's flagship show in Dublin in November 2025.

Why did Nokia acquire Juniper's RAN Intelligence and team?

noreply@blogger.com (Patrick Lopez) — Fri, 03 Oct 2025 14:02:00 +0000

You might have seen the headlines, Nokia announced on October 2nd the acquisition of Juniper Networks' RAN Intelligence team.

If you are not fully familiar with the space, here is a little perspective on this announcement and its impact on the market.

Juniper Networks had long looked to expand its footprint in operators networks beyond pure networking. Particularly, the RAN was a domain that was growing and of significant importance as it traditionally consumes up to 80% of the Capital Expenditure of a new telecom generation. It would have been costly and long to start an organic product development in the RAN radio or software (CU / DU) so the company smartly opted to attack a greenfield environment: the Open RAN RAN Intelligent Controller (RIC) space.

There are different flavours of RIC and Juniper selected the "easiest" and least controversial to start with, the non real time RIC. The company licensed source code from Turkcel's Netsia subsidiary and started development in 2021. The non RT RIC represents the evolution of Self Organizing Networks (SON), Element Management Systems (EMS) and of traditional Operational Support Systems (OSS). OSS is a market segment that has been dominated by AMDOCS and Netcracker, and represented two great opportunities for new entrants and traditional telco vendors:

A 20+ billion $ market segment that is ripe for disruption (entrenched legacy vendors, aging, proprietary technology, emerging cloud native standards and interfaces)
An "easy" entry into the (open) RAN market segment, with high control value, without having to develop the expensive, risky and difficult bits (radios and radio software).

Juniper Networks executed beautifully and even became an early leader in the RAN intelligence ecosystem in 2023. The market looked at this point like it was going to favour independent generalists such as Juniper and VMWare for early commercial launches, but HPE announced its acquisition of Juniper and Broadcom its acquisition of VMWare and the market took a pause to reconsider its options, unsure of HPE's and Broadcom's commitment to this space.

Meanwhile, traditional telecom vendors have caught up and Ericsson, Nokia, Samsung have announced different offering in the space. Nokia's strategy, in my mind wasn't very competitive, opting for near RT RIC rather than non RT RIC to start with. I have expanded my perspective on the market opportunity here.

With the acquisition of Juniper Network's RAN intelligence team and technology, Nokia is reinforcing its product offering with a leading technology team. It will be interesting to see how much progress has been made since the HPE's acquisition and how much effort will be necessary to integrate the capabilities within the larger Nokia product portfolio.

The 6G promise

noreply@blogger.com (Patrick Lopez) — Wed, 10 Sep 2025 17:54:00 +0000

As I attend TMForum Innovate Americas in Dallas, AI, automation and autonomous networks dominate the debates. I have long held the belief that the promise of 5G to deliver adapted connectivity to different organizations, industries, verticals and market segment was necessary for network operators to create sustainable differentiation. At Telefonica, nearly 10 years ago, I was positing that network slicing would only be useful if we were able to deliver hundreds or thousands or slices.

One of the key insights came from interactions with customers in the automotive, banking and manufacturing industries. The CIOs from these large organizations don’t want to be sold connectivity products. They don’t want the network operator to create and configure the connectivity experience.

The CIOs from Mercedes, Ford, Magna know better what their connectivity needs are and what kind of slices would be useful than the network operators serving them. They don’t want to have to spend time educating their providers so that they can design a service for them. They don’t want to outsource the optimization of their connectivity to a third party who doesn’t understand their evolving needs.

The growth in private networks implementations in healthcare, energy, mining, transportation and ports for instance, is a sign that there is demand in dedicated, customized connectivity products. It is also a sign that network operators have failed so far to build the slicing infrastructure and capacity to serve these use cases.

As a result, I proposed that network operators should focus on creating a platform for industries to discover, configure and consume connectivity services. This vision had a lot of prerequisites. Networks need to evolve and adopt network virtualization through separation of hardware and software, cloud native functions, centralized orchestration, stand-alone core, network slicing, the building of the platform and API exposure…

A lot of progress has been made in all these categories, to the point that we see emerging the first dedicated slicing solutions for first responders, defense and industries. These slices are still mostly statically provisioned and managed by the network operators, but they will gradually grow.

The largest issue for evolving from static to dynamic slicing and therefore moving from network operated to as a service user configurable is managing conflicts between the slices. Dedicating static capacity for each slice is inefficient and too cost prohibitive to implement at scale except for the largest governmental use cases. Dynamic slicing creation and management requires network observability, jointly with near real time capacity prediction, reservation, and attribution.

This is where AI can provide the missing step to enable dynamic slicing for network as a service. If you can extract data from the user device, network telemetry and functions fast enough to be made available to algorithms for pattern identification in near real time, you can identify the device, user, industry, service and create the best fit connectivity, whether for a gaming console connected to a 4K TV in FWA, a business user on a video conference call, industrial collaborating robots assembling a vehicle, or a drone delivering a package.

All these use cases have different connectivity needs that are today either served by best effort undifferentiated connectivity or rigidly rule-based private networks.

As 6G is starting to emerge, will it fulfil the 5G promises and deliver curated connectivity experiences?

The Orchestrator Conundrum strikes again: Open RAN vs AI-RAN

noreply@blogger.com (Patrick Lopez) — Thu, 31 Jul 2025 16:34:00 +0000

10 years ago (?!) I wrote about the overlaps and potential conflicts of the different orchestration efforts between SDN and NFV. Essentially, observing that, ideally, it is desirable to orchestrate network resources with awareness of services and that service and resource orchestration should have hierarchical and prioritized interactions, so that a service deployment and lifecycle is managed within resource capacity and when that capacity fluctuates, priorities can be enforced.

Service orchestrators have not really been able to be successfully deployed at scale for a variety a reasons, but primarily due to the fact that this control point was identified early on as a strategic effort for network operators and traditional network vendors. A few network operators attempted to create an open source orchestration model (Open Source MANO), while traditional telco equipment vendors developed their own versions and refused to integrate their network functions with the competition. In the end, most of the actual implementation focused on Virtual Infrastructure Management (VIM) and vertical VNF management, while orchestration remained fairly proprietary per vendor. Ultimately, Cloud Native Network Functions appeared and were deployed in Kubernetes inheriting its native resource management and orchestration capabilities.

In the last couple of years, Open RAN has attempted to collapse RAN Element Management Systems (EMS), Self Organizing Networks (SON) and Operation Support Systems (OSS) with the concept of Service Management and Orchestration (SMO). Its aim is to ostensibly provide a control platform for RAN infrastructure and services in a multivendor environment. The non real time RAN Intelligent Controller (RIC) is one of its main artefacts, allowing the deployment of rApps designed to visualize, troubleshoot, provision, manage, optimize and predict RAN resources, capacity and capabilities.

This time around, the concept of SMO has gained substantial ground, mainly due to the fact that the leading traditional telco equipment manufacturers were not OSS / SON leaders and that Orchestration was an easy target for non RAN vendors wanting to find a greenfield opportunity.

As we have seen, whether for MANO or SMO, the barriers to adoption weren't really technical but rather economic-commercial as leading vendors were trying to protect their business while growing into adjacent areas.

Recently, AI-RAN as emerged as an interesting initiative, positing that RAN compute would evolve from specialized, proprietary and closed to generic, open and disaggregated. Specifically, RAN compute could see an evolution, from specialized silicon to GPU. GPUs are able to handle the complex calculations necessary to manage a RAN workload, with spare capacity. Their cost, however, greatly outweighs their utility if used exclusively for RAN. Since GPUs are used in all sorts of high compute environments to facilitate Machine Learning, Artificial Intelligence, Large and Small Language Models, Models Training and inference, the idea emerged that if RAN deploys open generic compute, it could be used both for RAN workloads (AI for RAN), as well as workloads to optimize the RAN (AI on RAN and ultimately AI/ML workloads completely unrelated to RAN (AI and RAN).

While this could theoretically solve the business case of deploying costly GPUs in hundreds of thousands of cell site, provided that the compute idle capacity could be resold as GPUaaS or AIaaS, this poses new challenges from a service / infrastructure orchestration standpoint. AI RAN alliance is faced with understanding orchestration challenges between resources and AI workloads

In an open RAN environment. Near real time and non real time RICs deploy x and r Apps. The orchestration of the apps, services and resources is managed by the SMO. While not all App could be categorized as "AI", it is likely that SMO will take responsibility for AI for and on RAN orchestration. If AI and RAN requires its own orchestration beyond K8, it is unlikely that it will be in isolation from the SMO.

From my perspective, I believe that the multiple orchestration, policy management and enforcement points will not allow a multi vendor environment for the control plane. Architecture and interfaces are still in flux, specialty vendors will have trouble imposing their perspective without control of the end to end architecture. As a result, it is likely that the same vendor will provide SMO, non real time RIC and AI RAN orchestration functions (you know my feelings about near real time RIC).

If you make the Venn diagram of vendors providing / investing in all three, you will have a good idea of the direction the implementation will take.

Is AI-RAN the future of telco?

noreply@blogger.com (Patrick Lopez) — Wed, 16 Apr 2025 16:39:00 +0000

AI-RAN has emerged recently as an interesting evolution of telecoms networks. The Radio Access Network (RAN) has been undergoing a transformation over the last 10 years, from a vertical, proprietary highly concentrated market segment to a disaggregated, virtualized, cloud native ecosystem.

Product of the maturation of a number of technologies, including telco cloudification, RAN virtualization and open RAN and lately AI/ML, AI-RAN has been positioned as a means to disaggregate and open up further the RAN infrastructure.

This latest development has to be examined from an economic standpoint. RAN accounts roughly for 80% of a telco deployment (excluding licenses, real estate...) costs. 80% of these costs are roughly attributable to the radios themselves and their electronics. The market is dominated by few vendors and telecom operators are exposed to substantial supply chain risks and reduced purchasing power.

The AI RAN alliance was created in 2024 to accelerate its adoption. It is led by network operators (T-Mobile, Softbank, Boost Mobile, KT, LG Uplus, SK Telecom...) telecom and IT vendors (Nvidia, arm, Nokia, Ericsson Samsung, Microsoft, Amdocs, Mavenir, Pure Storage, Fujitsu, Dell, HPE, Kyocera, NEC, Qualcomm, Red Hat, Supermicro, Toyota...).

If you are familiar with this blog, you already know of the evolution from RAN to cloud RAN and Open RAN, and more recently the forays into RAN intelligence with the early implementations of near and non real time RAN Intelligence Controller (RIC).

AI-RAN goes one step further in proposing that the specialized electronics and software traditionally embedded in RAN radios be deployed on high compute, GPU based commercial off the shelf servers and that these GPUs manage the complex RAN computation (beamforming management, spectrum and power optimization, waveform management...) and double as a general high compute environment for AI/ML applications that would benefit from deployment in the RAN (video surveillance, scene, object, biometrics recognition, augmented / virtual reality, real time digital twins...). It is very similar to the edge computing early market space.

The potential success of AI-RAN relies on a number of techno / economic assumptions:

For Operators:

It is desirable to be able to deploy RAN management, analytics, optimization, prediction, automation algorithms in a multivendor environment that will provide deterministic, programmable results.
Network operators will be able and willing to actively configure, manage and tune RAN parameters.
Deployment of AI-RAN infrastructure will be profitable (combination of compute costs being offloaded by cost reduction by optimization and new services opportunities).
AI-RAN power consumption, density, capacity, performance will exceed traditional architectures in time.
Network Operator will be able to accurately predict demand and deploy infrastructure in time and in the right locations to capture it.
Network Operators will be able to budget the CAPEX / OPEX associated with this investment before revenue materialization.
An ecosystem of vendors will develop that will reduce supply chain risks

For vendors:

RAN vendors will open their infrastructure and permit third parties to deploy AI applications.
RAN vendors will let operators and third parties program the RAN infrastructure.
There is sufficient market traction to productize AI-RAN.
The rate of development of AI and GPU technologies will outpace traditional architecture.
The cost of roadmap disruption and increased competition will be outweighed by the new revenues or is the cost to survive.
AI-RAN represents an opportunity for new vendors to emerge and focus on very specific aspects of the market demand without having to develop full stack solutions.

For customers:

There will be a market and demand for AI as a Service whereas enterprises and verticals will want to use a telco infrastructure that will provide unique computing and connectivity benefits over on-premise or public cloud solutions.
There are AI/ML services that (will) necessitate high performance computing environments, with guaranteed, programmable connectivity with a cost profile that is better mutualized through a multi tenant environment
Telcom operators are the best positioned to understand and satisfy the needs of this market
Security, privacy, residency, performance, reliability will be at least equivalent to on premise or cloud with a cost / performance benefit.

As the market develops, new assumptions are added every day. The AI-RAN alliance has defined three general groups to create the framework to validate them:

AI for RAN: AI to improve RAN performance. This group focuses on how to program and optimize the RAN with AI. The expectations is that this work will drastically reduce the cost of RAN, while allowing sophisticated spectrum, radio waves and traffic manipulations for specific use cases.
AI and RAN: Architecture to run AI and RAN on the same infrastructure. This group must find the multitenant architecture allowing the system to develop into a platform able to host a variety of AI workloads concurrently with the RAN.
AI on RAN: AI applications to run on RAN infrastructure. This is the most ambitious and speculative group, defining the requirements on the RAN to support the AI workloads that will be defined

As for Telco Edge Computing, and RAN intelligence, while the technological challenges appear formidable, the commercial and strategic implications are likely to dictate whether AI RAN will succeed. Telecom operators are pushing for its implementation, to increase control over spending, and user experience of the RAN, while possibly developing new revenue with the diffusion of AIaaS. Traditional RAN vendors see the nascent technology as further threat to their capacity to sell programmable networks as black boxes, configured, sold and operated by them. New vendors see the opportunity to step into the RAN market and carve out market share at the expense of legacy vendors.

MWC 25 thoughts

noreply@blogger.com (Patrick Lopez) — Tue, 11 Mar 2025 02:09:00 +0000

Back from Mobile World Congress 2025!

I am so thankful I get to meet my friends, clients, ex colleagues year after year and to witness how our industry is moving first hand.

2025 was probably my 23rd congress or so and I always find it invaluable for many reasons.

Innovation from the East

What stood up for me this year was how much innovation is coming from Asian companies, while most Western companies seem to be focusing on cost control.

The feeling was pervasive throughout the show and the GLOMO awards winners showed Huawei, ZTE, China Mobile, SK, Singtel… investing in discovering and solving problems that many in Western markets dismiss as futuristic or outside their comfort zone. In mature markets, where price attrition is the rule, differentiation is key.

On a related topic, being Canadian, I can’t help thinking that many companies and regulators who looked at the banning of some Chinese vendors from their markets due to security preoccupations are now finding themselves in the situation to evaluate whether American suppliers do not also represent a risk in the future.

Without delving into politics, I saw and heard many initiatives to enhance security, privacy, sovereignty, either in the cloud or the supply chain categories.

Open telco APIs

Open APIs and the progress of telco networks APIs is encouraging, but while it is a good idea, it feels late and lacking in comparison with webscalers tooling and offering to discover, consume, and manage network functions on demand. Much work remains to be done in my opinion to enhance the aaS portion of the offering, particularly if slicing APIs are to be offered.

Open RAN & RIC

Open RAN threat has successfully accelerated cloud and virtualized RAN adoption. Samsung started the trend and Ericsson’s deployment at AT&T has crystalized the mMIMo +CU+DU+non RT RIC from a main vendor and small cells + rApps from others as a viable option. Vodafone’s RAN refresh should see maybe more players into the mix as Mavenir and Nokia are struggling to gain meaningful market share.

The Juniper / HPE acquisition drama, together with the Broadcom / VMware commercial strategy seem to have killed the idea of an independent Non RT RIC vendor. Near RT RIC, remains in my mind a flawed proposition as host of 3rd party xApps, and as an expensive gadget for anything else than narrow use cases.

AI

AI of course, was the belle of the ball at MWC. Everyone had a twist, a demo, a model, an agent but few were able to demonstrate utility beyond automated time series regression as predictions or LLM based natural language processing as nauseam…

Some were convincingly starting to show Small Models that were tailored to their technology, topology and network with promising results. It is still early but it feels that this is where the opportunity lies. The creation and curation of a dataset that can be used to plan, manage, maintain, predict the state of one’s network, with bespoke algorithms seems more desirable than the wholesale vague large and poorly trained models.

Telco Cloud and Edge computing is having a bit of a moment with AI and GPU aaS strategies being enacted.

All in all, many are trying to develop an AI strategy, and while we are still far from the AI-Native Telco Network, there is some progress and some interesting ventures amidst the noise.

The AI-Native Telco Network VI: Storage

noreply@blogger.com (Patrick Lopez) — Thu, 06 Feb 2025 21:35:00 +0000

The AI-Native Telco Network I

The AI-Native Telco Network II

The AI-Native Telco Network III

The AI-Native Telco Network IV: Compute

The AI-Native Telco Network V: Network

As it turns out, a network that needs to run AI, either to self optimize or to offer wholesale AI related services needs some adjustments from a conventional telecom network. After looking at the compute and network functions, this post is looking at storage.

Storage has, for the longest time, been an afterthought in telecoms networks. Beyond the IT workloads and the management of data centers, storage needs were usually addressed embedded with the compute functions, sold by server vendors, or when necessary as direct attached storage appliances, usually OEMd or resold by the same vendors.

Today's networks see each network function, whether physical, virtualized or containerized coming with its own dedicated storage. The data generated by each function, whether telemetry, alarm, user, or control plane, logs or event is stored first locally, then a portion is exported to a data lake for cleaning and processing, then eventually a data warehouse, whether on a private or public cloud so that OSS, BSS and analytics functions can provide dashboards on the health, load, usage of the network and recommendations on optimizations.

The extraction, cleaning, and processing of these disparate datasets takes time, anywhere between 30 minutes to hours to accurately represent the network state.

One of the applications of AI/ML in telecoms networks is to optimize the networks reactively when there is an event or proactively when we can plan for a given change. This supposes that a feedback loop is built between the analytics layer and the operational layer, whereas a recommendation to change network parameters can be executed programmatically and automatically.

Speed becomes necessary, particularly to react to unpredicted events. Reducing reaction time if there is an element outage is crucial. This supposes that the state of the network must be observable in near real time, so that the AI/ML engines can detect patterns, anomalies and provide root cause analysis and remediation as fast as possible. The compute applied to these calculations, together with the speed of transmission have a direct effect on the speed, but not only.

Storage, as it turns out is also a crucial element of creating an AI-Native network. The large majority of AI/ML relies on storing data as object, whereas each data element is stored independently, in an unstructured manner, irrespective of size, but with an associated metadata file that describes the data element in details, allowing easy association and manipulation for AI/ML.

Why are traditional storage architectures not suitable for AI-Native Networks?

To facilitate the AI Native network, data element must be extracted from their network functions fast and transferred in a data repository that allows their manipulation at scale. It is easier said than done. Legacy systems have been built originally for block storage (databases and virtual machines, great for low latency, bad for high throughput). Objects are usually not natively supported and are in separate storage. Each vendor supports different protocols and interface, and each store is single tenant to its application.

Data needs to be shared and read by many network functions simultaneously, while they are being processed. Traditional architectures see data stored individually by network functions, then exported to larger databases, then amalgamated in data lakes for processing. The process is lengthy, error-prone and negates the capacity to act/react in real time.

The data sets are increasingly varied, between large and small objects, data streams and files, random and sequential read and write requirements. Legacy storage solutions require different systems for different use cases and data sets. This lengthens further the data amalgamation necessary for automation at scale.

Data needs to be properly labeled, without limitation of metadata, annotation and tags equally for billions of small objects (event records) or very large ones (video files). Traditional storage solutions are designed either for small or large objects and struggle to accommodate both in the same architecture. They also have limitations in the amount of metadata per object. This increases cost and time to insight while reducing their capacity to evolve.

Datasets are live structures. They often exist in different formats and versions for different users. Traditional architectures are not able to handle multiple formats simultaneously, and versions of the same datasets require separate storage elements. This leads to data inconsistencies, corruption and divergence of insight.

Performance is key in AI systems, and it is multidimensional. Storage solutions need to be able to accommodate simultaneously high throughput, scale out capacity and low latency. Traditional storage systems are built for capacity but not designed for high throughput and low latency, which reduces dramatically the performance of data pipelines.

Hybrid and multi cloud become a key requirement for AI, as data needs to be exposed to access, transport, core, OSS/ BSS domains in the edge, the private cloud and the public cloud simultaneously. Traditional storage solutions necessitate adaptation, translation, duplication, and migration to be able to function across cloud boundaries, which significantly increase their cost, while reducing their performance and capabilities.

As we have seen, the data storage architecture for a telecom network becomes a strategic infrastructure decision and the traditional storage solutions cannot accommodate AI and network automation at scale.

Storage Requirements for AI-Native Networks

Perhaps the most important attribute for AI project storage is agility—the ability to grow from a few hundred gigabytes to petabytes, to perform well with rapidly changing mixed workloads, to serve data to training and production clients simultaneously throughout a project’s life, and to support the data models used by project tools.

The attributes of an ideal AI storage solution are:

Performance Agility

• I/O performance that scales with capacity.

• Rapid manipulation of billions of items, e.g., for randomization during training.

Capacity Flexibility

• Wide range (100s of gigabytes to petabytes) .

• High performance with billions of data items.

• Range of cost points optimized for both active and seldom accessed data.

Availability & Data Durability

• Continuous operation over decade-long project lifetimes.

• Protection of data against loss due to hardware, software, and operational faults.

• Non-disruptive hardware and software upgrade and replacement.

• Seamless data sharing by development, training, and production.

Space and Power Efficiency

• Low space and power requirements that free data center resources for power-hungry computation.

Security

• Strong administrative authentication.

• “Data at rest” encryption.

• Protection against malware (especially ransomware) attacks.

Operational Simplicity

• Non-disruptive modernization for continuous long-term productivity.

• Support for AI projects’ most-used interconnects and protocols.

• Autonomous configuration (e.g. device groups, data placement, protection, etc.).

• Self-tuning to adjust to rapidly changing mixed random/ sequential I/O loads.

Hybrid and Multi Cloud Natively

• Data agility to cross cloud boundaries

• Centralized data lifecycle management

• Decide which data set is stored and processed where

• From edge for inference to private cloud for optimization and automation to public cloud for model training and replication.

Traditional "spinning disk" based storage have not been designed for AI/ML workloads. They lack the performance, agility, cost effectiveness, latency, power consumptions attributes necessary to enable AI networks at scale. Modern storage infrastructure, designed for high performance computing rely on Flash storage, an efficient, cost effective, low power, high performance technology that enables compute and network elements to perform at line rate for AI workloads.

The AI-Native Telco Network V: Network

noreply@blogger.com (Patrick Lopez) — Tue, 28 Jan 2025 18:10:00 +0000

The AI-Native Telco Network I

The AI-Native Telco Network II

The AI-Native Telco Network III

The AI-Native Telco Network IV: Compute

As we have seen in previous posts, AI and the journey to autonomous networks forces telco operators to look at their network architecture and reevaluate whether their infrastructure is fit for this purpose. In many cases, the first reflex for them is to deploy new servers and GPUs in AI dedicated pods and to find out that processing power itself is not enough for a high performance AI system. The network connectivity needs to be accelerated as well.

SmartNICs

While dedicated routing and packet processing are necessary, one way to increase performance of an AI pod is to deploy accelerators in the shape of Smart Network Interface Cards (SmartNICs).

SmartNICs are specialized network cards designed to offload certain networking tasks from the CPU and provide additional processing power at the network edge. Unlike traditional NICs, which merely serve as communication devices, SmartNICs come equipped with onboard processing capabilities such as CPUs, ASICs, FPGAs or programmable processors. These capabilities allow SmartNICs to handle packet processing, traffic management, and other networking tasks, without burdening the CPU.

While they are certainly hybrid compute / network dedicated silicon, they accelerate overall performance by offloading packet processing, user plane functions, load balancing, etc. from the CPUs and GPUs that can be freed up for pure AI workload processing.

For telecom providers, SmartNICs offer a way to improve network efficiency while simultaneously boosting the ability to handle AI workloads in real-time.

High-Speed Ethernet

One of the most straightforward ways to increase network speed is by adopting higher bandwidth Ethernet standards. Traditional networks may rely on 10GbE or 25GbE, but AI workloads benefit from faster connections, such as 100GbE or even 400GbE, which provide higher throughput and lower latency.

AI models, especially large deep learning models, require massive data transfer between nodes. Upgrading to 100GbE or 400GbE can drastically improve the speed at which data is exchanged between GPUs, CPUs, and storage systems in an AI pod, reducing the time required to train models and increasing throughput.

AI models often need to pull vast amounts of training data from storage. Higher-speed Ethernet allows AI pods to access data more quickly, decreasing bottlenecks in I/O.

Use Low-Latency Networking Protocols

Adopting advanced networking protocols such as InfiniBand or RoCE (RDMA over Converged Ethernet) is essential to reduce latency in AI pods. These protocols are designed to enable faster communication between nodes by bypassing traditional network stacks and reducing the overhead that can slow down AI workloads.

InfiniBand and RoCE provide extremely low-latency communication between AI pods, which is crucial for high-performance AI training and inference.
These protocols support higher bandwidths (up to 200Gbps or more) and provide more efficient communication channels, ideal for high-throughput AI workloads like distributed deep learning.

To increase AI performance, telecom operators need to focus on upgrading their network infrastructure to support the growing demands of AI workloads. By implementing strategies such as high-speed Ethernet, SmartNICs, and specialized AI interconnects, operators can enhance the speed, scalability, and efficiency of their AI pods. This enables faster processing of large datasets, reduced latency, and improved overall performance for AI training and inference, allowing telecom operators to stay ahead in the competitive AI-driven landscape.

Storage, we will see in the next post, plays also an integral part in AI performance on a telecom network.

The AI-Native Telco Network IV: Compute

noreply@blogger.com (Patrick Lopez) — Thu, 23 Jan 2025 15:44:00 +0000

The AI-Native Telco Network I

The AI-Native Telco Network II

The AI-Native Telco Network III

As we have seen in previous posts, to accommodate and make use of AI at scale, a network must be tuned and architected for this purpose. While any telco network can deploy AI in discrete environments or throughout its fabric, the difference between a Data strategy and an AI strategy is speed + feedback loop.

Most Data collected in a telco network has been used for very limited purpose. Mainly archiving for forensics to determine the root cause of an anomaly or outage, charging and customer management functions or for legal interception or regulatory requirements. For these use cases, Data needs to be properly formatted and laid to rest until analytics engines can provide a representation of the state of the network or an account. Speed is not an issue here, the system can suffer minutes or hour delays before a coherent picture is formed and represented.

AI altogether can provide better insight through larger datasets than classical analytics. It provides better capacity to correlate events and to predict the evolution of the network state. It can also propose optimization, enhancements, mitigation recommendations, but to be truly effective, it needs to be able to have feedback loop to the network functions, so that these recommendations can be turned into actions and automated.

Herein lies the trick. If you want to run AI in your network, so that you can automate it, allowing it to reactively or proactively auto scale, heal, optimize its performance, power consumption, cost, etc... at scale, it cannot be done manually. Automation is necessary throughout. Speed from event, anomaly, pattern, insight detection to action becomes key.

As we have seen, speed is the product of high performance, low latency in the production, extraction, storage, and processing of data to create actionable insights that can be automated. At the fabric layer, compute, connectivity and storage are the elements that need to be properly designed to enable the speed to run AI.

In this post, we will look at the compute function. Processing, analyzing, manipulating Data requires computing capabilities. There are different architectures of computing units for different purposes.

The CPU (Central Processing Units) are general purpose computing, suitable for serial tasks. Multiple CPU Cores can work in parallel to enhance performance. Suitable for most telecoms functions, except real time processing. Generic CPUs are used in most telco data centers and clouds for most telco functions, from OSS, BSS to Core and transport. At the edge and the RAN, CPUs are used for Centralized Unit functions.
ASICs (Application Specific Integrated Circuits) are CPUs that have been designed for specific tasks or applications. They are not as versatile as other processing units but deliver the absolute highest performance in smallest footprint for specific applications. They can be found in first generation Open RAN servers to run Distributed Unit functions, as well as in specialized packet routing and packet switching (more on that in the connectivity post).
FPGA (Field Programmable Gate Arrays) are CPUs that can be programmed to adapt to specific workloads without necessitating complete redesign. They provide a good balance between adaptability and performance and are suitable for cryptographic and rapid data processing. They are used in telco networks in security gateways, as well as advanced routing and packet processing functions.
GPUs (Graphics Processing Units) feature large numbers of smaller cores, coupled with high memory bandwidth making them suitable for graphics processing and large number of parallel matrix calculations. In telco network, GPUs are starting to be introduced for AI / ML workloads in data centers and clouds (neural networks and model training), as well as in the RAN for the Distributed Unit and RAN Intelligent Controller.
TPUs (Tensor Processing Units) are Google's specialized processing units optimized for Tensor processing of ML and deep learning model training and inference. They are not yet used in Telco environments but can be used on Google Cloud in a hybrid scenario.
NPUs (Neural Processing Units) are designed for Neural Networks for deep learning processing. They are very suitable for inference tasks as their power consumption and footprint are very small. They start to appear in telco networks at the edge, and in devices.

Artificial Intelligence, Machine Learning can run on any of the above computing platform. The difference is the performance, footprint, cost and power consumption profile. We have seen lately the emergence of GPUs as the new processing unit poised to replace CPUs, ASICs and FPGAs in specialized traffic functions, using the RAN and AI as its beachhead. GPUs are key in running AI workloads at scale , delivering the performance in terms of low latency and high throughput necessary for rapid time to insight.

Their cost and power consumption forces network operators to find the right balance between the number of GPUs and their placement throughout the network, to enable both high processing power necessary for model training, in the private cloud, together with low latency for rapid inferencing and automation at the edge. While this architecture might provide the best basis for an automated or autonomous network, its cost and the rapid rate of change in GPU generations might give most a pause.

The main challenge becomes the selection of compute architecture that can provide the most capacity, speed, while remaining cost effective to procure and run. For this reason, many telco operators have decided to centralize in a first step their GPU farms, to fine tune their use cases, with limited decentralized deployments. Another avenue for exploration is the wholesaling of the compute capacity to reduce internal costs. We have seen a few GPUaaS and AIaaS initiatives recently announced.

In any cases, most operators who have deployed high capacity AI pods with GPUs, find that the performance of the overall system requires further refinement and look at connectivity as the next step in their AI-Native network journey. That will be the theme of our next post.

The AI-Native Telco Network III

noreply@blogger.com (Patrick Lopez) — Thu, 19 Dec 2024 14:44:00 +0000

The AI Native Telco Network I

The AI Native Telco Network II

Telecommunications Networks have evolved over time to accommodate voice, texts, images, web browsing, video streaming and social media. Radio, transport and core networks have seen radical evolution to accommodate these. Recently, Cloud computing has influenced telecom networks designs, bringing separation of control /user plane, hardware /software and centralization of management, configuration, orchestration and administration functions.

Telecom networks have always generated and managed enormous amounts of data which have historically been stored in local appliances, then offloaded to larger specialized data storage systems for analysis, post processing and analytics. The journey between the creation of the data to its availability for insight was 5-10 minutes. This was fine as long as data was used for alarming, dashboards and analytics.

Lately, Machine Learning, used to detect patterns in large data sets and to provide actionable insights, has undergone a dramatic acceleration with advances in Artificial Intelligence. AI has changed the way we look at data by opening the promises of network and patterns predictability, automation at scale and ultimately autonomous networks. Generative AI, Interpretative AI and Predictive AI are the three main applications of the technology.

Generative AI is able to use natural language as an input and to create text, documentation, pictures, videos, avatars and agents, intuiting the intent behind the prompt by harnessing Large Language Models.

Interpretative AI provides explanation and insight from large datasets, to highlight patterns, correlation and causations that go unnoticed if processed manually.

Predictive AI draws from time series and correlation pattern analysis to propose predictions on the evolution of these patterns.

Implementing an AI-Native network requires careful consideration - the way data is extracted, collected, formatted, exported, stored before processing has an enormous impact on the quality and precision of the AI output.

To provide its full benefit, AI is necessarily distributed, with Large Language Models training better suited for large compute clusters in private or public clouds, while inference and feedback loop management is more adequately deployed at the edge of the network, particularly for latency sensitive services.

In particular, the extraction and speed of transmission of the data, throughout the compute continuum, from edge to cloud is crucial to an effective AI native infrastructure strategy.

In a telecom network, the compute continuum consists of the device accessing the network, the Radio Access Network with its Edge, the Metro and Regional Central Offices, the National Data Centers hosting the Private Cloud and the International Data Centers hosting the Public Clouds.

As network operators examine the implications of running AI in their networks, enhancing, distributing and linking compute, storage and networking throughout the continuum becomes crucial.

Compute is an essential part of the AI equation but it is not the only one. For AI to perform at scale, connectivity and storage architecture are key.

To that end, large investments are made to deploy advanced GPUs, SmartNICs and next generation storage from the edge to the cloud, to allow for hierarchized levels of model training and inference.

One of the applications of AI is the detection of patterns in large data sets, allowing the prediction of an outcome or the generation of an output based on statistical analysis. The larger the datasets, the more precise the pattern detection, the more accurate the prediction, the more human-like the output.

In many cases, AI engines can create extremely good predictions and output based on large datasets. The data needs to be accurate but not necessarily recent. Predicting seasonal variations in data traffic in a network, for instance, requires accurate time series, but not up to the minute refresh.

However, networks automation and the path to autonomous require datasets to be perpetually enriched and refreshed with real time data streams, enabling fast optimization or adaptation.

Telecoms networks are complex, composed of many domains, layers and network functions. While they are evolving towards cloud native technology, all networks have a certain amount of legacy, deployed in closed appliances, silos or monolithic virtual machines.

To function at scale in its mission of automation towards autonomous networks, AI needs a real time understanding of the network state, health, performance, across all domains and network functions. The faster data can be extracted and processed, the faster the feedback loop and the reaction or anticipation of network and demand events.

As AI applications scale, the network infrastructure must be able to handle increased data traffic without compromising performance. High-speed data transmission and low latency are key to maintaining scalability. For applications like autonomous vehicles, real-time fraud detection, and other AI-driven services, low latency ensures a seamless and responsive user experience. Data transmission speed and low latency are essential for the efficient and effective operation of AI-based network automation, enabling real-time processing, efficient data handling, improved performance, scalability, and enhanced user experience.

There are several elements that impact latency and data transmission in a telecom network. Among those is how fast traffic can be computed throughout the continuum.

To that end, AI-Native Telco networks have been rethinking the basic architecture and infrastructure necessary for the networking, compute and storage functions.

I will examine in the subsequent posts the evolution of compute, networking and storage functions to enable networks to evolve to an AI-Native architecture.

The AI-Native Telco Network II

noreply@blogger.com (Patrick Lopez) — Mon, 16 Dec 2024 15:39:00 +0000

The AI-Native Telco Network I

I have been working on telco networks big Data, Machine Learning, Deep Learning and AI for the last 8 years or so. Between Interpretative AI, Predictive AI and Generative AI, we have seen much progress lately, but I think a lot of the discussions about using general Large Language Models for telco networks is not applicable.

Much of the datasets in Telcos, like in government and defense, is proprietary. It is not shared outside the organization and wouldn't suffer "contamination" from external sources unless under very specific conditions, for very limited subsets.

As a result, a large part of cloud-based, public LLMs are just noise as far as telcos are concerned. The largest opportunity is in proprietary, smaller models, where the algorithmics can be somewhat outsourced but the storage, processing, training of the model are in house. This type of sovereign or proprietary AI can better account for the specificity of a network and its users than larger models trained on generic data.

The problem many encounter is that the operators don't necessarily have all the data literacy or resource necessary to develop the algorithms or even to format the dataset properly, while specialized vendors might have the AI/ML domain expertise but cannot train the models on real data, since they are proprietary and stay on-network.

The result is telcos first focusing on the architecture and infrastructure of the data network and pipeline, the formatting and scrubbing of the dataset, the storage, processing and transmission of the data between on premise, private and the interaction with hybrid / public cloud instances.

Vendors are proposing a variety of solutions with promises of savings, new revenues and new services, but in many cases, they are based on models running on synthetic data and no one knows what the result will be until tested with the real dataset, tuned and remodeled.

Training models on synthetic data might be necessary for vendors but it's a bit like training for football in the hope to play rugby. Sure. some skills are transferable, but even a world class football player won't make it to professional rugby.

This is where the opportunity lies for operators. Recruit, train telco professionals to be data literate, so that they can understand how vendors should produce datasets and how to exploit them. This is not a spectator sport where you can just buy solutions off the shelf and let your vendors manage them for you.