RAN, ORAN, VRAN, CRAN, and OpenRAN – What is this ALL About?
1. What is RAN?
The RAN acronym stands for the Radio Access Network segment of a 3G, 4G or 5G cellular network. The rest of the cellular network can be described as the “Core” network.
The RAN takes care of the so-called Air Interface (Air I/F) between the network providers’ (operator) network and the wireless
end-user devices like for example smartphones or IoT appliances. It connects those end-user devices to the core network and thereby – through the core network – to the services
that are provided by either the network provider or by 3rd party over the top (OTT) service providers like Microsoft, Netflix, Face
book, Amazon Web Services, Spotify and Google.
Historically, prior to the advent of VoIP (Voice over IP) technology, there was a circuit-switched “Core”, taking care of all voice calls and all circuit-switched narrowband data. As part of the evolution of 2G into 2.5G networks, another dedicated packet-switched “Core” was added, taking
care of packet-switched data only. That packet-switched core has since evolved into the current EPC (Evolved Packet Core) that takes care of all services, “voice” and “data” alike. But let’s focus on the RAN here.
The RAN concept was introduced by 3GPP at the beginning of the 3G era (late 1990’s), to differentiate it from the 2G-era “BSS” equivalent. In the 2G era, what we now call (3G, 4G, or 5G) RAN was called the BSS or Base Station Sub-system. The BSS consists of the (2G) BTS (Base Transceiver Station) and the BSC (Base Station Controller).
With the introduction of 3G WCDMA, the 2G BTS was renamed to NodeB and the 2G BSC to RNC (Radio Network Controller). In 4G LTE (Long Term Evolution), the NodeB was renamed to eNodeB and – at least conceptually and logically – divided into an RRH (Remote Radio Head) and a BBU (Base Band Unit) – refer to Figure 1.
2. Clash of Acronyms
There is ample confusion and ambiguity surrounding certain often-used (and abused) Radio Access Network (RAN) terminology and acronyms like:
- O-RAN,
- Open RAN (also denoted as ORAN),
- OpenRAN(written with no whitespace),
- VRAN (also denoted as v-RAN) and
- Cloud Ran(also denoted as C-RAN).
These five terms are often muddled and some of them are used interchangeably, which easily leads to misunderstandings and confusion. Here, we’ll first explain the intended meaning of those terms and then take a slightly deeper explanatory dive into selected concepts and their meaning.
2.1 O-RAN
O-RAN – hyphenated – specifically refers to the O-RAN Alliance, although it has been used without the hyphen and denoted simply as “ORAN”. With the hyphen, the term emerged to specifically refer to the O-RAN Alliance, an industry organization, and it’s initiative.
2.2 Open RAN
Open RAN – with whitespace – which is often denoted by the “ORAN” acronym to make things confusing, is a reference to the O-RAN Alliance’s publication of numerous RAN architecture specifications. Those “ORAN” specifications are the Alliance’s core theme and a foundation in its mission to offer an open architecture in the RAN ecosystem.
Open RAN standards are complementary to and compatible with standards promoted by 3GPP and other industry standards organizations.
The meaning of the ORAN acronym, therefore, has to be deduced from its context. It can refer to the O-RAN Alliance or (more commonly) to the Open RAN specifications and standards created by the O-RAN Alliance.
2.3 OpenRAN
The term “OpenRAN” refers to the OpenRAN Telecom Infra Project (OpenRAN TIP). The OpenRAN project group was created to focus on developing vendor-neutral hardware and software-defined technology based on open interfaces, like those defined by O-RAN with the Open RAN (ORAN) framework.
OpenRAN’s mission is to accelerate the development, innovation, and commercialization of multi-vendor interoperable products and solutions in the RAN domain that readily integrate with the operator’s network and are verified (interoperability) to work for different deployment scenarios.
TIP’s OpenRAN program supports the development of disaggregated (e.g., VRAN and C-RAN – see below) and interoperable (e.g., ORAN) 2G/3G/4G/5G NR Radio Access Networks (RANs) using general-purpose vendor-neutral software and hardware technology.
OpenRAN is therefore focusing on the implementation – in SW and HW – of the open RAN standards developed (the “how”) by initiatives like Open RAN (the “what”).
2.4 VRAN or v-RAN
Traditionally, RAN baseband processing has utilized purpose-built hardware typically using ASICs (Application Specific Integrated Circuits).
VRAN or v-RAN refers to the concept of Virtualized RAN. This virtualization has the following attributes:
- Disaggregation (separation) of the RAN (networking, data processing) baseband functions from the hardware those functions run on. Those functions are now implemented (entirely) in software. Previously hardware-centric functions become virtualized or software-based.
- 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 any commercial off-the-shelf (COTS) computing platform.
- Separation of the control plane (CP) and the data plane (DP) so that they can scale independently and therefore most efficiently. This is also part of the 3GPP and O-RAN specifications of the 5G RAN.
- Pooling the less latency-sensitive (non-real-time) controller functions of the RAN to centralized servers, closer to the core network edge. This pooling leads to optimal resource optimization through oversubscription / statistical multiplexing.
The term VRAN is strongly associated with 5G networks because it is expected or assumed that 5G networks will require virtualization to support the use cases and performance requirements of 5G in a resource- and cost-effective manner.
2.5 C-RAN or Cloud RAN or Centralized RAN
C-RAN or Cloud RAN or Centralized RAN (a misnomer) denotes a Virtualized RAN (VRAN) designed to be cloud-native (CN). CRAN – Cloud-native VRAN and it is therefore by default, virtualized. It incorporates key cloud-native attributes such as microservices and containerization.
Figure 3 illustrates how the five different RAN terms fit together and how they can – but not necessarily do – overlap.
3. ORAN versus VRAN
The terms ORAN and VRAN are often used in conjunction with each other, and sometimes confused. In fact, they represent different concepts altogether. ORAN prescribes standardized, open interfaces between well-defined constituent components of the (5G) RAN. VRAN is just one of the possible implementations of those constituent components and (ORAN or proprietary) interfaces.
It is, therefore, possible to have (also refer to Figure 3), for instance:
- A fully ORAN-compliant RAN implementation using proprietary “bare metal” or “black boxes” only, without implementing any of its constituent elements as a VRAN,
- A fully virtualized (VRAN) implementation of the DU and CU that uses proprietary interfaces and is not ORAN-compliant at all,
- An ORAN-compliant RAN implementation network that is (partly or wholly) implemented as a VRAN.
3.1 ORAN
ORAN is about subdividing a base transceiver station (BTS) – and more specifically a 5G BTS or gNodeB (gNB) – into three parts and introducing one new network function, with open interfaces defined between these four functional parts.
The BTS (gNB) is split into a Radio Unit (RU), which is a radio transceiver, a Distributed Unit (DU) for L1 computing and real-time (RT) L2 computing and a Centralized Unit (CU), for non-real-time (NRT) L2 and L3 computing. Refer to Figure 4.
As the name suggests, such a split enables the centralization of CUs relative to the cell sites and DUs, whereas DUs can be more distributed and even remain at cell sites.
A CU can control DUs in an 80 km radius and maintain a low latency in the order of 1 ms. The 5G core may be located up to 200 km away from the CU.
Traditionally, in for example 4G, we lumped the CU and DU together as a “Baseband” function or Base Band Unit (BBU) – refer to Figure 4. Furthermore, RU and DU can be combined into a Radio Access Point (RAP), which is customary in mmWave (typically small cell) 5GNR (5G New Radio) implementations.
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.
Also Read: How to Free Up RAM and Reduce RAM Usage on Windows
The ORAN open interfaces between the RU, DU, CU, RAP (DU + CU), RIC and towards the outside world are – refer to Figure 5:
- eCPRI7-2: the fronthaul interface between RU and DU, specified by O-RAN.
- F1: the midhaul interface between DU and CU, or between the RAP and the CU, specified by 3GPP.
- E2: the backhaul interface between the CU and the RIC, specified by O-RAN.
- A1: the interface between the RIC and the ONAP (Open Network Automation Platform) / MANO (Management & Orchestration), specified by O-RAN.
- E1: the (internal) interface between the control plane of the CU (CU-CP) and the user plane of the CU (CU-UP), specified by 3GPP.
- X2: interface between (in some instances) different suppliers’ CUs, specified by 3GPP.
As many operators are keen to leverage ORAN by combining RUs from supplier A with DUs and CUs from supplier B, the openness of the front-hauling interface of eCPRI7-2 is typically of the greatest
The meaning of the frequently used (RAN) terms fronthaul, midhaul, and backhaul in 4G and 5G respectively is elucidated in the following figure:
3.2 VRAN
VRAN implies that the baseband functions, such as L1, L2, L3, and transport processing, or at least some of them, are run on top of General-Purpose Processors (GPP, such as x86 processors), inside a commercial off-the-shelf (COTS) computing platform. Traditionally, RAN baseband processing has utilized purpose-built hardware with ASICs (Application Specific Integrated Circuits).
With a VRAN, we can implement the baseband processing elements of the RAN on COTS platforms, either as a bare metal deployment or on a private or public cloud computing platform. Implementation on a public cloud holds the promise of a substantial reduction in the cost of RAN the baseband processing and computing.
We can distinguish two different levels or phases in RAN virtualization:
- Virtualization of the CU: the virtual CU (vCU) runs on a cloud computing platform, but the DU still uses vendor-specific ASICs. This could be the first stage in virtualizing a RAN, as the CU takes care of the easier-to-implement non-real-time baseband processing, and because higher trunking or statistical multiplexing gain (= savings on the processing real estate) can be attained closer to the core network.
- Virtualization of the DU and CU: the virtual DU (vDU), in addition to the vCU, runs on a cloud computing platform. Hence, the DU and CU part of the RAN can be fully virtualized.
Note that the Radio Unit (RU) does not lend itself to virtualization. It is primarily a radio transmitter and receiver (transceiver) and an analogue device, with radiofrequency amplifiers, waveguides, filters, AD/DA converters.
4. Conclusion
A RAN is the access part of a 3G, 4G, or 5G cellular radio access network. It takes care of primarily the air interface between the mobile terminal/handset and the core network.
There (5G) RAN terminology can be rather confusing, as very similar terms have different and, in certain contexts, overlapping meanings. It’s therefore of paramount importance that we stick to the intended meaning of RAN terms and take due note of the context where they are used.
Certain baseband processing and networking parts of the 5G RAN – the DU and CU in particular – lend themselves well to (network function) virtualization (NFV): they can be implemented as software on top of COTS hardware or inside private or public clouds. This opens the door to combining and virtualizing multiple hitherto discrete network functions, like for example the DU and a Cell Site Router (CSR), and run them off the same hardware, which in turn holds the promise of substantial cost savings.
