Making sense of ORAN and vRAN – Part 1
Let me try to explain Open RAN (ORAN) and Virtualized RAN (VRAN, sometimes called Cloud RAN) in a simple manner. This is an attempt to explain their value, potential and challenges using a fact-based approach. Indeed, there are many misconceptions around ORAN and VRAN – and some hype too - but that doesn’t mean that they would not be highly interesting technologies.
In fact, ORAN and VRAN have the potential to materialize as the “next big things in wireless”, after Massive MIMO, beamforming, 5GNR (New Radio), Dynamic Spectrum Sharing (DSS), or the use of Artificial Intelligence (AI) and Machine Learning (ML) in RAN.
To simplify things a little bit, Open RAN (ORAN) is about splitting a base transceiver station (BTS) into three parts and introducing one new network function, with open interfaces between these three or four parts.
A BTS is split into a Radio Unit (RU, which is a radio transceiver), a Distributed Unit (DU, for the so-called Layer 1 or L1 computing and real-time L2 computing) and a Centralized Unit (CU, for non-real-time L2 and L3 computing). As the name suggests, such a split would enable the centralization of CUs relative to the cell sites and DUs, whereas DUs can be more distributed and even remain at cell sites.
Traditionally, we called the CU and DU together as “Baseband”. Further, RU and DU can be combined into a Radio Access Point (RAP), which is customary in mmWave 5GNR. The new network element in ORAN is the RAN Intelligent Controller (RIC), which adds a sort of open API into the RAN and can run AI/ML to make the RAN more intelligent, as the name suggests.
To simplify things even further, these are the new open interfaces between the RU, DU, CU, RAP, RIC and towards the outside world:
- eCPRI7-2 front-haul interface between RU and DU
- F1 mid-haul interface between DU and CU, or RAP and CU
- E1 interface between control plane of CU (CU-CP) and user plane of CU (CU-UP)
- X2 interface between different suppliers’ CUs
- E2 interface between CU and RIC
- A1 interface between RIC and ONAP/MANO
As many operators are keen to make use of ORAN by first combining the RU from one supplier with the DU and CU from another supplier, the open front-hauling interface of eCPRI7-2 is typically of greatest interest. This is not the first time this topic is has been explored in the industry.
In 2000, Nokia introduced the OBSAI (Open Base Station Architecture Initiative) interface between Radio and Baseband. As other suppliers did not want OBSAI to proliferate, some of them teamed up to create a competing interface called CPRI (Common Protocol for Radio Interface) to fragment the market. Both OBSAI and CPRI remained proprietary, because even if most parts of the two interfaces were standardized and open, the Operation and Management (O&M) protocols remained proprietary. Coming back to today, it is hardly a surprise to learn that it was Nokia that contributed the open eCPRI7-2 specification to ORAN.
Let’s move on to Virtualized RAN (VRAN, Cloud RAN). Basically, VRAN means that the Baseband functions, such as L1, L2, L3 and transport processing, or at least some of them, are run by General Purpose Processors (GPP, such as x86 processors), on top of virtually (pun intended) any commercial off-the-shelf (COTS) computing platform. Until now, baseband has been run in purpose-built hardware (HW) using either ASIC (Application Specific Integrated Circuit) or CSSP (Custom Specific Standard Product) type of System-on-Chips (SoC).
Today, the obvious choice for COTS platforms are cloud computing platforms. In what Nokia calls VRAN1.0, the CU runs in a cloud computing platform (vCU) but the DU still uses ASIC/CSSP SoCs, also known as “bare metal”. In what we call VRAN2.0, we have also virtualized the DU (vDU), in addition to the vCU. Radio (RU) is – well – a radio transmitter and receiver, or transceiver, and cannot be virtualized as such.
We often hear the terms ORAN and VRAN used in conjunction with each other, sometimes even as substitutes for each other, or being the same thing. They are of course interlinked but they are not the same thing at all. It is possible to make fully ORAN-compliant BTS without VRAN, using “bare metal”. It is also possible to make full-fledged VRAN that is not ORAN-compliant.
The main reason why ORAN and VRAN are interlinked is simply the fact that the new entrants who aspire to make ORAN-compliant baseband cannot afford to - and perhaps should not – develop “custom silicon” SoC or any HW for that matter by themselves. Instead, they turn to General Purpose Processors (GPP), and focus on developing baseband software (SW) that can be run on a cloud computing platform.
But why go ORAN and VRAN? The reasons why operators and some suppliers are interested in ORAN and VRAN are, at least:
- Some operators expect to get CAPEX/OPEX savings through increased competition amongst suppliers.
- Some operators expect to get CAPEX/OPEX savings through use of cloud computing HW (or platform) as opposed to purpose-built HW (or platform).
- Some operators expect to get CAPEX/OPEX savings through decoupling of DU/CU HW, cloud infrastructure SW and RAN application SW.
- Some operators expect to get CAPEX/OPEX savings through the “trunking gain” of pooling CU capacity for DUs.
- ORAN makes it easier for new entrants to get into the business, as they don’t have to make the whole BTS.
- ORAN – and VRAN - can stimulate innovation, as companies can focus where they can best add value, and as there is more competition.
- Even if RIC could have been invented without ORAN, we can consider RIC as an enabler of innovation in ORAN.
- ORAN reduces supplier lock-in, as it is easier to change part of a BTS when the whole BTS does not need to be changed.
- Different suppliers’ portfolios may also be complementary in that one has the best RU for a specific case, whereas another one has the best CU or DU, and these can be combined, for example.
- Some operators use ORAN as a catalyst to get their organization moving into Virtualized RAN (VRAN, Cloud RAN) to reap benefits of cloud computing.
- Some operators want to ensure there is choice if a geopolitical situation limits the use of some suppliers.
The challenges to be addressed are, at least:
- Not all established suppliers support ORAN. Some say they will support but only “when it makes sense”.
- When a BTS is disaggregated, it needs to be logically “re-aggregated” for ensuring network performance, inter-operability between different suppliers, feature and roadmap alignment, network operations process alignment, and lifecycle management alignment.
- Purpose-built computing is more CAPEX-efficient – and consumes less power (OPEX) - than cloud computing or use of General Purpose Processors (GPP), especially in L1 processing, though overall benefits of cloud computing and ORAN architecture may offset such inefficiency.
- Some argue that proprietary eCPRI implementations such as eCPRI7-3 (which differ from one supplier to another) have better performance than eCPRI7-2, but eCPRI7-3 would increase entry barrier for new RU suppliers into ORAN space.
- Even if ORAN is introduced in 4G/LTE and/or 5GNR, many operators have the legacy and installed base of 2G/GSM, 3G/WCDMA, 4G/LTE, and even “classic 5GNR”, and they could lose the benefits of Single RAN for 2G/3G/4G/5G.
- Lack of fiber and cost-efficient transport solutions for front-hauling between RU and DU and mid-hauling between DU and CU can prevent reaping the benefits of the centralized/distributed architecture.
At Nokia, we are committed to ORAN. We believe that the above challenges can be resolved.
In the next blog, I will tell you why and how. Some new entrants or ORAN hopefuls have tried to fling mud at Nokia by suggesting that our ORAN and VRAN is not truly open. Nothing could be further from the truth. Further, some ask if we are shooting ourselves in the foot (note: we are not) by supporting ORAN, as we may help create new competitors and expose our Radio and/or Baseband business in accounts where we have supplied complete BTS. Some have asked if it makes sense to invest in ReefShark System-on-Chip (SoC) technology in ORAN world (note: it does). Next time, I will shed light on these topics as well.
Share your thoughts on this topic by joining the Twitter discussion with @nokia or @nokianetworks using #ORAN #VRAN