CTO insights into Open RAN features and vendor flexibility

Open RAN  features and vendor flexibility | Digis Squared CTO AbdelRahman Fady shares his insights.

In this series of blogs focussing on Open RAN, AbdelRahman Fady, Digis Squared CTO, and Mohamed Hamdy, Chief Commercial Officer, share their insights.

In this first blog, AbdelRahman considers traditional, legacy RAN implementations, why Open RAN is needed, and the benefits and options it brings. He looks at technical features and vendor selection considerations, and how to balance features, flexibility and efficiency.

Open RAN features and vendor flexibility: a technical overview

AbdelRahman talks us through traditional legacy RAN implementations, and the new architectures and benefits of Open RAN.

“Mobile networks comprise two domains: the Radio Access Network (RAN), and the Core Network (Core).

• RAN: the final link between the phone and network. Includes the antennas and towers we see on top of buildings, as well as base stations. The RAN base station digitises the signal to and from devices. One of the most expensive parts of the network.
• Core: Provides access controls, authentications of users, routes calls, handles charging and billing, manages interconnect to other networks and internet. Ensures continuity of connection as a user moves and travels from one RAN tower to another.

Traditional, legacy RAN: hardware and software are very closely linked; selecting a vendor for the traditional RAN implementation guarantees performance, however it also constrains feature roadmap. A lack of interoperability means that there is little choice in where equipment is sourced, or the ability to influence innovation; however, identifying the vendor responsible for any fault resolution is simple.

In legacy RAN implementations each single site has its own hardware, however there is no concept of pooling sites’ baseband processing, and this leads to inefficient utilisation of hardware resources.

Legacy sites still need a sufficient space for all the equipment, plus an excellent and reliable power source, and these requirements and limitations have a big impact on the MNO or CSP’s OPEX.

The total cost of ownership (TCO) of Radio sites is still very high, and this impacts the scale and pace of CSPs expansion plans, especially in city outskirts and rural areas; any expansions is completely locked into the current vendor’s equipment.

The drive for new RAN architecture has been powered by better resources utilisation through pooling, and more powerful processing through centralisation. Additionally, the introduction of machine learning (ML) concepts in handling radio resources, as well as reducing sites TCO. The new RAN model should provide CSPs with implementations that need far less space and power, thereby significantly reducing the OPEX.

Before addressing the new RAN architectures, we will first consider the main RAN components we have and how can we split them.

RAN solutions typically have three key components,

• Radio Unit (RU): radio frequency signals are transmitted, received, amplified and processed
• Baseband processing: all the digital processing over the signals, along with all the interfaces needed to the transport network, and the CPU functions of the site. Today we can split this function into,
  • Distributed Unit (DU): handling all real time processing over the signal
  • Centralised Unit (CU): non-real-time processing over the signals plus the main computational function for the signal.

3GPP has defined models to split the functions between DU and CU, and provide the CSP/MNOs with a high degree of freedom to deploy the most suitable split model according to their network readiness. With new RAN architectures, away from legacy solutions, there are different implementation options based on the location of DU and CU,

• Distributed Cloud RAN
  • DU: co-located with RU on the same site, where the remote Radio Unit (RRU) is connected to the DU through fronthaul interface (eCPRI)
  • CU: co-located near(er) the Core, and connected to DU through mid-haul transport network with specific transport network requirements, and connected to the central network (CN) through the backhaul
• Dual split Cloud RAN
  • DU: is located away from RU, within Edge Cloud. More than cell site could be connected to the same DU, however, the fronthaul requirements should be achieved by the transport network.
  • CU: co-located near(er) the Core, and connected to DU through the mid-haul transport network, with specific transport network requirements, and connected to CN through the backhaul
• Centralised RAN DU & CU:  centralised in the same location, near to the CN

The selection of the architecture to be deployed, and the functional split model should be carefully considered, with particular awareness of the transport network readiness and capabilities.

DU and CU concepts are introduced along with the concept of virtualisation; now the HW and SW are not locked to a specific vendor and from here we can jump to the ORAN concept.

Open RAN aims to ensure that the interfaces between these components are standardised, interoperable and open – expanding the ecosystem of solutions and vendors, driving speed and diversity of innovation and opening up greater flexibility in deployment.”

Benefits: Open RAN features and vendor flexibility

“Open RAN aims to deliver greater flexibility and vendor choice. When this is implemented as vRAN, the open and flexible architecture virtualizes network functions in software platforms based on general purpose processors.”

Together Open RAN as vRAN can deliver,

• Cost savings: virtualised network, with containerised components – true scalability and cost management.
• Sharing via network function virtualisation – one or more virtual machines run different software and processes, on standard high-volume servers, without the need for custom hardware appliances for each network function – enables multiple operators to securely run segregated networks, side by side on the same platform. In the future, this will also enable network sharing through software.
• Vendor choice: contractual flexibility to balance features, cost, and adjust future decisions; opening up and standardising interfaces gives a greater choice of vendor solutions.
• Third-party testing: plug-fests and independent testing will give MNOs and CSPs greater clarity on capability and interoperability, enable benchmarked KPIs, and test-labs will develop deep knowledge of quirks and capabilities of different systems.

Open RAN architecture

“The model above shows the new open interfaces available as part of Open RAN. These have been introduced between fully virtualised nodes with the newly standardised concept of RIC (RAN intelligent controller, with near RT RIC and non real time RIC options) for controlling the radio resources and features. They enable huge opportunities for new vendors to innovate new algorithms and features to enhance the overall performance of the new system supported with Machine Learning and Deep Learning algorithms.”

Challenges for the new RAN evolution

AbdelRahman, you have shared a lot of technical insights into the changes in RAN technology, and the benefits the new standards and architecture OpenRAN will bring. But let’s balance that out, it can’t all be good news!

AbdelRahman, what do you consider to be the three greatest challenges currently?

1. “Performance: For sure, comparing the performance of very mature solutions from vendors who deployed very early, against the very latest ORAN vendors solution is not very fair! There is still a long way to go to reach good maturity for ORAN solutions
2. Real interoperability: Actually, one of the big issues of the ORAN nowadays is the full interoperability between OS, SW, HW and orchestrators vendors. In reality, today, not all vendors are compatible for the time being, and that’s why, before deployment, CSPs still need to do IOT interoperability testing of the solution
3. Infrastructure readiness: In ORAN the fronthaul interface is mostly conveying real time data and signalling. That’s why we need to adopt very strict performance requirements between sites and EDGE clouds or Central clouds according to the selected split options.”

In conversation with AbdelRahman Fady, Digis Squared CTO.

A whole new world of acronyms

Let’s answer some common queries!

Is cloud RAN the same as Open RAN? And what about vRAN?

• Cloud RAN / C-RAN: centralised, consolidating the baseband functionality across a smaller number of sites in the telco’s network and cloud.
• Virtualised, vRAN: more open and flexible architecture which virtualizes network functions in software platforms based on general purpose processors.
• Open-RAN (notice the hyphen!): uses new open standards to replace 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.

What is the difference between O-RAN, OpenRAN, Open-RAN and Open RAN?

• O-RAN: an organisation, the O-RAN Alliance. Work to support open standards.
• OpenRAN: a standard written by TIP, Telecom Infra Project.
• Open-RAN (notice the hyphen!): uses new open standards to replace 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.
• Open RAN: industry-wide interface standards that enable RAN equipment and software from different vendors to communicate.

How can Digis Squared help you with Open RAN?

The Digis Squared team are here to help, and can provide their experience, AI-led tools, and capabilities to help operators and CSPs with all aspects of Open RAN strategy, testing and deployment optimisation.

• We provide the industry with a range of OpenRAN related services including integration, performance benchmarking and systemisation.
• Collaborate with operators, vendors, system integrators and research institutes to promote and accelerate OpenRAN ecosystem development, focused on,
  • System Integration
  • Interoperability between vendor components
  • Release validation
  • End to end performance benchmarking
  • Trials and PoCs.
• Showcase and promote OpenRAN within the industry (TIP, O-RAN, GSMA)
  • Capacity solutions, cost-effective rural coverage, 5G solutions.

If you or your team would like to discover more about our OpenRAN capability, or other elements of the work we do, please get in touch: use this link or email sales@DigisSquared.com .

Read CCO Mohamed Hamdy’s blog, Digis Squared Open RAN projects and capabilities.

Keep up to speed with company updates, product launches and our quarterly newsletter, sign up here.

Digis Squared, independent telecoms expertise.

Sources

1. Nokia
2. Mavenir 1 and 2

Abbreviations

• CN: Central Network
• CSP: Communications Service Provider (ComSP)
• CU: Centralised Unit
• DL: Deep Learning (AI)
• DU: Distributed Unit
• eCPRI: enhanced Common Public Radio Interface
• HW: hardware
• ML: Machine Learning (AI)
• NFV: Network Function Virtualization (=VNF, Virtualized Network Function)
• PoC: Proof of Concept
• RAN: Radio Access Network
• RIC: RAN Intelligent Controller
• RU: Radio Unit
• RRU: Remote Radio Unit
• SW: software
• VNF: Virtualized Network Function (= NFV, Network Function Virtualization)

Image credit, Digis Squared social media and blog banner image: Andy Newton @bacchanalia, The Floating Harbour, Bristol dock, UK.