Nokia tells Ericsson to put up or shut up on cloud RAN

A general-purpose processor (GPP), as the name implies, is good enough for a multitude of jobs, if not brilliant at any. But the label is increasingly deceptive, according to Nokia. In a just-published white paper, the Finnish vendor says some GPPs or central processing units (CPUs) aimed at cloud radio access network (RAN) technology are essentially frauds – not general purpose at all but cloud RAN-specific. It is a thinly veiled attack on Intel and Ericsson.

The Swedish equipment vendor is nowhere named in Nokia's white paper, while the US chip giant is mentioned only once as the provider of the Sapphire Rapids processor that Nokia buys. Yet they are the obvious targets of Nokia's criticism. Intel dominates today's virtual RAN sector, boasting a 99% market share earlier this year, and it accounted for 71% of all server CPUs shipped in 2022, according to Counterpoint Research. It advocates a technique called "lookaside" acceleration to support virtual RAN technology. Nokia is scathing about this approach.

But Ericsson is not, and its plans to adopt Intel's technology for its portfolio have led to a massive disagreement between the Nordic vendors on how cloud RAN should be done. Nokia prefers an alternative technique known as "inline," which takes all the Layer 1 functions – the most computationally demanding software – off the CPU and puts them on a separate chip, usually hosted on a PCIe card that can be slotted into a compatible server. That's markedly different from lookaside, where the CPU continues to handle most functions.

Accelerating toward conflict

What's Nokia's beef? For one thing, it derides lookaside as a less efficient option and says that is proven by its tests. Currently, however, it is hard for third-party observers to know for sure. Inline acceleration has still not been deployed in any commercial RAN and won't be until next year. Intel, naturally, champions lookaside as the most energy-efficient technology, while many CSPs sound undecided. Santiago Tenorio, the network architecture director for Vodafone Group, says the jury is still out.

Another problem highlighted by Nokia is Intel's move to integrate accelerators with the CPUs. This likely explains the Finnish vendor's characterization of them as cloud RAN-specific and generates a huge overhead, it argues. With inline, a communications service provider (CSP) can add Layer 1 support independently of the CPU, slotting in an extra card when there is a need for more capacity. With no option but an integrated lookaside accelerator, where components are soldered to the motherboard, a CSP might have to buy a whole new server even if Layer 1 were the only thing that needed to change.

Granite Rapids, Intel's future successor to Sapphire Rapids, appears to go even further, according to multiple sources. A version called Granite Rapids-D, aimed at virtual RAN operators, would apparently come with a soldered ball grid array that includes not only lookaside accelerators but also mobile ciphers and the chips for fronthaul connectivity to radio units.

Intel declined to answer questions about Granite Rapids, but this design could make swapping out or modifying an individual part extremely difficult. To critics, the whole setup looks more like a highly customized piece of proprietary hardware than common, off-the-shelf equipment. One source said it looked like an "Intel appliance."

Nokia's big pitch is that feature parity between purpose-built and cloud-RAN products will be easier to deliver with inline because the same Layer 1 software can be used across them. Having worked with Marvell, a US chipmaker, on its traditional 5G equipment, it is now bringing those Marvell chips into its cloud RAN portfolio.

In purpose-built kit, the Marvell silicon sits inside an appliance. In cloud RAN, it is hosted on a PCIe card that slots into a Sapphire Rapids server. But it could theoretically go into a server based on the designs of Arm, an alternative to Intel's x86 architecture. And the code Nokia writes does not have to change unless the silicon does.

Ericsson, by contrast, appears to have two sets of Layer 1 code (although it has never publicly acknowledged this). The first is for its own purpose-built products, using chips developed by the in-house Ericsson Silicon unit. The other is for cloud RAN, based originally on Intel's CPUs and lookaside accelerators. To prevent purpose-built and cloud RAN from falling out of sync, Ericsson would have to make changes across these two sets of code whenever there were a 5G update. From a resource perspective, that does not sound ideal.

Ericsson hits back

The rejoinder is that Nokia's Layer 1 code is tightly coupled with Marvell's chips. It could not be used with any other hardware without an extensive rewrite, something Nokia has acknowledged. Such inline accelerators are not genuinely "cloud-native," Intel argues. They cannot be managed with the same programming languages and tools as the rest of the network.

Unlike Nokia, Ericsson now claims to have deployed the same Layer 1 code with two different chipmakers. After starting with Intel, it this year showed compatibility with AMD, a competitor that relies on the same x86 architecture and is also a fan of lookaside acceleration. Vodafone's Tenorio, who has pushed for greater openness and code portability at Layer 1, is evidently encouraged.

Ericsson is just as critical of inline as Nokia is of lookaside. "We are not looking at the other type of architecture for Layer 1 because that is what we perceive to be a full lock-in," said Matteo Fiorani, the head of Ericsson's cloud RAN product line, during a recent interview. "If you go with the full Layer 1, then you lock yourself in because the Marvell card is very different from the Qualcomm card or an Nvidia GPU [graphical processing unit], so you can't really port the code. You have to redo it all the time, and that's not affordable."

Yet Nokia clearly believes it has been more transparent about its cloud RAN strategy than other big RAN vendors. It concludes its white paper by demanding they share "clear details of their execution plans for cloud RAN and open RAN, rather than making conflicting commitments to various CSPs, and vague leadership claims in the press and social media." The gloves are definitely off.