The O-RAN

Whitepaper 2021
Overview, Architecture, and Traffic
Steering Use Case

Open RAN, as a new approach to building mobile networks, offers

faster innovation and the possibility of lowering costs. This whitepaper
provides an overview of Open RAN in general, and O-RAN specifically.
The O-RAN concept, relevant standardization, and ecosystem players
are introduced. The architecture as defined by the O-RAN Alliance
is described. Near-Real-Time RAN Intelligent Controller (RIC) along
with the idea of xApps is discussed. The use cases for O-RAN are
overviewed with a particular focus on Traffic Steering.

J U N E 202 1
The O -RAN Whitepaper 2021 Table of Contents

Table of Contents

Executive Summary 03

1.0 Introduction to Open RAN 04

2.0 O-RAN Overview 08

3.0 O-RAN Architecture, Nodes, and Interfaces 15

4.0 O-RAN near-Real-Time RIC 22

5.0 O-RAN Use Cases: Traffic Steering 27

Summary & Conclusions 36

References 38

Glossary 39

2 www.rimedolabs.com
The O -RAN Whitepaper 2021 Executive Summar y

Executive Summary

Currently, one of the hot topics in Telecoms world is Open RAN. This white-
paper provides a technical discussion in this field. It starts with a definition
of Open RAN as a trend. This is followed up by an overview of O-RAN, a term
introduced by the O-RAN Alliance, a standardization entity, whose mission
is “to re-shape the RAN industry towards more intelligent, open, virtualized
and fully interoperable mobile networks”. The overall concept of O-RAN is
provided together with entities involved in the ecosystem's creation.

Later, the whitepaper discusses the different nodes and interfaces creating
the flexible and disaggregated O-RAN architecture along with various op-
tions for implementation.

Next, more details are provided of the O-RAN concept with the topic of RAN
Intelligent Controller (RIC). RIC provides the possibility to manage the ra-
dio resources and radio network. It is designed within O-RAN architecture
as a separate entity together with Radio Resource Management (RRM) or
Self-Organizing Networks (SON) functions defined as xApps.

The idea of having RIC is to be able to efficiently manage and optimize the
RAN's operation. By using the concept of open interfaces and xApps, O-RAN
enables the provision of tailored algorithms for specific use cases. O-RAN
Alliance specifies preliminary use cases and defines the policy framework
by which the algorithms to support the use cases can be controlled.

The final part of the whitepaper provides an overview of the use cases, fol-
lowed by a detailed discussion of the Traffic Steering use case. Discussion
continues of the use case requirements, operation of the O-RAN nodes,
along with the specified interfaces, and a description of the scenario as
defined in O-RAN Alliance specifications.

The whitepaper is finalized with a summary and conclusions section along

with a glossary of the O-RAN terms.

3 www.rimedolabs.com
The O -RAN Whitepaper 2021 1 .0 Introduction to Open RAN

1.0
Introduction
to Open RAN

Like almost everything in Telecoms, Open RAN is

complicated. It's not a single idea. It's not a single
product or service. It's not an optimization technique
or path towards improved efficiency. In fact, it’s
hardly even an agreed term.

You’ll find references in the literature to Open RAN,

OpenRAN, ORAN, and O-RAN (see e.g., [1-7]). The general
trend is called Open RAN and as such we will use it
throughout this chapter. The later chapters will focus
on the technicalities as per O-RAN Alliance thus, we'll
use the term O-RAN (with the "dash").

4 www.rimedolabs.com
The O -RAN Whitepaper 2021 1 .0 Introduction to Open RAN

1.1 General Open RAN idea

The term "Open RAN" is used to refer to the overall movement of opening
up the RAN by disaggregating hardware and software and creating open
interfaces between them. In turn, "OpenRAN" is used by Telecom Infra Pro-
ject [6], while O-RAN with a "dash" or hyphen is used by the O-RAN Alliance [1].

Open RAN is essentially two foundational ideas:

» The disaggregation of network functionality from the underlying

hardware. In other words, software-defined functionality.

» The specification of discrete functional blocks having well-defined

interfaces. In other words, modularity.

Below, the different aspects of Open RAN are elaborated.

1.2 Disaggregation
Disaggregation means the desired functionality is implemented in software,
with as little dependence as possible on specific hardware. The software
should be able to run almost anywhere on general-purpose, commonly
available hardware (also known as CoTS - commercial off-the-shelf). This
is not a radical notion. It is entirely consistent with today's best practices of
virtualization and containerization which are known from the IT world.

The virtualization hypervisor and the containerization runtime strip away

all hardware specificity. Disaggregation makes software relatively portable
and gives the MNO (Mobile Network Operator) tremendous flexibility in their
network architecture. The concept of disaggregation is so simple it is a little
surprising that it holds the possibility to radically alter the Telecoms busi-
ness. But it does. We'll get to that.

1.3 Discrete functions with

well-defined interfaces
Today, the ideas of open APIs (Application Programming Interfaces) and
standard interfaces are so mainstream that you're forgiven for wonder-
ing why they are not more common in Telecoms. GSM, Global System for
Mobile Communications, tried this approach 30 years ago. The European
2G GSM standard was developed to allow MNOs to use equipment from
different vendors.

GSM defined blocks of functionality using standard interfaces. But it was

a different technology World back then. The vendors did not want to play
along and had enough power to thwart the nascent standard. By the time
3G was defined, GSM’s standard interfaces were ignored.

5 www.rimedolabs.com
The O -RAN Whitepaper 2021 1 .0 Introduction to Open RAN

1.4 What motivates Open RAN?

Several factions making common causes are driving interest in Open RAN.
MNOs are keen to reduce their reliance on a dwindling number of suppliers
and avoid the lock-in of proprietary solutions. The software industry, being
much larger today than it was in the GSM era, would like the opportunity to
expand into Telecoms.

The public cloud providers also see the chance to grow their addressable
markets. And as the Internet has continued to grow and expand its reach
into every aspect of life, the pace of change continues to accelerate. Inno-
vation is surely one of the most significant motivating factors.

1.5 Market concentration

Some people like to cast Open RAN as a battle between Mobile Network
Operators (MNOs) and traditional telecom manufactures. Today, there are
a few traditional telecom manufacturers. This concentration causes deep
concern among mobile operators. The concentration of basic telecoms
capabilities into so few providers is a worry.

Having only a few suppliers to choose from gives these companies enor-
mous power over the MNOs. For years, the relationship between the ven-
dors and MNOs has been complex. MNOs dislike being locked into the pro-
prietary solutions offered by the vendors and having no leverage. But the
MNOs also liked having a single provider to help manage the network.

1.6 Avoiding vendor lock-in

The are several problems associated with relying on the proprietary solu-
tions offered by the traditional vendors. A proprietary solution from one
vendor will not work with the solution of another vendor. So once the
choice of the vendor has been made, tremendous sums will be spent to
build a network. Most of it will be paid to that single proprietary vendor. In
this, there is little opportunity to negotiate better prices. To change ven-
dors means the MNO will have to buy almost a completely new network.
The costs are huge!

1.7 Not repeating the Over-The-Top

(OTT) debacle
Mobile commerce was first becoming a reality in the mid to late 3G era
when companies came up with business models selling to mobile sub-
scribers. Facebook, Youtube, Netflix, the Instant Messaging apps, and other,
those companies needed higher bandwidth and greater coverage to ca-
ter to their audiences. 4G was not yet deployed. The MNOs could not serve
these Over-The-Top (OTT) companies. So, the companies simply found
ways to solve their connectivity problems for themselves. The MNOs were
bypassed and mostly locked out of this sizable new revenue stream. The
MNOs would like to not repeat that mistake.

6 www.rimedolabs.com
The O -RAN Whitepaper 2021 1 .0 Introduction to Open RAN

1.8 Hyperscalers
In the days since the OTT players bypassed the MNOs, another industry has
arisen: the Hyperscalers, or the public cloud providers. Facebook, Apple, Am-
azon, Google, Microsoft, and others have become among the largest com-
panies in the world by making it very easy to virtualize functions for many
kinds of networks. As the Internet has grown, these companies have grown
right along with it. Expanding their reach into Telecoms is quite natural.

1.9 Independent Software Vendors (ISVs)

Another industry that has grown tremendously over the last 3 decades is
the Independent Software Vendors, ISVs. As Marc Andreessen once said,
“software is eating the world.” Opening the Telecoms Market to ISVs should
be a terrific opportunity for them. They’ve been coding standard interfaces
for decades and will be well-positioned to expand into an industry support-
ing standard interfaces.

1.10 Innovation
The last motivation for Open RAN that we mention is innovation. The mobile
industry has for years defined technology generations in roughly 10-year
intervals. The reasons for this are many. One is certainly that the vendors
needed time to develop and build the next generation of technology, and
then needed enough time to sell that technology so that they could recoup
their investment. The MNOs, too, needed time to recoup their investment in
the latest technology.

In this aspect, the interests of the vendors and their MNO customers were
well aligned. But Telecom technology is not monolithic. It’s dynamic, moving
forward on many fronts simultaneously. The 10-year cycle of Mobile tech-
nology generations has long been an anachronism. To force customers to
wait 10 years for the latest innovations to be offered is no longer worka-
ble. The industry needs a way to deploy new technology much faster. Think
about how the apps on your mobile phone are enhanced. Many apps are
upgraded 2 or 3 times or more each month. Each new upgrade enhances
the functionality or improves the security.

7 www.rimedolabs.com
The O -RAN Whitepaper 2021 2.0 Introduction to O -RAN

2.0
Introduction to O-RAN

This chapter provides an introduction to O-RAN. First of

all, to avoid misunderstandings, the thing that is subject
to discussion is the O-RAN with the “dash”. This is the
Open RAN as defined by O-RAN Alliance, an entity, which
mission is “to re-shape the RAN industry towards more
intelligent, open, virtualized and fully interoperable
mobile networks” [1].

8 www.rimedolabs.com
The O -RAN Whitepaper 2021 2.0 Introduction to O -RAN

2.1 RAN Transformation

Fig. 2.1-1 shows the transformation of the Radio Access Network (RAN) when
moving from the regular approach to the Open RAN.

Fig. 2.1-1. RAN Transformation (CN - Core Network, RIC - RAN Intelligent Controller, CU -
Central Unit, DU - Distributed Unit, RU - Remote Unit, FH - Fronthaul)

In the traditional way of providing RAN there is a single black box and the in-
ternal interfaces within that box are closed and are in hands of one vendor.
Moving towards Open RAN, the functions of the base station (BS) are divided
into the following entities with open interfaces between them: a centralized
unit (CU), a distributed unit (DU), and a remote unit (RU). With the O-RAN ap-
proach, those entities can be developed by different vendors due to the
open interfaces between them (including Open Fronthaul, Open FH). In ad-
dition, the important element is the RAN intelligent controller (RIC) which is
extracted from the processing units and allows to provide the management
functionality, like radio resource management (RRM) or self-organizing net-
works (SON) functions. They control the radio resources and RAN operation.
In the O-RAN concept, this is where the intelligence sits, by the means of
artificial intelligence (AI) models for radio network automation.

The claimed characteristics of the O-RAN concept are also shown in Fig.
2.1-1. and include:

» Disaggregation of the RAN into the mentioned functions (i.e., CU, DU,
RU, RIC), decoupling of software from hardware (virtualization), and
opening of internal RAN interfaces.

» This allows creating an open ecosystem where there could be different

vendors, like CU/DU vendors, RIC vendors, xApp developers, or system
integrators.

» Intelligent management – this is enabled by the RIC, where the

intelligence is to be natively embedded within the O-RAN architecture
using AI models and various specialized RRM functions, like Traffic
Steering, Mobility Management, Interference Management, etc.

9 www.rimedolabs.com
The O -RAN Whitepaper 2021 2.0 Introduction to O -RAN

2.2 Radio Access Network

using O-RAN concept
Let’s now take a look at the 5G RAN architecture with the management en-
tities and interfaces brought by O-RAN Alliance [1] definition (see Fig. 2.2-1).

Fig. 2.2-1. O-RAN-based Radio Access Network (D/A – digital to analog, RFE – RF Frontend, SDAP – Service Data Adaptation Protocol,
AMF – Access and Mobility Function, UPF – User Plane Function, PDCP – Packet Data Convergence Protocol, RLC – Radio Link Control,
MAC – Medium Access Control, PHY – Physical Layer, Sched. – Scheduler)

10 www.rimedolabs.com
The O -RAN Whitepaper 2021 2.0 Introduction to O -RAN

A simplified protocol stack of the radio interface between the base sta-
tion (BS) and the user equipment (UE) is presented, with PHY layer, MAC,
RLC, PDCP, and finally, RRC controlling the connection. In 5G, there are two
defined entities further splitting the CU, namely CU-CP (Control Plane – for
connection management) and CU-UP (User Plane – for UP data process-
ing). Also, compared to LTE, there is an SDAP protocol in the UP path for QoS
mapping. Now, when getting to O-RAN the CU-UP, CU-CP, DU, and RU, gets
the “O-” prefix, meaning that they are adapted to the O-RAN Alliance ar-
chitecture. Due to being connected to the E2 interface, they are called E2
nodes in the O-RAN Alliance specifications.

On the other end of the E2 interface, there is the RIC, which is split onto
“near-Real Time RIC” (nRT RIC) and “Non-Real Time RIC” (NRT RIC), which can
be provided by a third party. (Note that the small “n” is for near-RT, where-
as the capital “N” – for Non-RT. They are used to distinguish those entities
in this whitepaper.) The former is responsible for handling the near-RT ra-
dio resource management functions (i.e., on a timescale of > 10 ms and
< 1 s), like Mobility Management, Interference Management, etc. The latter
one is handling the more high-level functions and provides policies to nRT
RIC over the A1 interface. An important aspect to mention here is that the
Real-Time (RT) RRM is still there, embedded in O-DU (like MAC scheduler or
power control). To summarize, there are three control loops: RT (< 10 ms)
handled by O-DU, near RT (> 10 ms, < 1 s) handled by nRT RIC, and Non-RT (> 1
s) handled by NRT RIC. This is a hierarchical design, which allows separating
the resource management aspects depending on the time scale.

11 www.rimedolabs.com
www.rimedolabs.com
The O -RAN Whitepaper 2021 2.0 Introduction to O -RAN

2.3 Entities involved in

the O-RAN developments
Fig. 2.3-1. shows the relevant entities involved in O-RAN definitions and de-
velopments as well as relations between them.

Fig. 2.3-1. O-RAN-Related Entities (MANO - Management and Orchestration, LLS - Lower Layer Split, MMIMO - Massive MIMO)

First, there is the 3GPP [2] that defines the 5G standard including architec-
ture, radio interface, operation of RAN, UE, core network. In regards to Open
RAN, only part of those goes further into the processing, while others (like
core network, CN) are out of the scope of O-RAN. In this context, the relevant
parts include CU, DU, management, and orchestration (MANO), and inter-
faces like E1, F1, etc.

Secondly, there is the O-RAN Alliance [1], which takes the 3GPP defined el-
ements of RAN and builds upon them with E2 and A1 interfaces, both RICs,
lower layer split (LLS), a fronthaul solution, the Service and Management
Orchestration (SMO), etc. Doing so, O-RAN Alliance creates the O-RAN open
architecture.

Later, an important player is the Open Networking Foundation (ONF) [3] with
its software-defined RAN (SD-RAN) [4]. O-RAN Alliance specifications are in-
put to the ONF’s SD-RAN, but not all of them are taken into account. SD-RAN is
focusing on building an exemplary platform for O-RAN-based design choic-
es called “micronos-RIC”. The aim is to provide open-source RIC with emu-
lators to allow xApp developers to test their solutions and allows operators
to test the different xApps. Additionally, O-RAN Alliance, together with Linux
Foundation, created the O-RAN Software Community (OSC) [8] that aims at
creating an open-source software reference design for the whole O-RAN
(See the relevant projects within OSC in Fig. 2.3-2).

Another important player is Telecom Infra Project (TIP) [5] within the O-RAN
area [6]. Specifically, within the RRM part, TIP defines the RAN Intelligence and
Automation subgroup (RIA) aiming to use the “micronos-RIC” (or OSCs, or
other RICs) to develop and deploy AI-based xApps for use cases like SON,
RRM, MMIMO, etc.

12 www.rimedolabs.com
The O -RAN Whitepaper 2021 2.0 Introduction to O -RAN

Summing up, from the left side of Fig. 2.3-1 there are reference design ar-
chitectures, interfaces, and nodes; then, there are exemplary platforms;
and finally, use case development, where e.g., the operators are setting up
priorities for developments. There are also other entities as well, e.g., Open
RAN Policy Coalition [7] to promote the Open RAN concept adoption within
the governments and ecosystem players. In terms of commercial devel-
opments, O-RAN Alliance is also providing a virtual exhibition platform [9]
where implementations of various elements of O-RAN are provided and are
constantly updated. Small Cell Forum is also being active in the Open RAN
developments adapting Small Cell interfaces and the nFAPI interface [10].
This configuration may also be further expanded in the near future by e.g.,
cloud platform providers for interoperability testing, “xApp stores” and alike.

Notes: There are additional supporting projects, like, Simulations (SIM), Integration and test (INT), or Infrastructure (INF)

Fig. 2.3-2. O-RAN Software Community

13 www.rimedolabs.com
The O -RAN Whitepaper 2021 2.0 Introduction to O -RAN

2.4 O-RAN Alliance

specifications
O-RAN Alliance specifies the overall architecture, the management, and
orchestration, RICs, E2, A1, O1 interfaces, use cases, etc. Table 2.4-1 provides
an extract of the key specifications (based on [1]). Note that O-RAN Alliance
has recently released a new set of specifications together with significant
updates to the existing ones [12].

Specification Name Title Contents

O-RAN.WG1.O RAN Architecture O-RAN definitions, architecture, interfaces,

O-RAN Architecture Description
Description v02.00 block diagrams

O-RAN.WG1.OAM Architecture O-RAN Operations and Maintenan- OAM use cases, OAM architecture
v03.00 ce Architecture

nRT RIC Architecture, APIs for xApps, require-

O-RAN.WG3.RICARCH v01.00 Near-RT RIC Architecture
ments

O-RAN.WG1.Use Cases Detailed Use cases background, entities involved,

Use Cases Detailed Specification
Specification v03.00 solutions, required data

nRT RIC Functional allocation, architecture,

Near-Real-time RIC Architecture &
O-RAN.WG3.E2GAP v01.01 and support functions, E2 principles and
E2 General Aspects and Principles
functions, service model

A1 interface: General Aspects and A1 service architecture and functions, A1 sig-

O-RAN WG2.A1GAP v02.00
Principles naling procedures, protocol structure

A1 services, API definitions, Open API specifi-

O-RAN.WG2.A1AP v02.00 A1 interface: Application Protocol
cation, JSON objects (e.g. for TS policy)

O-RAN Operations and Maintenan- Management services (provisioning, fault

O-RAN.WG1.O1 Interface.0 v03.00
ce Interface Specification supervision, performance assurance, etc.)

Table 2.4-1: Selected O-RAN Alliance Specifications (based on [1]). Please note that the above provides a non-exhaustive list of the
specifications. For the full list, please go to the O-RAN Alliance website [1].

14 www.rimedolabs.com
The O -RAN Whitepaper 2021 3.0 O -RAN Architecture, Nodes, and Inter faces

3.0
O-RAN Architecture,
Nodes, and Interfaces

In the previous chapter, the overall O-RAN concept as

provided by O-RAN Alliance was presented. This one
discusses the different nodes and interfaces creating
the flexible and disaggregated O-RAN architecture
along with various options for implementation.

15 www.rimedolabs.com
The O -RAN Whitepaper 2021 3.0 O -RAN Architecture, Nodes, and Inter faces

3.1 O-RAN nodes

Fig. 3.1-1 shows a high-level view of the O-RAN Alliance defined nodes.
The white elements are 3GPP defined and adapted by O-RAN spec-
ifications (thus, the “O-” is added), while the yellow ones are O-RAN
defined elements. (Note: the interfaces between the elements are
explicitly not shown in this figure – they are introduced in the next
section of this chapter.)

The different building blocks could in general be provided by sepa-

rate vendors; thus, they can create an ecosystem of players devel-
oping only CUs, or DUs, or only xApps or RICs, etc. This is where one of
the advantages of the O-RAN concept sits.

Fig. 3.1-1. O-RAN Defined Entities

16 www.rimedolabs.com
The O -RAN Whitepaper 2021 3.0 O -RAN Architecture, Nodes, and Inter faces

The individual elements are as follows (as per

definition from [11]):

O-Cloud a Cloud Computing platform comprising physical infrastructure nodes

to host O-RAN functions, like near RT-RIC, O-DU, etc.; supporting software
components (e.g. OS, VM monitoring, container runtime), management,
and orchestration functions.

O-RU (O-RAN a logical node hosting a low-PHY layer (e.g. FFT/IFFT, PRACH) and RF-based
Remote Unit) on LLS (Lower-Layer Split);

O-DU (O-RAN a logical node hosting RLC (Radio Link Control) / MAC (Medium Access
Distributed Unit) Control) / high-PHY layers based on LLS;

O-CU-CP (O-RAN Central a logical node hosting RRC (Radio Resource Control) and CP (Control
Unit-Control Plane) Plane) part of PDCP (Packet Data Convergence Protocol);

O-CU-UP (O-RAN Central a logical node hosting SDAP (Service Data Adaptation Protocol) and UP
Unit-User Plane) (User Plane) part of PDCP;

near-RT RIC (near a logical node enabling near-RT control/optimization of RAN elements and
Real-Time RAN Intelligent Control- resources via fine-grained data collection and actions over E2. nRT RIC
ler or nRT RIC) may include AI/ML workflow.

Non-RT RIC (Non-Real- a logical node enabling Non-RT control/optimization of RAN elements and
Time RAN Intelligent resources, capturing AI/ML workflow, and policy-based guidance of appli-
Controller or NRT RIC) cations/features in nRT RIC;

xApp an application designed to run on nRT RIC, likely to consist of one or more
microservices, that identifies data to consume and provide. xApp is inde-
pendent of nRT RIC and may be provided by a third party;

SMO (Service and system supporting orchestration of O-RAN components that includes NRT
Management Orchestration) RIC.

17 www.rimedolabs.com
The O -RAN Whitepaper 2021 3.0 O -RAN Architecture, Nodes, and Inter faces

3.2 O-RAN architecture

Let’s now take a look at the overall O-RAN architecture (Fig. 3.2-1), where the
entities provided in Fig. 3.1-1 are connected by the interfaces as per O-RAN
Alliance specification [11].

Fig. 3.2-1. Overall O-RAN Architecture

18 www.rimedolabs.com
The O -RAN Whitepaper 2021 3.0 O -RAN Architecture, Nodes, and Inter faces

The “white” entities are specified by the 3GPP (both

including functionality provided by white boxes as well
as interfaces, like F1 and E1), while “yellow” elements
and interfaces are specified by O-RAN Alliance. Let’s
now focus on the “yellow” interfaces:

A1 interface is defined between NRT RIC and nRT RIC, through which NRT RIC provides
nRT RIC with policies, enrichment info, and ML model updates, while on the
other hand, nRT RIC provides back the policy feedback;

E2 interface touches and gets into the specific entities within the base station, i.e.,
O-DU, O-CU. Therefore, e.g. on one hand we can control what is happening
within that BS, using monitor, suspend, override, control messages, and
execute actions coming from by xApps/nRT RIC, and get data collection
and feedback from those entities;

O1 and Open-Fronthaul a regular FCAPS (Fault, Configuration, Accounting, Performance, Security)

M-plane interfaces interface with configuration, reconfiguration, registration, security, perfor-
mance, monitoring aspects exchange with individual nodes, like O-CU-UP,
O-CU-CP, O-DU, O-RU, and nRT RIC;

O2 interface to manage the platform resources and workload (like resource scaling
and FCAPS for cloud computing platform).

Fig. 3.2-1 also shows the three control loops, namely the first control loop
being real-time, where actions of a timescale below 10 ms take place, like
the O-DU scheduler (not subject to the O-RAN Alliance specification). Then,
there is the near-real-time control loop, with timing between 10 ms and 1 s,
where the functions like Traffic Steering, Mobility Management, and Inter-
ference Management operate. Finally, the most outer control loop touches
the non-real-time operations of more than 1 s, with orchestration and opti-
mization functions and incorporation of ML models.

19 www.rimedolabs.com
The O -RAN Whitepaper 2021 3.0 O -RAN Architecture, Nodes, and Inter faces

3.3 O-RAN
implementation options
Fig. 3.3-1 and Fig. 3.3-2 show various options for the implementation of O-RAN
architecture based on [11]. It should be noted that the E2 Node is a logical
node terminating the E2 interface, for NR it is O-CU-CP, O-CU-UP, O-DU, or
any combination as allowed by O-RAN Alliance.

Fig. 3.3-1. O-RAN Aggregation Options: Disaggregated Network Functions (Left); Aggregated O-CU-CP, O-CU-UP, and O-DU (Right)

The left side of Fig. 3.3-1 shows the fully disaggregated architecture (i.e., the
same that was presented in Fig. 3.2-1), where nRT RIC has E2 connections to
each individual O-CUs, and O-DU which then become individual separated
E2 Nodes. However, the nodes can also be aggregated in different ways.
One example option is shown on the right side of Fig. 3.3-1, where O-CU and
O-DU are combined and are collectively treated as a single E2 Node, to
which there is only a single E2 connection (and a single O1 connection).

20 www.rimedolabs.com
The O -RAN Whitepaper 2021 3.0 O -RAN Architecture, Nodes, and Inter faces

The next set of options in Fig. 3.3-2 shows different ways to combine the
different functional elements. The left side presents the incorporation of
nRT RIC together with O-CUs, which means that the E2 interface to control
O-CUs is internal, and from that combined node there is a regular E2 inter-
face towards O-DU only. Finally, the right side of Fig. 3.3-2 presents an option
where all the nodes (except SMO) are combined, thus, the E2 interface is
internal, and there are only single O1 and A1 connections.

Fig. 3.3-2. O-RAN Aggregation Options: Aggregated nRT RIC, O-CU-CP, O-CU-UP (Left), All Nodes Aggregated (Right)

21 www.rimedolabs.com
The O -RAN Whitepaper 2021 4 .0 O -RAN near-Real-Time RIC

4.0
O-RAN
near-Real-Time RIC

RAN Intelligent Controller (RIC) provides the possibility

to manage the radio resources and radio network and
is designed within O-RAN architecture as a separate
entity. As presented in the previous parts of the whitepaper,
RIC is split into near-Real-Time RIC (O-RAN near-RT RIC)
and Non-Real-Time RIC. In this chapter, the former one
is discussed.

22 www.rimedolabs.com
The O -RAN Whitepaper 2021 4 .0 O -RAN near-Real-Time RIC

4.1 O-RAN near-RT RIC

As the name suggests, near-RT RIC operates in near-real-time (i.e., in the
timeframe > 10 ms and <1 s) and is responsible for RAN control and optimiza-
tion, incorporates xApps to realize RRM, and bases its operation on UE and
cell-specific metrics.

The requirements for the near-RT RIC

as provided by O-RAN Alliance in [13]
are that the near-RT RIC shall:
» provide a database function that stores the configurations relating to
E2 nodes, Cells, Bearers, Flows, UEs, and the mappings between them;

» provide ML (machine learning) tools that support data pipelining;

» provide a messaging infrastructure;

» provide logging, tracing, and metrics collection from near-RT RIC

framework and xApps to SMO (service and management orchestration
system);

» provide security functions;

» support conflict resolution to resolve the potential conflicts or overlaps

which may be caused by the requests from xApps.

Based on the above requirements O-RAN Alliance specified the near-RT RIC
internal architecture and building blocks as shown in Fig. 4.1-1, as per [13].

23 www.rimedolabs.com
The O -RAN Whitepaper 2021 4 .0 O -RAN near-Real-Time RIC

To have an overview of the different entities’ opera-

tions: xApp subscription management is required to be
able to identify the new xApps and to allow data dis-
tribution among all of them that subscribe to the data
collection and provide awareness of the xApps that are
onboarded. To distribute the information among those
entities, we need the message bus, thus, the messag-
ing infrastructure is included. Conflict mitigation in turn
is needed to resolve e.g., overlapping requests. For ex-
ample, we may have one function, being mobility load
balancing (MLB), and another one, mobility robustness
optimization (MRO). Both of them can have an adver-
sarial impact on the actual user behavior. E.g., one may
decide that the user needs to be moved from one cell
to another due to high traffic load, while the other at the
same time may move the user back as the handover
boundary change due to high handover failure rate. In
such a case, the individual user will be “ping-ponged”
between the two cells. In such a case, the conflict miti-
gation function’s job is to align the potential actions to
avoid undesired behavior.

Fig. 4.1-1. O-RAN near-RT RIC – Internal Architecture

The individual elements shown in Fig. 4.1-1 are

as follows (as per [13]):
Functions hosted by allow services (i.e. RRM control functionalities) to be executed at the
xApps near-RT RIC and the outcomes sent to the E2 Nodes (i.e. enforced in the E2
Nodes) via E2 interface;

Database together with allows reading and writing of RAN/UE information;

shared data layer

Conflict mitigation resolves potentially overlapping or conflicting requests from multiple

function xApps;

Messaging infrastructure enables message interaction amongst near-RT RIC internal functions;
function

xApp subscription merges subscriptions from different xApps and provides unified data
management function distribution to xApps;

Security function provides security scheme for the xApps;

Management services element is used for: fault, configuration management, and performance
function management; Life-cycle management of xApps; Logging, tracing, and
metrics collection and transfer to an external system for evaluation.

24 www.rimedolabs.com
The O -RAN Whitepaper 2021 4 .0 O -RAN near-Real-Time RIC

4.2 near-RT RIC

implementation options
Let’s now have a look at the two different implementation options for near-
RT RIC as per the O-RAN Alliance definition (see Fig. 4.2-1) [11].

The upper side of Fig. 4.2-1 shows the centralized near-RT RIC, where the
whole gNB (by means of O-CUs and O-DU) or eNB, or both are handled by
the same near-RT RIC that allows to take unified decisions for an individual
base station and globally/holistically optimize its operations. On the con-
trary, the lower side of Fig. 4.2-1 shows a fully distributed near-RT RIC, where
each E2-Node type is handled by a specialized logical entity of near-RT RIC
that allows optimizing of the individual types of the managed entities (i.e.,
specific E2-Node).

Based on defs from: O-RAN Alliance Specifications

Fig. 4.2-1. near-RT RIC implementation options

25 www.rimedolabs.com
The O -RAN Whitepaper 2021 4 .0 O -RAN near-Real-Time RIC

4.3 near-RT RIC

deployment flexibility
The implementation options, as discussed in the previous section, allowed
by O-RAN Alliance specifications have their advantages and disadvantag-
es. The advantage is that it allows flexibility, where we may combine the
entities or split them and allows being deployed and delivered by differ-
ent companies. The price to pay, however, is the design of the E2 interface,
which is responsible for providing measurements and controlling certain
functions, where we need to know which actual E2-Node we are talking to
and, thus, needs overhead to account for this. This is mainly done by en-
capsulation of the information elements which need those different options.

An example is shown in Fig. 4.3-1 (based on [14]) where the Performance

Measurements Indicator provided by E2-Node to the near-RT RIC is nest-
ed through three levels of encapsulation (Performance Management
(PM) container --> O-DU PM container --> O-DU Measurement format for
5GC). The example accounts for a situation, where the E2-Node sending
the measurement is an O-DU node with 5G in a standalone mode (SA) of
operation (i.e. gNB connected to 5GC). If the same O-DU would be send-
ing measurements in a configuration, where it is connected to EPC (i.e. a
non-standalone mode, NSA), a different format would have been used.

PM Container O-DU PM container

O-DU Measurement Format for 5GC

Source: ORAN-WG3.E2SM-KPM-v01.00.00

Fig. 4.3-1. E2 Key Performance Measurements – O-DU Measurement format for 5GC Example

26 www.rimedolabs.com
The O -RAN Whitepaper 2021 5.0 O -RAN Use Cases: Traffic Steering

5.0
O-RAN Use Cases:
Traffic Steering
One of the key elements of having RIC (and the overall O-RAN concept
for the management of radio networks) is to be able to efficiently
manage and optimize the radio network. By using the concept of
open interfaces and xApps, O-RAN enables tailored algorithms for
specific use cases. O-RAN Alliance specifies preliminary use cases
and defines the policy framework by which the algorithms to support
the use cases can be controlled. This chapter provides an overview
of the use cases, which is followed by a detailed discussion of one of
them, namely Traffic Steering. We discuss the use case requirements,
operation of the O-RAN nodes with the specified interfaces and
describe the scenario as characterized in O-RAN Alliance
specifications.

27 www.rimedolabs.com
The O -RAN Whitepaper 2021 5.0 O -RAN Use Cases: Traffic Steering

Fig. 5.1-1. O-RAN Use Cases (UAV - Unmanned Aerial Vehicle, V2X - Vehicular-to-Anything, SLA - Service Level Agreement,
QoE - Quality-of-Experience, QoS - Quality-of-Service)

5.1 O-RAN use cases

Fig. 5.1-1 shows the different use cases that are defined by O-RAN Alliance [15,
16] and which are split into two phases as per the organization members’
preference [16]. This means that the use cases specified within Phase I shall
be developed earlier to solve the most immediate needs of the operators.

The split between phases is rather natural. Phase I use cases deal mostly
with the relatively generic items like white box hardware, traffic steering,
QoS/QoE optimization, or massive MIMO. Those are of high priority, as they
are related to most of the scenarios that will be treated by most operators.
Phase II, in turn, is related to specialized applications, like slicing/RAN shar-
ing or UAV (Unmanned Aerial Vehicles)/V2X (Vehicular to Anything) aspects
that require specific treatment (and are highly demanding) for some net-
works that serve a specific type of applications.

28 www.rimedolabs.com
The O -RAN Whitepaper 2021 5.0 O -RAN Use Cases: Traffic Steering

5.2 Traffic Steering use case

Let’s now take a look at one of the use cases, namely Traffic Steering (TS).
Fig. 5.2-1. shows the aspects related to this use case to set up the scene as
per [15].

Let’s start with what a TS is. It specifies how to steer traffic and in mobile
network’s case, i.e., to what cell or to what base station (BS) the user is con-
nected. It may be more general: if we have multiple Radio Access Technol-
ogies (RATs), like 4G, 5G, Wi-Fi, TS has to decide, to which RAT, then to which
cell, then to which band, and in that band to which component carriers the
UE shall be connected to. In addition to that, we may have dual connectivity
(DC) function in place. If this is the case, it might be a decision of what is
the primary and secondary base station for that UE. Furthermore, once we
decide which cells and base stations the UE is connected to, there may be
different traffic types that the UE may have, like voice or MBB connection.
Those may be treated differently as well, by being assigned to different cells.

The problem is that the typical TS schemes treat all the users in the same
way. They are also limited to cell selection or handover parameters up-
dates, based on which the UE is moved between cells. Those schemes don’t
take into account that a specific user is a V2X user and that it may not
be switched to another cell at the same time as a nomadic MBB user. For
instance, it might make sense to change the cell of V2X UE earlier than for
MBB UE. This is specifically a challenge within 5G, where the network is very
heterogeneous. There is slicing, there are various architectural options (like
Non-Standalone/Standalone), there are different types of cells and a multi-
tude of frequency bands. Therefore, the TS may be very complicated. At the
same, it is very important to properly assign connections to cells to utilize
the resources efficiently.

29 www.rimedolabs.com
The O -RAN Whitepaper 2021 5.0 O -RAN Use Cases: Traffic Steering

Fig. 5.2-1. O-RAN Traffic Steering: Use Case Description

Therefore, the purpose of this particular use case as per O-RAN Alliance is to have a customization possibility where
the operators might apply different strategies for individual users. Depending on the type of services or slice types
assigned to a specific user, we might treat them differently. According to O-RAN Alliance, ML can be “hired” to en-
able intelligent traffic steering control. It specifies the required data to take a particular decision, e.g. RSRP/RSRQ,
handover performance, cell load, and UE performance statistics. When taken collectively, they can be used to have
a specific user being treated individually, and as a result of its specific characteristics, obtain a unique allocation.

To realize the above, RIC is employed, where through ML schemes we can learn the specific traffic pattern/user
behavior. E.g., there is a street where the users are moving in a specific direction and if they are in a car and have a
specific slice type, they may be treated one way. The learning mechanism can tell the xApp controlling the hand-
over to do it in a certain way for that type of user and differently for another one.

30 www.rimedolabs.com
The O -RAN Whitepaper 2021 5.0 O -RAN Use Cases: Traffic Steering

5.3 Traffic Steering use case

operation within O-RAN
Let us now look into the specific entity responsibilities within the O-RAN Alli-
ance architecture for handling the TS use case, as shown in Fig. 5.3-1.

Fig. 5.3-1. O-RAN Architecture Use Case

31 www.rimedolabs.com
The O -RAN Whitepaper 2021 5.0 O -RAN Use Cases: Traffic Steering

The O-RAN entities shown in Fig. 5.3-1 are responsible for:

Non-RT RIC » Defines and updates policies – to guide the behavior of TS xApp in near-
RT RIC (e.g., optimization objectives to guide carrier/band preferences for
UE/UE-group);

» Performs statistical analysis to provide enrichment info for near-RT RIC to

assist TS function (e.g., RF fingerprint based on UE measurement report
like RSRP/RSRQ/CQI info for serving/neighboring cells);

» Communicates policies and enrichment info (e.g., RF fingerprints) to

near-RT RIC & measurement configuration parameters to RAN nodes.

near-RT RIC » Interprets and enforces policies from Non-RT RIC;

» Uses enrichment info to optimize control function, e.g., near-RT RIC can
use RF fingerprint to predict inter-frequency cell measurement based on
the intra-frequency cell measurement to speed up the TS;

E2-Node (here being » E2-Node (here being O-CU):

O-CU):
» Collects and transmits data with required granularity to SMO over O1;

» Executes actions.

The information provided at the related interfaces is as follows:

A1 is used to provide » A1 policy – declarative policy to enable Non-RT RIC to guide near-RT RIC
near-RT RIC with: on steering the behavior of RAN functions towards stated objectives;

» A1 enrichment info – additional info used by near-RT RIC collected at

SMO/non-RT RIC from non-network data or NFs;

E2 is used to deliver to » control messages, like handover execution or Secondary Cell activation /
the E2-Nodes: Secondary Cell Group addition, etc.

The Non-RT RIC defines and updates the policies to guide the behavior of the TS xApp that is sitting in the near-RT
RIC. It also performs the statistical analysis of the data and provides policies and enrichment information (e.g., RF
fingerprints). Here is also where the learning and setting up policies that are sent over the A1 happens. The policy
can be e.g., “prefer/forbid/allow cell X for user Y for a particular service/slice/QoS profile”. The implementation of the
policy happens within the near-RT RIC, which takes the specific decision. For instance, a specific user needs to move
from one cell to another. nRT RIC provides that decision over the E2 interface via control messages. In turn, E2 nodes
execute those actions by means of RRC procedures (e.g., Handover command, Secondary Node addition, etc.)

32 www.rimedolabs.com
The O -RAN Whitepaper 2021 5.0 O -RAN Use Cases: Traffic Steering

5.4 Example TS Use Case

Fig. 5.4-1 shows the example scenario for the TS use case as per [15].

Fig. 5.4-1. TS use case example scenario (5QI – 5G Quality-of-Service Indicator, S-NSSAI –
Single – Network Slice Selection Assistance Information, CP - Control Plane, MBB - Mobile
Broadband)

In this example, there are:

» macro BS (denoted as gNB1) that » small BS (denoted as gNB2), with
controls cells (A and B), located wide BW/high throughput cells
on low bands (e.g., 700/800 MHz) (C and D), using high frequency
with 10 MHz carrier bandwidths (e.g. 3.8/4.5 GHz) with plenty of
and allows low latency; available resources, by which
the UE can transfer/receive all
the data it needs.

33 www.rimedolabs.com
The O -RAN Whitepaper 2021 5.0 O -RAN Use Cases: Traffic Steering

Cells C/D are designated as MBB cells. For the voice service, we don’t need
much BW and we focus on wide coverage, to avoid frequent handovers.
The UE under consideration has two services – voice, and MBB. The UE is en-
tering the area covered by the four cells mentioned above. From the O-RAN
perspective, the Non-RT RIC understands the requirements and character-
istics of that services. It decides that due to having a voice and Control
Plane (CP) connection, it needs to put those on a low band on the largest
cell, i.e. cell B. On the contrary, for MBB connection when the user moves to
the coverage of small cells, we can add a second transmission leg and
offload this MBB traffic to cell C/D, thus, avoid consuming resources from
the cells A/B. This shall be sent to near-RT RIC, through several policies as
described below.

The Non-RT RIC sends two policies to near-RT RIC as shown in Fig. 5.4-2. The
first policy steers voice services to be served by cell B, whereas the second
policy is for MBB service, which states, that UE shall avoid cells B and A, and
it should prefer cells C and D (which are dedicated for MBB).

Fig. 5.4-2. Example policies at A1 interface for the considered scenario

34 www.rimedolabs.com
The O -RAN Whitepaper 2021 5.0 O -RAN Use Cases: Traffic Steering

Fig. 5.4-3. near-RT RIC operation for the considered scenario

After receiving the messages, the near-RT RIC needs to locate that UE and
enforce the assigned policy, by telling the base station to execute specific
RRC commands (like handover, relocation, SCG addition/change, etc.) as
shown in Fig. 5.4-3. The control messages are as follows:

» perform handover to cell B, which becomes then PCell and handles CP

traffic;

» add cell A to the Carrier Aggregation set for voice service;

» add secondary gNB (SCG) to be used for handling MBB service.

At the end of the operation, the UE has connections to two BSs and has
each service being delivered to it from different cells.

35 www.rimedolabs.com
The O -RAN Whitepaper 2021 Summar y & conclusions

Summary &
Conclusions
Open RAN solves several problems that have long-
plagued mobile Telecoms. For this reason alone,
it has a great potential for growth and success.

36 www.rimedolabs.com
The O -RAN Whitepaper 2021 Summar y & conclusions

In this whitepaper, we provided an introduction to O-RAN, where we set up

the scene and showed basics like characteristics of O-RAN, the basic build-
ing blocks as well as entities involved in the development of this concept.

Later, in chapter 3.0 we discussed the nodes and interfaces defined by

O-RAN Alliance. The provided implementation options visualize one of the
benefits of O-RAN, namely the implementation flexibility with the open
O-RAN architecture. On the one hand, those options provide the flexibility
in implementation and various vendor configurations, but the price to pay
for this variety is that you need a way to identify the internal nodes that you
want to control, i.e. it requires the E2 and O1 interface to be able to capture all
those different options and encapsulate control elements e.g., for O-DU only.

near-RT RIC is one of the key elements in the O-RAN architecture, which al-
lows feeding an “external” intelligence into the operations of the radio net-
work. It creates a platform to which the vendors (either software vendors, or
Telco vendors, or xApp developers) could provide per-use case RRM algo-
rithms to allow adaptation/optimization radio resources usage for specific
scenarios. It will be interesting to see how the creation of the ecosystem for
those applications will play out. Will there be Google Plays and xApp Stores
for the Telco world?

The final chapter 5.0 closes the bracket of our O-RAN discussion concern-
ing the architecture, design, and application scenarios. We went from the
overall description of use cases as per O-RAN Alliance specifications final-
ized by showing a particular example of Traffic Steering. Each of the use
cases described in the first part of chapter 5.0 is detailed in [15] with similar
elaboration. Traffic Steering, discussed in this chapter is an important el-
ement of the current mobile systems due to the multitude of options for
cell assignment and multi-node transmission, and as such is addressed by
O-RAN Alliance in the so-called “Phase I”.

» adding intelligence to network with external entities, namely xApps and

The conclusions both RICs;
taken from this use » control of RAN behavior by declarative policies;
case elaboration » combination of various applications (like xApps/rApps) to realize certain
of using O-RAN are objectives of network performance optimization;

that it allows: » a hierarchical and modular approach to resource management;

» defining RRM applications (xApps) on per use case basis.

37 www.rimedolabs.com
The O -RAN Whitepaper 2021 References

References

[1] O-RAN ALLIANCE (o-ran.org)

[2] 3GPP

[3] Open Networking Foundation

[4] SD-RAN – Open Networking Foundation

[5] Telecom Infra Project | Global Community Connectivity collaboration

[6] OpenRAN – Telecom Infra Project

[7] Home – Open RAN Policy Coalition

[8] O-RAN Software Community

[9] O-RAN Virtual Exhibition

[10] Open RAN Small Cell Forum

[11] O-RAN.WG1.O RAN Architecture Description v03.00, “O-RAN Architecture

Description”, O-RAN Alliance, November 2020

[12] O-RAN ALLIANCE Introduces Minimum Viable Plan Towards Commercial O-RAN
Solutions and 28 New O-RAN Specifications Released Since November 2020

[13] O-RAN.WG3.RICARCH-v01.01, “Near-Real-time RAN Intelligent Controller

(Near-RT RIC) Architecture”, O-RAN Alliance, November 2020

[14] ORAN-WG3.E2SM-KPM-v01.00.00, “O-RAN Near-Real-time RAN Intelligent

Controller E2 Service Model (E2SM) KPM”, O-RAN Alliance, February 2020

[15] O-RAN.WG2.Use-Case-Requirements-v02.01, “Non-RT RIC & A1 Interface:

Use Cases and Requirements”, O-RAN Alliance, Nov. 2020

[16] “O-RAN Use Cases and Deployment Scenarios”, O-RAN Alliance Whitepaper

38 www.rimedolabs.com
The O -RAN Whitepaper 2021 Glossar y

Glossary

5GC 5G Core Network O-RAN Open RAN

5QI 5G QoS Indicator O-RU O-RAN Radio Unit

AMF Access and Mobility Function OSC O-RAN Software Community

API Application Programming Interface PDCP Packet Data Convergence Protocol

CA Cell Association PHY Physical Layer

CN Core Network PM Performance Measurements

CP Control Plane QoS Quality of Service

CU Central Unit R/W Read/Write

D/A Digital to analog RA Resource Allocation

DU Distributed Unit RAN Radio Access Network

FCAPS Fault, Configuration, Accounting, RFE Radio Front-End

Performance, Security
RIC RAN Intelligent Controller
FH Fronthaul
RLC Radio Link Control
gNB next-generation NodeB
RRC Radio Resource Control
I/F Interface
RRM Radio Resource Management
LLS Lower-Layer Split
RT Real-Time
MAC Medium Access Control
RU Remote/Radio-Unit
MANO Management and Orchestration
SDAP Service Data Adaptation Protocol
MBB Mobile Broadband
SD-RAN Software Defined RAN
Mgmt Management
SM Spectrum Management
ML Machine Learning
SMO Service Management and Orchestration
NG-RAN Next Generation RAN
S-NSSAI Single - Network Slice Selection
nRT near Real-Time Assistance ID

O-CU-CP O-RAN Central Unit Control Plane SON Self-Organizing Networks

O-CU-UP O-RAN Central Unit User Plane TS Traffic Steering

O-DU O-RAN Distributed Unit UE User Equipment

O-eNB O-RAN evolved NodeB UPF User Plane Function

ONF Open Networking Foundation xApp Application to be placed at nRT RIC

39 www.rimedolabs.com
The O -RAN Whitepaper 2021 About the Authors

About the Authors

Marcin Dryjański, Ph.D.

Principal Consultant / CEO

Marcin Dryjanski received his Ph.D. (with distinction) from the Poznan Uni-
versity of Technology in September 2019. Over the past 12 years, Marcin
served as an R&D engineer and consultant, technical trainer, technical
leader, advisor, and board member. Marcin has been involved in 5G design
since 2012 when he was a work-package leader in the FP7 5GNOW project.
Since 2018, he is a Senior IEEE Member. He is a co-author of many articles
on 5G and LTE-Advanced Pro and a co-author of the book „From LTE to
LTE-Advanced Pro and 5G” (M. Rahnema, M. Dryjanski, Artech House 2017).
From October 2014 to October 2017, he was an external advisor at Huawei
Technologies Sweden AB, working on algorithms and architecture of the
RAN network for LTE-Advanced Pro and 5G systems. Marcin is co-founder
of Grandmetric, where he served as a board member and wireless ar-
chitect between 2015 and 2020. Currently, he serves as CEO and principal
consultant at Rimedo Labs.

You can reach Marcin at marcin.dryjanski@rimedolabs.com

Russell Lundberg
Consultant & Senior Manager, USA

Russell Lundberg has 30+ years of experience working in mobile technology

for MNOs around the world, specializing in greenfield buildouts, quality of
service, cost-effective operations, 5G, and OpenRAN.

Presently Russell is Principal at Intelefy LLC, consulting to Mobile Network Op-

erators and others interested in wireless technologies. He also helps Tele-
com Pros develop their careers through outreach, education, and mentor-
ship. Intelefy has hosted over 10,000 Telecom Pros in their training webinars.
At Rimedo Labs, Russell serves as an Advisory Board Member.

40 www.rimedolabs.com
The O -RAN Whitepaper 2021 About Rimedo Labs

About
Rimedo Labs
Rimedo Labs specializes in providing
high quality consulting, implementation
and R&D services in the field of modern
wireless systems.

We implement this through an individual and open approach to the client,

constantly improving the team operationally and substantively, updating
knowledge and a unique combination of science and business applica-
tions. Rimedo Labs is a spin-off from the Poznan University of Technology,
Poland from the Institute of Radiocommunications.

To read more about us, check out our website: www.rimedolabs.com/about/

41 www.rimedolabs.com
The O -RAN Whitepaper 2021 About Rimedo Labs

Our Services

Applied Research
As a spin-off from Poznan University of Technology we aim at translating
the fundamental research onto applied science and commercialize the
ideas coming from scientific background. The areas of our specialization
cover wireless systems (like LTE, 5G, 6G, IoT, Wi-Fi), spectrum sharing and
management, radio resource management, AI for wireless systems and
private mobile networks. We offer our expertize as part of consortiums for
EU and National funded projects (like Horizon 2020, Horizon Europe, NCBR,
etc.). We can take part in those projects as leader, partner or subcontractor.

Consulting
Having extensive experience in the field of modern wireless systems we
offer high quality consulting and advisory services delivered by our sea-
soned engineers and consultants. Rimedo Labs Consulting include cover,
among others the following items: radio planning and site surveys, tech-
nology forecasting, preparation of feasibility studies, systems architecting,
wireless systems patent analysis, standards tracking, or expert/R&D team
outsourcing.

Training
Our training services include online and on-site courses, conferences,
meetups or workshops tailored to customer’s needs and requirements. The
topics, which are covered by us include: 4G, 5G and beyond, IoT, Wi-Fi, spec-
trum management, radio resource management, private networks, design,
planning and troubleshooting of wireless systems, artificial inteligence for
wireless systems. Our top-class instructors combine scientific and educa-
tional backround with practical experience. We speak about the systems
we design.

Technical Content Delivery

We provide technical contents for external training or consultancy com-
panies delivered as training materials, technical documents, dedicated re-
search papers or reports. The material can be developed as insights onto
a specific feature or aspect within wireless systems area, including topics
like: LTE, 5G and beyond, Wi-Fi, IoT, shared spectrum, AI, etc. The outcome
can be final products like books, book chapters, slides, whitepapers as well
as raw materials for further processing. Other set of materials include con-
tents for blogs and whitepapers and dedicated reports from the R&D works
and practical cases encountered in our daily work. The educational con-
tent, can be also delivered in the form of virtual radio labs.

42 www.rimedolabs.com
The O -RAN Whitepaper 2021 About Rimedo Labs

More Resources

Read more on Rimedo Labs Blog

RIMEDO Labs Get the latest updates on all things wireless including
Blog 5G, 6G, O-RAN, Telecom Trends.

Rimedo Labs joins the ONF to collaborate

on the O-RAN compliant RIC
Check out our press release on joining SD-RAN project at Open Net-
working Foundation.

O-RAN Architecture & Use Cases Webinar

Watch 1-hour long video explaining the basics and details of O-RAN.

O-RAN Architecture and Use Cases poster

Subscribe to our newsletter and download an easy-to-print A3-size
poster.

43 www.rimedolabs.com
Let's keep in touch!

info@rimedolabs.com
+48 (61) 665 38 17

RIMEDO sp. z o.o.

ul. Polanka 3
61-131 Poznan Poland, EU

www.rimedolabs.com

All information discussed in the document is provided "as is" and Rimedo
Labs makes no warranty that this information is fit for purpose. Users use
this information at their own risk and responsibility.

© 2021 Rimedo sp. z o.o. All rights reserved.