Open RAN and the future of mobile networks

Open Air

Article from Issue 262/2022
Author(s):

Open RAN brings a new spirit of openness to the radio access networks that form the foundation for the mobile revolution.

Mobile networks have been a major contributor to the technology and culture of the 21st Century. Companies such as Nokia or Ericsson shaped the early generations of the mobile revolution, orchestrated by industrial alliances such as GSMA, ETSI, or the 3GPP. These international organizations created open standards that enhanced competition and helped the growth of the sector. Fast forward to 2022, and the main actors have changed, with names such as Samsung, Apple, or Huawei shaping the smartphone market, but open standards have continued to play an important role.

Like many technological developments, the precedents of mobile communications go back to World War II. The concept of mobile telephones that could help soldiers on the field moved into the civilian sphere after the war, and the 1960s, '70s, and '80s saw the emergence of portable communication systems such as citizens band (CB) radio, walkie-talkies and, finally, early cellular communications.

In the early 1990s, the second generation (2G) of mobile telephony networks made an appearance with the CDMA standard (which was mainly used in the Americas, Japan, and South Korea) and the GSM standard (which was popular in Europe, Africa, Australia, and much of Asia). 2G saw the explosion of mobile phones and effectively transformed the way we view telecommunications: It was no longer about communicating between places but about connecting individuals.

Around this time, the Internet also became a commodity, and users who were accustomed to being connected wanted to browse the web and send email from their phones. Efforts to upgrade 2G soon fell short, and the third generation (3G) began to take shape. The 3rd Generation Partnership Project (3GPP) released the UMTS specification in 1994, which started its commercialization around the turn of the millennium. 3G supported mobile broadband, paving the way for smartphones a few years later.

The relentless appetite for higher bandwidths drove the 3GPP to provide almost yearly updates to the standard. UMTS was updated with Releases 99, 2000, 4, 5, 6, and 7. Although the numbering is odd, from that point on, there was a pretty stable numbering scheme. Releases 8 (2008) through 14 (2014) defined LTE and derivatives, which became known as 4G. LTE greatly simplified the network architecture, making it possible for smaller companies to operate and maintain a 4G network.

More recently, the fifth generation (5G), defined in 3GPP Releases 15 (2018) to 17 (2022), has continued to simplify the network. With the introduction of Network Function Virtualization (NFV) and Software Defined Radio (SDR) technologies, 5G has reduced the cost for fabricating network equipment, opening the market to smaller competitors.

Today the term "mobile network" usually refers to a 3GPP network, as opposed to IEEE WiFi or other types of wireless networking. The 3GPP standard defines some elements that are common to all the generations of digital cellular networks (from GSM onward). A 5G mobile network consists of two large blocks that each contain other functions (Figure 1): the Radio Access Network (RAN) and the Core Network (Core).

Figure 1: Main elements of a 5G mobile network.

Core Network

In 5G, the main core network functions are:

  • User Plane Function (UPF): contains all the functions that are directly related with connecting the terminal with the Internet. Among these functions are routing and forwarding, Network Address Translation (NAT), packet filtering, Deep Packet Inspection (for lawful communication interception; yes, this function is defined in the standard [1]) and, of course, billing. These functions compose the user plane. All the other functions of a 5G network are called control plane functions and are needed to support the correct operation of the user plane.
  • Access and Mobility Management Function (AMF): performs the roaming functionality, that is, the required operations for reassigning serving gNodeBs to the terminal and doing the handover such that the user plane can always provide connectivity to the terminal.
  • Authentication Server Function (AUSF): contains the user authentication features for other core functions.
  • Session Management Function (SMF): keeps track of the connections in the user plane and ensures their correct operation according to user policies for the specific terminal.
  • Network Slice Selection Function (NSSF): supports the network slicing [2] functionality, which divides resources of the network among several slices or sub-networks. Each slice can support different configurations, services, etc., virtually, while sharing bare metal resources with other slices.
  • Policy Control Function (PCF): contains the rules that regulate other control plane functions (such as the resource assignment to different slices) and the connections in the user plane (e.g., different quality of service (QoS) parameters).
  • Unified Data Management (UDM): Acts as a centralized database containing the user data, such as session status and authentication keys. It is used by other functions such as AUSF and SMF.
  • Application Function (AF): Provides services to the end user. The AF is the equivalent of a remote service over the Internet but with an increased integration into the mobile network (e.g., for using the user profile or faster user plane connections).
  • Network Repository Function (NRF): acts as a centralized repository for the software packages that implement all the core network functions.
  • Network Exposure Function (NEF): acts as an interface for developing new services in the 5G Core – contains SDKs, APIs for third-party AFs, and other elements.

All these network functions are implemented by software packages running over a powerful computer (which normally runs some enterprise-grade Linux distribution such as RHEL or SLE).

The RAN contains all the elements that make a mobile network mobile, namely, the base stations (Figure 2) that act as access points for the terminals. This architecture has advanced significantly with the consecutive generations, and the elements of a base station have been renamed, reshaped, and reduced in size several times. Since 4G, another part of the architecture is femtocells, which are small form factor base stations with a size and shape similar to a WiFi access point. Femtocells (Figure 3) improve coverage for small offices, indoor public spaces, and homes. In 5G (and, by the way, also in 6G), base stations are better known as gNodeBs.

Figure 2: Antenna of a typical base station.
Figure 3: 5G femtocell (CC BY-SA 4.0, user Liumjs from commons.wikimedia.org).

The RAN is basically a network of access points that provides connectivity below the IP layer and cannot on its own connect to the external world or provide services such as authentication or roaming. Instead, these services are functions of the core network. In other words, the core network contains all the elements that make a mobile network a network. (See the box entitled "Core Network" for more on the key core network functions.)

As new generations of mobile networks have advanced, these elements of the core network have become more and more open. In the 5G environment, core network functions can be programmed and distributed by different vendors, as long as they follow the 3GPP standard interfaces. This open approach has many benefits. For instance, the NRF function makes it easier to manage packages from different vendors, eliminating incompatibilities that could otherwise render a network inoperable.

This trend in opening the standards has also extended to the RAN, where a similar microservice-based architecture is emerging: Open RAN.

Open RAN

The microservice-based approach used in the 5G Core Network turned out to simplify the addition and maintenance of new functions, the integration of third-party software, and the usage of off-the-shelf computers for running the infrastructure. In other words, it was a good idea. So the next logical step was to move this good idea to the other part of the network, the RAN. In 5G, the RAN also had open specifications to a good degree (e.g., network functions, protocols, etc.). The only roadblock was that only a limited number of manufacturers had the fabrication capabilities for building the required equipment: high-frequency radio transceivers and amplifiers, carefully designed antennas, highly selective filters, and other highly specialized tools. Traditionally, this limit has reduced the number of actors in the RAN market to a few large enterprises, such as Huawei, Nokia, and Ericsson.

Nevertheless, the conjunction of several technological advances in recent years has changed the outlook for the RAN. First and foremost, Software-Defined Radio (SDR) allows the usage of generic radio equipment, which can be fabricated by third parties and acquired by RAN equipment integrators. There is no need to build custom RAN-specific radio chips, which are costly and only available to a few manufacturers. An SDR board with a powerful computer and the appropriate software for the signal processing can become a base station for a RAN. Secondly, the development of cloud computing has made it possible for integrators to use cloud providers to support all the signal processing. The need for "powerful computers" then is replaced for a much more economical cloud instance where resources are provided on demand. These two technologies on their own already point at drastic cost reductions, bringing smaller competitors into play, including small enterprise companies such as Amarisoft, Yepzon, and Viavi.

But an even higher degree of openness is possible. Although these small enterprises could each have their closed, monolithic solution, there is another way: Open RAN is a new approach that redefines the RAN as a set of microservices with an open specification of interfaces. The Open RAN specification defines functional blocks, along with the interfaces that connect them, such that a RAN integrator can make a RAN solution with off-the-shelf hardware (or cloud instances), some SDR modules, and a set of software components from different manufacturers that perfectly interact with each other. These components can be updated as vendors add new features, correct errors, or support future 3GPP releases.

Figure 4 shows the elements defined in Open RAN. The main concept is "disaggregation." Instead of having a discrete gNodeB, OpenRAN divides the functions among three main components:

Figure 4: Components of Open RAN.
  • The Radio Unit (RU): Contains all the functionalities of the gNodeB that deal with the radio signal, such as modulation and demodulation, filtering, etc. In technical terms, the RU implements the lower physical layer. You can find a definition of the physical layer in the "Reference Model" box. It is the part that normally will run within an SDR device.
  • The Distributed Unit (DU): Contains the rest of the lower layers, such as the baseband processing (see the "Radio Aspects" box) of the higher physical layer, the MAC layer, and the RLC layer. The DU communicates with the RU to send and receive data over the air, and it is called "distributed" because it is normally deployed physically near the RUs to reduce latency.
  • The Central Unit (CU): Contains the higher layers, that is, functions such as routing the user and control data (PDCP layer) and assigning network resources such as channels and carriers (RRC layer). It is usually in a centralized location (hence the name) and can even be physically running in the same computer as the core.

Reference Model

Figure 5 shows the reference model of the 5G network. The three main elements are the terminal, the gNodeB, and the core network. The terminal can be a smartphone, an IoT system, a laptop, or any similar device. The gNodeB is the equivalent of a switch in Ethernet, acting below the IP layer. The core network is the equivalent of the ISP network. From bottom to top, the layers of the reference model are:

  • Physical layer (PHY): deals with all the radio aspects of the communications, such as modulation and demodulation. See the "Radio Aspects" box for a definition of these terms.
  • Medium Access Control (MAC): defines logical channels over the PHY channels (which are defined by time and frequency). Also performs error correction.
  • Radio Link Control (RLC): provides a data transfer service to upper layers over the MAC, with error recovery, segmentation and reassembly, and reestablishment of radio link when needed.
  • Packet Data Convergence Protocol (PDCP): provides an interface to higher layers with one or several RLC entities. This allows multi-connectivity, the ability of connecting to more than one gNodeB at RLC layer. It also provides some throughput gains with header compression.
  • Service Data Adaption Protocol (SDAP): provides mechanisms to ensure certain quality of service (QoS) to different data flows. For instance, for video streaming, a steady data flow with a relatively high bandwidth is required, while for web browsing, the QoS requirements can be relaxed. This sublayer is present in the user plane, the part of the protocol stack that is used to transmit user data.
  • Radio Resource Control (RRC): this is a control plane sublayer, so the functions it contains do not deal with user data, but with the metadata required to keep the service working correctly. In this case, it contains all the required protocols to keep the radio connection open and stable. It deals with handovers (changes of serving gNodeB), changes to more robust or capable modulations, etc.
  • PDU layer: only present in the user plane and only in the terminal and the core network. It contains the IP functionality and connects the terminal to the UPF, which acts as a router.
  • Non Access Stratum (NAS): only present in the control plane and only in the terminal and core network. It contains the control functionality, such as the establishment of connection between the terminal and core in the user plane, authentication, and other services.
  • Application: in the user plane, the Application layer contains the higher layers of the services that operate between processes in the terminal and the remote servers.
Figure 5: Layers of the 5G protocol. Only the interfaces with the terminal are described.

Radio Aspects

Probably the first thing that comes to mind when talking about a mobile network is the radio technology that makes it possible. These functions are all contained in the PHY layer and are some of the most specialized parts of the network that require their own hardware. For digital radio transmission, we start with a baseband signal (Figure 6), which is made up of one or several electric signals that represent digital bits. The spectrum of this signal (its Fourier transform) is centered around 0 Hz and has a limited bandwidth. You can then modulate this signal, i.e., transform it such that its central frequency is at a specific given frequency. You can also modulate several different streams of bits in adjacent frequencies, which is called Frequency Division Multiple Access (FDMA). Each of these channels (also known as subcarriers) is dedicated to different users or data streams in different times (Transmission Time Intervals or TTI), a scheme that is called Time Division Multiple Access (TDMA). In mobile networks, Orthogonal FDMA (OFDMA, an improved version of basic FDMA) groups a set of several subcarriers into a carrier. The OFDMA subcarriers and TTIs define what is called the resource grid (Figure 6), in which each element has a defined logical function.

Figure 6: Process of modulation/demodulation and the resource grid resulting from TDMA and OFDMA in 5G.

Another element shown in Figure 4 is the RAN Intelligent Controller (RIC), which contains functions that control the overall operation of the RAN elements. The RIC includes functions such as optimization of resources, monitoring, etc., and even end user services that must be very close to the terminals. The RIC is further divided into Real Time RIC, for some lower-layer functions that require quick reaction times, and Non-Real Time RIC, for functions with longer timeframes In 6G, this element will contain ML-based solutions that continuously monitor the network, learn by reinforcement, and improve the quality of service.

Except the RU, all other components are software components that can run in any computer with the minimum CPU, memory, and storage requirements. This support for commodity hardware means a drastic cost reduction for RAN manufacturers and operators.

The RAN can then be thought of as a network containing cloud instances and off-the-shelf computers, some of them with SDR devices. Some of this infrastructure is centralized, in a third-party cloud (such as AWS or Azure) or in a data center of the operator. And some of it may be distributed all over the coverage area of the operator, near where the RUs and users are located, in what is called the "network edge." Thanks to virtualization, all of this infrastructure is available to all the functions of the RAN. Virtual functions can be moved flexibly between the central infrastructure and the network edge to reduce latency or to harmonize the usage of computing resources.

Undoubtedly, as was the case with the core network, Open Source is bound to play a major role in future networks. Open interfaces open the RAN market for small enterprises or even the Open Source community, and thanks to the ease of just using off-the-shelf hardware that is easily accessible, anyone with the required knowledge, some documentation, and, of course, lots of time can start developing functions. This work would also not need to be started from scratch, as you will see in the next section.

Open RAN Implementations

The O-RAN Alliance [3] was created to standardize the interfaces of an Open RAN implementation. The alliance is a consortium made up of large corporations, small and medium enterprises, universities, and research centers. Among them are open source vendors such as Red Hat and SUSE. The O-RAN Alliance regularly releases open specifications that anyone can access. These specifications define how the different elements of an Open RAN (as shown in Figure 4) should behave, including the protocols used in the interfaces and other elements. The alliance has also set up a partnership with the Linux Foundation, called the O-RAN Alliance Software Community, to create an open source software implementation of these specifications, which anyone will be able to downloaded and test, and to which any developer can contribute. The alliance is still in an early development stage. Some elements are already working, and some proof-of-concepts are at a showcase stage. Some other elements, such as the RU, are still missing.

The Telecom Infra Project (TIP) [4] is another partnership of large enterprises of the sector that initially was created for defining another Open RAN specification, but it soon adopted the design of the O-RAN Alliance and promoted its own software implementation: OpenRAN (note that in this case there is no space between Open and RAN). TIP works actively in creating implementations of Open RAN elements, including some radio interface designs (such as a full WiFi stack), and also other mobile network elements, like an Open Core network. TIP also holds "plugfests," where different Open RAN vendors test the integration and interoperativity of their functions. Although these are the most known Open RAN projects, there are some other implementations, such as OpenAirInterface [5], which provides an Open Source, O-RAN Alliance compliant solution.

There is some criticism [5] on the Open RAN concept for not having achieved the promise of a fully Open Source RAN, with a focus on the difficulty of developing the radio infrastructure. In fact, there are several roadblocks that make development of SDR functions for mobile networks very difficult or outright impossible (at the moment) for small enterprises or community developers. On the one hand, the required equipment, which is not only the SDR boards, but also testing equipment to verify functionality and compliance of standards and regulations, is very expensive. On the other hand, regulations are also very restrictive: The equipment that is used in mobile networks needs to be certified by the appropriate authorities, and a special license granted by public authorities is required to transmit radio signals in most frequencies (including those where most of cellular communications take place). In the long term, there are solutions for some of these problems. For instance, expensive measuring equipment might be replaced in the future by open source SDR-based implementations. Regulatory roadblocks, on the other hand, are harder to overcome. Currently, small enterprises and research centers access the spectrum usage license through partnerships with operators, which greatly limits the development, and expensive tools such as anechoic chambers (basically Faraday chambers that block outgoing high frequency radio signals). In any case, the creativity and ingenuity of the open source community has time and again proven that it can overcome such problems.

The Role of Open Hardware

One of the main selling points of NFV in the network core and the Open RAN are the possibilities for running most of the network functions in off-the-shelf computers or common cloud instances. Regarding the underlying hardware, the first name that comes to mind to the layman when talking about "off-the-shelf" computers are x86-based systems. These systems are easy to acquire and easy to replace, and once their lifetime in the network ends, they can be reused for other purposes. Their operation and maintenance is low, documentation and expertise abounds, and they have a very high level of support from manufacturers and tools. On the downside, x86 systems are not very energy efficient, which is an increasingly important concern for operators, both in terms of carbon footprint and energy bills.

More recently, energy-efficient ARM processors are starting to be used in servers. Although ARM currently doesn't have the level of support or the quantity of software available for the x86, interest in ARM is growing by the day.

Finally, no processor discussion would be complete without mentioning RISC-V. The RISC-V platform has the advantages of ARM in power consumption (although it falls behind in terms of maturity), and it is open source hardware. Potentially, small enterprises could extend RISC-V processors to include specific functions for the mobile network. Also, thanks to its openness, it is expected that once the demand for RISC-V increases, the prices will drop.

Up to this point, I have discussed the hardware for supporting the software part of the mobile network, that is, the core network and the DU, CU, and RIC in the Open RAN. What about the RU? Although on the paper it looks just like a small part, the RU is fundamental for radio communications, and it is one of the hardest parts to work on. However, there are several options, such as the USRP devices from Ettus Research [6], which offer open source drivers. USRPs are a favorite of researchers in the field due to the large community that has gathered around them. Another commercial option is the LimeSDR [7] boards, which are open source hardware. They are more cost effective than USRPs and are starting to be adopted by the community. They are also used in several commercial RAN solutions developed by integrators such as Amarisoft. The HackRF [8] and PlutoSDR [9] devices, which are also open source, are very cheap alternatives that can be acquired by community developers. Although these devices are not as powerful as LimeSDR or USRPs, they are good starting points for learning and exploring Open RAN functions. You can also use HackRF and PlutoSDR to start developing much needed auxiliary tools, such as spectrum analyzers.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • DCCP

    The DCCP protocol gives multimedia developers a powerful alternative to TCP and UDP.

  • ESP8266 for WiFi Sniffing

    The ESP8266 is in the core of many IoT devices. Thanks to ESP8266 sniffer mode, you can monitor the WiFi medium for diagnostics and optimization.

  • Mesh Networking

    Mesh networking comes to with the IEEE802.11s draft standard. We'll show you how to mix a mesh.

  • OpenDaylight

    Several well-known companies are collaborating on the foundations of future SDN products under the umbrella of the OpenDaylight open source project.

  • OpenDaylight Project Formed

    OpenDaylight is an open source software-defined networking project committed to furthering adoption of SDN and accelerating innovation in a vendor-neutral and open environment.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News