Showing posts with label Open RAN. Show all posts
Showing posts with label Open RAN. Show all posts

Tuesday, July 28, 2026

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

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

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

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

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

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

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

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

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

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

Tuesday, June 9, 2026

O-RAN PlugFest Spring 2026: Smaller, Sharper, More Ambitious


The O-RAN ALLIANCE published results from its Global PlugFest Spring 2026 on June 4. Conducted from February to May 2026, it brought together 31 companies and institutions across 9 labs worldwide, co-hosted by 13 operators, OTICs and independent institutions. Those numbers will look like a step backward to anyone tracking PlugFest participation over time — and they are, deliberately.

For comparison: the Fall 2024 PlugFest ran across 28 labs with 115 participants. Spring 2025 had 19 labs and 69 participants. Spring 2026 cut the footprint by more than half again. This is not a loss of momentum. It is a deliberate shift from ecosystem-building to integration hardening. Getting everyone in the tent was the objective of the first five years. Making what exists actually work together is the objective now.

Massive MIMO — finally the main act

The centrepiece of Spring 2026 was multi-vendor end-to-end integration of massive MIMO O-RAN components, including mMIMO beamforming. This matters more than it might appear. Massive MIMO has always been the credibility gap for Open RAN. Traditional vendors have proprietary beamforming pipelines refined over a decade of commercial deployment. High-band, high-capacity urban coverage — stadiums, CBDs, transport hubs — has been essentially off-limits for disaggregated RAN. Demonstrating that multi-vendor mMIMO beamforming can be integrated in a structured, neutral lab environment is the first necessary step toward closing that gap.

AmpliTech's O-RAN CAT-B 64T64R Massive MIMO radio was the only radio of that configuration at the event — the only American-designed and commercialized O-RU at that specification level — and it demonstrated multi-vendor interoperability alongside operators including AT&T, Deutsche Telekom, Korea Telecom, LG Uplus, Orange and Rakuten Mobile. That combination — 64 transmit, 64 receive antennas, multi-vendor integration, neutral lab, named Tier-1 operator validation — is the kind of result that shifts a proof of concept into a procurement conversation.

Commercial-grade performance parity with incumbent vendors is a separate question, and a longer road. But you cannot get there without first doing what was done here.

AI-RAN — directionally consistent, details deferred

Several labs focused on AI-RAN solutions targeting network performance improvements and energy savings. The press release did not publish quantified results — a contrast with Spring 2025, which reported 25–30% intelligent RAN energy savings delivered by rApps on Non-Real-Time RICs. Detailed results will follow in technical session readouts. The direction is not in question. AI-driven energy efficiency via the RIC architecture has been the dominant AI-RAN use case in structured testing for two years running, and the logic is clear: energy is the largest controllable operating cost in RAN, the levers are cell on/off switching and power scaling, and the RIC is the right control point. What the Alliance needs to demonstrate next is that these savings hold at scale, under real traffic conditions, not just in lab scenarios with predictable load profiles.

The open-source stack is growing up

Four open-source frameworks were deployed at the PlugFest: Open Air Interface, OCUDU, O-RAN SC, and Sylva. Each represents a different layer of the stack, and their simultaneous presence in integration testing is worth noting.

OAI has become the de facto open-source O-CU/O-DU choice in lab settings — widely trusted, well-documented, increasingly operator-deployed in production pilots. O-RAN SC provides the RIC and SMO components from the Alliance's own software community. OCUDU is a combined CU/DU implementation targeting simplified deployment at the edge. And Sylva — the Linux Foundation's cloud-native telco infrastructure framework — is where the container orchestration and lifecycle management work happens. Carrier-grade Kubernetes for RAN workloads, in plain language.

The intersection of Sylva and O-RAN SC is the one to watch. Cloud infrastructure meeting RAN software — not as a research experiment, but as a jointly validated integration — is where operator confidence in virtualized open RAN will be won or lost operationally. It is still early. But it is no longer theoretical.

ISAC — a 6G signal in a 5G event

Initial tests were performed on Integrated Sensing and Communication, or ISAC — using the RAN simultaneously for wireless communications and environmental sensing. Object detection, positioning, radar-like environmental awareness, all from the same radio infrastructure. This is a 6G-era capability appearing in 5G Advanced specifications, and its inclusion in a 2026 PlugFest is a deliberate statement by the Alliance. They are not waiting for a new standards cycle to begin building the interoperability baseline. Given how long it took Open RAN to move from specification to commercial deployment, starting ISAC integration work in 2026 is not premature. It is probably necessary.

Who was there, and who wasn't

The full participant list is a useful read. Operators present included Korea Telecom, LG Uplus, Orange and Rakuten Mobile, with AT&T represented at the governance level through Brian Daly's TSC co-chairmanship. Academic institutions — Virginia Tech's Commonwealth Cyber Initiative, Iowa State University, North Carolina State University, ETRI and Fraunhofer HHI via the i14y Lab — signal that the research-to-commercialisation pipeline is being built at the institutional level, not just the vendor level. Software Radio Systems, the team behind srsRAN, continues to appear — their open-source 5G stack is quietly becoming a reference DU/CU implementation in operator testbeds.

What is absent is equally notable. No traditional vendors. The large incumbents engage with the Alliance at the specification level; they do not typically show up at PlugFest lab level. This is not surprising, but it is a structural tension. The integration maturity of disaggregated RAN will ultimately be measured in Tier-1 operator deployments, and those operators currently run incumbent infrastructure. The path from PlugFest to procurement runs through a comparison the incumbents are not participating in on neutral terms.

What this PlugFest actually means

The O-RAN Alliance has always faced a version of the same challenge: translating credible lab results into commercial deployments at scale. PlugFests prove interoperability in controlled conditions. Operators need it in live networks, under real traffic, with real SLAs and real interference environments. That gap has not closed. But the Spring 2026 agenda — massive MIMO beamforming, AI-RAN energy efficiency, integrated open-source stacks, ISAC first tests — reflects an ecosystem that knows precisely where it needs to focus to close it. That is not a small thing. Three years ago, the conversation was still largely about whether disaggregated RAN could work at all. That question has been answered. The question now is how fast it can reach performance and cost parity with incumbent solutions in high-capacity, high-stakes deployments. Spring 2026 moved that needle. Not dramatically. But in the right direction, on the right problems.

Friday, October 3, 2025

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


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

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

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

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

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

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

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

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


Thursday, July 31, 2025

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

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

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

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

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

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

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

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

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

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

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

Wednesday, April 16, 2025

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.

Monday, March 10, 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.

Friday, July 5, 2024

Readout: Ericsson's Mobility Report June 2024

 


It has been a few years now, since Ericsson has taken to provide a yearly report on their view of the evolution of connectivity. Alike Cisco's annual internet report, it provides interesting data points on telecom technology and services' maturity, but focused on cellular technology, lately embracing fixed-wireless access and non terrestrial networks as well. 

In this year's edition, a few elements caught my attention:

  • Devices supporting network slicing are few and far in-between. Only iOS 17 and Android 13 support some capabilities to indicate slicing parameters to their underlying applications. These devices are the higher end latest smartphones, so it is no wonder that 5G Stand Alone is late in delivering on its promises, if end to end slicing is only possible for a small fraction of customers. It is still possible to deploy slicing without device support, but there are limitations, most notably slicing per content / service, while slicing per device or subscriber profile is possible.

  • RedCap (5G reduced Capability) for IoT, wearables, sensors, etc... is making its appearance on the networks, mostly as demo and trials at this stage. The first devices are unlikely to emerge in mass market availability until end of next year.

  • Unsurprisingly, mobile data traffic is still growing, albeit at a lower rate than previously reported with a 25% yearly growth rate or just over 6% quarterly. The growth is mostly due to smartphones and 5G penetration and video consumption, accounting for about 73% of the traffic. This traffic data includes Fixed Wireless Access, although it is not broken down. The rollout of 5G, particularly in mid-band, together with carrier aggregation has allowed mobile network operators to efficiently compete with fixed broadband operators with FWA. FWA's growth, in my mind is the first successful application of 5G as a differentiated connectivity product. As devices and modems supporting slicing appear, more sophisticated connectivity and pricing models can be implemented. FWA price packages differ markedly from mobile data plans. The former are mostly speed based, emulating cable and fibre offering, whereas the latter are usually all you can eat best effort connectivity.

  • Where the traffic growth projections become murky, is with the impact of XR services. Mixed, augmented, virtual reality services haven't really taken off yet, but their possible impact on traffic mix and network load can be immense. XR requires a number of technologies to reach maturity at the same time (bendable / transparent screens, low power, portable, heat efficient batteries, low latency / high compute on device / at the edge, high down/ up link capabilities, deterministic mash latency over an area...) to reach mass market and we are still some ways away from it in my opinion.

  • Differential connectivity for cellular services is a long standing subject of interest of mine. My opinion remains the same: "The promise and business case of 5G was supposed to revolve around new connectivity services. Until now, essentially, whether you have a smartphone, a tablet, a laptop, a connected car, an industrial robot and whether you are a working from home or road warrior professional, all connectivity products are really the same. The only variable are the price and coverage.

    5G was supposed to offer connectivity products that could be adapted to different device types, verticals and industries, geographies, vehicles, drones,... The 5G business case hinges on enterprises, verticals and government adoption and willingness to pay for enhanced connectivity services. By and large, this hasn't happened yet. There are several reasons for this, the main one being that to enable these, a network overall is necessary.

    First, a service-based architecture is necessary, comprising 5G Stand Alone, Telco cloud and Multi-Access Edge Computing (MEC), Service Management and Orchestration are necessary. Then, cloud-native RAN, either cloud RAN or Open RAN (but particularly the RAN Intelligent Controllers - RICs) would be useful. All this "plumbing" to enable end to end slicing, which in turn will create the capabilities to serve distinct and configurable connectivity products.

    But that's not all... A second issue is that although it is accepted wisdom that slicing will create connectivity products that enterprises and governments will be ready to pay for, there is little evidence of it today. One of the key differentiators of the "real" 5G and slicing will be deterministic speed and latency. While most actors of the market are ready to recognize that in principle a controllable latency would be valuable, no one really knows the incremental value of going from variable best effort to deterministic 100, 10 or 5 millisecond latency.

    The last hurdle, is the realization by network operators that Mercedes, Wallmart, 3M, Airbus... have a better understanding of their connectivity needs than any carrier and that they have skilled people able to design networks and connectivity services in WAN, cloud, private and cellular networks. All they need is access and a platform with APIs. A means to discover, reserve, design connectivity services on the operator's network will be necessary and the successful operators will understand that their network skillset might be useful for consumers and small / medium enterprises, but less so for large verticals, government and companies." Ericsson is keen to promote and sell the "plumbing" to enable this vision to MNOs, but will this be sufficient to fulfill the promise?

  • Network APIs are a possible first step to open up the connectivity to third parties willing to program it. Network APIs is notably absent from the report, maybe due to the fact that the company announced a second impairment charge of 1.1B$ (after a 2.9B$ initial write off) in less than a year on the 6.2B$ acquisition of Vonage.

  • Private networks are another highlighted trend in the report with a convincing example of an implementation with Northstar innovation program, in collaboration with Telia and Astazero. The implementation focuses on automotive applications, from autonomous vehicle, V2X connectivity, remote control... On paper, it delivers everything operators dream about when thinking of differentiated connectivity for verticals and industries. One has to wonder how much it costs and whether it is sustainable if most of the technology is provided by a single vendor.

  • Open RAN and Programmable networks is showcased in AT&T's deal that I have previously reported and commented. There is no doubt that single vendor automation, programmability and open RAN can be implemented at scale. The terms of the deal with AT&T seem to indicate that it is a great cost benefit for them. We will have to measure the benefits as the changes are being rolled out in the coming years.


Wednesday, July 3, 2024

June 2024 Open RAN requirements from Vodafone, Telefonica, Deutsche Telekom, Tim and Orange


 As is now customary, the "big 5" European operators behind open RAN release their updated requirements to the market, indicating to vendors where they should direct their roadmaps to have the most chances to be selected in these networks.

As per previous iterations, I find it useful to compare and contrast the unanimous and highest priority requirements as indications of market maturity and directions. Here is my read on this year's release:

Scenarios:

As per last year, the big 5 unanimously require support for O-RU and vDU/CU with open front haul interface on site for macro deployments. This indicates that although the desire is to move to a disaggregated implementation, with vDU / CU potentially moving to the edge or the cloud, all the operators are not fully ready for these scenario and prioritize first a deployment like for like of a traditional gnodeB with a disaggregated virtualized version, but all at the cell site. 

Moving to the high priority scenarios requested by a majority of operators, vDU/vCU in a remote site with O-RU on site makes its appearance, together for RAN sharing. Both MORAN and MOCN scenarios are desirable, the former with shared O-RU and dedicated vDU/vCU and the latter with shared O-RU, vDU and optionally vCU. In all cases, RAN sharing management interface is to be implemented to allow host and guest operators to manage their RAN resource independently.

Additional high priority requirements are the support for indoor and outdoor small cells. Indoor sharing O-RU and vDU/vCU in multi operator environments, outdoors with single operator with O-RU and vDU either co-located on site or fully integrated with Higher Layer Split. The last high priority requirement is for 2G /3G support, without indication of architecture.

Security:

The security requirements are sensibly the same as last year, freely adopting 3GPP requirements for Open RAN. The polemic around Open RAN's level of security compared to other cloud virtualized applications or traditional RAN architecture has been put to bed. Most realize that open interfaces inherently open more attack surfaces, but this is not specific to Open RAN, every cloud based architecture has the same drawback. Security by design goes a long way towards alleviating these concerns and proper no trust architecture can in many cases provide a higher security posture than legacy implementations. In this case, extensive use of IPSec, TLS 1.3, certificates at the interfaces and port levels for open front haul and management plane provide the necessary level of security, together with the mTLS interface between the RICs. The O-Cloud layer must support Linux security features, secure storage, encrypted secrets with external storage and management system.

CaaS:

As per last year, the cloud native infrastructure requirements have been refined, including Hardware Accelerator (GPU, eASIC) K8 support, Block and Object Storage for dedicated and hyper converged deployments, etc... Kubernetes infrastructure discovery, deployment, lifecycle management and cluster configuration has been further detailed. Power saving specific requirements have been added, at the Fan, CPU level with SMO driven policy and configuration and idle mode power down capabilities.

CU / DU:

CU DU interface requirements remain the same, basically the support for all open RAN interfaces (F1, HLS, X2, Xn, E1, E2, O1...). The support for both look aside and in-line accelerator architecture is also the highest priority, indicating that operators havent really reached a conclusion for a preferable architecture and are mandating both for flexibility's sake (In other words, inline acceleration hasn't convinced them that it can efficiently (cost and power) replace look aside). Fronthaul ports must support up to 200Gb by 12 x 10/25Gb combinations and mid haul up to 2 x 100Gb. Energy efficiency and consumption is to be reported for all hardware (servers, CPUs, fans, NIC cards...). Power consumption targets for D-RAN of 400Watts at 100% load for 4T4R and 500 watts for 64T64R are indicated. These targets seem optimistic and poorly indicative of current vendors capabilities in that space.

O-RU:

The radio situation is still messy and my statements from last year still mostly stand: "While all operators claim highest urgent priority for a variety of Radio Units with different form factors (2T2R, 2T4R, 4T4R, 8T8R, 32T32R, 64T64R) in a variety of bands (B1, B3, B7, B8, B20, B28B, B32B/B75B, B40, B78...) and with multi band requirements (B28B+B20+B8, B3+B1, B3+B1+B7), there is no unanimity on ANY of these. This leads vendors trying to find which configurations could satisfy enough volume to make the investments profitable in a quandary. There are hidden dependencies that are not spelled out in the requirements and this is where we see the limits of the TIP exercise. Operators cannot really at this stage select 2 or 3 new RU vendors for an open RAN deployment, which means that, in principle, they need vendors to support most, if not all of the bands and configurations they need to deploy in their respective network. Since each network is different, it is extremely difficult for a vendor to define the minimum product line up that is necessary to satisfy most of the demand. As a result, the projections for volume are low, which makes the vendors only focus on the most popular configurations. While everyone needs 4T4R or 32T32R in n78 band, having 5 vendor providing options for these configurations, with none delivering B40 or B32/B75 makes it impossible for operators to select a single vendor and for vendors to aggregate sufficient volume to create a profitable business case for open RAN." This year, there is one configuration of high priority that has unanimous support: 4T4R B3+B1. The other highest priority configurations requested by a majority of operators are 2T4R B28B+B20+B8, 4T4R B7, B3+B1, B32B+B75B, and 32T32R B78 with various power targets from 200 to 240W.

Open Front Haul:

The Front Haul interface requirements only acknowledge the introduction of Up Link enhancements for massive MIMO scenarios as they will be introduced to the 7.2.x specification, with a lower priority. This indicates that while Ericsson's proposed interface and architecture impact is being vetted, it is likely to become an optional implementation, left to the vendor's s choice until / unless credible cost / performance gains can be demonstrated.

Transport:

Optical budgets and scenarios are now introduced.

RAN features:

Final MoU positions are now proposed. Unanimous items introduced in this version revolve mostly around power consumption and efficiency counters, KPIs and mechanisms. other new requirements introduced follow 3GPP rel 16 and 17 on carrier aggregation, slicing and MIMO enhancements.

Hardware acceleration:

a new section introduced to clarify the requirements associated with L1 and L2 use of look aside and inline. The most salient requirement is for multi RAT 4G/5G simultaneous support.

Near RT RIC:

The Near Real Time RIC requirements continue to evolve and be refined. My perspective hasn't changed on the topic. and a detailed analysis can be found here. In short letting third party prescribe policies that will manipulate the DU's scheduler is anathema for most vendors in the space and, beyond the technical difficulties would go against their commercial interests. operators will have to push very hard with much commercial incentive to see xapps from 3rd party vendors being commercially deployed.

E2E use cases:

End-to-end use cases are being introduced to clarify the operators' priorities for deployments. There are many  but offer a good understanding of their priorities. Traffic steering for dynamic traffic load balancing, QoE and QoS based optimization, to optimize resource allocation based on a desired quality outcome... RAN sharing, Slice assurance, V2x, UAV, energy efficiency... this section is a laundry list of desiderata , all mostly high priority, showing here maybe that operators are getting a little unfocused on what real use cases they should focus on as an industry. As a result, it is likely that too many priorities result in no priority at all.

SMO

With over  260 requirements, SMO and non RT RIC is probably a section that is the most mature and shows a true commercial priority for the big 5 operators.

All in all, the document provides a good idea of the level of maturity of Open RAN for the the operators that have been supporting it the longest. The type of requirements, their prioritization provides a useful framework for vendors who know how to read them.

More in depth analysis of Open RAN and the main vendors in this space is available here.


Thursday, May 2, 2024

How to manage mobile video with Open RAN

Ever since the launch of 4G, video has been a thorny issue to manage for network operators. Most of them had rolled out unlimited or generous data plans, without understanding how video would affect their networks and economics. Most videos streamed to your phones use a technology called Adaptive Bit Rate (ABR), which is supposed to adapt the video’s definition (think SD, HD, 4K…) to the network conditions and your phone’s capabilities. While this implementation was supposed to provide more control in the way videos were streamed on the networks, in many cases it had a reverse effect.

 

The multiplication of streaming video services has led to ferocious competition on the commercial and technological front. While streaming services visibly compete on their pricing and content attractiveness, a more insidious technological battle has also taken place. The best way to describe it is to compare video to a gas. Video will take up as much capacity in the network as is available.

When you start a streaming app on your phone, it will assess the available bandwidth and try to deliver the highest definition video available. Smartphone vendors and streaming providers try to provide the best experience to their users, which in most cases means getting the highest bitrate available. When several users in the same cell try to stream video, they are all competing for the available bandwidth, which leads in many cases to a suboptimal experience, as some users monopolize most of the capacity while others are left with crumbs.

 

In recent years, technologies have emerged to mitigate this issue. Network slicing, for instance, when fully implemented could see dedicated slices for video streaming, which would theoretically guarantee that video streaming does not adversely impact other traffic (video conferencing, web browsing, etc…). However, it will not resolve the competition between streaming services in the same cell.

 

Open RAN offers another tool for efficiently resolving these issues. The RIC (RAN Intelligent Controller) provides for the first time the capability to visualize in near real time a cell’s congestion and to apply optimization techniques with a great level of granularity. Until Open RAN, the means of visualizing network congestion were limited in a multi-vendor environment and the means to alleviate them were broad and coarse. The RIC allows to create policies at the cell level, on a per connection basis. Algorithms allow traffic type inference and policies can be enacted to adapt the allocated bandwidth based on a variety of parameters such as signal strength, traffic type, congestion level, power consumption targets…

 

For instance, an operator or a private network for stadiums or entertainment venues could easily program their network to not allow upstream videos during a show, to protect broadcasting or intellectual property rights. This can be easily achieved by limiting the video uplink traffic while preserving voice, security and emergency traffic.

 

Another example would see a network actively dedicating deterministic capacity per connection during rush hour or based on threshold in a downtown core to guarantee that all users have access to video services with equally shared bandwidth and quality.

 

A last example could see first responder and emergency services get guaranteed high-quality access to video calls and broadcasts.

 

When properly integrated into a policy and service management framework for traffic slicing, Open RAN can be an efficient tool for adding fine grained traffic optimization rules, allowing a fairer apportioning of resource for all users, while preserving overall quality of experience.

 

Wednesday, March 27, 2024

State of Open RAN 2024: Executive Summary

 

The 2023 Open RAN market ended with a bang with AT&T awarding to Ericsson and Fujitsu a $14 billion deal to convert 70% of its traffic to run on Open RAN by end of 2026. 2024 started equally loud with the $13 billion acquisition of Juniper Networks from HPE on the thesis of the former company’s progress in telecoms AI and specifically in RAN intelligence with the launch of their RIC program.

2023 also saw the long-awaited launch of Drillish 1&1 in Germany, the first Open RAN greenfield in Europe, as well as the announcement from Vodafone that they will release a RAN RFQ that will see 30% of its 125,000 global sites dedicated to Open RAN.

Commercial deployments are now under way in western Europe, spurred by Huawei replacement mandates.

On the vendor’s front, Rakuten Symphony seems to have markedly failed to capitalize on Altiostar’s acquisition and convince brownfield network operators to purchase telecom gear from a fellow network operator. While Ericsson has announced its support for Open RAN with conditions, Samsung has been the vendor making the most progress with convincing market share growth across the geographies it covers. Mavenir has been steadily growing. A new generation of vendors have taken advantage of the Non-Real-Time RIC / SMO opportunity to enter the space. Non-traditional RAN vendors such as VMWare and Juniper Networks or SON vendors like Airhop have grown the most in that space, together with pure new entrants App players such as Rimedo Labs. With the acquisition of VMWare and Juniper Networks, both leaders in the RIC segment, 2024 could be live or die for this category, as the companies are reevaluating their priorities and aligning commercial interest with their acquirers.

On the technology side, the O-RAN alliance has continued its progress, publishing new releases while establishing bridgeheads with 3GPP and ETSI to facilitate the inclusion of Open RAN in the mainstream 5G advanced and 6G standards. The accelerator debate between inline and look aside architectures has died down, with the first layer 1 abstraction layers allowing vendors to effectively deploy on different silicon with minimal adjustment. Generative AI and large language models have captured the industry’s imagination and Nvidia has been capitalizing on the seemingly infinite appetite for specialized computing in cloud and telecom networks.

This report provides an exhaustive review of the key technology trends, vendors product offering, and strategies, ranging from silicon, servers, cloud CaaS, Open RUs, DU, CUs, RICs, apps and SMOs in the open RAN space in 2024.

Tuesday, March 19, 2024

Why are the US government and DoD in particular interested in Open RAN?

Over the last 24 months, it has been very interesting to see that the US Government has been moving from keen interest in Open RAN to make it policy for its procurement of connectivity technology.

As I am preparing to present for next week's RIC Forum, organized by NTIA and the US Department of Defense, many of my clients have been asking why the US Government seems so invested in Open RAN.

Supply chain diversification:

The first reason for this interest is the observation that the pool of network equipment provider has been growing increasingly shallow. The race from 3G to 4G to 5G has required vendors to attain a high level of industrialization and economy of scale, that has been achieved through many rounds of concentration. A limited supply chain with few vendors per category represents a strategic risk for the actor relying on this supply chain to operate economically. Open RAN allows the emergence of new vendors in specific categories that do not necessitate the industrial capacity to be delivering end to end RAN networks.

Cost effectiveness:

The lack of vendor choice has shifted negotiating power from network operators to vendors, which has negatively impacted margins and capacity to make changes. The emergence of new Open RAN vendors puts pressure on incumbents and traditional vendors to reduce their margins.

Geostrategic interest:

The growth of Huawei, ZTE and other Chinese vendors, with their suspected links to the Chinese government and Army, together with the somewhat obscure privacy and security laws there, has prompted the US government and many allies to ban or severely restraint the categories of Telecom Products that can be deployed in many telecom networks.

Furthermore, while US companies dominate traffic management, routing, data centers and hyperscalers space, the RAN, core network and general telco infrastructure remains dominated by European and Asian vendors. Open RAN has been an instrument to facilitate and accelerate Chinese vendors replacement, but also to stimulate the US vendors to emerge and grow.

DoD use case example: Spectrum Dominance

This area is less well understood and recognized but is an integral part of US Government generally and DoD's in particular interest in Open RAN. Private networks require connectivity products adapted for specific use cases, devices and geographies. Commercial macro networks offer "one size fits all" solution that are difficult and costly to adapt for that purpose. Essentially DoD runs hundreds of private networks, whether on its bases, its carriers or in ad hoc tactical environments. Being able to setup a secure, programmable, cost effective network, either permanently or ad hoc is an essential requirement, and can also become a differentiator or a force multiplier. A tactical unit deploying an ad hoc network might look at means not only to create a secure subnet, but also to establish spectrum dominance by manipulating waveforms and effectively interfering with adverse networks. This is one example where programmability at the RAN level can turn into an asset for battlefield dominance. There are many more use cases, but their classification might not enable us to publicly comment them. They illustrate though how technological dominance can extend to every aspect of telecom.

Open RAN in that respect provides programmability, cost effectiveness and modularity to create fit for purpose connectivity experiences in a multi vendor environment.


Monday, January 15, 2024

Gen AI and LLM: Edging the Latency Bet

The growth of generative AI and Large Language Models has restarted a fundamental question about the value of a millisecond of latency. When I was at Telefonica, and later, consulting at Bell Canada, one of the projects I was looking after was the development, business case, deployment, use cases and operation of Edge Computing infrastructure in a telecom network.

Since I have been developing and deploying Edge Computing platforms since 2016,  I have had a head start in figuring out the fundamental questions surrounding the technlogy, the business case and the commercial strategy.

Where is the edge?


The first question one has to tackle is where is the edge. It is an interesting question because it depends on your perspective. the edge is a different location if you are an hyperscaler, a telco network operator or a developer. It can also vary over time and geography. In any case, the edge is a place where one can position compute closer than the current Public or Private Cloud Infrastructure in order to derive additional benefits. It can vary from a regional, to a metro to a mini data center, all the way to on premise or on device cloud compute capability. Each has its distinct cost, limitation and benefit.

What are the benefits of Edge Computing?


The second question, or maybe the first one, from a pragmatic and commercial standpoint is why do we need edge computing? What are the benefits?

While these will vary depending on the consumer of the compute capability, and where the compute function is located, we can derive general benefits that will be indexed to the location. Among these, we can list data sovereignty, increased privacy and security and reduced latency, enabling cheaper (dumber) devices, the creation of new media types and new models and services.

What are the use cases of Edge Computing?

I have deployed and researched over 50 use cases of edge computing, from the banal storage, caching and streaming at the edge to the sophisticated TV production or the specialized Open RAN or telco User Plane Function or machine vision use cases for industrial and agriculture application.

What is the value of 1ms?

Sooner or later, after testing various use cases, locations and architectures, the fundamental question emerges. What is the value of 1ms? It is a question heavy with assumptions and correlations. In absolute, we would all like a connectivity that is faster, more resilient, more power efficient, economical and with lower latency. The factors that condition latency are the number of hops or devices the connection has to go through between the device and the origin point where the content or code is stored, transformed, computed and the distance between the device and the compute point. To radically reduce latency, you have to reduce the number of hops or reduce the distance, Edge Computing achieves both.

But obviously, there is a cost. The latency will be proportional to the distance,  so the fundamental question becomes what is the optimal placement of a compute resource, for which use case? Computing is a continuum and some applications and workload are not latency or privacy or sovereignty sensitive and can run on an indiscriminate public cloud, while others necessitate the compute to be in the same country, region or city. Others even require a closer proximity. The difference is staggering in terms of investments between a handful of centralized data centers and several hundreds / thousands? of micro data center.

What about AI and LLM?

Until now, these questions where somewhat theoretical and were answered organically by hyperscalers and operators based on their respective view of the market evolution. Generative AI and its extraordinary appetite for compute is rapidly changing this market space. Not only Gen AI accounts for a sizable and growing portion of all cloud compute capacity, the question of latency now is getting to the fore. Gen AI relies on Large Language Models that require large amount of storage and compute, to be able to to be trained to recognize patterns. The larger the LLM, the more compute capacity, the better the pattern recognition. Pattern recognition leads to generation of similar results based on incomplete prompts / question / data set, that is Gen AI. Where does latency come in? Part of the compute to generate a response to a question is in the inference business. While the data set resides in a large compute data center in a centralized cloud, inference is closer to the user, at the edge, where it parses the request and attempts to feed the trained model with unlabeled input to receive a prediction of the answer based on the trained model. The faster the inference is, the more responses the model can provide, which means that low latency, is a competitive advantage for a gen AI service.

As we have seen there is a relatively small number of options to reduce latency and they all involve large investment. The question then becomes: what s the value of a millisecond? Is 100 or 10 sufficient? When it comes to high frequency trading, 1ms is extremely valuable (billions of dollars). When it comes to online gaming, low latency is not as valuable as controlled and uniform latency across the players. When it comes to video streaming, latency is generally not an issue, but when it comes to machine vision for sorting fruits on a mechanical conveyor belt running at 10km/h, it is very important.

I have researched and deployed many edge computing use cases and derived a fairly comprehensive workshop on the technological, commercial and strategic aspects of Edge computing and Data Center investment strategies.

If you would like to know more, please get in touch.

Tuesday, January 9, 2024

HPE acquires Juniper Networks


On January 8, the first rumors started to emerge that HPE was entering final discussions to acquire Juniper Networks for $13b. By January 9th, HPE announced that they have entered into a definitive agreement for the acquisition.

Juniper Networks, known for its high-performance networking equipment, has been a significant player in the networking and telecommunications sector. It specializes in routers, switches, network management software, network security products, and software-defined networking technology. HPE, on the other hand, has a broad portfolio that includes servers, storage, networking, consulting, and support services.

 The acquisition of Juniper Networks by HPE could be a strategic move to strengthen HPE’s position in the networking and telecommunications sector, diversify its product offerings, and enhance its ability to compete with other major players in the market such as Cisco.

Most analysis I have read so far have pointed out AIOps and Mist AI as the core thesis for acquisition, enabling HPE to bridge the gap between equipment vendor and solution vendor, particularly in the Telco space.

While this is certainly an aspect of the value that Juniper Networks would provide to HPE, I believe that the latest progress from Juniper Networks in Telco beyond transport, particularly as an early leader in the emerging field of RAN Intelligence and SMO (Service Management and Orchestration) was a key catalyst in HPE's interest.

After all, Juniper Networks has been a networking specialist and leader for a long time, from SDN, SD WAN, Optical to data center, wired and wireless networks. While the company has been making great progress there, gradually virtualizing  and cloudifying its routers, firewalls and gateway functions, no revolutionary technology has emerged there until the application of Machine Learning and predictive algorithms to the planning, configuration, deployment and management of transport networks.

What is new as well, is Juniper Networks' efforts to penetrate the telco functions domains, beyond transport. The key area ready for disruption has been the Radio Access Network (RAN), specifically with Open RAN becoming an increasingly relevant industry trend to pervade networks architecture, culminating with AT&T's selection of Ericsson last month to deploy Open RAN for $14B.

Open RAN offers disaggregation of the RAN, with potential multivendor implementations, benefitting from open standard interfaces. Juniper Networks, not a traditional RAN vendor, has been quick to capitalize on its AIOps expertise by jumping on the RAN Intelligence marketspace, creating one of the most advanced RAN Intelligent Controller (RIC) in the market and aggressively integrating with as many reputable RAN vendors as possible. This endeavor, opening up the multi billion $ RAN and SMO markets is pure software and heavily biased towards AI/ML for automation and prediction.

HPE has been heavily investing in the telco space of late, becoming a preferred supplier of Telco CaaS and Cloud Native Functions (CNF) physical infrastructures. What HPE has not been able to do, is creating software or becoming a credible solutions provider / integrator. The acquisition of Juniper Networks could help solve this. Just like Broadcom's acquisition of VMWare (another early RAN Intelligence leader), or Cisco's acquisition of Accedian, hardware vendors yearn to go up the value chain by acquiring software and automation vendors, giving them the capacity to provide integrated end to end solutions and to achieve synergies and economy of scale through vertical integration.

The playbook is not new, but this potential acquisition could signal a consolidation trend in the telecommunications and networking industry, suggesting a more competitive landscape with fewer but larger players. This could have far-reaching implications for customers, suppliers, and competitors alike.


Monday, December 4, 2023

Is this the Open RAN tipping point: AT&T, Ericsson, Fujitsu, Nokia, Mavenir


The latest publications around Open RAN deliver a mixed bag of progress and skepticism. How to interpret these conflicting information?

A short retrospective of the most recent news:

On the surface, Open RAN seems to be benefiting from a strong momentum and delivering on its promise of disrupting traditional RAN with the introduction of new suppliers, together with the opening of traditional architecture to a more disaggregated and multi vendor model. The latest announcement from AT&T and Ericsson even would point out that the promise of reduced TCO for brownfield deployments is possible:
AT&T's yearly CAPEX guidance is supposed to reduce from a high of ~$24B to about 20B$ per year starting in 2024. If the 14B$ for 5 years spent on Ericsson RAN yield the announced 70% of traffic on Open RAN infrastructure, AT&T might have dramatically improved their RAN CAPEX with this deal.

What is driving these announcements?

For network operators, Open RAN has been about strategic supply chain diversification. The coalescence of the market into an oligopoly, and a duopoly after the exclusion of Chinese vendors to a large number of Western Networks has created an unfavorable negotiating position for the carriers. The business case of 5G relies heavily on declining costs or rather a change in the costs structure of deploying and operating networks. Open RAN is an element of it, together with edge computing and telco clouds.

For operators

The decision to move to Open RAN is mostly not any longer up for debate. While the large majority of brownfield networks will not completely transition to Open RAN they will introduce the technology, alongside the traditional architecture, to foster cloud native networks implementations. It is not a matter of if but a matter of when.
When varies for each market / operator. Operators do not roll out a new technology just because it makes sense even if the business case is favorable. A window of opportunity has to present itself to facilitate the introduction of the new technology. In the case of Open RAN, the windows can be:
  • Generational changes: 4G to 5G, NSA to SA, 5G to 6G
  • Network obsolescence: the RAN contracts are up for renewal, the infrastructure is aging or needs a refresh. 
  • New services: private networks, network slicing...
  • Internal strategy: transition to cloud native, personnel training, operating models refresh
  • Vendors weakness: Nothing better than an end of quarter / end of year big infrastructure bundle discount to secure and alleviate the risks of introducing new technologies

For traditional vendors

For traditional vendors, the innovator dilemma has been at play. Nokia has endorsed Open RAN early on, with little to show for it until recently, convincingly demonstrating multi vendor integration and live trials. Ericsson, as market leader has been slower to endorse Open RAN has so far adopted it selectively, for understandable reasons.

For emerging vendors

Emerging vendors have had mixed fortunes with Open RAN. The early market leader, Altiostar was absorbed by Rakuten which gave the market pause for ~3 years, while other vendors caught up. Mavenir, Samsung, Fujitsu and others offer credible products and services, with possible multi vendors permutations. 
Disruptors, emerging and traditional vendors are all battling in RAN intelligence and orchestration market segment, which promises to deliver additional Open RAN benefits (see link).


Open RAN still has many challenges to circumvent to become a solution that can be adopted in any network, but the latest momentum seem to show progress for the implementation of the technology at scale.
More details can be found through my workshops and advisory services.