RAN Functional Splits: Whose CPU Capacity is it Anyway?

Why RAN Functional Splits?

#RAN needs standardised interfaces and logical splits. For many years we have worked with 2 logical interfaces/splits, with 1 or 2 'monolithic' models. The 'split' tells you where the RAN processing takes place.

To a small cell base-station site we have run backhaul/Split 0. This means that all the processing - and the radio - are in a single box.

To a macro base-station site we ran backhaul/Split 0 to the BaseBand Unit (BBU) and Split 8/CPRI between the BBU and the Radio Unit (RU). This again means that all the processing is in a single box, with a high-bitrate proprietary connection then taking the Radio information to separate (usually multiple) quite computationally simple Radio Units.

When the BBU is a single functional unit, and the RUs are connected on point-to point fibre within a site, the high CPRI bit-rates (around 2.5Gbps for a 20MHz 2T2R, 10Gbps for a 40MHz 4T4R radio, and 2x25Gbps for an 100MHz 8R8R MIMO radio) are tolerated. The equivalent backhaul requirements would be 250Mbps, 1000Mbps and 2.5Gbps respectively so very large 10X/20X increases with CPRI.

But as we cloudify the network, transporting 6x25Gbps, 9x10GBps & 6x5Gbps to a high capacity site is untenable, so computing power in the Radio to pre-process the data (and reduce the bit-rate) becomes essential.

CPUs save Bytes

In all the 3GPP Splits, the more CPU capability there is in the 'southbound' unit (typically the RU or the DU) the lower the bit-rate that is required on the northbound interface.

Functional decomposition initially created a 2-Split/F1 (between the Centralised Unit (CU) and Distributed Unit (DU) functions of the BBU) and a 7-Split/eCPRI between the DU and a smarter RU. The O-RAN Alliance selected 7.2x split to simplify the RU while keeping the bandwidths to ~800Mbps, ~3200Mbps, ~8200Mbps for the 3 examples above (compression of 300-600% compared to CPRI).

OpenRAN from Legacy Vendors

5 Years on from O-RAN Alliance Specifications, and a consortium led by Ericsson is proposing a 7.3 split which they say will improve capacity of massive MIMO radios. The difference is that functions such as channel estimation and Interference Rejection Combining (IRC) which are implemented inside the DU in option 7.2x, are implemented inside the RU in option 7.3

This brings lower fronthaul BW requirements as more functions are done inside the RU and higher performance compared to option 7.2x due to channel estimation being done inside the RU.

Unfortunately 7.3 requires powerful chips in the RU resulting in a higher cost RU relative to option 7.2x, a more complex interface than option 7.2x and therefore more difficulties in multi-vendor integration.

Deferring the Event Horizon

If 7.3 is also adopted by O-RAN Alliance we will encounter a period of uncertainty as vendors evaluate operating 7.3 (mMIMO) and 7.2x (MIMO) in parallel - and if so whether to separate HW or to negotiate 7.3/7.2x with each RU - or whether to add Compute (and heat, meaning more volume as well as cost) to existing RUs to allow them all to operate as 7.3. R&D, testing and re-integration then follow, and we could easily find ourselves 2 years down the line with no significant benefits for majority of sites (those without massive MIMO).

Whose CPU is it Anyway?

Traditional RAN Vendors deliver 100% of the revenue of active equipment today. In most Open vRAN, the vCU and vDU infrastructure comes from a COTS 3rd party, even if the traditional RAN vendor delivers vCU and vDU SW and oRU HW & SW. 3 years ago, they were saying that COTS was not capable of delivering the Open FrontHaul computation, so the market responded with PCI Accelerator Cards and SmartNICs to allow COTS to remain COTS. Arguably this pushed the Virtualised infrastructure from say 20% of the BoQ to 25%, both tackling the problem, and reducing the legacy share of wallet to 75%.

A move to 7.3 split emphasises the oRU (legacy product) and de-emphasises the vRAN (Open or otherwise) and essentially moves the 5% back into the addressable market of the traditional vendor. As importantly, it defers or slows down the increased take-up of Open vRAN in the market, continuing to offer 100% of revenues per site to the legacy vendors.

The Clouds are Inevitable.

Over 80% of functions in a mobile network are now by default delivered Containerised in Public / Private / Telco Clouds. RAN is the majority of revenues still, but is - along with transport - in a minority of areas where cloud has not dominated.

Cloud pooling allows for much better utilisation and scaling of resources. Smart orchestration further reduces the energy consumption by optimising instantaneous supply to demand. Centralised compute assets will allow us to optimise Scope 1,2 and 3. The sooner we do it, the sooner we save.

Pushing compute assets out into every Radio Unit on the planet - remember that the CPRI we have used for the past 25 years requires very little Radio CPU power - denies us of some of those pooling gains.

Perfect is the enemy of Good

We're half-way through the 5G Era, and I've not encountered anyone who believes that 6G will be delivered by appliances. It's perfectly natural for businesses to protect their existing business model. But kicking the can down the road only makes it shinier, it does not make the challenge go away.

#Open #vRAN #Edge #FunctionalSplit