Adapting telecom networks for AI

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

MWC 25 thoughts

 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

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

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

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 II

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.

Telco grade or cloud grade ? II

I have oftentimes criticized network operators’ naivety when it comes to their capacity to convince members of the ecosystem to adopt their telco idiosyncrasies.

I still have doubts that they will successfully create a profitable marketplace for open APIs, for instance, but today I want to turn towards the cloud providers' poor track record in telco.

On the heels of Microsoft’s abandonment of their telco software ambitions, one has to wonder whether all the perceived threats of cloud providers competing with telcos was warranted.

Between the rush from network operators to become cloud providers, to their precipitous exit, or the first iterations of AWS outpost and wavelength or Google Anthos or Microsoft Azure for operators, there has been multiple attempts for cloud and network operators to find coopetitive model.

While it would be easy to generalize, there are a few similarities between the approach of the webscalers even if the tactics have been different.

AWS has been the first to look at the telco market and try to monetize it. The initial idea was to try and convince the operators to deploy their cloud infrastructure in the data centers and central offices in the form of outposts. As its name suggests, AWS was looking at these as beachheads of managed infrastructure in the telco networks, with a view that more and more telco functions would run there.While the economic model was attractive, the operating model was incompatible with most operators ambitions.

Google, as the challenger in the public cloud space, took the approach of providing open source and do it yourself tools for telco cloud creation and operation. This model offered the most flexibility and cost efficiency but supposed skills and resource that were not immediately available for operators.

Microsoft adopted an intermediate approach, allowing operators to deploy their COTS Azure approved infrastructure and run a specific version of Azure integrated with the public cloud. Unfortunately, the company wasn't really quick to execute and the frequent changes in strategy, naming and services offering became very confusing for operators.

In my opinion, the cloud vendors neglected several things in their calculations:

• While operators at the time were still convinced that most telco functions weren’t suitable for a cloud grade environment, Cloud providers were convinced it was only a question of mindset and failed to understand the legitimate telco specific requirements for specialized compute or network synchronization for instance.
• The regulatory landscape might vary from market to market, but in most cases, data sovereignty, privacy, and security concerns weren’t properly factored in.
• Operators  usually need to be convinced that their vendors are committed to delivering and supporting their products products for at least 10 years (typical duration between the start of the sale cycle and the end of amortization).
• Very few network operators accept to be commoditized to a simple connectivity provider. They aim to provide ranges of products and services and saw the entrance of cloud providers in their networks as an existential threat.
• While over time, most operators came to accept that their network needed to evolve to be more like a cloud than a traditional telco network, they did not have the necessary skills and resources for a rapid evolution.
• Between cloud providers who envisioned that every telco functions could / should live in the public cloud and traditional operators who believed that all telco functions should be hosted on a private cloud or on premises, the reality is somewhere in between. Each operator has to arbitrate which function should be instantiated where, not only from a technological standpoint but more importantly from an economical perspective. These techno-economic models take time to evaluate.

On the positive side, vendors have been diligent in porting their software to the cloud, starting with BSS, OSS, Core and lately RAN functions. Most traditional and emerging vendors have been able to develop or port a large part of their offering into public / hybrid / private clouds environments.

This has benefited greenfield operators who have been able to leapfrog brownfield by adopting a cloud native operation from the start. This adaptation is still ongoing, though, and cloud providers are learning that there is more than elasticity to provide a telco grade cloud network.
Microsoft’s exit from the telco cloud software to focus on the infrastructure is understandable but reinforces the belief that cloud providers can be poor telco vendors.

It also highlights the need for telco operators to provide better cloud capabilities if they desire to capture the enterprise market. Enterprises use cloud providers for a variety of services and telco networks for the most basic utility connectivity. If operators want to stand a chance in that market, the need to evolve is more urgent than ever. Beyond offering APIs, operators need to build a platform to allow those enterprise customers who want to customize their connectivity to discover, reserve and consume network resources on demand.

The telco multi core

TobiasD / Pixabay

 
There is something that has been irking me for the last few months: everyone in telco seems to carry on thinking that they will continue have a single omnipotent centralized core network. Even though variations between workloads (voice vs browsing vs video vs gaming vs AR vs AI vs IoT...) continue to amplify and the business models (owned, and operated, IaaS, SaaS, PaaS...) increasingly require separate command and control.

The answer seems to be that slicing will magically solve everything. I fail to understand how slicing can accommodate diverging simultaneous needs from the same infrastructure without overprovisioning but that's a question for another time.

What troubles me most, is that networks have dealt with separate cores for a long time. In many cases, because of IoT or B2B business units who could not afford the timelines and costs of adapting the centralized core, or because, simply the network authority wanted to separate consumer traffic from enterprises. In other cases, you have network sharing and multi-operator core networks (MOCN) that have emerged as viable solution to segregate and manage traffic in a logical network.

I am not an engineer or a scientist, but it feels like the most advancement in processing in the last years is due to parallelization or specialization, and I don't see silicon vendors building bigger CPUs, but rather orchestrating as many CPUs on the same board as possible to manage concurrent, yet different workloads. This analogy has also seen the emergence of specialized processing units such as GPU or TPUs for specific workloads, in specific circumstances...

Now that most cloud providers and many telco vendors have proven the compatibility of their core network (at least the control plane) with cloud infrastructure and networks, I don't understand why telco standards and industry still feel that 5G will have THE core network to evolve to, and that, when, it will be 5G, when it will be standalone, when it will support slicing, when it will have a platform to recognize, identify, reserve, network resources, when it will be able to create dynamic slices on demand... all will be solved.

I feel that many of these issues have been resolved yet? Slicing is just a new iteration of tunneling, VPN, packet tagging, traffic shaping that are today prevalent in many networks. Cloud providers have effectively solved most of these challenges within their networks already so why are telcos trying to reinvent the wheel? 

Wishing a single, unique, centralized core is not necessarily going to make it so. Other telcos, cloud providers, soon industry verticals, governments, IT vendors will have their core. Thinking that the telco single core architecture will be able to manage all workloads and use cases and verticals simultaneously in a 5G world seems too much like magical thinking.

If you're a telco, you might not like it but you better plan for a multi core network, because others will be soon, whether you want it or not. Chances are there are already premises in the third party caches and edge infrastructure being deployed in your networks.

You might want to start thinking in terms of core per service types, like voice, unicast TV, general browsing, low latency IoT, high compute applications, Edge... and per business model like retail consumer, retail enterprise, wholesale telco, wholesale cloud, IaaS, PaaS...

TelecomTV Panel on Hyperscalers and Telcos coopetition model at the edge

 Q&A with Telefonica, Verizon Wireless and Dell

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

Objectives of xRAN

Extracted from the xRAN 2020 report.

The primary objective of xRAN was to change the cost of designing, purchasing and operating Radio Access Networks. This can be achieved by a variety of means:

Software virtualization

Traditional RAN vendors provide integrated proprietary hardware and software solutions for their equipment. Separating the hardware from the software, and virtualizing the latter yields a variety of benefits:

Part of the hardware can now be purchased commercial off the shelf, based on cost efficient white box designs.

Virtualized software is able to make full use of Software Defined Networking (SDN). When a software is virtualized using virtual machines, we use virtual bridges to connect the VMs with the physical servers. We use virtual switches such as OVS to optimize the servers utilization. Cables and physical switches are used to connect physical servers between each other. Hyperscalers have, early on identified that white box switches can be deployed at a fraction of the cost of the proprietary switches used in telco networks. It is very difficult, in practice to orchestrate VMs that are not on the same servers, as well as VMs with the physical servers’ capacity.

In a software-defined network, the decision-making processes for the categorization, management and routing of IP traffic is separated from the software functions and centralized in the form of a Controller. That Controller can expose (northbound) interfaces to define the rules for traffic handling and (southbound) interfaces to program the traffic management elements. This enables to create sophisticated traffic rules to optimize for performance, latency, congestion or failure avoidance. When applied to the RAN, SD RAN is sometimes used to describe these systems.

A SD RAN can be managed remotely, from a controller API on a web interface, rather than dialing into each network element separately, either remotely of physically. This yields operational savings inasmuch as less in-the-field maintenance is necessary and technicians do not need to physically access the equipment to perform upgrades, patches and maintenance.

 Open interfaces and solution disaggregation

RANs are composed of a variety of elements that are tightly integrated in a traditional solution. The interfaces and protocols linking these elements are closed, which means that only the vendor of the solution can perform a change because even if they are using standards based interfaces, they augment them with proprietary parameters and headers.. Opening these interfaces means designing, specifying and enforcing the implementation of standards-based interfaces between these elements without any modification. This yields a variety of benefits:

•      These elements can be scaled independently from each other.
•      Since the interfaces are open, you can replace an element from one vendor by one from another vendor with minimum testing and integration.
•        It is possible to deploy elements from different vendors in the same network configuration, allowing best of breed deployment for specific use cases

Value chain disaggregation

A key means to reduce the cost structure of the traditional RAN value chain is to reduce the dependency on powerful vendors. This can be achieved by breaking the RAN products and services into modular components and essentially go directly to the Original Design Manufacturer (ODM) to try and get better commercial conditions. This tactic is not always effective. These ODM might be eager to get closer to the end customer and shortening the intermediary, but they are usually weary as well to discontent their current customers (OEMs) with whom they have long term relationship and volume commitments. Additionally, the traditional vendors provide valuable design, integration and testing work which now has to be carried by the operator or their new subcontractors.

A better solution is to try and stimulate the market to see the emergence of new suppliers to challenge the supremacy of the traditional vendors. This can be achieved in a variety of ways. Many operators have an investment arm or an incubator or accelerator for start ups. A telecom operator entering a technology company’s capital as a strategic investor is a good signal to the market. When several operators invest in companies in the same market segment, it shows that it is strategic and forces other venture capital companies to evaluate whether they should invest in similar companies. It spurs, in turn, entrepreneurs to create start ups in that area. It is a difficult virtuous circle to create and takes time, but it is powerful once it has sufficient momentum.

Another tactic is the in-house development of a new solution, together with the creation of an open source community. The seed development does not need to be huge, but it needs to show steadfast and long-term commitment to developer community for interested parties to adhere to the project. Open source development can become a force multiplier as start-ups emerge to industrialize and resell the shared code.

The last tactic, and probably the most effective, is the purchase and deployment of these new vendors products and services. Telco operators are notoriously slow to take purchasing decisions and the sales engagement is a marathon, from presentations, to demonstrations, to proof of concept, to lab deployment, to integration tests and hundreds other processes before deployment in the field. It is not surprising therefore, that the best suited vendors are those with robust project / program management and deep pockets, able to sustain long sales cycle by their market reach and scale. Start-ups are usually ill-equipped to sell to large operators and more of them have died during the sales cycle than have emerged successful. There is nothing like focus and the ability to test, refine and purchase volumes of start ups products and services in a short timeframe to signal to the market that an operator is serious about it.

All these tactics combined have seen the emergence of a class of RAN suppliers, smaller, more agile, more efficient than their traditional counterparts. They certainly have a higher risk profile, as they are not as financially sustainable and haven’t reached the operational excellence operators demand in their market, but the cost-ratio with their counterpart is sufficiently important that some operators feel these vendors are good enough for specific use cases.

The introduction of these new vendors in the value chain, with their lower price points and their more open interfaces forces the traditional vendors to adapt their offering, by compressing their margins and / or developing equivalent product lines.

Why telco operators need a platform for edge computing

Initially published in The Mobile Network.

Extracted from the edge computing and hybrid cloud 2020 report.

Edge computing and hybrid clouds have become subjects of many announcements and acquisitions over the last months.

Edge computing, in order to provide a capacity for developers and third party to reserve and consume operators computing, storage and networking capacity need a platform. The object of this platform is to provide a web interface and series of APIs to abstract network topology and complexity and offer developers a series of cloud services and product to package within their offering. Beyond hyperscalers who have natively developed these platforms, a few vendors have emerged in the telco space, such as MobiledgeX and ORI Industries.

Network operators worldwide are confronted with the inexorable growth of their data traffic due to the consumers’ voracious appetite for video streaming and gaming. Since video content is the largest and fastest growing data type in the networks, an economical challenge is slowly arising. Data charging models have departed from per Megabyte metered billing to bundles and unlimited data, which encourages traffic growth, while reducing the operators’ capacity to monetize this growth. Consumers are not willing to pay much more for a HD video versus Standard Definition. For them, it is essentially the same service and the operator is to blame if the quality is not sufficient. Unfortunately, the problem is likely to accelerate with emerging media hungry video services relying on 4K, 8K and Augmented Reality. As a consequence, the average revenue per user stagnates in most mature markets, while costs continue to rise to increase networks capacity.

While 5G promises extraordinary data speeds, enough to complement or equal fibre fixed capacity, there is no real evidence that the retail consumer market will be willing to pay a premium for improved connectivity. If 5G goes the way of 4G, the social media, video streaming, gaming services and internet giants will be the ones profiting from the growth in digital services. The costs for deploying 5G networks will range in the low to double digit billions, depending on the market, so… who will foot the bill?

If properly executed, the 5G roll out will become in many markets the main broadband access at scale. As this transition occurs, new opportunities arise to bundle mobile connectivity with higher level services, but because the consumer market is unlikely to drastically change its connectivity needs in the short term, the enterprise market is the most likely growth opportunity for 5G in the short to medium term.

Enterprise themselves are undergoing a transformation, with the commoditization of cloud offering.

Cloud is one of the fastest growing ICT businesses worldwide, with IaaS the fastest growing segment. Most technology companies are running their business on cloud technology, be it private or public and many traditional verticals are now considering the transition.

Telecom operators have mostly lost the cloud battle - AWS, Microsoft, Google, Alibaba have been able to convert their global network of data centers into an elastic, on-demand as-a-service economy.

Edge computing, the deployment of mini data centers in telco networks promises to deliver a range of exciting new digital services. It may power remote surgery, self driving cars, autonomous industrial robots, drone swarms and countless futuristic applications.

In the short term, though, the real opportunity is for network operators to rejoin the cloud value chain, by providing a hyper local, secure, high performance, low latency edge cloud that will complement the public and private clouds deployed today.

Most private and public clouds ultimately stumble upon the “last mile” issue. Not managing the connectivity between the CPE, the on-premise data center and the remote data center means more latency, less control and more possibility for hacking or privacy issues.

Operators have a chance to partner with the developers’ community and provide them with a cloud flavour that extends and improve current public and private cloud capabilities.

The edge computing market is still emerging, with many different options in terms of location, distribution, infrastructure and management, but what is certain is that it will need to be more of a cloud network than a telco network if it succeeds in attracting developers.

Beyond the technical details that are being clarified by deployments and standards, the most important gap network operators need to bridge with a true cloud experience is the platform. Operators traditionally have deployed private cloud for their own purpose -  to manage their network. These clouds do not have all the traditional features we can expect from commercial public cloud (lifecycle management, third party authentication, reservation, fulfillment…). The key for network operators to capture the enterprise opportunity is to offer a set of APIs that are as simple as those from the public clouds, so that developers and enterprise may reserve, consume and pay for edge computing and connectivity workloads and pipelines.

A possible outcome of this need if operators do not open their private cloud to enterprises is that hyperscalers will expand their clouds to operators’ networks and provide these services to their developer and client community. This would mean that operators would be confined to a strict connectivity utility model, where traffic prices would inexorably decline due to competitive pressure and high margin services would be captured by the public cloud.

• Edge computing can allow operators to offer IaaS and PaaS services to enterprises and developers with unparalleled performance compared to traditional clouds:
• Ultra-low and guaranteed latency (typically between 3 -25ms between the CPE and the first virtual machine in the local cloud)
• Guaranteed performance (up to 1Gps in fibre and 300Mbps in cellular)
• Access to mobile edge computing (precise user location, authentication, payment, postpaid / prepaid, demographics… depending on operators’ available APIs)
• Better than cloud, better than WIFI services and connectivity (storage, video production, remote desktop, collaboration, autonomous robots,…)
• Flexible deployment and operating models (dedicated, multi-tenant…)
• Local guaranteed data residency (legal, regulatory, privacy compliant)
• Reduce cloud costs (data thinning and preprocessing before transfer to the cloud)
• High performance ML and AI inferring
• Real time guiding and configuration of autonomous systems

It is likely that many enterprise segments will want to benefit from this high-performance cloud. It is also unlikely that operators alone will be able to design products and services for every vertical and segment. Operators will probably focus on a few specific accounts and verticals, and cloud integration providers will rush in to enable specific market edge cloud and connectivity services:

• Automotive
• Transport
• Manufacturing
• Logistics
• Retail
• Banking and insurances
• IoT
• M2M…

Each of these already have connectivity value chain, where network operators are merely a utility provider for higher value services and products. Hybrid local cloud computing offer the operators the opportunity to go up the value chain by providing new and enhanced connectivity and computing products directly to consumers (B2C), enterprises (B2B) and developers (B2B2x).

Fixed and mobile networks have not been designed to expose their capabilities to third party for reservation, consumption and payment of discrete computing and connectivity services. Edge computing, as a new greenfield environment is a great place to start if an operator would like to offer these types of services. Because it is new, there is no legacy deployed and the underlying technology is closer to cloud native. This is necessary to create a developer and enterprise platform. Nonetheless, an abstraction layer is necessary to federate and orchestrate the edge compute infrastructure and provide a web-based authentication, management, reservation, fulfillment, consumption and payment model for enterprises and developers to contract these new telco services.

This is what a platform provides. An abstraction layer, that hides telco networks complexity, federates all edge computing capacity across various networks and operators and present a coherent marketplace for enterprise and developers to build and consume new services offered by the operator community as IaaS, PaaS and SaaS. By deploying a platform, operators can reintegrate the cloud supply chain, but they will have to decide whether they want to own the developer relationship (and build their own platform) or benefit from existing ecosystems (and deploy an existing third party platform). In the first case, it is a great effort, but the revenues flow directly to the operator, the platform is just another technology layer. In the second, revenues go to the platform provider and are shared with the operator. It provides faster time to market, but less control and margin. This model, in my mind is inevitable, it remains to be seen whether operators will be able to develop and deploy the first one in time and at scale.