Differentiating

between V-RAN, Open

RAN and Cloud RAN

D-RAN, C-RAN, E-RAN, V-RAN, O-RAN, Open RAN, and Cloud RAN. These are all
terms that we are hearing on a regular basis. Unfortunately, from time to time,
these terms are used incorrectly. This e-Learning course is designed to explain the
meaning of each term, and the evolution of virtualization towards Cloud RAN
within Ericsson.

1
 Ericsson RAN architectures

Distributed RAN Centralized RAN Elastic RAN Virtualized RAN

& Cloud RAN

Colocation of resources for

Simple flat architecture maximum interworking Adaptable interworking Enables split architecture
relaxed interconnect and and performance in across the network for for full flexibility
simple deployment hotspots D-RAN and C-RAN

Let’s begin with Ericsson’s initial RAN architecture concepts. Depending on the operator’s
needs, the technology evolution, 3GPP mandate, and the business aspect, Ericsson offers
different types of RAN architectures.

Distributed RAN, or D-RAN, is a flat RAN architecture where all processing for each RAN
node is done locally at the antenna site, at the very edge of the network. This is by far, the
most popular deployment option of Ericsson Radio System.

Centralized RAN, or C-RAN, centralizes the baseband functionality further away from the
antenna sites and can feed multiple antenna sites from a C-RAN hub, or “baseband
hotel”. Centralized processing with C-RAN simplifies network management, enables
resource pooling and improves coordination of radio resources.

Elastic RAN, or E-RAN, enables full coordination across the entire network, agnostic on
baseband deployments – centralized, distributed or a mix of both. There are no limits to
the coordination area, it is fully dynamic (elastic) throughout the network. Elastic RAN
requires a high quality and high speed ethernet network to interconnect basebands but it
is packet switched, more flexible and less demanding than the CPRI radio interconnects of
a C-RAN configuration.

Virtualized RAN, or V-RAN, decouples the software from the hardware by virtualizing
Network Functions. It also leverages an architecture split which separates the upper parts
of the radio protocol stack from the lower. This enables the use of commercial server
hardware as well as cloud and virtualization techniques. Furthermore, it enables RAN,
Core and application functionality to be co-located and co-hosted on the same execution
platform. V-RAN has gone through several iterations in Ericsson. From V-RAN 1.0 to V-
RAN 2.0 to what we now call Cloud RAN. This course intends to explain that evolution
and the advances made to Ericsson RAN architecture options.

2
 Layers involved in RAN processing

To delve further into these various architectures, it is important to understand a few

things.

First, when we talk about processing within the RAN architecture, terms like Layer1,
Layer2, and Layer3 are often mentioned. These layers align with the OSI model which
divides the processing into layers to make it more efficient and systematic.

Layer 1 is the Physical layer which handles the baseband functions such as channel
coding, beamforming, and so on. This layer is further divided into sublayers as in the
‘Ericsson Lower Layer Split’, which we will learn about later on.

Layer 2 consists of two sublayers, Lower Layer2 which handles the RLC and MAC
functions and Higher Layer2 handling the PDCP function in addition to SDAP.

Finally, Layer 3 handles the Radio Resource Control and IP functions used for routing
packets across interconnected networks.

3
 Layers in RAN Domain

Example - Baseband 6648

Multiple layers - Baseband Function L3 Radio Control Function

DU (Digital Unit) (RRC)

RAN Compute L2 Layer 2 Baseband Processing

(RLC, MAC, PDCP, SDAP)
OFDM : Orthogonal Frequency Division Multiplexing L1, BF Layer 1 and Beamforming Processing
PDCP : Packet Data Convergence Protocol (modulation, precoding, OFDM)
RLC : Radio Link Control
MAC : Medium Access Control L1 Layer 1 Baseband Processing
RRC : Radio Resource Control (Physical layer, channel coding)
SDAP :: Service Data Adaptation Protocol

For our purpose-built networks, the Baseband is Ericsson’s RAN Compute hardware
which performs the majority of the processing functions. It interconnects the core and
the radio site via the transport network.

Its smart hardware uses the EMCA (Ericsson Multi Core Architecture) card which is a
combination of DSPs (Digital Signal Processor) processing the actual data.

The Baseband or RAN Compute follows a flexible architecture and topology to support
all 5G requirements like ultra low latency and ultra high throughput. It also enables the
split functions, including the separation of the user plane’s PPF (Packet Processing
Function) and the control plane’s RCF (Radio Control Function) in the higher layers.

Why am I talking about the baseband? Well, it’s important to understand its functions in
order to understand how Ericsson networks are evolving.

4
 CPRI vs. eCPRI

Before we go any further, I think it is also important to explain the difference between CPRI
and eCPRI.

CPRI
• CPRI, or Common Public Radio Interface, is the key interface between the radio unit and
the baseband unit. It was the interface of choice for fronthaul communications between
towers and base stations through several generations of wireless networks, including
GSM, WCDMA, and LTE.
• CPRI is TDM based and vendors implemented their own protocols over CPRI, making
“multivendor interoperability” almost impossible.

eCPRI
• With the introduction of new 5G applications, flexible fronthaul communications became
necessary.
• The enhanced CPRI (eCPRI) interface is a Packet-based (IP or Eth) interface, introduced
in 2017 for 5G NR.
• eCPRI can balance important components of latency, throughput, and reliability
requirements for advanced 5G applications, thus enabling increased efficiency.
• Furthermore, eCPRI is an open interface, allowing carriers to work together in a more
complementary way.

Generally speaking, CPRI is commonly used for traditional systems, while eCPRI is more
suitable for 5G wireless communication technology.
Next, let’s delve a little deeper into each RAN architecture and an explanation of split
architecture.

5
 Distributed RAN

This is a picture of how mobile towers used to look in the 2G and 3G days. The
radio and baseband units used to be in one or more cabinets at the bottom of a
mast or a tower. RF cables would then run to the antennas on top of the mast.
While this was a simple approach, the RF signal attenuation in the RF cable was a
big problem.

As a result during the later phases of 3G and during 4G roll out, the industry
moved to a new approach that worked better.
Instead of sending RF signals from the cabinet to the antennas, the RF equipment
is moved close to the antennas. Whether the radio is a separate unit on the mast
or embedded with the antenna in one unit, the result is that RF signal loss is kept
to a minimum, as the radios and antennas are connected to the Baseband in the
enclosure site at the bottom, via CPRI cable. The baseband unit is then connected
directly to the core via an S1/NG interface.
All of these geographically-distant baseband sites are connected to each other via
X2/Xn interface for coordination.

I’d like to draw your attention to one final detail: for the Purpose-built Distributed
RAN, all signal processing and network access functionalities (that is, layers 1, 2
and 3) are located in the baseband unit and belong to the same vendor and
operator.
Distributed RAN is still the most common deployment option, with over 90% of
existing sites are deployed with a D-RAN architecture.

6
 Centralized RAN

Centralized RAN (C-RAN) is an alternative to de-centralized or Distributed RAN,

(DRAN). Here, the radio nodes are still co-located with the antenna, but the basebands
may be located further away in a centralized Baseband hotel. Again, note that all
signal processing and network access functionalities (that is, layers 1, 2 and 3) reside
in the baseband unit.

In this situation, each baseband unit is still part of a Distributed RAN. The basebands
are connected to each other via an X2/Xn interface and since they are at the same
rack or at the same site, the X2/Xn interface performance is better than the standard
Distributed RAN.
Moving processing to a central office reduces the antenna site footprint, power and
battery backup requirements. It also simplifies network management, enables
resource pooling and improves coordination of radio resources.

In DRAN, the transport segment from the antenna site to the core network is referred
to as the backhaul. In CRAN, the interface between the antenna site and the
centralized data center is referred to as the fronthaul. Generally speaking, fronthaul
has shorter latency and wider bandwidth requirements when compared to backhaul.
Today, the fronthaul transport solution is usually based on dark fiber – a point-to-
point connection between the antenna site and the CRAN hub.

The decision for service providers then becomes choosing between expanding
backhaul capacity and maintaining their Distributed RAN architecture or migrating to
CRAN architecture with investments in fronthaul.

7
 Elastic RAN

So, let’s recap: we have Distributed RAN, where the baseband is on site.
We have Centralized RAN, where the basebands are located further away from
the antenna site in a centralized baseband hotel.
Next, let’s discuss Elastic RAN.
Elastic RAN (E-RAN) enables coordination to be fully dynamic throughout the
network. The term Elastic can be thought of as the possibility to use E-RAN both
between basebands that are located next to each other, as in a C-RAN case, or
between basebands at different radio sites, as in a D-RAN case, or a mixture of
both.
Ericsson uses an E5 interface to interconnect the basebands in Elastic RAN.

To summarize, we have just described the three architectures supported by

purpose-built networks. For purpose-built networks, in all three scenarios, the
Radio Unit, Baseband unit, and the interfaces between the Baseband and Radio,
and between basebands at different sites, contain vendor-specific hardware and
software.
Distributed RAN, Centralized RAN, and Elastic RAN will also work for virtualized
Radio Access Network. Let’s explore virtualized RAN next.

8
 Virtualization

Virtualization involves the migration from purpose-built network nodes to network

functionality implemented in software running on a generic hardware compute
platform. By definition, virtualized RAN involves disaggregation of software and
hardware. There is an expectation that an operator will be able to run the same 5G
software stack on a variety of servers and evolve capacity by swapping out the
hardware, as we do with our PCs.

As shown in this image, the purpose-built, vendor specific, baseband unit, or RAN
Compute unit, can be broken into two components: the Central Unit and the
Distributed Unit. The Central Unit—with less stringent processing requirements—
has been more amenable to virtualization than the Distributed Unit and its
functions that are closer to the radio. However, the intention of virtualization is
that both the Central and Distributed units can run their software over common off
the shelf hardware.

9
 Virtualized RAN architectures

As mentioned previously, Distributed RAN, Centralized RAN, and Elastic RAN will
also work for virtualized Radio Access Networks. In these cases, the baseband
unit is replaced with the Distributed and Central units. For a D-RAN deployment,
the DU and CU would be located at the antenna site. For a C-RAN deployment the
DU and CU would be centrally located in a C-RAN hub with fronthaul to the
antenna site. And E-RAN could still be used for coordination between sites.

A fourth architecture type that also works well with virtualized RAN is split
architecture. In this case, the CU and DU are at different physical locations, similar
to a Centralized RAN architecture. We’ll explore split architecture in more detail
over the next few slides.

10
Ericsson’s initial concept for V-RAN 1.0 took the functions of the baseband unit
and split them based on their protocol layers.
On the RAN side, some Layer 1 radio processing functionality was moved directly
into the newer generation of antennas. These Advanced Antenna Systems can
perform functions such as beamforming.
With VRAN 1.0 the baseband could be replaced with a different RAN Compute
unit known as the Radio Processor (RP). This hardware unit, which looks very
similar to a baseband unit, handled the Layer 1 and lower Layer 2 radio processing
functionality.
And the remaining baseband functionality was moved up in the network, towards
to core. Here, physical hardware was replaced by virtualized network functions
(VNFs) running on virtual machines in a cloud environment. One VNF was called
virtual Packet Processor (vPP) which was responsible for higher Layer 2
functionality such as processing data packages in the user plane. Another VNF
was the virtual Radio Controller (vRC), which was responsible for radio control and
mobility management.
This PDCP split architecture used an interface called C5, which is an IP fronthaul
between the Radio Processor and the virtualized RAN.
Splitting the baseband processing into three separate functions is called split
architecture and with the introduction of virtual machines, we separated Layer 2
and Layer 3 functionality from purpose-built HW, hence forming our first
Virtualized RAN.

11
So why is Virtualized RAN such a big deal?

There are many benefits to virtualizing the network:

• A fully virtualized RAN (V-RAN) could bring significant benefits of harmonization: one
single uniform hardware platform across the core network, RAN and edge could simplify the
management of the complete network, reducing operations and maintenance costs. As
well, use of virtual machines replaces proprietary and expensive hardware.
• Virtualization provides the ability to spin workloads up and down with minimal effort, and it
allows resources to be scaled elastically to address changing network demands.
• With virtualization, network functions can be flexibly deployed: In the context of 5G, this is
very important to support higher cell and device density and a wide variety of use cases not
limited to physical network functions.
• And finally, disaggregating the RAN architecture can introduce the possibility for open
interfaces and an ecosystem in which many vendors and solution providers can innovate.

So with all these wonderful advantages, what happened to V-RAN 1.0?

Many advances have been made in the cloud ecosystem, including such innovations as
machine learning, artificial intelligence and standardized open interfaces that did not exist
when we conceptualized V-RAN 1.0.

However, now, many things are maturing at the same time, giving virtualized networks a more
realistic time plan and a chance to be commercially deployed. Some of these are standards-
based, such as the definitions of centralized units and distributed units in 3GPP, and the
packet-based fronthaul in eCPRI. But we are also seeing that the cloud infrastructure itself is
maturing; starting out with NFVI and moving forward into bare metal deployment. We also
feel that the COTS hardware ecosystem can now provide potential solutions to fulfill the full
5G requirements with high bandwidths and more sophisticated antennas. These did not exist
5 years ago! And finally, operators themselves have more experience along with Ericsson in
running these virtualized networks. All in all, we feel that timing is finally right for cloud-based
network deployments to complement our existing Ericsson Radio System portfolio.

12
So going back to our V-RAN explanation. This was what we had for V-RAN 1.0
before it was defined in the 3GPP standards of Release 15.

A separation of the upper and lower parts of the RAN was standardized in 3GPP
R15, where a higher-layer split was specified with a well-defined interface (F1)
between two logical units: the Distributed Unit (DU) and the Central Unit (CU). The
digital unit hardware, such as the baseband unit, and the radio hardware, which
contains the radio and antenna are defined together as a Distributed Unit.
The Central Unit houses the control plane, which handles the virtual radio control,
and the User Plane handles the virtual packet processing. For full-stack RAN
virtualization, the DU is connected to the radio via a packet interface known as
eCPRI. There are multiple ways to divide functions between the DU and the radio;
in standards discussions these are referred to as lower-layer split (LLS) options.
One possible alternative specified by the O-RAN Alliance is referred to as the 7-2x
split, but other functional splits are also being considered.

So, to summarize, by 3GPP Release 15, a standard definition of virtualized RAN

was finally taking shape. The next step for Ericsson was to evolve V-RAN 1.0 with
purpose-built hardware into the new V-RAN 2.0 with disaggregated hardware and
software. For many in the telecom industry this evolution is called Open RAN. For
Ericsson, this evolution in virtualized RAN has become our new solution Cloud
RAN.

Let’s take a moment now to get a clear definition of Open RAN, Virtualized RAN
and Cloud RAN.

13
 Open RAN vs Cloud RAN vs V-RAN
Open RAN
An industry term for open radio access OpenRAN
network architecture. A RAN with Refers to initiatives driven by
separation between HW & SW with open O-RAN Telecom Infra Project (TIP)
interfaces and virtualization allowing Refers to the O-RAN Alliance, an OpenRAN Project Group
multiple vendor products to work industry initiative for additional
together in one network. disaggregation and openness in RAN.
Its main objective is to create global
Open RAN is Virtualized RAN standard specifications.

Cloud RAN is considered part of the broader Open RAN

and a technology evolution within virtualization & cloud V-RAN,
Virtualized RAN decouples the software from
Cloud RAN the hardware by virtualizing Network
A cloud-native software solution where RAN applications are Functions. It uses virtualization technologies
run as cloud native container-based network functions on COTS such as NFV or containers to deploy the CU
hardware and orchestrated using a cloud infrastructure. and DU over COTS hardware.

V-RAN is not necessarily Open RAN

Virtualized RAN, or V-RAN, decouples the software from the hardware by virtualizing Network
Functions. It uses virtualization technologies such as NFV or containers to deploy the Centralized
Unit (CU) and Distributed Unit (DU) over common off the shelf x86 servers.

Open RAN takes vRAN to the next level. Open RAN is an industry term for open radio access
network architecture. It describes a RAN with separation, or disaggregation, between hardware
and software with standardized and interoperable open interfaces between systems in the Radio
Access Network. This implies that a customer can mix and match the components from different
vendors without being locked to one vendor for all these three components, thus resulting in an
open RAN network. The question becomes, how to you standardize this so that all vendors agree
to build interoperable solutions? That brings us to the next term: O-RAN.

O-RAN is short for the O-RAN Alliance ([Link] which is an industry initiative
for additional disaggregation and openness in RAN. Its main objective is to create global
standard specifications for Open RAN. It can be considered a complement to 3GPP.

OpenRAN: is an initiative of the Telecom Infra Project that aims at disintegration in the
2G/3G/4G/5G RAN by having multi-vendor interoperable solutions built on general-purpose
hardware (COTS). It differentiates from O-RAN Alliance because it mainly focuses on lab
activities and early trials, not on creating a global ecosystem based on open standards.

Cloud RAN is the latest evolution in virtualized RAN. It is a cloud-native software solution where
RAN applications are run as cloud native container-based network functions on commercial off
the shelf hardware and orchestrated using a cloud infrastructure. Cloud RAN is a technology
evolution within virtualization and cloud technology.

So to summarize: Open RAN is a concept for virtualized RAN. V-RAN is not necessarily Open
RAN since the CU and DU could still be purpose-built. And Cloud RAN is considered to be part of
the broader concept of Open RAN, and an evolution of V-RAN. However, how each vendor
implements Cloud RAN may or may not comply with O-RAN Alliance standards.

14
 Example Scenario: Purpose-built deployment model

To explain the concept of Open RAN, let’s look at an example scenario. Here is a
simplified view of a typical network with purpose-built hardware, RAN software
and platforms, Transport Network, core and services.
In practice, most operators “vendor-balance” by assigning parts of the RAN
network, either:
• By splitting out different geographical areas (more common)
• Or by deploying different RAT or frequency bands with different vendors (less
common)
X2 interfaces allow sites deployed by different vendors to communicate on
handovers, etc.

The RAN and Core domains are quite independent through the S1/NG interface,
so RAN and Core from the same vendor is not a requirement.

So you can see, with 3GPP open interfaces, multiple vendors can work together in
one network, but not at the same level of disaggregation as in Open RAN.

15
 Example Scenario: Open RAN deployment model
Existing ODM/OEM
Example scenario
SP/MNO
New could
ODM/OEM replace
Vendor
where A hardware
Vendor V1 as
is

Service

Service
Service

Service

Service

Service

Service
Service

Service

Service

Service

Service

Service
Service
the RAN
Vendor Bsoftware
provides
could be swapped
supplying out
virtualized
easily
RAN as they did the
easilyhardware
softwarewhenand
that
required
hardware.
can work Existing
out of the
with a
ODM/OEM new hardware
Vendor A
RANwith
box hardware
Vendor 1
either from
is supplying
continues to the
work Core
software
ODM/OEM Vendor B
hardware
with the new software
or a newer
from Vendor V2. Transport Network
ODM/OEM Vendor C
Software from any V1
V2
software vendor
COTS Servers

Hardware from any

ODM/OEM/RAN A
C A
B A A
C B
A B
A A
C A A
B A
C
vendor

Here is the scenario that Open RAN would like to achieve:

Let's assume that the service provider has deployed software from vendor V1 that
runs on COTS servers. For the hardware, they are using Remote Radio Units from
an OEM/ODM Vendor A.

Now let's say they're upgrading some sites or deploying new sites and they
decided to use RRUs from another vendor, B. These should work with the software
from vendor V1 out of the box because of open interfaces.

Again the service provider has decided to introduce a new hardware vendor, C, as
they may either have more advanced features or are lighter or consume less power
or any other reason. Again these should work with vendor V1 software straight out
of the box.

Now, let’s say the service provider is unhappy with software from vendor V1
because the vendor road map was not aligned to their own or perhaps they do not
have advanced features or any other reason. What they can do here is replace
vendor V1 with vendor V2. Because of open interfaces, the hardware from vendors
A, B and C should work with software from vendor V2.

The challenge with this approach is that it requires extensive system integration
(hardware + software integration and node integration). As a result, the lower
hardware prices may ultimately be offset by the System Integration costs. Making
this scenario work is an intense and costly effort. And, to date, no swaps have been
done in Open RAN deployments so this premise hasn’t really been tested.

16
 Example Scenario: 5G Open RAN deployment model

This theoretical approach can be taken one step further with multiple vendors
being able to interoperate at the CU, DU and Radio level because of open specified
interfaces.

We do see examples where different RAN SW vendors work with the same Radio
HW vendor for instance, but the multivendor aspect is not yet proven.

I’ll explain in more detail in a few slides, but it cannot be overstated: Open RAN is
more than just open interfaces. It takes a lot of work on behalf of all the vendors
involved to integrate, maintain and ensure system performance in a multi vendor
network.

17
 Evolving from V-RAN to Open RAN
Open RAN from O-RAN Alliance

Open Fronthaul (O-LLS)

Whitelabel
Radio

Open RAN introduces additional interfaces, functional splits and disaggregation

So what needs to happen in order to turn a virtualized RAN solution into something that meets the
objectives of Open RAN? Lots of moving parts need to work together to achieve Open RAN, but
part of it is indeed open interfaces.

Looking closely, the interface from the core network towards the CU and between the CU and DU
are already standard and defined by 3GPP. They are already interoperable between the vendors on
both purpose-built and new COTS-based platforms. These include the E1, F1, NG, X2, Xn and the
Uu interface

The O-RAN Alliance introduces additional interfaces, functional splits and disaggregation:
• The A1 interface will better prepare the RAN to use Artificial Intelligence and Machine Learning
technologies.
• The entity known as Non Real Time RAN Intelligent Controller (Non-real time RIC) has the goal
of supporting intelligent RAN optimization in Non-real-time (that is greater than one second) by
providing policy-based guidance using data analytics and leveraging AI capabilities.
• Service Management and Orchestration (SMO) is also a new concept that is introduced by the
O-RAN Alliance. It includes Non-RT RIC capabilities for RAN optimization, basic management
support for network functions, as well as the O-cloud management via open interface A1, O1
and O2 defined by O-RAN community. At the time of recording this course, the details on these
interfaces are still in development.
• Open RAN also introduces the Near Real Time RAN Intelligent Controller (or Near Real Time
RIC) open architecture and the E2 interface between the Near Real Time RIC and the CU and
DU stack. The Near Real Time RIC is a logical entity that enables near-real-time control and
optimization of O-RAN nodes ( O-CU and O-DU). This is achieved by exchanging data between
so called xAPPs in the near-RT RIC and the actual RAN nodes over the E2 interface. It should be
noted that at the time of this recording, Ericsson is currently not planning to support the E2
interface in the RAN nodes nor to offer a near-RT RIC product.
• Connecting the DU and the Radio Unit is a new open fronthaul interface called the O-LLS (open
lower layer split). Ericsson believes that currently multivendor deployments using the O-LLS will
have several limitations. Ericsson promotes instead the Ericsson lower-layer split (E-LLS) that is
supported in both the purpose-built (ERS) RAN and the Cloud RAN.

18
 Open interfaces doesn’t equal multivendor

System integration Life-cycle management

Extensive integration project to verfiy an Software releases between vendors need to
open interface between vendors adds be coordinated, tested and verified to ensure
TTM & cost to the solution interoperability is not broken.

Assurance of
System performance
KPIs & security
Minimum common denominator dictates

4 Fundamental
Challenges
feature support by the vendors involved,
resulting in performance limitations
Challenging root cause analysis to identify
vendor at fault and who is responsible for
providing fixes

As I alluded to in the last few slides, just because it becomes increasingly possible
to mix and match vendors by leveraging open interfaces, it does not mean that the
vendors themselves are favorable to implementing these interfaces, or that
operators are overwhelmingly interested in selecting a diversity of vendors over an
integrated proprietary solution!

Implementing an Open RAN solution is so much more than just an open interface!
System integration testing between vendors needs to be performed, vendors need
to coordinate their software releases and verify that interoperability is maintained,
minimum network performance requirements need to be met, and above all,
customers still expect the same if not better, key performance indicators and
security measures to be maintained.

Regardless of how virtualization is achieved, as the hardware and software are

not necessarily aggregated by a network vendor, these systems will necessitate
new business models with clearly defined accountability. System integration,
whether managed by a RAN software supplier or a cloud infrastructure provider,
will be crucial to ensure network performance and reliability. Regardless which
party takes on this responsibility, the additional costs due to increased system
integration work cannot be overlooked.

19
 Open RAN & Ericsson Cloud RAN differences

So, while Ericsson is supportive of Open RAN and is a member of the O-RAN
Alliance, we believe that at the current time, there are both interoperability and
Intellectual Property Rights that represent challenges that must be resolved before
large scale R&D investments by vendors and large-scale deployments by operators
can be achieved.

This brings us to the next question: What is Ericsson’s solution for virtualized RAN?
The answer is Cloud RAN! Ericsson Cloud RAN will support valuable elements
from O-RAN, with a few adjustments to ensure high performance.

Cloud RAN will include Open RAN cloudification elements such as hardware and
software disaggregation, a fully cloud native RAN solution including Cloud RAN
Centralized Unit, Distributed Unit and gateway, and the implementation of X86
COTS HW.
Cloud RAN will also implement intelligence and automation features in its Service
management and orchestration framework such as Non-Real Time Radio
Intelligent Controller, and RAN optimization and AI/ML applications.

And finally, Cloud RAN will use open interfaces defined by 3GPP while introducing
its own Ericsson Lower Layer Split open fronthaul for high performance scenarios.

20
 2019-10-21

Open RAN
Architecture

To get a visual understanding of the differences between Open RAN and Cloud
RAN, let’s look at these two slides.

The main differences are:

1. Open RAN offers Open Fronthaul for multivendor radio management, where
Ericsson will have its own version called Ericsson Lower Layer Split.
2. Open RAN will have an E2 interface and Near Real Time RIC for multivendor
Radio Resource Management. Ericsson will not be implementing these
concepts at this time.

O-RAN Alliance is also working on hardware reference designs for baseband and
radio units that would allow operators to purchase “white box” server hardware
directly from third party manufacturers and bypass traditional telco vendors to
achieve lower prices. Ericsson’s Cloud RAN will also support third party server
hardware that meets the requirements of 5G RAN workloads. As mentioned in
earlier slides, the challenge with this approach is that it requires extensive system
integration so that the lower hardware prices may ultimately be offset by the
System Integration costs.

21
 2019-10-21

Ericsson Cloud RAN

So let’s breakdown the logical view of the Ericsson Cloud RAN Architecture. The
Ericsson Cloud RAN solution virtualizes real time functions as well as provides
disaggregation of HW and SW.

Ericsson’s Cloud RAN Distributed Unit runs on x86 COTS (commercial

off-the-shelf) hardware. It supports processing functionality of L1, RLC, MAC
layers. This is based on cloud native, microservice based architecture run on bare
metal and agnostic to the underlying Containers as a Service (CaaS) layer and x86
HW.

Ericsson’s Cloud RAN Centralized Unit also runs on x86 COTS hardware. The
Cloud RAN CU holds the responsibility for radio controller and packet processing
functions. This is enabled with Control & User plane separation, allowing these
functions to scale independently. The Cloud RAN CU supports split architecture
with both Cloud RAN DU and ERS RAN Compute via the F1 interface. This will be
useful for flexible deployments with a mixed combination of low-, mid- and high-
bands as the Cloud RAN solution matures.

Finally, a family of products known as the Cloud RAN Gateway has been
introduced to enable an all packet fronthaul system that includes the conversion of
Ericsson CPRI to Ericsson eCPRI (moving L1 processing). This product also
enables ESS between Ericsson Cloud RAN and ERS RAN Compute.

To conclude, Ericsson’s Cloud RAN offering is fully compatible with the complete
Ericsson Radio System, and supports Ericsson Spectrum Sharing (ESS), 5G
standalone and non standalone modes. The Ericsson Cloud RAN offering
seamlessly interworks with the service providers high-performing ERS installed
base (ERS RAN Compute).
22
 RAN Architecture Summary

At this point I think we’ve given a pretty clear definition of virtualized RAN, Open
RAN, and Cloud RAN.

So, let’s review the different RAN architectures that apply to Ericsson:
• We have Purpose-built Distributed RAN, where the baseband is at the edge of
the network on site with the antenna and radio.
• We have Purpose-built Centralized RAN, where the basebands are located
further away from the antenna site, in a central baseband pool.
• Next, we have Elastic RAN which enables coordination between Ericsson’s
basebands at different sites.
• And finally, Ericsson’s current response to Open RAN and virtualized RAN is the
Cloud RAN solution where the Centralized Unit and Distributed Unit run over
common off the shelf hardware.
• It can be a Distributed RAN,
• a Centralized RAN,
• an Elastic RAN
• or a Split RAN architecture with the Ericsson Lower Layer split.

I hope this course has been helpful in explaining the meaning of each architecture
term, the evolution of virtualization and how Ericsson uses V-RAN, Open RAN and
Cloud RAN to mean different things.

Thank you for listening.

23
24