Orange Business Moves Agentic AI Onto Open-Weight Models

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

Sovereignty is the differentiator

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

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

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

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

Agentic AI Could Raise Telco Opex by 30%

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

A new cost layer on top of the old one

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

Revenue is the stated priority, savings are the measured one

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

The number the business case is missing

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

What has not been published

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

The Telco AI $60 Billion "Opportunity"

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

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

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

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

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

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

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

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

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

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

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.

Is AI-RAN the future of telco?

 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: 

1. 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.
2. 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. 
3. 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.

Why was virtualized RAN started?

 

Traditional RAN equipment vendors have developed and deployed RAN solutions in every band, in every generation, for any network configuration. This doesn’t happen without an extremely well industrialized process, with rigid interfaces and change management. This cumulative intellectual property, together with the capacity to deploy in a few months a new generation of network is what operators have been valuing until now.

The creation of a new Radio platform is a large investment, in the range of tens of millions, with a development timeframe extending from 18 to 30 months. Because it is a complex solution, underpinned with large hardware dependencies, it requires very good planning and development management only available to highly industrialized companies. The development of subsequent radios on the same platform might take less time and costs, but essentially the economics remain the same, you need at least 10,000 units of firm order, for a radio to be economically viable.

It is expensive because it works. As long as you don’t mind being essentially dependent of your vendor for all professional services associated with their product, they can guarantee it will work. This part is key, because taking sole responsibility for deployment, operation and maintenance of a radio system is a huge undertaking. Essentially, the traditional vendors are selling together with equipment and services an insurance policy in the form of onerous Service Level Agreements (SLA), willing to undertake penalties and damages in case of failure.

Unfortunately, most network operators find themselves in a situation where, with the reduction of their Average Revenue per User (ARPU) combined with the perpetual traffic growth and appetite for video streaming, they see their costs steadily increase and their margins compressed. Connectivity seems increasingly like a commodity from a customer standpoint, with easy availability and low friction to change provider, whereas it comes at an increasing cost for its operators.

Changing the cost structure of buying capacity is a must for all networks operators to survive, and it touches all aspects of their network.

Fortunately, there are a few markets that have seen similar needs in the past and solutions have emerged. Particularly, the internet giants, video streaming services and social networks, have had to face explosive growth of traffic, with essentially flat pricing or advertising-based revenue models which forced them to reimagine how to scale their network capacity.

From there have emerged technologies such as network virtualization, Software Defined Networking (SDN) and their higher levels of abstraction leading to the cloud computing market as we know it.

Applying these methods and technologies to the RAN market seemed like a sensible and effective way to change its cost structure.

Edge computing risks and opportunities for operators and hyperscalers

 Part of a presentation to the World Bank's investment teams regarding institutional investment in ICT for emerging countries.

Edge Computing risks and Opportunities for Telco and hyperscalers from Patrick Lopez

The Lean Telco

As alluded to in my previous posts, I have tweaked the Lean Startup methodology 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 2020 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; SDN and 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 dollar 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 last role at Telefonica.

1. 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.
2. 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.
3. 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.
4. 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... 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 telco network virtualization (NFV), orchestration (MANO), cloud native distribution and orchestration (K8, micro service) and hybrid cloud / edge computing (telco private stacks, AWS outpost, MS Azure edge, Google Anthos...). 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 comprehension 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. 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 5G, augmented reality or a private network 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 will define 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.

NFV costs expectation gap

I am fresh off from an interesting week in sunny San Jose, at the NFV World Congress, where I chaired the operations stream on the first day.

As usual, it is a week where operators and vendors jostle to show off their progress since last year and highlight the challenges ahead. before I speak about the new and cool developments in terms of stateless VNFs, open source orchestration, containers, kubernetes and unikernels, I felt the need to share some observations regarding diverging expectations from traditional telecoms vendors, VNF vendors, systems integrators and operators.

While a large part of the presentations showed a renewed focus on operations in NFV, a picture started to emerge in my mind in terms of expectations between vendors, systems integrators and operators at the show.

Hardware
Essentially, everyone expects that the hardware bill for a virtualized network will reduce, due to the transition to x86 hardware. While this transition might mean less efficiency in the short term, all players seem to think that it will resolve itself over the next few years. In the meantime, DPDK and SR-IOV are used to address the performance gap between virtualization and traditional appliance, even at the cost of agility. By my estimate, the hardware cost reduction demonstrated by VNF vendors and systems integrators still falls short of operators expectations. Current figure places them around a 30% cost reduction vs. traditional model, whereas operators' expectations hover between 50 to 66%.

Software
This is an area where we see sharp expectations variations between all actors in the value chain.
VNF vendors expect to be able to somehow capture some of the hardware savings and translate them into additional license fees. This thinking is boosted by the need for internal business case to transition from appliance to software, to virtualized and eventually to orchestrated VNF. We are still very early in the market and software licensing models for VNFs are all over the place, in many case simply translated from the appliance model in other cases built from scratch but with little understanding of he value of specific functions in the overall service chain. Increased competition and market entering from non-traditional telco vendors will level the licensing structure over time.

Systems integrators are increasingly looking at VNFs as disposable. Operators tell them that they want to be able to have little dependency on vendors and to replace VNFs and vendors as needed, even running different vendors for the same function in different settings or slices. Systems integrator are buying into the rationale and are privileging their own VNFs, putting emphasis (and price premium) on their NFVI (infrastructure) and VNFM (management). Of course this leads also to the conclusion that while VNFs (and VNF vendors) should be interchangeable, the NFV MANO (management and orchestration) function will be very sticky and will likely stay a single vendor proposition in a given network. As a result, some are predicted the era of orchestrators war, which certainly feels timely, after the SDN management war (winner OpenStack), southbound interface war (winner OpenFlow), hypervisor war winner (KVM)...
I have spoken at length about the danger operators expose themselves if they vacate the orchestration field and leave systems integrators to rule it. It seems to have gained some traction with open source orchestration projects being pushed in standards. In any case, VNF vendors expect a growth in software licensing vs. appliance model, whereas integrators and operators expect a reduction.

Professional services
This is the area where everyone sees to agrees that an increase is inevitable. SDN and NFV provide layers upon layers of abstraction and while standards and open source are not fully defined, there is much integration and "enhancements" necessary to make a service on NFV work.
VNF vendors and operators who do not want to perform integration themselves usually expect a 50% increase vs. appliance projects, whereas integrators budget a robust 100% increase in average. This, of course, increases even further if the integrator is managing the infrastructure / service itself.

Maintenance and support
Vendors and integrators expect the ratio of these to be essentially comparable  to appliance models, whereas operators expect a sharp reduction, in light of all professional services being extended for integration and automation.

Total
VNF vendors behind closed doors will usually admit that, in the short term, the cost of rolling out a new VNF function /service might be a little higher than appliance, due to the performance gap and increase in professional services. There are sharp variations between traditional vendors that are porting their solutions to NFV and new vendors that cloud-native and have designed their solution for a software defined virtualized environment.
Systems integrator can show an overall cost reduction but usually because of proprietary "enhancements and optimization".
All are confident, though that automation and orchestration makes operation of existing services much cheaper and ramping up of new ones much faster. Expectations are that VNF architecture will be much more cost effective than appliance on a 3 to 5 years TCO model. Operators, on their end expect a NFV architecture to yield savings from day one, compared to appliance and to further increase this gap over a 3 years period.

SDN world 2015: unikernels, compromises and orchestrated obsolescence

Last week's Layer123 SDN and OpenFlow World Congress brought its usual slew of announcements and claims.

From my perspective, I have retained a contrasted experience from the show. 

On one hand, it is clear that SDN has now transitioned from proof of concept to commercial trial, if not full commercial deployment and operators are now increasingly understanding the limits of open source initiatives such as OpenStack for carrier-grade deployments. The telling sign is the increasing number of companies specialized in OpenFlow or other protocols high performance hardware based switches.

It feels that Open vSwitch has not hit its stride, notably in term of performance and operators are left with either going open source, cost efficient but not scalable nor performing or compromising with best of breed, hardware-based, hardened switches that offer high performance and scalability but not the agility of software-based implementation yet. What is new, however, is that operators seem ready to compromise for time to market, rather than wait for a possibly more open solution that could -  or not - deliver on its promises.

On the NFV front, I feel that many vendors have been forced to lower their silly claims in term of performance, agility and elasticity. It is quite clear that many of them have been called to prove themselves in operators' labs and have failed to deliver. In many cases, vendors are able to demonstrate agility, through VM porting / positioning using either their VNFM or an orchestrator's integration, they are even, in some cases, able to show some level of elasticity with auto-scaling powered by their own EMS, and many have put out press releases with Gbps or Tbps or millions of simultaneous sessions of capacity...
... but few are able to demonstrate all three at the same time, since their performance achievement has, in many cases been relying on SR-IOV to bypass the hypervisor layer, which ties the VM to the CPU in a manner that makes agility and elasticity extremely difficult to achieve.
Operators, here again, seem bound to compromise between performance or agility if they want to accelerate their time to market.

Operators themselves came in troves to show their progress on the subject, but I felt a distinct change in tone in term of their capacity to effectively get vendors deliver on the promises of the NFV successive white papers. One issue lies flatly on the operators' attitude themselves. Many MNO are displaying unrealistic and naive expectations. They say that they are investing in NFV as a means to attain vendor independence but they are unwilling to perform any integration themselves. It is very unlikely that large Telecom Equipment Manufacturer will willingly help deconstruct their value proposition by offering commoditized, plug-and-play, open interfaced virtualized functions.

SDN and NFV integration is still dirty work. Nothing really performs at line rate without optimization, no agility, flexibility, scalability is really attained without fine tuned integration. Operators won't realize the benefits of the technology if they don't get in on the integration work themselves.

At last, what is still missing from my perspective is a service creation strategy that would make use of a virtualized network. Most network operators still mention service agility and time to market as a key driver, but when asked what they would launch if their network was fully virtualized and elastic today, they quote disappointing early examples such as virtual (!?) VPN, security or broadband on demand... timid translations of existing "services" in a virtualized world. I am not sure most of the MNOs realize their competition is not each other but Google, Netflix, Uber, Facebook and others...
By the time they launch free and unlimited voice, data and messaging services underpinned by advertising or sponsored model, it will be quite late to think of new services, even if the network is fully virtualized. It feels like MNOs are orchestrating their own obsolescence.

At last, the latest buzzwords you must have in your presentation this quarter are:
The pet and cattle analogy, 
SD WAN,
5G

...and if you haven't yet formulated a strategy with respect to containers (Dockers, etc...) don't bother, they're dead and the next big thing are unikernels. This and more in my latest report and workshop on "SDN NFV in wireless networks 2015 / 2016".

Report from SDN / NFV shows part II

Today, I would like to address what, in my mind, is a fundamental issue with the expectations raised by SDN/NFV in mobile networks.
I was two weeks ago in Dallas, speaking at SDN NFV USA and the Telco Cloud forum.

While I was busy avoiding bodily fluids with everyone at the show, I got the chance to keynote a session (slides here) with Krish Prabhu, CTO of AT&T labs.

Krish explains that the main driver for the creation and implementation of Domain 2.0 is the fact that the company CAPEX while staggering at $20 billion per year is not likely to significantly increase, while traffic (used here as a proxy for costs) will increase at a minimum of 50% compounded annual growth rate for the foreseeable future.
Krish, then to lament:

"Google is making all the money, we are making all the investment, we have no choice but to squeeze our vendors and re architect the network."

Enter SDN / NFV.
Really? These are the only choices? I am a little troubled by the conclusions here. My understanding is that Google, Facebook, Netflix, in short the OTT providers have usually looked at creating services and value for their subscribers and then, when faced with unique success had to invent new technologies to meet their growth challenges.

Most of the rhetoric surrounding operators' reasons for exploring SDN NFV nowadays seem to be about cost reduction. It is extremely difficult to get an operator to articulate what type of new service they would launch if  their network was fully virtualized and software-defined today. You usually get the salad of existing network functions with the newly adorned "v". vBRAS, vFirewall, vDPI, vCPE, vEPC...
While I would expect these network functions to lend themselves to virtualization, they do not create new services or necessarily more value. A cheaper way to create, deploy, manage a firewall is not a new service.

The problem seems to be that our industry is again tremendously technology-driven, rather than customer-driven. Where are the marketers, the service managers who will invent, for instance, real-time voice translation services by virtualizing voice processing, translation functions in the phone and at the edge? There are hundred of new services to be invented, I am sure SDN NFV will help realize them. I bet Google is closer to enable this use case than most mobile network operators. That is a problem, because operators can still provide value if they innovate, but innovation must come first from services, not technology. We should focus on what first, how after.
End of the rant, more techno posts soon. If you like this, don't forget to buy the report.

Mobile network 2030

It is summer, nice and warm. England and Italy are out of the world cup, France will beat Germany on Friday, then Brazil and Argentina in the coming weeks to obtain their second FIFA trophy. It sounds like a perfect time for a little daydreaming and telecom fiction...

The date is February 15, 2030

The mobile world congress is a couple of weeks away and has returned to Cannes, as the attendance and indeed the investments in what used to be mobile networks have reduced drastically over the last few years. Finished are the years of opulence and extravagant launches in Barcelona, the show now looks closer to a medium sized textile convention than the great mass of flashy technology and gadgets it used to be in its heyday. 

When did it start to devolve? What was the signal that killed what used to be a trillion dollar industry in the 90's and early 2000's. As usual, there is not one cause but a sort of convergence of events that took a momentum that few saw coming and fewer tried to stop. 

Net neutrality was certainly one of these events. If you remember, back in 2011, people started to realize the level of penetration fixed and wireless networks were exposed to from legal and illegal interception. Following the various NSA scandals, public pressure mounted to protect digital privacy. 
In North America, the battle was fierce between pro and con neutrality, eventually leading to a status quo of sorts, with many content providers and network operators in an uneasy collaborative dynamic. Originally, content providers unwilling to pay for traffic delivery in wireless networks attempted to secure superior user experience by implementing increasingly bandwidth hungry apps. When these started to come in contention for network resources, carriers started to step in and aggressively throttle, cap or otherwise "optimize" traffic. In reaction, premium content providers moved to an encrypted traffic model as a means to obfuscate traffic and prevent interception, mitigation and optimization by carriers. Soon enough, though, the encryption-added costs and latency proved impractical. Furthermore, some carriers started to throttle and cap all traffic equally, claiming to adhere to the letter of net neutrality, which ended up having a terrible effect on  user experience. In the end cooler heads prevailed and content providers and carriers created integrated video networks, where transport, encryption and ad insertion were performed at the edge, while targeting, recommendation, fulfillment ended up in the content provider's infrastructure. 

In Europe, content and service providers saw at the same time "net neutrality" as the perfect excuse to pressure political and regulatory organizations to force network providers to deliver digital content unfiltered, un-prioritized at best possible effort. The result ended up being quite disastrous, as we know, with content being produced mostly outside Europe and encrypted, operators became true utility service providers. They discovered overnight that their pipes could become even dumber than they were.

Of course, the free voice and texting services launched by some of the 5G licensees new entrants in the 2020's accelerated the trend and nationalization of many of the pan European network operator groups.

The transition was relatively easy, since many had transcended to full virtual networks and contracted ALUSSON the last "european" Telecom Equipment Manufacturer to manage their networks. After they had spent collectively over 100 billion euros to virtualize it in the first place, ALUSSON emerged as the only clear winner of the cost benefits brought by virtualization. 
Indeed, virtualization was attractive and very cost effective on paper but proved very complex and organizationally intensive to implement in the end. Operators had miscalculated their capacity to shift their workforce from telecom engineering to IT when they found out that the skill-set to manage their networks always had been in the vendors' hands. Few groups were able to massively retool their workforce, if you remember the great telco strikes of 2021-2022.
In the end, most ended up contracting and transitioning their assets to their network vendor. Obviously, liberated from the task of managing their network, most were eager to launch new services, which was one of the initial rationale for virtualization. Unfortunately, they found out that service creation was much better implemented by small, agile, young entrepreneurial structures than large, unionized, middle aged ones... With a couple of notable exceptions, broadband networks were written off as broadband access was written in the European countries' constitutions and networks aggregated at the pan European level to become pure utilities when they were not downright nationalized.

Outside Europe and North America, Goopple and HuaTE dominate, after voraciously acquiring licenses in emerging countries, ill-equipped to negotiate the long term values of these licenses versus the free network infrastructures these companies provided. The launch of their proprietary SATERR (Satellite Aerial Terrestrial Relay) technology proved instrumental to creating the first fully vertical service /network/ content / device conglomerates.  

Few were the operators who have been able to discern the importance of evolving their core asset "enabling communication" into a dominant position in their market. Those who have succeeded share a few common attributes:

They realized first that their business was not about counting calls, bites or texts but enabling communication. They first started to think in term of services and not technology and understood that the key was in service enablement. Understating that services come and go and die in a matter of months in the new economy, they strove not to provide the services but to create the platform to enable them.

In some cases, they transitioned to full advertising, personal digital management agency, harnessing big data and analytics to enrich digital services with presence, location, preference, privacy, corporate awareness. This required much changes organizationally, but as it turned out, marketing analyst were much easier and cost effective to recruit than network and telecom engineers. Network management became the toolset, not the vocation. 

In other cases, operators became abstraction layers, enabling content and service providers to better target, advertise, aggregate, obfuscate, disambiguate, contextualize, physical and virtual communication between people and machines.

In all cases they understood that the "value chain" as they used to know it and the consumer need for communication services was better served by an ever changing ecosystem, where there was no "position of strength" and where coopetition was the rule, rather than the exception. 

LTE World Summit 2014

This year's 10th edition of the conference, seems to have found a new level of maturity. While VoLTE, RCS, IMS are still subjects of interest, we seem to be past the hype at last (see last year), with a more pragmatic outlook towards implementation and monetization. 

I was happy to see that most operators are now recognizing the importance of managing video experience for monetization. Du UAE's VP of Marketing, Vikram Chadha seems to get it:

"We are transitioning our pricing strategy from bundles and metering to services. We are introducing email, social media, enterprise packages and are looking at separating video from data as a LTE monetization strategy."

As a result, the keynotes were more prosaic than in the past editions, focusing on cost of spectrum acquisitions and regulatory pressure in the European Union preventing operators to mount any defensible position against the OTT assault on their networks. Much of the agenda of the show focused on pragmatic subjects such as roaming, pricing, policy management, heterogeneous networks and wifi/cellular handover. Nothing obviously earth shattering on these subjects, but steady progress, as the technologies transition from lab to commercial trials and deployment. 

As an example, there was a great presentation by Bouygues Telecom's EVP of Strategy Frederic Ruciak highlighting the company's strategy for the launch of LTE in France, A very competitive market, and how the company was able to achieve the number one spot in LTE market share, despite being the "challenger" number 3 in 2 and 3G.

The next buzzword on the hype cycle to point its head is NFV with many operator CTOs publicly hailing the new technology as the magic bullet that will allow them to "launch services in days or weeks rather than years". I am getting quite tired of hearing that rationalization as an excuse for the multimillion investments made in this space, especially when no one seems to know what these new services will be. Right now, the only arguable benefit is on capex cost containment and I have seen little evidence that it will pass this stage in the mid term. Like the teenage sex joke, no one seems to know what it is, but everybody claims to be doing it. 

There is still much to be resolved on this matter and that discussion will continue for some time. The interesting new positioning I heard at the show is appliance vendors referring to their offering as PNF (as in physical) in contrast and as enablers for VNF. Although it sounds like a marketing trick, it makes a lot of sense for vendors to illustrate how NFV inserts itself in a legacy network, leading inevitably to a hybrid network architecture. 

The consensus here seems to be that there are two prevailing strategies for introduction of virtualized network functions. 

1. The first one, "cap and grow" sees existing infrastructure equipments being capped beyond a certain capacity and little by little complemented by virtualized functions, allowing incremental traffic to find its way on the virtualized infrastructure. A variant might be "cap and burst" where a function subject to bursts traffic is dimensioned on physical assets to the mean peak traffic and all exceeding traffic is diverted to a virtualized function. 
2. The second seems to favour the creation of vertical virtualized networks for market or traffic segments that are greenfield. M2M and VoLTE being the most cited examples. 

Both strategies have advantages and flaws that I am exploring in my upcoming report on "NFV & virtualization in mobile networks 2014". Contact me for more information.

NFV & SDN Part II: Clouds & Openstack

I just came back from the OpenStack Summit taking place in Atlanta this week. In my quest to understand better SDN, NFV and Cloud maturity for mobile networks and video delivery, it is an unavoidable step. As announced a couple of weeks ago, this is a new project for me and a new field of interest.
I will chronicle in this blog my progress (or lack thereof) and will use this tool to try and explain my understanding of the state of the technology and the market. 
I am not a scientist and am somewhat slow to grasp new concepts, so you will undoubtedly find much to correct here. I appreciate your gentle comments as I progress.

So... where do we start? Maybe a couple of definitions.
Clouds
What is (are) the cloud(s)? Clouds are environments where software resources can be virtualized and allocated dynamically to instantiate, grow and shut down services.
Public clouds are made available by corporations to consumers and businesses in a commercial fashion. They are usually designed to satisfy a single need (Storage, Computing, Database...). 
The most successful examples can be Amazon Web Services, Google Drive, Apple iCloud, or DropBox. Pricing models are usually per hour rental of computing or database unit or per month rental of storage capacity. We will not address public clouds in this blog.

Private clouds are usually geo-dispersed capabilities federated and instantiated as one logical network capacity for a single company. We will focus here on the implementation of cloud technology in wireless networks. Typical use cases are simple data storage or development or testing sandbox.

Cloud technology relies on Openstack to abstract compute, storage and networking functions into logical elements and to manage heterogeneous virtualized environments. OpenStack is the Operating System of the cloud and it allows to instantiate Infrastructure or platform-as-a-service (respectively IAAS and PAAS).

OpenStack

The OpenStack program is also an open source community started by NASA and Rackspace, now independent and self governed. It essentially functions as a collaborative development community aimed at defining and releasing OpenStack software packages. 

After attending presentations and briefings from Deutsche Telecom, Ericsson, Dell, RedHat, Juniper, Verizon, Intel… I have drawn some very preliminary thoughts I would like to share here:

OpenStack is in its 9th release (IceHouse) and wireless interest is glaringly lacking. It has been setup primarily as an enterprise initiative and while enterprise and telecoms IT share many needs, wireless regulations tend to be much more stringent. CALEA (law enforcement), Sarbanes Oxley (accounting, traceability) are but a few of the provisions that would preclude OpenStack to run today in a commercial telco private cloud.

As presented by Verizon, Deutsche Telekom and other telcos at the summit, the current state of OpenStack does not allow it to be deployed "out of the box" without development and operations teams to patch, adapt and stabilize the system for telco purposes. These patches and tweaks have a negative impact on performance, scalability and latency, because they have not been taken into account at the design phase. They are workarounds rather than fixes. Case studies were presented, ranging from CDN video caching in a wireless infrastructure to generic sandbox for storage and software testing. The results show the lack of maturity of the technology to enable telco-grade services.

There are many companies that are increasingly investing in OpenStack, still I feel that a separate or focused telco working group must be created in its midst if we want it to reach telco-grade applicability.

More importantly, and maybe concerning is my belief that the commercial implementation of the technology requires a corresponding change in organizational setup and behaviour. Migrating to cloud and OpenStack is traditionally associated with the supposed benefits of increasing service roll out, reducing time to market, capex and opex as specialized telco appliance "transcend" to the cloud and are virtualized on off-the-shelf hardware.

There is no free lunch out there. The technology is currently immature, but as it evolves, we start to see that all these abstraction layers are going to require some very specialized skills to deploy, operate and maintain. these skills are very rare right now. Witness HP, Canonical, Intel, Ericsson all advertising "we are hiring" on their booths and during their presentations / keynotes. I have the feeling that operators who want to implement these technologies in the future will simply not have the internal skill set or capacity to roll them out. The large Systems Integrators might end up being the only winners there, ultimately reaping the cost benefits of a virtualized networks, while selling network-as-a-service to their customers.

Network operators might end up trading one vendor lock-in for another, much more sticky if their services run on a third party cloud. (I don't believe, we can realistically talk about service migration from cloud to cloud and vendor to vendor when 2 hypervisors supposedly running standard interfaces can't really coexist today in the same service).