Telefónica views on

the design, architecture,

and technology of 4G/5G
Open RAN networks
Francisco Javier Lorca Hernando, Elena Serna Santiago, Maite Aparicio Peña,
Alexander Chassaigne Ricciulli, Jose Luis Esplá Gutiérrez

January 2021
Open RAN White Paper

Abstract

This paper provides an overview of the main

technology elements that Telefónica is developing
in collaboration with selected partners in the Open
RAN ecosystem.
It describes the architectural elements, design
criteria, technology choices and key chipsets
employed to build a complete portfolio of radio
units and baseband equipment capable of a full
4G/5G RAN rollout in any market of interest.
Open RAN White Paper Open RAN White Paper

Table of Contents

1. Introduction 7 4.2. FPGA selection criteria for the RRU 17

2. Targeted 4G/5G sites based on Telefónica needs 9 4.3. O-RAN Fronthaul interface 17
3. DU design details 9 4.3.1. IOT Fronthaul profiles 18
3.1. Central Processing Unit (CPU) 11 4.3.2. Implementation of O-RAN Fronthaul in an O-RU 18
3.2. Hardware Acceleration Card 12 4.3.2.1. O-RU “Category A” 19
3.3. Time, Phase and Frequency Synchronization 13 4.3.2.2. O-RU “Category B” 19
3.4. Time Sync NIC Card 13 4.4. Radio units for 4G/5G low and mid bands (up to 3.5 GHz) 21
3.5. Memory Channel Interfaces 14 5. Cloud Architecture 22
3.6. External Interface Ports 15 5.1. Open RAN virtualized solution 22
4. RRU design details 15 5.2. vCU and vEMS 23
4.1. Remote Radio Unit Reference Architecture 15 6. Site Integration aspects 24
4.1.1. Synchronization and Fronthaul Transport Function Block 16 7. Summary and Conclusions 25
4.1.2. Lower PHY Baseband Processing 16 8. References 26
4.1.3. Digital Front End (DFE) 16 9. Glossary 27
4.1.4. RF Front End (RFFE) 17
Open RAN White Paper Open RAN White Paper

List of Figures 1. Introduction

Figure 1: Types of sites typically found in 4G/5G RAN deployments 9 Open RAN represents a giant step forward in take the leadership in Open RAN development,
Radio Access Network (RAN) evolution. It cons- testing, integration, rollout, and end-to-end ope-
Figure 2: 3GPP split 2 and split 7 architecture 10 titutes a radical transformation of the RAN ration. That is why Telefónica has been an early
technology, from the design stage to the com- adopter and is playing a very active role in open
Figure 3: Example of main components that can be identified in an Open RAN DU server 11
plete operation of the network. The whole radio networks.Telefónica is writing a new chapter
Figure 4: Integration of Silicom’s Hardware ecosystem is evolving in this direction by giving in RAN history by leading this transformation
Acceleration Card ACC100 into a FlexRAN-based system platform 12 rise to a richer landscape of vendor partners, and among the traditional network operators. Other
network operators are also evolving to encom- disruptive 5G operators, like Dish, Rakuten, and
Figure 5: Internal architecture of a Time Sync NIC card based on Columbiaville 13 pass such transformation. Reliance Jio, are already challenging their peers
Figure 6: While former Open RAN implementations rely on fronthaul switches for connec- in the countries where they operate. Traditional
tion of RUs to the DU, Time-Sync NIC cards allow direct connection for improved reliability 14 Telefónica believes that mobile networks are cable and satellite content providers are also ac-
evolving towards an Open RAN virtualised model, quiring spectrum and becoming operators. The
Figure 7: Reference architecture of an Open RAN RRU 15 built on off-the-shelf hardware and cloud-based result is a new dynamic RAN economy in which
software in a multivendor environment with open operators, software suppliers, IT and radio hard-
Figure 8: O-RAN Fronthaul interface protocol structure 18 interfaces between network elements. This new ware vendors, and system integrators will take
Figure 9: Functional basic block diagram of fronthaul interface in O-RU 18 architecture will have a significant impact on the part.
telecoms industry. It will allow the entry and dis-
Figure 10: O-RU “Category A”. Blocks above the O-RAN FH line are ruption of new entrants, enable faster software Open RAN technology is already gaining momen-
executed at the O-DU, whereas those below it are executed at the O-RU 19 innovation, allow more network flexibility, and fa- tum. The transition from the lab to a technically
cilitate network exposure to third-party Multi-ac- demanding dense urban scenario is being aided
Figure 11: O-RU “Category B”. Blocks above the O-RAN FH line are
cess Edge Computing (MEC) applications through by the works in industrial associations like the
executed at the O-DU, whereas those below it are executed at the O-RU 20
open Application Programming Interfaces (APIs). O-RAN Alliance, the Open RAN Policy Coalition,
Figure 12: Illustration of a Telco Cloud Open RAN architecture 22 the Telecom Infra Project (TIP), the GSMA, the
5G can strongly benefit from the introduction of Broadband Forum or the Open RAN G4, to name
Figure 13: Schematic illustration of the main the open network paradigm. Current RAN pro- a few. Open RAN is also part of the agenda of the
interfacesand network elements in a 5G Open vRAN architectur 23 viders and many smaller suppliers are putting European Commission to be incorporated in the
strong efforts in developing Open RAN efficient next Joint Undertaking program of public/private
Figure 14: Interconnection of Open RAN DUs for the main four 4G/5G
site types, where time and phase references are provided by a GNSS receiver 24 and innovative hardware and software. However, partnerships to foster network research. All public
Telefónica is a firm believer that operators are the and private stakeholders recognize the strategic
Figure 15: Example of the interconnection of two Open RAN DUs and a 2G/3G BBU ones who must really pave the way in this endea- importance of streamlining the adoption of Open
in a 2G/3G/4G/5G site where the time and phase references are provided by the network 25 vor. Operators should clearly set the needs and RAN in all the relevant markets.

List of Tables
Table 1: Memory Channel Feature List 14
Table 2: External Port List 15
Table 3: Radio units for 4G/5G low bands (below 3 GHz) 21
Table 4: Radio Units for 5G mid band (3.5 GHz) 21

6 7
Open RAN White Paper Open RAN White Paper

This paper provides an overview of the main tech-

nology elements that Telefónica is developing in
2. Targeted 4G/5G sites based on Telefónica needs
collaboration with selected partners in the Open
RAN ecosystem. It describes the architectural
elements, design criteria, technology choices Sites within Telefónica footprint can be broadly classified into four types, from low/medium
and key chipsets employed to build a complete capacity 4G to high/dense capacity 4G+5G, as illustrated in Figure 1. Each of those types correspond
portfolio of radio units and baseband equipment to a particular arrangement of DUs and RRUs whose design and dimensioning represents a key
capable of a full 4G/5G RAN rollout in any market milestone that must be achieved prior to any further development. Representative frequency
of interest. bands are just shown for illustration purposes, as well the number of cells that can be typically
found in each site type.
The remaining sections in this paper are structu- In all cases, dimensioning must ensure that Open RAN fulfils all 4G/5G essential features
red as follows. Section 2 summarizes the main including massive MIMO, Dynamic Spectrum Sharing (DSS), NB-IoT or RAN sharing (to name a
site types found in most 4G/5G deployments, few), while complying with an extensive list of Key Performance Indicators (KPIs) aimed to
that constitute the basis for the targeted confi- verify that performance is on par with traditional RAN.
gurations of the DU and RRU. Section 3 highlights
the DU design details, with strong emphasis on
the case where the DU is physically located at the
site. Section 4 illustrates key design considera-
tions for remote radio units and active antenna
units. Section 5 describes the elements of a Telco
cloud architecture that comprises the CU and the
virtualization environment. Section 6 is devoted
to the site integration aspects in a fully-fledged
2G/3G/4G/5G network, and finally Section 7 is
devoted to the conclusions.

RRU: Remote Radio Unit DU: Distributed Unit

Figure 1: Types of sites typically found in 4G/5G RAN deployments.

The present paper describes the main design considerations of the key Open RAN hardware elements
that Telefónica, in collaboration with key technology partners, has developed to be prepared for
deployments of full-fledged 4G/5G networks based in Open RAN.

3. DU design details
3GPP defined a new architectural model in Release 15, where the gNB is logically split into three
entities denoted as CU, DU and RRU. The RAN functions that correspond to each of the three
entities are determined by the so-called split points. After a thorough analysis of the potential
split options, 3GPP decided to focus on just two split points: so-called split 2 and split 7, although,
only the former one was finally standardized. The resulting partitioning of network functions is
shown in Figure 2.

8 9
Open RAN White Paper Open RAN White Paper

Figure 2: 3GPP split 2 and split 7 architecture.

The CU (Centralized Unit) hosts the RAN functions above split 2; the DU (Distributed Unit) runs
those below split 2 and above split 7; and the RRU hosts the functions below split 7 as well as
all the RF processing.
The O-RAN Alliance further specified a multi-vendor fronthaul interface between the Figure 3: Example of main components that can be identified in an Open RAN DU server.
RRU and DU, by introducing a specific category of split 7 called split 7-2x, whose control, data,
management, and synchronization planes are perfectly defined. The midhaul interface between
CU and DU is also specified by 3GPP and further upgraded by the O-RAN Alliance to work in multi- In the example shown above, the Central Processing Unit (CPU) is an Intel Xeon SP system that
vendor scenarios. performs the main baseband processing tasks. To make the processing more efficient, an ASIC-
The CU and DU can be co-located with the RRU (Remote Radio Unit) in purely distributed based acceleration card, like Intel’s ACC100, can be used to assist with the baseband workload
scenarios. However, the real benefit of the split architecture comes from the possibility to processing. The Intel-based network cards (NICs) with Time Sync capabilities can be used for both
centralize the CU, and sometimes also the DU, in suitable data centers where all RAN functions fronthaul and midhaul interfaces, with suitable clock circuits that provide the unit with the clock
can be fully virtualized and therefore run on suitable servers. signals required by digital processing tasks. PCI-e slots are standard expansion slots for additional
The infrastructure needed to build a DU is nothing else than a server based on Intel Architecture peripheral and auxiliary cards. Other essential components not shown in the figure are random-
optimized to run those real-time RAN functions located below split 2, and to connect with the access memory (RAM) for temporary storage of data, flash memory for codes and logs, and hard
RRUs through a fronthaul interface based on O-RAN split 7-2x. It is the real-time nature of the disk devices for persistent storage of data even when the unit is powered-off.
DU which motivates the need to optimize the servers required to run DU workloads. In what follows we describe in more detail the main characteristics of the key elements that
The DU hardware includes the chassis platform, mother board, peripheral devices, power supply comprise the DU.
and cooling devices.
When the DU must be physically located inside a cabinet, the chassis platform must meet 3.1. Central Processing Unit (CPU)
significant mechanical restrictions like a given DU depth, maximum operating temperature, or full To provide the DU with the best possible capacity and processing power, 3rd Generation Intel
front access, among others. The mother board contains processing unit, memory, the internal I/O Xeon Scalable Processor Ice Lake is employed to benefit from the latest improvements in I/O,
interfaces, and external connection ports. The DU design must also contain suitable expansion memory, storage, and network technologies.
ports for hardware acceleration. Other hardware functional components include the hardware and Intel Xeon Scalable processors comprise a range of CPU variants (called SKUs) with different
system debugging interfaces, and the board management controller, just to name a few. Figure core counts and clock frequency that can support from low-capacity deployments (for rural
3 shows a functional diagram of the DU as designed by Supermicro. scenarios) to higher capacity deployments (for dense urban) such as massive MIMO.
Intel Ice Lake CPU features, among other improvements, Intel Advanced Vector Extensions 512
(Intel AVX-512) and up to 2 Fused Multiply Add (FMA) instructions which boosts performance for
the most demanding computational tasks1 .

1
https://www.intel.com/content/www/us/en/products/docs/processors/xeon/3rd-gen-xeon-scalable-processors-brief.html

10 11
Open RAN White Paper Open RAN White Paper

3.2. Hardware Acceleration Card 3.3. Time, Phase and Frequency Synchronization
One of the most compute-intensive 4G and 5G workloads is RAN layer 1 (L1) forward error Open RAN solutions rely on stringent time synchronization requirements for end-to-end
correction (FEC), which resolves data transmission errors over unreliable or noisy communication latency and jitter. Timing synchronization has become a critical capability and now is fully
channels. FEC technology detects and corrects a limited number of errors in 4G or 5G data without available on COTS hardware using specific NICs with time synchronization support.
the need for retransmission. FEC is a very standard processing function that is not differentiated 5G requires support of time synchronization accuracy across the whole network below 3
across vendor implementations. microseconds for Time-Division Duplex (TDD) carriers, and even more stringent when using MIMO
FEC has been typically implemented on Field Programmable Gate Arrays (FPGA) accelerator or Carrier Aggregation. Contrary to non-Open RAN technologies, Frequency Division Duplex (FDD)
cards, like the Intel PAC N3000. However, recent accelerator cards feature a low-cost, power carriers also require stringent synchronization to sustain eCPRI-based fronthaul interface.
efficient, acceleration solution for vRAN deployments based on Intel eASIC technology, called To ensure this level of precision on COTS hardware, network-based synchronization protocols
the Intel vRAN Dedicated Accelerator ACC100. like Synchronous Ethernet (SyncE) and IEEE 1588v2 Precision Time Protocol (PTP) are key to
Intel eASIC™ devices are structured ASICs, an intermediate technology between FPGAs ensure synchronization at the physical layer. This will be even more essential as moving to
and standard Application-Specific Integrated Circuits (ASICs). These devices provide lower unit- higher frequency radio spectrums like millimeter wave (mmWave) with large MIMO antenna
cost and lower power compared to FPGAs and faster time to market and lower non-recurring configurations.
engineering cost compared to standard- ASICs. Both accelerator options connect to the server In addition, synchronization based on Global Navigation Satellite Systems (GNSS) like GPS,
processor via a standard PCIe Gen 3 x16 interface. Galileo, Glonass or Beidou can provide essential time and phase references in those cases where
Silicom’s FEC Accelerator Card “Pomona Lake” utilizes Intel ACC100 dedicated accelerator to network-based synchronization is not available, or as a back-up in case of network timing failure.
perform forward error correction (FEC) processing in real time, thus offloading such intensive task Open RAN DUs should be prepared for both GNSS and network synchronization when
from the CPU in the host server. The ACC100 implements the Low-Density Parity Check (LDPC) integrating them into a 4G/5G site.
FEC for 5G and Turbo FEC for 4G and supports both concurrently. The ACC100 supports the O-RAN
adopted DPDK BBDev API - an API which Intel contributed to the opensource community for FEC 3.4. Time Sync NIC Card
acceleration solutions. The ORAN fronthaul interface between the DU and the Radio Unit relies on the standard
Intel has invested heavily in a reference software architecture called FlexRAN to accelerate Ethernet protocol to enable multi-vendor interoperability between DUs and radio units.
RAN transformation. FlexRAN contains optimized libraries for LTE and for 5G NR Layer 1 workload Network Interface Cards (NICs) are standard elements in COTS hardware. As an example,
acceleration including optimizations for massive MIMO. The FlexRAN reference software enables the Intel Ethernet 800 Series card (also known as Columbiaville NIC) supports multiple port
customers to take a cloud native approach in implementing their software utilizing containers. speeds (from 100 Mb/s to 100 Gb/s in Intel’s E810) with a single architecture, to meet a range of
As illustrated in Figure 4, the FlexRAN software reference architecture supports the ACC100 fronthaul/midhaul/backhaul requirements for the transport network that makes it suitable for
which enables users to quickly evaluate and build platforms for the wide range of vRAN networks. Enterprise, Cloud, and Telco applications.
Enhancing NICs with support of time synchronization is however essential to make NICs usable
in Open RAN DUs. These cards are usually called Time Sync NICs (Figure 5).
Silicom design a family of NICs (called STS) for Time Synchronization services in 4 ports, 8
ports and 12 ports configurations including support for PTP and SyncE, suitable for the site types
shown in Figure 1.

Figure 5: Internal
architecture of a
Time Sync NIC
card based on Intel
Ethernet 800 series.

Figure 4: Integration of Silicom’s Hardware Acceleration Card

ACC100 into a FlexRAN-based system platform.

12 13
Open RAN White Paper Open RAN White Paper

As shown in Figure 6, Time Sync NICs allow removal of the fronthaul switch between the RU and 3.6. External Interface Ports
DU, thus saving costs and reducing network complexity. Time Sync NICs can provide an accurate The DU must be equipped with enough external ports to enable proper interfacing with hard
Clock to multiple Radio Units and at the same time recover the clock from the midhaul. drives, PCIe cards, Ethernet ports, and other peripherals. Below is a table with some of the main
external interface ports that the DUs should have for an Open RAN application, according to
Supermicro.

Table 2:
External Port List

Figure 6: While former Open RAN implementations rely on fronthaul switches for connection of RUs
to the DU, Time-Sync NIC cards allow direct connection for improved reliability.

Key features supported by Silicom Time Sync (STS) NICs include:

· T-TC Transparent Clock /G.8273.3
4. RRU design details
· T-BC/T-TSC Boundary Clock and TSC Slave Clock /G.8273.2
· T-GM Grand Master /G.8273.1 per G.8275.1 PTP Profile 4.1. Remote Radio Unit Reference Architecture
· PRTC Primary Reference Time Clock Class B/G.8272 An Open RAN Remote Radio Unit (RRU) is used to convert radio signals sent to and from the
antenna into a digital baseband signal, which can be connected to the DU over the O-RAN split
· OC Own Clock (Master / Slave) – Class C (Stratum 3e)
7-2x fronthaul interface.
· 1588/PTP over IPv4 / IPV6, IEEE1588v2 For illustration, the reference architecture of an Open RAN RRU from Gigatera
· SyncE /G.8262 Communications is shown in Figure 7. It shows the functional high-level diagram of the RRU
containing the following components:
· BMCA - Best Master Clock Algorithm (OCXO, SyncE, GNSS, 1588)
· Support for ≥4 Hours Hold Over TIE @1.5uSeconds · Synchronization and Fronthaul Transport Functional Block
· Lower PHY Layer Baseband Processing Functional Block
3.5. Memory Channel Interfaces
As in any other server based on Intel Architecture, memory components are a standard element · Digital Front End (DFE) Functional Block
that must be incorporated and properly dimensioned. An example of system memory capacity, · RF Front End (RFFE) Functional Block
type and related information that Supermicro recommends for an Open RAN application is
described in the following table.

Table 1:
Memory Channel
Feature List

Figure 7: Reference architecture of an Open RAN RRU.

14 15
Open RAN White Paper Open RAN White Paper

In what follows we describe the above main components of an Open RAN RRU. All the components power signals in FDD.
in Figure 7 can be implemented in one or several FPGAs with the exception of the PA, LNA and Filter
elements, as explained below. 4.1.4. RF Front End (RFFE)
The RF Front End comprises Power Amplifiers (PA), Low Noise Amplifiers (LNA), Digital to
4.1.1. Synchronization and Fronthaul Transport Function Block Analog Converters (DAC), and Analog to Digital Converters (ADC). Some of the latest RFSoC (RF
The PTP synchronization module is aimed to extract the main timing signal from the eCPRI System on Chip) devices, like Zynq RFSoC, integrate direct RF sampling Data Converters based
fronthaul interface. PTP provides accurate time and phase references to the RRUs for the on CMOS technology with improved power consumption [5].
transmissions of all sectors to be synchronized with each other. SyncE also provides additional The integrated RF DACs and RF ADCs perform direct RF sampling of the carrier signal instead
frequency stability, and acts as a backup source of synchronization in case PTP fails. Both PTP and of Intermediate Frequency (IF) sampling, thus avoiding analog up/down Converters. As a result,
SyncE are generally required and must be provided by the DU through the fronthaul link. RRUs can have reduced sizes thus enabling dual/triple band Radios in single mechanical enclosure.
The fronthaul connectivity between RRU and DU is usually realized by means of an optical Active Antenna Units (AAU) also integrate suitable antenna arrays and bandpass filters in the
Ethernet interface with the aid of suitable Small-Form Factor Pluggable (SFP) modules. RRUs are same enclosure.
usually equipped with two fronthaul ports to support daisy chain configurations where several radio
units can be cascaded to minimize the number of fronthaul links towards the DU. The presence of 4.2. FPGA selection criteria for the RRU
two fronthaul ports also enables network sharing scenarios, where the same RRU is shared by two Field Programmable Gate Arrays (FPGAs) from Xilinx in the RRU not only perform digital processing
different DUs and each DU performs the baseband functions corresponding to a different operator. tasks but can also integrate some of the analog subsystems. Xilinx has integrated mixed analog-
The Fronthaul Transport Function block involves specific processing of data packets to ensure digital subsystems (including DACs and ADCs) into its RFSoC device family. This is the case of the
interoperability in a multi-vendor environment. The use of an FPGA-based solution allows the Zynq® UltraScale+ RFSoC™ family from Xilinx used in the RRUs.
addition of features as O-RAN specifications evolve over time. The need for wider bandwidths in the radio unit (RU) is not just about increasing data rates
and performance, but also to support more complex and diverse radio configurations as needed
4.1.2. Lower PHY Baseband Processing for existing and new bands. The sheer number of global bands would be unmanageable if each
The lower PHY layer processing includes blocks for performing Fast Fourier Transform (FFT)/ required a unique radio. Radios are designed to support the widest possible bandwidth and
Inverse Fast Fourier Transform (iFFT), Cyclic Prefix addition and removal, Physical Random Access seemingly random carrier configurations to meet these requirements. Early 5G radios supported
Channel (PRACH) filtering, and digital beamforming. bandwidths up to 200MHz, but future bandwidths up to 400MHz are being requested. These radios
Beamforming is only required in Active Antenna Units (AAUs), where antennas are integrated support multiple bands and hence are called multi-band. In some cases, vendors use multiple
as part of the RRU (as in massive MIMO). Power Amplifiers (PAs) to cover multiple bands; in other cases, advanced wideband Gallium Nitride
(GaN) PAs are used, requiring state of the art wide-band DPD. Zynq UltraScale+ RFSoC family is
4.1.3. Digital Front End (DFE) designed for this purpose.
The digital front end comprises specialized blocks for the transmit (TX) and receive (RX) paths. RFSoC devices integrate, in addition to an FPGA for digital processing, a fully hardened digital
The TX path contains a spectrum shaping filter and a Digital Upconverter (DUC) towards the front-end (DFE) subsystem with all required processing blocks, and direct RF sampling ADC and
desired carrier frequency. In addition, it contains two fundamental blocks: Digital Pre-Distortion ADC converters thus eliminating power-hungry JESD204 interface. A hardened DFE is equivalent
(DPD), and Crest Factor Reduction (CFR) which are provided by Xilinx and integrated by Gigatera. to having an ASIC-based DFE embedded in the RFSoC with an optimized mix of programmability
CFR reduces the Peak-to-Average Ratio (PAR) of the 4G/5G signals by clipping those peaks that and ASIC functions. The benefit is a significant reduction in total power, board area, and complexity
create highest distortion. DPD compensates the Power Amplifier (PA) distortion in RFFE to improve of the radio solution. This is most apparent in 64T64R massive MIMO AAUs.
the RF linearity. Both CFR and DPD improve the energy efficiency of the RRU. Minimization of State-of-the-art Xilinx Zynq RFSoC DFE devices will support up to 7.125 GHz of analog RF
the PA power consumption is a source of continuous improvement and innovation because PAs bandwidth in 2021.
represent a large fraction of the overall power consumption in the RAN. An adaptable FPGA-based
solution enables customization for a range of PA output power requirements and technologies. 4.3. O-RAN Fronthaul interface
When digital beamforming is implemented, a beamforming calibration function in either time The O-RAN Alliance has defined a multi-vendor fronthaul interface between DU and RRU based
domain or frequency domain is also implemented. on Split 7-2x. In O-RAN terminology, RRU is denoted as O-RU and DU is denoted as O-DU.
The RX path contains a Digital Downconverter (DDC), a Low-Noise Amplifier (LNA) and an The fronthaul specifications include Control, User and Synchronization (CUS) & Management
optional PIMC (Passive Inter-Modulation Canceller). PIMC aims to compensate the interference (M) plane protocols, as indicated in Figure 8, whose elements can be summarized here:
appearing on the RX path that is generated by passive intermodulation distortion caused by high- · Control Plane (C-Plane) data between the O-DU and O-RU, such as data section information,
scheduling information, beamforming information, etc.

16 17
Open RAN White Paper Open RAN White Paper

· User Plane (U-Plane) data based on frequency-domain IQ samples. Based on O-RAN split 7-2x, an RRU can be configured to operate in two different modes,
· Synchronization Plane (S-Plane) including timing and synchronization information. denoted as “Category A” and “Category B” depending on the functionality of both the RRU
and DU. Depending on these modes and on the configuration parameters allowed by O-RAN, a
· Management Plane (M-Plane) enabling initialization, configuration, and management of the split 7-2x can actually correspond to three different split points (namely split 7-1, 7-2 and 7-3)
O-RU through suitable management and control commands between O-DU and O-RU. depending on the configuration chosen.

4.3.2.1. O-RU “Category A”

In this case the precoding function is performed at the O-DU, thus allowing for simpler RRU
design. This is equivalent to a split 7-1 in O-RAN terminology [6].
Precoding converts so-called spatial layers into spatial streams, which can require higher
fronthaul throughput in massive MIMO systems. As a result, O-RUs Category A are typical for
non-massive MIMO implementations, where the difference between performing the precoding
function at the O-DU or at the O-RU is minimal. However, O-RUs Category B are better suited for
massive MIMO AAUs.
Figure 10 shows the Downlink signal processing for O-RUs Category A.

Figure 8: O-RAN Fronthaul interface protocol structure

For a complete description of O-RAN protocol structure, refer to [1]-[4].

4.3.1. IOT Fronthaul profiles

Unambiguous separation of the C-Plane, U-Plane, S-Plane and M-Plane protocol and
functions enables stepwise integration of the fronthaul interface between O-DU and O-RU in a
multivendor environment.
Additionally, O-RAN Alliance facilitates such multi-vendor integration by defining suitable inter-
operability (IOT) profiles, test configurations and test cases in a non-intrusive manner, so that the
3GPP-related radio conformance testing remains independent from the O-RAN fronthaul testing.
The IOT profiles describe the typical set of parameters, transport characteristics, synchronization
topologies, and security considerations required for a complete conformance testing.

4.3.2. Implementation of O-RAN Fronthaul in an O-RU

Figure 9 illustrates the basic block diagram of the processing blocks devoted to the fronthaul
interface at the O-RU. All the functions take place in the FPGA including synchronization (hardware
Figure 10: O-RU “Category A”. Blocks above the O-RAN FH line are executed at the
timestamping, SyncE and PTP) and application-layer framing/de-framing. O-DU, whereas those below it are executed at the O-RU.

Figure 9:
Functional
basic block
diagram
of fronthaul
interface in
O-RU.

18 19
Open RAN White Paper Open RAN White Paper

4.3.2.2. O-RU “Category B” 4.4. Radio units for 4G/5G low and mid bands (up to 3.5 GHz)
In this case the precoding function is performed at the O-RU, hence making the radio more Table 3 and Table 4 contain as a reference the radio configurations required for proper 4G/5G
complex but also reducing fronthaul bitrate in massive MIMO implementations. Open RAN deployments in the most typical scenarios of Telefonica footprint.
This category allows so-called “Modulation Compression”, which can be performed in the
downlink to effectively send only the bits equivalent to the constellation points of the complex
IQ signals, hence reducing the downlink fronthaul throughput effectively. This is equivalent to a
split 7-3 in O-RAN terminology [6].
Figure 11 shows the Downlink signal processing for O-RUs Category B.

Table 3: Radio units for 4G/5G low bands (below 3 GHz)

Figure 11: O-RU “Category B”. Blocks above the O-RAN FH line are executed at the
O-DU, whereas those below it are executed at the O-RU.

Table 4: Radio Units for 5G mid band (3.5 GHz)

20 21
Open RAN White Paper Open RAN White Paper

5. Cloud Architecture
5.1. Open RAN virtualized solution
The Open RAN solution follows a fully cloudified network design. The CU and DU, as well as
the Element Management System (EMS) managing the RAN network elements, benefit from
a software-defined architecture. Suitable virtual instances of the vCU, vDU and vEMS can
be deployed over a scalable cloud-based platform managed by a Service Management and
Orchestration Framework. This is graphically shown in Figure 12 as implemented by Altiostar.

Figure 13: Schematic illustration of the main interfaces and network elements in a 5G Open vRAN architecture.

The Telco Cloud Open RAN concept can be taken one step further by implementing a container-
based cloud-native micro-service architecture. This new architecture enables advanced cloud-
based networks supporting new applications and services with advanced automation, newer
algorithms and improved Quality of Experience (QoE), while ensuring network slicing and full
support of Control/User-Plane Separation (CUPS). This is the means to achieve the true promise
of a service-based architecture for 5G.
Altiostar’s container-based 5G solution further disaggregates CUs and DUs into micro-
services comprising transport, management, monitoring, control plane and user plane functions.
Depending on the type of network slice and application being deployed, containerized network
functions can be rapidly deployed at various locations in a very light footprint and then scaled
up based on traffic.
Figure 12: Illustration of a Telco Cloud Open RAN architecture.

5.2. vCU and vEMS

The two main virtualized elements of the Telco Cloud architecture in Open RAN technology are
the vCU and the vEMS.
The vCU performs the CU functions of PDCP and RRC sublayers on an Intel Xeon server platform.
The service management framework also allows the introduction of the RAN Intelligent Contrary to the vDU, vCU involves only higher-layer functions and can therefore fully rely on
Controller (RIC), whose near-Real Time (Near-RT RIC) and Non-Real Time (Non-RT RIC) standard COTS hardware without Time Sync NICs as long as the PTP Primary Reference Timing
components are being defined in the O-RAN alliance with the goal of optimizing RAN behavior Clock (PRTC) sits between the DU and the CU.
and interfacing with third-party applications. The role of the vEMS is to gather information with the right granularity from the different
The ability to run RAN functions as virtual instances for 4G and 5G brings the flexibility software modules to control and operate them in an automated way as commanded by the OSS.
to deploy the vDU, vCU and vEMS workloads in different possible locations depending on As an example, Altiostar’s vEMS is a Virtual Network Function (VNF) working on Intel
implementation needs, as shown in Figure 13. The fronthaul interface follows the O-RAN split Architecture-based COTS servers, running kernel-based virtual machine (KVM) and managed by
7-2x, whereas the midhaul interface between the DU and the CU (called F1 for 5G, and W1 for 4G) OpenStack Virtual Infrastructure Management (VIM) software. It includes a set of applications for
is based on 3GPP specifications. The vCU functions are further split into UP (User Plane) and CP delivering Element Management System solutions like FCAPS (Fault, Configuration, Accounting,
(Control Plane), according to 3GPP/O-RAN. Performance and Security), 3GPP IRP (Integration Reference Point) for OSS integration, and

22 23
Open RAN White Paper Open RAN White Paper

scripting support. The Altiostar vEMS can also be flexibly deployed as a set of containerized Figure 15 illustrates another example where time and phase references are provided by the
network functions to meet evolving 5G deployment scenarios. network in a 2G/3G/4G/5G site. In this case there is no GNSS receiver and the CSR must propagate
Integration of the vEMS into the Service Management and Orchestration Framework paves the PTP and SyncE towards the DUs. A legacy 2G/3G BBU is also shown that must be interconnected
way to the extensive use of Artificial Intelligence (AI) and Machine Learning (ML) techniques with the other DUs through the CSR.
in multiple domains, such as RAN performance enhancement, radio resource management, Network-based synchronization is deemed as the best and most future-proof option because
or advanced traffic/service optimization, to name a few. AI/ML can benefit from the use of it avoids potential points of failure, like the GNSS receiver or the daisy-chain connection of DUs
automation in cloud-based software architectures, thus reducing operational complexity in to propagate synchronization. However, it requires full network support of PTP and can therefore
multi-vendor Open RAN scenarios. be applicable only in a limited set of scenarios.

6. Site Integration aspects

An Open RAN site may comprise not only a certain number of RRUs and DUs, but also potentially
a Cell Site Router (CSR), a GNSS antenna and receiver, and a legacy 2G/3G baseband unit (BBU).
Proper interconnection of all these elements is essential to ensure seamless site integration of
Open RAN technology in all the site types described in Figure 1.
Figure 14 illustrates a typical arrangement of DUs and RRUs that correspond to the site types Figure 15: Example of the
in Figure 1, for the case where synchronization is provided by a GNSS receiver. As can be seen, a interconnection of two Open
4G/5G site can contain up to three Open RAN DUs in the most complex case. The first DU server RAN DUs and a 2G/3G BBU
in a 2G/3G/4G/5G site
gets proper time (Time of Day, ToD) and phase (PPS) synchronization from a GNSS receiver, while where the time and phase
acting as a Grandmaster clock (T-GM) to the other DUs at the site by means of a daisy-chain references are provided by
configuration. All DUs must be interconnected with each other and to the CSR, but RRUs and the network.

AAUs can be directly connected to the DUs thanks to the use of Time Sync NICs.

7. Summary and Conclusions

The goal of this paper was to illustrate, in a technical way, how the main Open RAN network
elements can be designed and dimensioned to meet the needs of operators which, like Telefónica,
demand a wide portfolio of radio units, site capacities and synchronization options.
Emphasis was put in the case where the DU is physically located at the site, but all the
considerations remain equally valid when the DU is centralized, except for possibly different
mechanical requirements for the DU chassis as needed in a data center.
The actual portfolio of radio units and frequency bands can of course differ from network to
network, but the fundamental considerations in 4G and 5G design described here will remain
equally applicable. Site integration aspects are also key to secure seamless coexistence with
whatever legacy 2G/3G network equipment is located at the site.
The technology components described in this paper will take Open RAN out of the lab and into
a real 4G/5G network. The key steps towards making this transition are already happening in the
form of pilots and field activities, whose goal is to test whether performance is on par with the
traditional RAN. Such assessment cannot happen without the combined efforts of both Operators
and technology partners.
Figure 14: Interconnection of Open RAN DUs for the main four 4G/5G site types,
where time and phase references are provided by a GNSS receiver.

24 25
Open RAN White Paper Open RAN White Paper

8. References 9. Glossary

[1] ORAN-WG4.CUS.0-v02 “Control, User and Synchronization Plane Specification”, AAU: Active Antenna Units KPIs: Key Performance Indicators
O-RAN Alliance, Working Group 4.
ADC: Analog to Digital Converters KVM: Kernel-based Virtual Machine

[2] ORAN-WG4.MP.0-v02 “Management Plane Specification”, O-RAN Allicance, Working AI: Artificial Intelligence LNA: Low-Noise Amplifier
Group 4. APIs: Application Programming Interfaces Massive MIMO: Massive Multiple-Input

[3] O-RAN-WG4.IOT.0-v02.00 ASICs: Application-Specific Integrated Circuits Multiple-Output

CFR: Crest Factor Reduction MEC: Multi-access Edge Computing
[4] O-RAN-WG4-MP-YANGs-v02.00
CPU: Central Processing Unit ML: Machine Learning
[5] Xilinx WP489 “An Adaptable Direct RF-Sampling Solution”, Feb 20, 2019, available for CSR: Cell Site Router NB-IoT: Narrowband-IoT
download at: https://www.xilinx.com/support/documentation/white_papers/wp489-
CU: Centralized unit NICs: Network Interface Cards
rfsampling-solutions.pdf
CUPS: Control/User-Plane Separation PA: Power Amplifier
[6] NGMN White Paper “5G RAN CU – DU Network Architecture, Transport Options and
DAC: Digital to Analog Converters PAR: Peak-to-Average Ratio
Dimensioning”, V1.0, available for download at: https://www.ngmn.org/wp-content/
uploads/Publications/2019/190412_NGMN_RANFSX_D2a_v1.0.pdf DDC: Digital Downconverter PIMC: Passive Inter-Modulation Canceller
DFE: Digital Front End PRACH: Physical Random Access Channel
DPD: Digital Pre-Distortion QoE: Quality of Experience
DUC: Digital Upconverter RAN: Radio Access Network
DSS: Dynamic Spectrum Sharing RAM: Random-Access Memory
DU: Distributed Unit RFFE: RF Front End
EMS: Element Management System RFSoC: RF System on Chip
FCAPS: Fault, Configuration, Accounting, RIC: RAN Intelligent Controller
Performance and Security RRU: Remote Radio Unit
FEC: Forward Error Correction RX: Receive
FFT: Fast Fourier Transform STS: Silicom Time Sync
FMA: Fused Multiply Add SyncE: Synchronous Ethernet
FPGA: Field Programmable Gate Arrays TDD: Time-Division Duplex
gNB: Next generation Node B TIP: Telecom Infra Project
GNSS: Global Navigation Satellite Systems TX: Transmit
iFFT: Inverse Fast Fourier Transform VIM: Virtual Infrastructure Management
I/O: Input/Output

26 27