A few telecom generations ago, Radio Access Network (RAN) equipment was typically provided by a quite small number of telecom equipment manufacturers. There was Ericsson, Nokia, Huawei, Siemens, Alcatel, Lucent, Nortel, Motorola and a few more. Although there were standardized interfaces – by ETSI/3GPP – from BTS to BSC (in 2G) and Node B to RNC (in 3G), conventional wisdom among operators was that mixing equipment from different vendors could result in trouble, or at least some lost functionality.
During the last decade or so, trends like virtualization, cloudification and softwarization has changed the RAN landscape. The 4G/LTE base station, the eNB, is technically one entity in 3GPP specifications. But real-world implementations often split the eNB into multiple physical and logical parts, often referred to as e.g. Base Band Units (BBUs) and Remote Radio Units (RRUs). It’s important to note that the terminology here is un-standardized, which means that there is no all-encompassing view of what a BBU, RRU, RRH or RU exactly is or does. And obviously, splitting base stations into smaller parts leads to the introduction of new (more or less standardized) interfaces and protocols.
In 5G, 3GPP introduces a split of the 5G base station, the gNB, into a central unit (gNB-CU) and a distributed unit (gNB-DU), separated by the F1 interface. The gNB-CU can in turn be split into a control plane part (gNB-CU-CP) and a user plane part (gNB-CU-UP) since handling the control plane signalling to/from UEs is quite a different task from handling the user plane traffic. Hence, the E1 interface has been introduced resulting in a gNB design shown in the picture below.
Figure 1: gNB split according to 3GPP
So where does Open RAN fit into all this? First of all, Open RAN is not one single thing! In fact, there are various Open RAN initiatives and projects that, in different ways, aim to make the RAN ecosystem more “open”. For example, the Telecom Infra Project (TIP) has a high-level goal of making affordable telecom infrastructure available to a larger share of the world’s population. There is also the Open RAN Policy Coalition which, as the name suggests, tries to influence policy makers to act for more openness in the RAN world.
And then there is the O-RAN Alliance, who in their own words are “Transforming the Radio Access Networks Industry Towards Open, Intelligent, Virtualized and Fully Interoperable RAN”. So, it is about openness and interoperability, which means allowing new players to enter the RAN market with new software, hardware or services. It is about intelligence, which means using Artificial Intelligence (AI) and Machine Learning (ML) to make RANs faster, better and more flexible. And obviously, the assumption is that most things in a RAN will be deployed as virtualized network functions (VNFs) rather than physical entities.
O-RAN Alliance has 26 operator members including some of the biggest operator groups on this planet. They cannot be ignored! There are also some 200 contributors – a variety of companies of different sizes and businesses that are in some way involved in the O-RAN activities.
The O-RAN Alliance writes technical specifications. Their purpose is to complement 3GPP specs, not to replace or compete with them. In fact, the O-RAN Alliance also aims to give input to 3GPP specification work so that more openness can be achieved.
O-RAN Alliance has presented an O-RAN logical architecture as shown in figure 2 below.
Figure 2: O-RAN overall logical architecture (source: O-RAN Alliance white paper)
Some things are familiar, like the F1 and E1 interfaces and terms like O-CU-CP, O-CU-UP and O-DU, which can roughly be mapped to the 3GPP terminology. But in the O-RAN architecture, there is also an O-RU (O-RAN Radio Unit) which contains the lower part of the physical layer. This calls for the introduction of yet another interface – the Open Fronthaul interface.
The Open Fronthaul interface is based on eCPRI (enhanced Common Public Radio Interface). Despite eCPRI being an industry standard, there is still room for implementation-dependent features and tweaks. And actually, the same has been said for F1. Although F1 is standardized by 3GPP, vendors are often tempted to squeeze in some special vendor x-specific feature. Understandable as this may be, it still counteracts the idea of open interfaces and interoperability. And this is of course why O-RAN Alliance aims for truly open and standardized interfaces.
The O-RAN logical architecture also shows an “O-Cloud” which is where virtualized O-RAN network functions are implemented as virtual machines (VMs) and/or containers using COTS (or white-box) hardware. Decoupling of software and hardware is one of the pillars in the O-RAN approach.
One area which historically often has been unclear or incomplete in 3GPP specifications is Management and Operation. We frequently use acronyms like OSS/BSS, O&M, FCAPS etc. but these systems and features are typically based on proprietary solutions from vendors or the operator itself. So, in order to have a common approach to how the RAN entities are configured, supervised and dynamically managed, there is the Non-Real Time RIC (RAN Intelligent Controller) and Near-Real Time RIC.
In 5G NR, radio resources are assigned and re-assigned on millisecond level. In fact, Radio Resource Management (RRM) can even be done in fractions of milliseconds subject to so-called NR numerologies. These super-fast RRM cycles happen between O-DU and O-RU, i.e. “far out” in the RAN. But if we want the RRM to be dynamic, adaptive and flexible, then the base stations – or parts of them – need to be informed that another priority scheme shall be used. Or that the interference level in some cell(s) calls for a different algorithm to be used, or that a certain group of Public Safety UEs now needs 25% more capacity. This is where the Near-Real Time RIC comes in, working in decision cycles of 10 ms – 1s, giving RRM instructions to the O-CU and O-RU. The Near-Real Time RIC hosts so-called xApps which can be viewed as applications that perform some type of radio-related service. The xApps can come from the vendor of the Near-Real Time RIC or from a third-party company. Again, openness refers also to the possibility for a small company with a nice idea for some RAN-related service to be part of the huge global RAN market. The figure below shows applications inside the Near-Real Time RIC.
Figure 3: O-RAN Alliance reference architecture (source: O-RAN Alliance white paper)
And then we have the Service Management and Orchestration (SMO) layer containing, among other things, the Non-Real Time RIC. In short, SMO is about managing equipment and functions. Starting and configuring things, scaling them when conditions change, making sure they work as they should and stopping/deleting things when they are no longer needed.
The Non-Real Time RIC operates in “cycles” of more than 1s. It makes decisions based on input from the RAN itself, but also other external sources, for example a Business Support System or an Application Server. In a sense, this allows “the outside world” to interact with the RAN and influence the Radio Resource Management in almost real-time.
If you were in the telecom business about 20 years ago, you may remember that some operators feared that their networks would be reduced to “stupid bit pipes” for OTT (Over-The-Top) services provided by someone else. In hindsight, it is true that most services/applications today are not from the traditional operator. But the networks have become far from “stupid bit pipes”! And perhaps we should view the various Open RAN initiatives as yet another way to make RANs even more intelligent, allowing everyone involved to get more value from them.
[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]
