OPENAIRINTERFACE SIMULATOR/EMULATOR

Navid Nikaein

July 23, 2015

AUTHOR ’ S A DDRESS :
Navid Nikaein
Eurecom
Mobile Communication Department
Campus SophiaTech
450 Route des Chappes
06410 Biot Sophia Antipolis – France
Email: navid.nikaein@eurecom.fr
URL: http://www.eurecom.fr/˜nikaeinn
Contents

1 OpenAirInterface : An Open Cellular Ecosystem 3

1.1 Software Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Hardware Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Build-in Emulation Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Experiment Design Workflow . . . . . . . . . . . . . . . . . . . . . . 8
1.3.2 Discrete Event Generator . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.3 Protocol Vectorization and Emulation Data Transport . . . . . . . . . . 12
1.3.4 PHY Abstraction [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Comparison of OAI with Other Platforms and Approaches . . . . . . . . . . . 15
1.5 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Bibliography 22

List of Tables 25

List of Figures 27
2 CONTENTS
Chapter 1

OpenAirInterface : An Open Cellular

Ecosystem

This docuement presents OpenAirInterface (OAI) wireless technology platform as a suitably

flexible platform towards an open LTE ecosystem. The platform offers an open-source software-
based implementation of the LTE system spanning the full protocol stack of 3GPP standard
both in E-UTRAN and EPC [2–4]. It can be used to build and customized an LTE base station
and core network on a PC and connect a commercial UEs to test different configurations and
network setups and monitor the network and mobile device in real-time. OAI is based on a PC
hosted software radio frontend architecture. With OAI, the transceiver functionality is realized
via a software radio front end connected to a host computer for processing. This approach is
similar to other software-defined radio (SDR) prototyping platforms in the wireless network-
ing research community such as SORA [5]. Other similar approaches combining PCs and
FPGA-based processing make use of NI LabVIEW software [6] or using the WARP [7] archi-
tecture. To our best knowledge, OpenAirInterface is the only fully x86-based SDR solution in
open-source, providing both UE, eNB, and core-network functionality. A similar closed-source
development commercialized by Amarisoft (LTE 100) which targets several USRP platforms
provides eNB and core-network functionality on standard Linux-based PCs [8]. OAI is written
in standard C for several real-time Linux variants optimized for x86 and released as free soft-
ware under the terms of version 3 of the GNU General Public License (GPLv3). OAI provides
a rich development environment with a rang of build-in tools such as highly realistic emula-
tion modes, soft monitoring and debugging tools, protocol analyzer, performance profiler, and
configurable logging system for all layers and channels.
Towards building an open cellular ecosystem for flexible and low-cost 4G deployment and
experimentations, OAI aims at the following objectives:

• Open and integrated development environment under the control of the experimenters;
• Fully software-based network functions offering flexibility to architect, instantiate, and
reconfigure the network components (at the edge, core, or cloud using the same or dif-
ferent addressing space);
• Playground for commercial handsets as well as application, service, and content providers;
• Rapid prototyping of 3GPP compliant and non-compliant use-cases as well as new con-
cepts towards 5G systems ranging from M2M/IoT and software-defined networking to
4 Chapter 1. OpenAirInterface : An Open Cellular Ecosystem

cloud-RAN and massive MIMO.

1.1 Software Platform

Currently, the OAI platform includes a full software implementation of 4th generation mobile
cellular systems compliant with 3GPP LTE standards in C under real-time Linux optimized for
x86. At the Physical layer, it provides the following features:

• LTE release 8.6 compliant, with a subset of release 10;

• FDD and TDD configurations in 5, 10, and 20 MHz bandwidth;
• Transmission mode: 1 (SISO), and 2, 4, 5, and 6 (MIMO 2x2);
• CQI/PMI reporting;
• All DL channels are supported: PSS, SSS, PBCH, PCFICH, PHICH, PDCCH, PDSCH,
PMCH;
• All UL channels are supported: PRACH, PUSCH, PUCCH, SRS, DRS;
• HARQ support (UL and DL);
• Highly optimized base band processing (including turbo decoder). With AVX2 optimiza-
tion, a full software solution would fit with an average of 1x86 core per eNB instance
(64QAM in downlink, 16QAM in uplink, 20MHz, SISO).

For the E-UTRAN protocol stack, it provides:

• LTE release 8.6 compliant and a subset of release 10 features;

• Implements the MAC, RLC, PDCP and RRC layers;
• protocol service for all Rel8 Channels and Rel10 eMBMS (MCH, MCCH, MTCH) [9];
• Channel-aware proportional fair scheduling [10, 11];
• Fully reconfigurable protocol stack;
• Integrity check and encryption using the AES and Sonw3G algorithms;
• Support of RRC measurement with measurement gap;
• Standard S1AP and GTP-U interfaces to the Core Network;
• IPv4 and IPv6 support.

Evolved packet core network features:

• MME, SGW, PGW and HSS implementations. OAI reuses standards compliant stacks of
GTPv1u and GTPv2c application protocols from the open-source software implementa-
tion of EPC called nwEPC [12];
• NAS integrity and encryption using the AES and Snow3G algorithms;
• UE procedures handling: attach, authentication, service access, radio bearer establish-
ment;
• Transparent access to the IP network (no external Serving Gateway nor PDN Gateway
are necessary). Configurable access point name, IP range, DNS and E-RAB QoS;
• IPv4 and IPv6 support.
1.2 Hardware Platform 5

IP packets AT commands Management (OSS)

MME Application S+P-GW Application

Linux IP
NAS eNB Application NAS HSS S11 S1-U
stack

RRC RRC S1-MME X2AP S1-U S1-MME S6a/Diameter GTP-U SGi

PDCP PDCP SCTP UDP SCTP UDP

RLC RLC IP IP

MAC MAC Ethernet Ethernet

PHY PHY

OAI soft UE OAI soft eNB OAI soft EPC (MME and S+P-GW

3GPP layers Linux stack Data Plane Control Plane

Figure 1.1: OpenAirInterface LTE software stack.

Figure 1.1 shows a schematic of the implemented LTE protocol stack in OAI. OAI can
be used in the context of a rich software development environment including Aeroflex-Geisler
LEON / GRLIB, RTOS either RTAI or RT-PREEMPT, Linux, GNU, Wireshark, control and
monitoring tools, message and time analyser, low level loggin system, traffic generator, pro-
filing tools and soft scope. It also provide tools for protocol validation, performance evalu-
ation and pre-deployment system test. Several interoperability tests have been successfully
performed with the commercial LTE-enabled mobile devices, namely Huawei E392, E398u-1,
Bandrich 500 as well as with commercial 3rd party EPC prototypes. OAI platform can be used
in several different configurations involving commercial components to varying degrees:

• OAI UE ↔ OAI eNB + OAI EPC

• OAI UE ↔ OAI eNB + Commercial EPC
• OAI UE ↔ Commercial eNB + OAI EPC
• OAI UE ↔ Commercial eNB + Commercial EPC
• Commercial UE ↔ Commercial eNB + OAI EPC
• Commercial UE ↔ OAI eNB + Commercial EPC
• Commercial UE ↔ OAI eNB + OAI EPC

1.2 Hardware Platform

For real-world experimentation and validation, the default software radio frontend for OAI is
ExpressMIMO2 PCI Express (PCIe) board. This board features a LEON3 embedded system
based on Spartan 6 LX150T FPGA as well as 4 high-quality RF chipsets from Lime Micro
Systems (LMS6002), which are LTE-grade MIMO RF front-ends for small cell eNBs. It sup-
ports stand-alone operation at low-power levels (maximum 0 dBm transmit power per channel)
simply by connecting an antenna to the board. External RF for high-power and TDD/FDD
duplexing can be connected to ExpressMIMO2 depending on the deployment scenario. RF
equipment can be configured for both TDD or FDD operation with channel bandwidths up to
20 MHz covering a very large part of the available RF spectrum (250 MHz-3.8 GHz) and a
subset of LTE MIMO transmission modes. ExpressMIMO2 boards are reasonably-priced and
6 Chapter 1. OpenAirInterface : An Open Cellular Ecosystem

completely open (GNU GPL), both at the hardware and software level. Figure 1.2 shows the
ExpressMIMO2 hardware platform.

RF RX
(4 way)

RF TX
(4 way)

PCIe (1 or 4 way)
4xLMS6002D RF ASICs GPIO for external Spartan 6 LX150T 12V from ATX
250 MHz – 3.8 GHz RF control power supply

Figure 1.2: OAI ExpressMIMO2 hardware platform.

The embedded software for the FPGA is booted via the PC or can reside entirely in the boot
ROM which is part of the FPGA design (c.f. Fig. 1.3). In the current design, the embedded
software is booted by PCIexpress dynamically under control of the PC device driver. The basic
design does not include any on-FPGA signal processing and consumes approximately 10-15%
of the FPGA resources. There is significant room left for additional processing on the FPGA,
for instance Xilinx FFT processors to offload some processing from the host PC if required.
To enhance the current design in the FPGA, every newly added block should have an AHB
bus interface. The LEON3 processor is easily configured in order to interact with every block
connected to the AHB bus. The PCI express controller block has been optimized in order to
support the transfer of samples between the ExpressMIMO2 card and the PC at a rate that
can goes up to 30.72 Msamples/s in both directions, while using only a one-lane PCI Express
interface.
As shown in Fig. 1.3, there is a direct bus between the ADC/DAC and AHB PCIe interfaces
to avoid the AHB protocol delay for DMA and as a results improve the transfer rate between
the two blocks without passing through AHB and Leon3. All the DMA transfers are done
through a shared allocated memory in the PC between the card and the user application. This
shared memory has the size of one LTE frame (10 ms). There are also some shared allocated
structures which allows to easily configure the card to the desired mode. The interface between
the user application and the card is a command based interface. The Leon3 processor reads
the commands written by the driver in a dedicated register in the PCI Express controller and
executes the corresponding instructions. Although the role of the integrated Leon3 processor
is very limited and consists only on configuring the RF chips and executing the DMA transfers
between the card and the PC, it is easily reconfigured to add new functionality because the
firmware that runs on top of it is dynamically uploaded from the PC.
Besides ExpressMIMO2, OAI now supports the UHD interface on recent USRP PC-hosted
1.3 Build-in Emulation Platform 7

Spartan 6 AHB ROM

Leon 3
AHB Controller AHB RAM
uProcessor

Master/ Master
Slave

AHB Bus
Master/
Slave

ADC/DAC Interface &

I/O TX and Rx Buffers Direct Bus AHB PCIe
(Lime)
DMA

GTP3 GTP2 GTP1 GTP0

Control
L7 L6 L5 L4 L3 L2 L1 L0

PCIe Connectors

Figure 1.3: ExpressMIMO2 FPGA design.

software radio platforms which are widely used in the research community. Specifically, Ag-
ilent China has recently succeeded in interconnecting the OpenAirInterface softmodem soft-
ware with a USRP B210 platform [13, 14]. This development is now delivered as part of the
publicly-available software package from the OAI website and SVN server [2]. EURECOM
will continue to maintain this development and extend to X300 (USRP-Rio) family products.
This achievement illustrates the validity of the standard PC plus generic SDR frontend approach
taken in OAI since the code has been independently ported successfully on a totally different
hardware target.

1.3 Build-in Emulation Platform

Apart from real-time operation of the software modem on the hardware targets described above,
the full protocol stack can be run in a controlled laboratory environment for realistic system val-
idation and performance evaluation (see Fig. 1.4) [15]. The platform is designed to represent
the behavior of the wireless access technology in a real network setting, while obeying the tem-
poral frame parameters of the air-interface. The behavior of the wireless medium is obtained
(a) using a PHY abstraction unit which simulates the error events in the channel decoder, and
(b) using (real) channel convolution with the PHY signal in real-time. The platform can be run
either with the full PHY layer or with PHY abstraction. The remainder of the protocol stack for
each node instance uses the same implementation, as would be in the full system. Each node
has its own IP interface that can be connected either to a real application or a traffic generator.
The emulator also implements the 3GPP channel models comprising three components, path
loss, shadow fading and stochastic small scale fading, and interacts with the mobility generator
to perform different channel realization over time with interference. The platform targets large-
8 Chapter 1. OpenAirInterface : An Open Cellular Ecosystem

scale repeatable experimentation in a controlled laboratory environment with various realistic

test-cases and can be used for integration, performance evaluation and testing.

ATTACHED
UEn
Web Portal CONNECTED
Scenario eNB0
SYNCHED
Descriptor Dispatcher
NOT SYNCHED
Console Results
UE0 UE1

External External
OAI Emulator

Path Loss

Small Scale Fading

Large Scale Fading

Application Traffic Gen
Channel Model
Channel Model
Channel Model

Packet Tracer L3 Protocols Config Gen.

Log Gen. Network Interface Traffic Gen.
L2 Protocols
Channel Descriptor Mobility Gen
Message Seq. PHY Procedures Mobility Gen.
PHY Abstraction
Result Gen. Channel Gen. Channel Trace EMOS
Emulation Medium

Figure 1.4: Built-in Emulation Platform.

The OAI emulation platform is based on a hybrid discrete event generator in that it handles
periodic and user-defined events in a timely manner, preserving reproducibility, scalability, and
applicability properties. It supports large number of users/connections per cell with PHY ab-
straction module and up to few users with full PHY under the same addressing space. Channel
is described using a channel model, path loss, and node positions, and realized with the a pre-
defined granularity (e.g. slot, subframe, frame). The supported channel models are AWGN,
SCM A, SCM B, SCM C, SCM D,EPA, EVA, ETU, Rayleigh with 1 to 8 delay taps, Rice
with 1 to 8 delay taps. Node positions are provided by the mobility generator module, which
supports different mobility models, including STATIC, RWP, RWALK, Trace-based, steady-
state RWP, and connection domain mobility model. Different traffic patterns are available for
each node including voice, video, (background) data, chat/messaging, online gaming traffics as
well as machine-type communication ranging from a simple sensing device (e.g. smoke, tem-
perature sensor) to complex real-time application scenarios (e.g. embedded automatic driving
system in a vehicle) [16]. Traffic pattern can be also customized in terms of packet size, packet
inter-arrival time, traffic state, and session duration. Both packet size and inter-arrival time
processes are modelled as i.i.d. series of random variables that can follow different distribu-
tions (e.g. uniform, Poisson, Parteo). Each node can generate multiple traffic patterns and each
generated traffic type can be mapped into a logical channel allowing a specific treatment and
QoS to be applied. Different key performance indicators (KPI) can be measured, namely (i)
one-way delay, (ii) jitter of one-way-delay, (ii) Delay variation, (iv) loss rate, and (v) number
of connected users.
The following subsections presents the OAI top-level experiment workflow, and provides
further details about the three main design principles of the emulation platform.
1.3 Build-in Emulation Platform 9

1.3.1 Experiment Design Workflow

A sequential experiment workflow, where the output of each step will be the input of the next,
is employed to allow an experiment to be reproduced. Five consecutive steps are defined:
scenario description, configuration, execution, monitoring, analysis, where each step is split
into several sub-steps as explained in the following subsections (see Figure 1.5.

Scenario Description
Environment/System Network Topology Application EMU IO Parameters

Models & Configuration

Network Interface Traffic/Mobility Protocol Stack PHY/RF Abstraction

Execution
Debug Mode Soft Realtime Mode Hard Realtime Mode

Monitoring
Logs and Stats Wireshark Signal Analyzer Timing analyzer

Analysis
Performance Evaluation Protocol Validation System Testing

Figure 1.5: Experiment design workflow

Scenario Description

A scenario has four main elements described in xml format, namely (1) system/environment,
where system (e.g. bandwidth, frequency, antenna) and environment (e.g. pathloss and channel
models) parameters are defined; (2) network topology, where network area, network topology
(i.e. cellular, mesh), nodes’ type, initial distribution, and mobility model (e.g. static, random
way point, random walk, trace-based, steady-state random way point, and connected domain
mobilities) are set; (3) application where real application and/or emulated traffic pattern in
terms of packet size and inter-departure time are defined; (4) EMU IO Parameters, where su-
pervised parameters (e.g. emulation time, seed, performance metrics) and analysis method (e.g.
protocol PDUs and operation) are set.

Configuration

This step defines a sequence of components’ initialization based on the scenario description.
It includes four sub-steps: (1) network interface, where the OAI IP interface is configured, (2)
traffic and mobility, where traffic pattern and mobility model parameters are set, (3) protocol
stack, where protocols are configured given the network topology and PHY abstraction, where
a channel model predicting the modem performance is configure.
 10 Chapter 1. OpenAirInterface : An Open Cellular Ecosystem

Execution

This step defines the execution environment for the emulator in order to synchronize the em-
ulated nodes and run the experimentation. It includes four execution modes: (1) debug mode,
where the emulation is executed in user space without any Linux IP connectivity, (2) soft real-
time mode, where the emulation has the IP connectivity and calibrated to respect the layer 2
frame timing on average, and (3) hard real-time mode, where the emulation is executed in real-
time/low-latency kernel with Linux IP protocol stack respecting layer 2 frame timing strictly.

Monitoring

This step defines how the experiment is monitored (passive and/or active). It includes: (1)
logs and stats, where experiment traces and logs are collected, labelled and archived for post-
processing, and online control and data place status are available to the experimenter (2) packet
traces, where protocol control- and data-place signalling is captured and stored during the ex-
periment.

Analysis

This step processes raw data and produces results and statistics. It includes three -non exclusive-
analysis objectives: (1) performances evaluation, where the key performance indicators are
measured and evaluated, (2) protocol validation, where the protocol control- and user-plane
signalling are validated versus protocol specification, and (3) system testing, where the system
as a whole is analysed and tested.

1.3.2 Discrete Event Generator

The discrete event generator (DEG) is one of the main building block of simulation/emulations
allowing high-level control over a user experiments. This is important to meet different experi-
ment requirements and use cases, in particular when targeting large scale scenarios. They allow
simulation/emulation configuration and monitoring as well as scheduling user-defined events
over time and space. A typical DEG consists of an event producer, an event list, a scheduler,
and an event consumer. A simplified DEG implementation in OAI is shown in Listing 1.1.
1
2 s t a t i c v o i d m y f u n c t i o n ( Model ∗ model ) {
3 //
4 }
5
6 i n t main ( ) {
7 mod model ;
8 ev e v e n t ;
9 i n i t i a l i z e (&mod,& ev ) ;
10 c o n f i g u r e (&mod,& ev ) ;
11 s c h e d u l e e v e n t ( e v op , e v t y p e , t i m e , &my func , &mod ) ;
12 ...
13 s c h e d u l e e n d s i m u ( ev ) ;
 1.3 Build-in Emulation Platform 11

14 run ( ) ;
15 release () ;
16 return 0;
17 }
18
19 void run ( ) {
20 while ( ! end of simulation ( ) ) {
21 time= get timestamp ( ) ;
22 / / u s e r −d e f i n e d e v e n t s
23 w h i l e ( ( ev = e v e n t l i s t g e t h e a d (& g l o b a l e v e n t l i s t ) ) ! = NULL) {
24 i f ( ev . t i m e == t i m e )
25 e x e c u t e ( ev ) ;
26 }
27 / / execute periodic events
28 process subframe ( time ) ;
29 }
30 }
Listing 1.1: Example of discrete event generator

In OAI, the emulation events are divided into two types. Periodic events are those events
occurring at each period and must be executed in the current timestamp (e.g. MAC/PHY sub-
frame processing). These events are not queued and does not interfere with the simulation
logic and user-defined events. The second type is the user-defined events, which are happening
in a specific emulation time and mainly relates to the modifications of the model, reconfigu-
ration, or changes in the state of a simulation/emulation entity. These events are stored in a
timely-ordered event list.
Fig. 1.6 illustrate main components of DEG in OAI. It can be seen that there is top level
emulation scheduler that controls the emulation progress and coordinates the execution of all
the components. DEG interacts with the emulation scheduler through two components, event
scheduler (or producer) used to add the user-defined events to the list, and event handler (or
consumer) to retrieve the event corresponding to the current time and remove it from the list.
Then, the emulator scheduler proceeds with the execution of the user-defined events followed
by the periodic events.

1.3.3 Protocol Vectorization and Emulation Data Transport

OAI provides vectorization (or virtualization) of the entire protocol stack within the same phys-
ical machine to increase the scalability of the emulation platform (c.f. Fig. 1.7). Protocol vec-
torization consists of sharing the same operating system instance and Linux IP protocol stack
for independent emulated node instances. It allows networks nodes to coexist in the same ex-
ecution environment. Note that, protocol virtualization offers the same functional properties
(i.e. services) and the same non functional properties (i.e. performances) than that of a real
protocol.
To further increase the platform scalability and allow complex network experimentation,
two or more emulated data flows may coexist between emulated nodes as shown in Fig. 1.7.
Either nodes communicate via direct memory transfer (shared memory) or via IP multicast
(over Ethernet) depending on whether they are part of the same physical machine or not. From
12 Chapter 1. OpenAirInterface : An Open Cellular Ecosystem

Emulation
Emulation Scheduler

DEG
Event Handler Event Scheduler
(consumer) (producer)

remove add

EVi EVj EVn

User Event List
t=200ms t=500ms ... t=900ms

Periodic Periodic Periodic

EV1 EV2 ... EVm

Figure 1.6: Discrete event generator of OAI emulation.

the point of view of the protocol stack, the data flow is transparent and that the network con-
nectivity is independent from the node distribution on a physical machine.

Real Application Server

Emulated or Real Network

Real Application Client Real Application Client

…
Physical Machine 0 Physical Machine k
Inst0 Inst0
Network Interface Network Interface

Real Protocol Stack Real Protocol Stack

Channel realization Channel realization
PHY/RF Abstract PHY/RF Abstract
Shared memory Emulation Medium
Shared memory Emulation Medium

Inst1 Inst K Inst1 Inst K

Traffic/Mobility Traffic/Mobility Traffic/Mobility Traffic/Mobility

Real Protocol Stack … Real Protocol Stack Real Protocol Stack … Real Protocol Stack

PHY/RF Abstract PHY/RF Abstract PHY/RF Abstract PHY/RF Abstract

Emulation Medium Emulation Medium Emulation Medium Emulation Medium

Shared Kernel (Host+ virtual instances) Shared Kernel (Host+ virtual instances)

Emulated data transport

through IP Multicast

Figure 1.7: Protocol vectorization and complex network experimentation based on the OAI emulation-
platform.
1.3 Build-in Emulation Platform 13

1.3.4 PHY Abstraction [1]

It was found with the help of profiling in OAI system-level emulator that for any kind of emu-
lation more than 75% of the total simulation time and resources were spent only on the mod-
ulation, demodulation, coding, decoding and the convolution of the channel with the signal at
the physical layer. This is a huge overhead in terms of complexity and time duration of system
level evaluations. Therefore, to reduce the complexity and duration of system level evaluations
a new interface is needed to replace the actual physical layer computations and provides the
higher layers with necessary and accurate link quality metric, i.e., block error rate (BLER) or
packet error rate (PER).
The use of PHY abstraction in system evaluations should provide three main benefits as
follows:

1. Low complexity and speed by replacing the complete physical layer processing with a
rather simple calculations using table look ups,

2. Scalability by making it possible to evaluate huge systems with hundreds of nodes,

3. Realism by providing the true link quality metric as it would have obtained with full
PHY processing.

PHY abstraction, also referred to as link-to-system mapping and link prediction, provides
such an interface between system level simulators and link level simulators for the large scale
system simulations. This interface is normally a metric representing the quality of an instan-
taneous physical link (channel) between the eNodeB and the connected UEs by taking into
account other important parameters of the system. These parameters as shown in Fig. 1.8 may
include the knowledge about power and resource allocation to the specific UE, number of spa-
tial layers, modulation and coding scheme (MCS), and mainly channel characteristics such as
path loss, shadowing, fading, and interference.

Figure 1.8: Link Abstraction in System Performance Evaluation.

PHY abstraction is rather trivial for the frequency flat channels as the simple averaging of
channel qualities is sufficient for link quality mapping but for highly frequency selective chan-
14 Chapter 1. OpenAirInterface : An Open Cellular Ecosystem

nels the performance evaluation is not that trivial. This is mainly because of the smaller coher-
ence bandwidth than that of the signal bandwidth giving rise to the multi-state channel at the
receiver. However to address this issue many link abstraction techniques have been proposed
in the literature for these multi-state channels [1]. OpenAirInterface apply the methodology of
expected effective SINR mapping (EESM) based PHY abstraction [17, 18].
In OpenAirInterface the required parameters for large scale system simulations are highly
dynamic and can be generated either by the specialized tools already included in the emulator,
such as openair traffic generator (OTG) and openair mobility generator (OMG), or these pa-
rameters can be specified explicitly in great details for the specific scenarios and evaluations.
The use of PHY abstraction in OpenAirInterface system-level emulator is explained in Fig. 1.9.

L3 Protocols
OAI Network Interface
Channel Model

L2 Protocols
PHY Procedures Uncoded msg
Path Loss

PHY Abstraction
F(SNR, MCS)=P(BLER)

Same IF
Channel L3 Protocols
Mobility Gen Channel Descriptor Realization: OAI Network Interface
ENB2UE L2 Protocols
UE2ENB PHY Procedures
EMOS Channel Trace
Coding Decoding Uncoded msg

Mod. Demod.
PHY Signal
Same IF as
Parameterization with RF
Convolution

Processing 3

Figure 1.9: PHY Abstraction in System Performance Evaluation in OpenAirInterface

It can be seen from the Fig. 1.9 that there are two important steps in any evaluation us-
ing OpenAirInterface, parameterization and processing. It is important to note that parame-
terization is independent of the knowledge about the PHY abstraction. The output (channel
realizations) from parameterization step is given to the processing where the comparison be-
tween using the full PHY and PHY abstraction is shown. It can be seen that in the case of
PHY abstraction there is no coding, decoding or other complex operations involved from the
transceiver chain at the physical layer (L1) only. The main purpose of the physical layer is to
inform the higher layers about the status of the decodability of data packet. If the decoding
is successful then the higher layers are notified about it. However in the case of using PHY
abstraction this is achieved by predicting a link quality metric in terms of block error probabil-
ity from the instantaneous channel realizations across all of the subcarriers. After the BLER
is calculated using PHY abstraction, a random number between 0 and 1 is generated which is
compared with this BLER for taking the decision on the successful or unsuccessful transmis-
1.3 Build-in Emulation Platform 15

Table 1.1: S IMULATION TIMES DIFFERENT TRANSMISSION M ODES

Time in minutes and seconds

Full PHY PHY Abstraction
Total time 2m26.602s 0m6.794s
TM 1
user CPU time 2m25.633s 0m6.480s
system CPU time 0m0.924s 0m0.328s
Total time 4m1.607s 0m9.085s
TM 2
user CPU time 3m59.079s 0m8.753s
system CPU time 0m1.940s 0m0.364s
Total time 2m19.320s 0m7.027s
TM 6
user CPU time 2m18.473s 0m6.752s
system CPU time 0m0.824s 0m0.300s

sion. Then the outcome of this probabilistic experiment is passed to the higher layers which
perform their tasks independent of the knowledge about the PHY abstraction.
To illustrate the speedup factor, system level simulations for different transmission modes
both with full PHY and PHY abstraction. The underlying scenario consists of a system with
one eNodeB and two UEs, 500 frames, and full buffer in downlink. In the comparison, only
downlink abstraction is considered.
During the simulations the accumulated averaged throughput of system over given number
of frames and also the execution time for the simulation are calculated. To show that using
PHY abstraction is less complex and it speeds up the evaluation process, execution time for
system simulations of same scenarios with full PHY and PHY abstraction are measured. It is
found that simulations with abstraction took extremely short time than that of with full PHY.
The calculated speedup factor for PHY abstraction was found to be around 30 when compared
to the time for full PHY. Table 1.1 shows the execution time for the simulation and it is clear
from the results that PHY abstraction speeds up the process very drastically.
The next important thing to demonstrate is the realism of abstraction in system level emula-
tion. Here realism means that the emulations with PHY abstraction should produce the results
similar to the simulations with full PHY. This is shown by plotting the accumulated average
throughput of the system over a given number of frames in Fig. 1.10 for transmission mode 1,
2 and 6 respectively. It is very clear that performance of both full PHY and PHY abstraction is
very much close to each other and provide the same system throughput. Another important as-
pect to note is that although the adjustment factors are calibrated with Rayleigh channel model
but to show the applicability of PHY abstraction in diverse channel models, different channel
models are used for the simulations of these transmission modes. For example simulation for
the TM 1 was performed with 8-tap Ricean channel, simulation for TM 2 with 8-tap Rayleigh
channel and simulation for TM 6 with single tap Ricean channel. It is clear that the calibrated
factors for Rayleigh channel are also applicable to other channel models thus giving rise to its
applicability. Further it can be straight forwardly inferred that in the case of more UEs in the
system, the gains achieved from PHY abstraction will be even significant while maintaining
the realism of evaluations.
16 Chapter 1. OpenAirInterface : An Open Cellular Ecosystem

2500 1800 2500

1600

2000 2000
1400
Throughput [kbps]

Throughput [kbps]

Throughput [kbps]
1200
1500 1500
1000

800
1000 1000
600

400
500 500
Full PHY Full PHY Full PHY
PHY ABSTRACTION 200 PHY ABSTRACTION PHY ABSTRACTION

0 0 0
0 50 100 150 200 250 300 350 400 450 500 0 50 100 150 200 250 300 350 400 450 500 0 50 100 150 200 250 300 350 400 450 500
Frames Frames Frames

Figure 1.10: Accumulated average system throughput over given number of frames: LTE Transmission
Mode 1 (left), Transmission Mode 2 (middle), and Transmission Mode 6 (right).

1.4 Comparison of OAI with Other Platforms and Approaches

Wireless testbeds are essential for furthering the evolution of wireless communication net-
works. It enables precise evaluation and validation of new algorithms, protocols and techniques
for researchers. Testbeds can be built using commercial base stations and some allow open ac-
cess for experiments. The CREW (Cognitive Radio Experimentation World) project [19], like
Berlin LTE-advanced testbed [20] has implemented an LTE testbed that operates in the 2.1
GHz band with both indoor and outdoor configurations. Such testbeds are few in number and
expensive to deploy.
Wireless technology platforms are generally classified as software oriented and hybrid plat-
forms.

• Software platforms such as GNU Radio [21] are used with low cost external pro-
grammable hardware (FPGA and DSP cores) that performs most of the signal processing
and includes an RF front end. Testbeds build using these platforms usually generate their
signal offline using Matlab or Octave and use the nodes for transmission. Some pro-
grammable hardware that are commonly used for build such SDRs are Ettus USRP [13],
Nuand bladeRF [22], and hackRF [23]. Hydra [24] is one such wireless testbed that is
implemented using GNU Radio and Ettus USRP [13]. It uses a 16 bit ADC and supports
upto 400 MSps and can transmit between 70 Mhz to 60 GHz;

• Hybrid platforms such as OAI and PicoSDR provide both the hardware and the software
in a complete package to enable rapid deployment of high performance wireless testbeds.
These platforms are developed from the scratch to operate with dedicated and/or com-
monly used hardware and software platforms.

LTEENB [25] is a base station software that simulates an LTE core network with all the
processing performed using a standard PC and uses an Ettus USRP. It implements 3GPP release
8 and runs in real-time. It can achieve about 60 Mb/s in downlink and about 25 Mbps in uplink.
The gr-lte [26] is a GNU Radio LTE receiver that can receive, synchronize and decode LTE
signals that runs on the user equipment. OPEN-LTE is another open-source implementation of
the 3GPP LTE specifications that has been successfully run on USRP and hackRF. It requires
the signal to be processed offline using Octave.
Nutaq PicoSDR [27] is a MIMO waveform development platform that is capable of es-
tablishing 4X4 MIMO communication between 300 MHz and 3.8 Ghz. Each PicoSDR board
contains one or two Perseus cards, each of which contains an FPGA which is connected to the
RF front-end. Currently it supports 3GPP Release 9 and is configured to work with commercial
1.5 Validation 17

LTE UEs but it does not scale well and can only support low data rates. Recently, the PicoSDR
has been used at INRIA [27] to develop an wireless technology platform that has been shown
to achieve upto 250 kbps Tx rate at the PHY layer.
SORA is a hybrid SDR platform that was developed by Microsoft Asia. It consists of a radio
control board connected to a RF front end and is capable of supporting very high data rates with
commodity PCs. It achieves high system throughput using a PCIe-based interface card (upto
16Gbps) and uses several software and hardware techniques to achieve high performance such
as drastically reducing computation requirement by using look-up tables for PHY processing.
SORA supports upto 8X8 MIMO communication with 802.11 a/b/g/n at full data rates. It
provides a modular data flow composition system called Brick for programming various layers.
It currently does not have support for standard compliant LTE.
Wireless open-Access Research Platform (WARP) is a programmable SDR platform that
consists of FPGAs for DSP-optimised development connected to an RF front end. It uses pro-
grammable blocks to enable creation of highly flexible and tailored architectures. These pro-
grammable blocks offer high computation capability for moderate energy consumption. WARP
can support upto 65 MSps with a 14 bit ADC and upto 4X4 MIMO configuration. It has ref-
erence designs for 802.11 a/g PHY and MAC and is designed to interoperate with commercial
WiFi devices. But its RF range is currently limited to the 2.4 GHz and 5 GHz bands.
Cognitive baseband radio (COBRA) [28] is a wireless platform architecture for future mo-
bile handsets and battery operated devices as well as base stations for small cells. The archi-
tecture can be adapted for 802.11 a/c/n, LTE and TVWS networks. This wireless platform
is standard compliant and can interoperate with commercial devices. This platform is mostly
suitable for battery operated devices and does not scale to macro base stations.
Small Form Factor SDR (SFF SDR) [29] radio platform is an open development platform
developed by Texas Instruments that is made up of three modules, digital processing, data
conversion and RF module which offers high flexibility for development. It is portable and can
support a wide range of technologies from RFID to WiMAX and can communicate in the 360
MHz to 960 MHz range. As an additional feature, it provides embedded power monitoring to
further improve energy efficiency and accurately estimate battery life. Currently it does not
support standard compliant LTE.
Table 1.3 provides a comparison among the commonly used platforms.

1.5 Validation
To demonstrate the validity and operation of OpenAirInterface LTE eNB and EPC, and the
usage of commodity hardware to run LTE network in a PC, a sample indoor experiment is
presented in this section. The considered setup is depicted in Figure 1.11, and consists of a
static laptop equipped with a USB LTE dongle (Bandrich C500), 1 OAI soft eNB and 1 OAI
soft EPC running on the top of Intel-based PC(s). Different setups are possible ranging from
an all-in-one PC to all in a physically separated entities, which are deployment-specific. For
the experiment, we used two different physical machines to run eNB and EPC so as to take
into account the delay of S1 interface. In such a configuration, eNB is running on the host PC
under real-time/low latency Linux, MME and S+P-GW running on regular Linux, and HSS in
18 Chapter 1. OpenAirInterface : An Open Cellular Ecosystem

Table 1.2: C OMPARISON BETWEEN SDR S

Feature SORA WARP GNU Radio LTEENB Nutaq OAI

+ USRP PicoSDR
(OpenLTE)
Open- Partial (for Yes Yes No No Yes
Source academic
purposes
only)
Work with No No Yes No, Yes Yes Yes
commercial for the
LTE UEs ? commercial
version
Emulation Yes Yes Yes Yes Yes Yes
Capability
Cost $8000 ; $ 6000 $2000 $2000 $ 11000 $3200 4x4
Multi-core MIMO, $
PC: $1000 1000 NI/Ettus
,4x4 MIMO B210 without
Kit: $7000 host PC
Performance Upto 300 54 Mbps 12 Mbps Downlink Upto 300 Downlink 20
Mbps 60 Mbps ; Mbps Mbps ; Up-
Uplink 25 link 2 Mbps 1
Mbps
Features Supports Supports Supports Implements Supports Supports
802.11 802.11 some features LTE release LTE PHY 802.11n, LTE
a/b/g/n in of LTE 8 with FDD only E-UTRAN
full data- and a core (Rel. 8 and
rate with network 10) and EPC
4x4 MIMO emulation (Rel. 9 and
10) in both
FDD and
TDD
Project Ac- Yes Yes Currently in Yes (Com- Commercial Yes
tive development mer-
cialised by
Amarisoft)
Community 50 aca- Very pop- Small com- No commu- No Com- 30 academic
Size demic ular with munity, avg 2 nity municty and industrial
institutions several ac- new threads institutions
and several tive projects per week in and sev-
ongoing ( headed the forum eral active
projects by Mango (low traffic) projects
Communic-
tions)
Power Con- 450 W 200 W USRP’s USRP’s 220 W 30W
sumption (180+20) EXMIMO
card for
4x4 MIMO,
USRP’s

another PC. The eNB is configured for in FDD band 7, with 5MHz BW and transmission mode
1 (SISO). The OS is a low latency Linux kernel and the hardware platform is the EXMIMO 2.
1.6 Conclusion 19

Table 1.3: C OMPARISON BETWEEN RF F RONTEND

Feature HackRF BLADERF- BLADERF- USRP- USRP- EXMIMO2

FX40 FX15 B210 X300
Radio 30Mhz - 300 MHz – 300 MHz – 50MHz – 6 50MHz – 6 300 MHz – 6
Spectrum 6GHz 3.8 GHz 3.8 GHz GHz GHz GHz
Bandwidth 20MHz 28MHz 28MHz 30.72 MHz 120 MHz 20MHz ?
Duplex half full 1x1 full 1x1 full 2x2 full 2x2 full 4x4
ADC/DAC MAXIntegratedLIME LIME AD AD LIME
Chip
Sample 8 bits 12 bits 12 bits 12 bits 14 bits 16 bits
Size (AD-
C/DAC)
Sample 20MS/s 40MS/s 40MS/s 61Ms/s 200 MS/S ?
Rate (AD-
C/DAC)
Interface USB2 USB3 USB3 USB3 SFP,ETH,PCIe PCIe x 1
x4
FPGA Yes CPLD 40K 115K 150K 325K - 30K ?
Logic 400K
Elements
Opensource all all all host code host code all?
Cost 300$ 400$ 650$ 1100$ 4000$ 4000$

Fig. 1.12 shows the two screen-shots of the connection manager of the dongle. It can be
observed a successful attached procedure (left figure) and downlink data rate of 7Mbps obtained
(right figure).2
A set of experiments is carried out to characterize the performance in terms of round trip
time (RTT) considering only one logical channel. In particular, the RTT is evaluated through
different traffic patterns generated by D-ITG [30], namely 32, 125, 512, 1408 packet sizes (PS),
and 1, 0.5, 0.25, and 0.1 inter-departure time (IDT).
Fig. 1.13 demonstrates the measured RTT as a function of PS and IDT at 5 meters (setup
1) and 20 meters (setup 2) of distance from the eNB. As expected, higher RTT values are
observed when PS, IDT, and distance increase. However, low RTT variations are observed,
which is due to the fact that (a) the experiment is completely isolated, i.e. no external traffic,
and no user mobility, and (b) resource allocation is performed as a function of traffic load in
way to maximize the user spectral efficiency.

1.6 Conclusion
This document presents the OpenAirInterface as a suitably flexible platform for an open cel-
lular ecosystem for 4G and future 5G research. The platform offers an open-source reference
software implementation of 3GPP-compliant LTE system and a subset of LTE-A features for
real-time indoor/outdoor experimentation and demonstration as well as large scale system em-
ulation. An example usage of the platform to deploy a low cost LTE network on the top of
commodity hardware is shown.
2
Video can be found at https://plus.google.com/+OpenairinterfaceOrg
20 Chapter 1. OpenAirInterface : An Open Cellular Ecosystem

HSS OAI Soft EPC OAI Soft eNB COTS UE

App MME
Server

Internet SGi
GPP EXMIMO II
S+P-GW

Received Wireshark
messages at eNB
Received constellation OAI soft eNB in a PC
at eNB (PC+EXMIMO II)
FDD TX/RX
filters Antenna
(2.6GHz)

Figure 1.11: Experiment setup and eNB hardware components and tools.

Figure 1.12: Validation Results

1.6 Conclusion 21

RTT vs PS and IDT for setup 1 RTT vs PS and IDT for setup 2
38.5 38.5
Packet Size 32 Packet Size 32
Packet Size 128 Packet Size 128
Packet Size 512 Packet Size 512
Packet Size 1408 Packet Size 1408
RTT(ms)

RTT(ms)

38 38

37.5 37.5
1 2 4 10 1 2 4 10
Number of Packets per Second Number of Packets per Second

Figure 1.13: Experiment 1

22 Chapter 1. OpenAirInterface : An Open Cellular Ecosystem
Bibliography

[1] I. Latif, F. Kaltenberger, N. Nikaein, and R. Knopp. Large scale system evaluations using
phy abstraction for lte with openairinterface. In Workshop on Emulation Tools, Method-
ology and Techniques, 2013.

[2] The OpenAirInterface Initiative. http://www.openairinterface.org/.

[3] Navid Nikaein, Raymond Knopp, Florian Kaltenberger, Lionel Gauthier, Christian Bon-
net, Dominique Nussbaum, and Riadh Ghaddab. Demo: OpenAirInterface: an open LTE
network in a PC. In MOBICOM 2014, 20th Annual International Conference on Mobile
Computing and Networking, 2014.

[4] N. Nikaein, M. Marina, S. Manickam, A. Dawson, R. Knopp, and C. Bonnet. Openairin-

terface: A flexible platform for 5G research. ACM Sigcomm Computer Communication
Review, 2014.

[5] K. Tan et al. Sora: High-Performance Software Radio Using General-Purpose Multi-Core
Processors. Communications of the ACM, 54(1):99–107, Jan 2011.

[6] S. Shearman and J. Kimery. Software Defined Radio Prototyping Platforms Enable a
Flexible Approach to Design. IEEE Microwave Magazine, 13(5):76–80, Jul 2012.

[7] K. Amiri et al. WARP, a Unified Wireless Network Testbed for Education and Research.
In Proceedings of IEEE MSE, 2007.

[8] Amarisoft. http://www.amarisoft.com/.

[9] N. D. Nguye, R. Knopp, N. Nikaein, and C. Bonnet. Implementation and validation of

multimedia broadcast multicast service for lte/lte-advanced in openairinterface platform.
In International Workshop on Performance and Management of Wireless and Mobile Net-
works, 2013.

[10] A. Bhamri, N. Nikaein, F. Kaltenberger, Jyri J. Hämäläinen, and R. Knopp. Pre-processor

for MAC-layer scheduler to efficiently manage buffer in modern wireless networks. In
WCNC 2014, IEEE Wireless Communications and Networking Conference, 2014.

[11] A. Bhamri, N. Nikaein, F. Kaltenberger, Jyri J. Hämäläinen, and R. Knopp. Three-step

iterative scheduler for qos provisioning to users running multiple services in parallel. In
IEEE Vehicular Technology Conference, 2014.

[12] nwEPC - EPC SAE Gateway. http://sourceforge.net/projects/nwepc/.

24 BIBLIOGRAPHY

[13] M Dickens, Brian P Dunn, and J Nicholas Laneman. Design and implementation of a
portable software radio. IEEE Communications Magazine, 2008.
[14] Ettus usrp. http://www.ettus.com.
[15] Bilel Ben Romdhanne, Navid, Nikaein, Knopp Raymond, and Bonnet Christian. Ope-
nAirInterface large-scale wireless emulation platform and methodology. In PM2HW2N
2011, 6th ACM International Workshop on Performance Monitoring, Measurement and
Evaluation of Heterogeneous Wireless and Wired Networks, 2011.
[16] A. Hafsaoui, N. Nikaein, and L. Wang. Openairinterface traffic generator otg: A realistic
traffic generation tool for emerging application scenarios. In International Symposium on
Modeling, Analysis and Simulation of Computer and Telecommunication Systems (MAS-
COT), 2012.
[17] Nortel Networks. Ofdm exponential effective sir mapping validation, eesm simulation
results. Technical report, 3GPP, 2004.
[18] R.B Santos, Jr. Freitas, C. Walter, E. M. G. Stancanelli, and F. R. P. Cavalcanti. Link-to-
System Level Interface Solutions in Multistate Channels for 3GPP LTE Wireless System.
XXV Simposio Brasileiro de Telecomunicacoes, 2007.
[19] Cognitive Radio Experimentation World. http://www.crew-project.eu/.
[20] Thomas Wirth, V Venkatkumar, Thomas Haustein, Egon Schulz, and Rüdiger Halfmann.
Lte-advanced relaying for outdoor range extension. In Vehicular Technology Conference
Fall (VTC 2009-Fall). IEEE, 2009.
[21] Eric Blossom. Gnu radio: tools for exploring the radio frequency spectrum. Linux journal,
2004.
[22] the usb 3.0 superspeed software defined radio. http://nuand.com/.
[23] HackRF. https://github.com/mossmann/hackrf.
[24] K. Mandke, Soon-Hyeok Choi, Gibeom Kim, R. Grant, R.C. Daniels, Wonsoo Kim, R.W.
Heath, and S.M. Nettles. Early results on hydra: A flexible mac/phy multihop testbed. In
Vehicular Technology Conference, 2007. VTC2007-Spring. IEEE 65th, 2007.
[25] LTEENB: base station software. http://bellard.org/lte/.
[26] gr-lte. https://github.com/kit-cel/gr-lte.
[27] Abdelbassat MASSOURI and Tanguy RISSET. Fpga-based implementation of multiple
phy layers of ieee 802.15. 4 targeting sdr platform.
[28] O. Gustafsson and al. Architectures for cognitive radio testbeds and demonstrators an
overview. In Cognitive Radio Oriented Wireless Networks & Communications (CROWN-
COM). IEEE, 2010.
[29] Zhe Chen, Nan Guo, and Robert C Qiu. Building a cognitive radio network testbed. In
Proceedings of the IEEE Southeastcon, 2011.
BIBLIOGRAPHY 25

[30] Alessio Botta, Alberto Dainotti, and Antonio Pescapè. A tool for the generation of real-
istic network workload for emerging networking scenarios. Computer Networks, 56(15),
2012.
26 BIBLIOGRAPHY
List of Tables

1.1 Simulation times different transmission Modes . . . . . . . . . . . . . . . . . 15

1.2 Comparison between SDRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Comparison between RF Frontend . . . . . . . . . . . . . . . . . . . . . . . . 19
List of Figures

1.1 OpenAirInterface LTE software stack. . . . . . . . . . . . . . . . . . . . . . . 5

1.2 OAI ExpressMIMO2 hardware platform. . . . . . . . . . . . . . . . . . . . . . 6
1.3 ExpressMIMO2 FPGA design. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Built-in Emulation Platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Experiment design workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Discrete event generator of OAI emulation. . . . . . . . . . . . . . . . . . . . 11
1.7 Protocol vectorization and complex network experimentation based on the OAI
emulationplatform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.8 Link Abstraction in System Performance Evaluation. . . . . . . . . . . . . . . 13
1.9 PHY Abstraction in System Performance Evaluation in OpenAirInterface . . . 14
1.10 Accumulated average system throughput over given number of frames: LTE
Transmission Mode 1 (left), Transmission Mode 2 (middle), and Transmission
Mode 6 (right). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.11 Experiment setup and eNB hardware components and tools. . . . . . . . . . . 20
1.12 Validation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.13 Experiment 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21