RAN means radio access networks that form the link between a user’s device (smartphones, tablets, etc.) and other places in the network. A RAN has three components: i) Antennas- that convert electrical signals to electromagnetic waves; ii) Radios-that ensure electrical signals are transmittable, and iii) Base Band Units (BBUs)- that process signals for wireless communication. And these BBUs use proprietary technologies vendor locked to specific software. This situation reduces performance and collaboration by increasing operational complexity. Therefore, telecoms started searching for better solutions, giving rise to ORAN, cRAN, and vRAN; D-RAN is the traditional setup.
More about D-RAN
As mentioned above, the three components of RAN are:
- BBU: These units have the software and electronics necessary for crucial tasks, including signal processing, security implementation, optimizing resources, and error detection.
- Radio: After receiving the appropriate signals from the BBU, the radio transforms the signal into transmittable form. They also ensure that the waves have enough power to reach the destination and are in the appropriate channel.
- Antennas: These devices convert the signals to waves; the antennas’ dimensions depend on the area it has to cover. Larger the coverage, the bigger the antenna dimension.
All these components are present at every cell site in a D-RAN, which stands for a distributed RAN. And the network from the RAN to the core network is known as backhaul. Resource optimization can be tricky because you need all the components near every antenna; moreover, this situation makes network expansion costly. C-RAN aims to solve this situation.
C-RAN
C-RAN or “cloud RAN,” is a centralized RAN architecture where the BBUs are no longer at a cell site. BBUs in a specific region reside at a single location where managing the resources becomes more accessible, leading to higher performance. In addition, if you have to expand the network, adding more BBUs at a single location is more manageable than at every antenna site.
In addition to the backhaul, the C-RAN also has a fronthaul that connects BBUs to different areas. BBUs then connect to the core network via the backhaul as usual.
C-RAN structure can also split the BBU into distributed units (DU) and centralized units (CU), creating another line called the midhaul that connects DU and CU. This split reduces the distance between CU and the core network; DU will move closer to Radio Unit (RU).
Need for vRAN
Though C-RAN has made the network efficient, the RAN unit runs on the vendor’s proprietary software. This situation restricts collaboration between multiple telcos, so a solution is to use standard servers and run BBUs, CUs, and DUs virtually. That means you run various network functions, like routers, firewalls, and load balancers, on the same server instead of on separate devices.
This way, you can separate software and hardware; you no longer have to use software specific to the vendor. And this reduces hardware costs, making network expansion and collaboration easier.
ORAN
Even though you are free from a particular hardware vendor using vRAN, you still have to get virtualization technologies for RU, CU, and DU from the same vendor because of their proprietary software. ORAN aims to solve this problem by introducing open-source software and setting standards.
You can use different RU, CU, and DU vendors. And according to the O-RAN alliance, you must use specific specs for each RU, CU, and DU to make them ORAN capable. They become O-RU, O-CU, and O-DU.
OvRAN is the name given to such an open and virtualized RAN.
D-RAN | C-RAN | vRAN | ORAN |
Distributed RAN | Cloud RAN | Virtualized RAN | Open RAN |
BBU and RU on every site | Centralized BBU or CU/DU for multiple sites | BBU, CU, and DU run on servers using Network Function Virtualization | Servers run open-source software |
Only Backhaul connection from BBU to core network | Fronthaul from RU to BBU and then backhaul to core or fronthaul to DU then midhaul to CU then backhaul to Core network | fronthaul to DU then midhaul to CU then backhaul to Core network | fronthaul to DU then midhaul to CU then backhaul to Core network |
Difficult optimization of resourcesDependence on proprietary hardware and software | Increased Resource Optimization | Eliminated dependence on specific hardware | Eliminated vendor lock-in |
O-RAN Goal
The goal of the O-RAN alliance is to use any vendor in building a RAN architecture. In present ORAN, you have to use RU from the same vendor manufacturing the antenna; you can have DU and CU from a different vendor.
Need of ORAN in 5G
5G aims to enhance operation in many industrial sectors that collaborate extensively; therefore, you need to have highly collaborative 5G architecture, not locked on any specific vendor. And only an open architecture can fulfill this criterion, so ORAN and the O-RAN alliance are essential to using 5G technology efficiently.
Moreover, the high speed, low latency, and high device capacity of 5G increase the risk of cyberattacks. An ORAN architecture has several security features that benefit the 5G infrastructure:
- Software and Hardware disaggregation improves security as you need new interfaces, which have separate security layers.
- The disaggregation of functions ensures that any security breach will not affect all the network functions.
- The ORAN architecture implements Zero trust security where all the devices and users must-revalidate themselves regularly.
In conclusion, RAN architecture has undergone a significant shift over the generations in cellular services. It has changed from D-RAN to C-RAN to improve resource optimization and vRAN for software and hardware disaggregation. Finally, the goal of the O-RAN alliance is to build an open RAN architecture where you can use any vendor to build your radio access network. Besides eliminating vendor lock-in and improving collaboration, ORAN is necessary for 5G architecture. It has improved security due to software and hardware disaggregation, adding an extra layer of security. The ORAN architecture specifications also include a trust implementation, where every device will revalidate from time to time.