Why do open RAN? | C-RAN, vRAN and open-RAN explained
David Martin, Associate Senior Analyst
Nik Siersted, Consultant
What is open RAN? C-RAN, vRAN & open-RAN
The open RAN is an umbrella term for a group of different technologies that telecoms operators hope will break vendor-lock in and lead to a significant reduction in capex and opex for their radio access networks (RANs).
There are three main elements that may help them with this goal:
- Open-RAN (note the confusing hyphenation): replacing the legacy, proprietary interfaces between the baseband unit (BBU) at the foot of the cell tower and the remote radio unit (RU) at the top of the tower with open standards. This enables units from one vendor to interoperate with units from other vendors
- Virtual RAN (vRAN): virtualising (and now also containerising) the baseband unit, so that it is run as software on generic hardware platforms. This enables the baseband and radio software and hardware, and even different components of the software and hardware, to be supplied by different vendors
- Centralised/Cloud RAN (C-RAN): concentrating and consolidating the baseband functionality across a smaller number of sites across the telco’s network and cloud.
In effect: all instances of open RAN (umbrella term) involve some form of C-RAN; some of those involve vRAN; and open-RAN deployments (hyphenated) are a further subset of vRAN.
How will an open RAN architecture help telcos?
In short, open RAN is designed to make the radio access network more cost effective and flexible. The extent of this will depend on exactly what is deployed – and how.
In our recent report Open RAN: What should telcos do?, we discuss the merits of a more open, multi-vendor architecture (open-RAN, vRAN and C-RAN together) as promoted by challenger vendors such as Mavenir, Parallel Wireless and Altiostar versus a more single-vendor proprietary architecture (C-RAN and vRAN, without open-RAN) promoted by traditional vendors such as Nokia, Ericsson and Huawei.
Beyond this, we want to make an observation which is perhaps obvious but rarely stated as bluntly: open RAN has the potential to drastically reduce the volume of physical kit that MNOs need to deploy and operate. And this is the case even if the centralised BBUs (cBBUs) are not virtualised and running on COTS platforms. Consolidating baseband processing in a much smaller number of sites enables much less kit to be used, as processing capacity can be intelligently adjusted to network load and there is no need to maintain masses of physical equipment at each base station, which is standing idle for much of the time.
Arguably, these efficiency gains should be even greater with virtualised BBUs (vBBUs), as baseband capacity can be scaled up or down dynamically in response to demand, reducing the amount of redundant processing power that needs to be maintained. And with open-RAN – so its advocates would have it – the equipment, energy and cost efficiencies are even greater. This is because different radios (e.g. macro, small or micro cells) from different vendors – and from different mobile generations and spectrum ranges – can in theory be run from the same vBBUs.
Where should operators deploy open RAN? Centralisation vs distribution
Where operators decide to physically locate their (v)BBUs will be a function of two things:
- what existing infrastructure they can re-use
- and what they want to do with the open RAN – beyond delivering connectivity more cost-effectively.
Some operators are consolidating baseband functions in fewer, more centralised locations. Others are planning and deploying vRAN and open-RAN in many more sites, closer to the antennas.
More centralised model: incumbent operator
One incumbent operator in a populous but geographically medium-sized market told us it was deploying only ten CUs nationwide to support its 5G network. But then it is also building out redundant, high-capacity fibre-optic links over existing infrastructure to support fronthaul to the DUs and midhaul between the DUs and CUs. This is expected to enable sufficiently low latencies to support most 5G use cases that are presently envisaged, even some – but not all – those dependent on Ultra-Reliable Low-Latency Communications (URLLC).
More distributed model: Rakuten
On the other hand, others such as Rakuten are adopting a much more distributed approach. Their strategy involves deploying around 4,000 ‘far edge’ data centres hosting both DU and CU functions. This more distributed architecture is determined partly by the fact that Rakuten does not possess pre-existing, dense access and transport network coverage, unlike established incumbents. Putting more CUs and DUs closer to the end user, together with the use of open-RAN fronthaul interface specifications, enables low-latency use cases to be supported over IPv6, rather than via more expensive, dedicated fibre-optic links.
And Rakuten certainly aims to deliver many innovative use cases that leverage 5G, including – initially – gaming, AR and VR apps. But interestingly, the edge compute capabilities necessary to support these use cases will not always run in the same far edge data centres as the RAN. Instead, Rakuten’s architecture diagrams show edge compute facilities running on regional aggregation points as well closer to the RAN.
Open-RAN and edge meeting in the middle: Telefónica
By contrast, another incumbent operator, Telefonica, is very much integrating its open-RAN roadmap with its MEC (multi-access edge computing) strategy. In a 2019 white paper, it discusses in detail its deployment of both Open vRAN (open interfaces and virtualised RAN) being deployed in many of its central offices (COs) and aggregation nodes alongside MEC infrastructure and software.
This particular architecture choice is arguably shaped as much by Telefonica’s determination to drive and ‘own’ the technology specifications and infrastructure behind its network and MEC use cases as by the low-latency and geographical requirements of specific, future services. On the other hand, incumbents like Telefonica certainly have plenty of CO and aggregation facilities that lend themselves to being repurposed for both these functions. But there is by no inherent or universal requirement to co-locate open RAN and edge compute in this way.
Equally, a more flexible, open approach to locating these capabilities may in future involve more reliance on third-party or shared edge facilities, such as those offered by public cloud providers or neutral host networks, or in the enterprise edge.
Recommendation: locate RAN for cost-effective connectivity; take an open approach to edge
As we argue in our recent report on the topic, we think that operators should focus first on using the open RAN to deliver better 4G and 5G connectivity at a significantly lower cost, most notably by consolidating and rationalising the sheer volume of physical kit they need to deploy and maintain.
Further down the line, the open RAN has considerable potential to support future edge compute-enabled use cases by distributing, virtualising and – in the case of open-RAN proper – disaggregating RAN functionality: providing more choice and flexibility about the RAN components that can be deployed (and where to deploy them) to support service innovation.
But where the open RAN, and where edge compute, are located are a function of many factors. Whichever choices operators make about these factors, there is no single blueprint that covers all future needs.
And operators must not close off their options by deploying rigid forms of open RAN in fixed locations that cannot easily be adapted to as yet unknown requirements.