View
212
Download
0
Category
Preview:
Citation preview
8/17/2019 Cm Publi 4513
1/167
LATENCY, COOPERATION, AND CLOUD IN RADIO
ACCESS NETWORK
Navid Nikaein
Thesis submitted to
University of Nice
in partial fulfilment for the award of the degree of
Habilitation à Diriger des Recherches
19 March 2015
8/17/2019 Cm Publi 4513
2/167
AUTHOR’S A DDRESS:
Navid Nikaein
Eurecom
Mobile Communication DepartmentCampus SophiaTech
450 Route des Chappes
06410 Biot Sophia Antipolis – France
Email: navid.nikaein@eurecom.fr
URL: http://www.eurecom.fr/˜nikaeinn
mailto:navid.nikaein@eurecom.frhttp://www.eurecom.fr/~nikaeinnhttp://www.eurecom.fr/~nikaeinnhttp://www.eurecom.fr/~nikaeinnhttp://www.eurecom.fr/~nikaeinnmailto:navid.nikaein@eurecom.fr
8/17/2019 Cm Publi 4513
3/167
Forward
This document is written as support to my French ”Habilitation à diriger des recherches” (HDR)
degree. Unlike a Ph.D. thesis, a HR thesis does not aim at providing a detailed description of a
particular research problematic, but rather describes the various facets of responsibilities that I
experienced as researcher and assistant professor since I obtained my Ph.D.
My post-doctoral career started at Eurecom in January 2004, after having completed my Ph.D.
entitled “Architecture and protocols for supporting routing and quality of service for mobile ad
hoc networks” at École Polytechnique Fédérale de Lausanne EPFL, Switzerland in September
2003. After the postdoc, I joined the founding team of a startup company in Sophia-Antipolis,
France, working towards a range of intelligent wireless backhaul routing products for private
and public networks. Four years later, I deliberately chose to join Eurecom as an assistant pro-
fessor because of the experimental platform OpenAirInterface, which allowed me to work on
practical aspects of wireless access network. This means working on aspects that are sometimes
overlooked or not found interesting or even old fashioned by other researchers, or collecting
and analyzing data from experiments to prove a concept or a point. Working with this platformis a unique experience, since one has to deal with many practical problems that sometimes lead
to very interesting research avenues. Furthermore the platform is ideal for teaching, giving
students hands-on experience and showing them the problems of real implementations.
This document is composed of two parts. The first part describes the highlights of my research
work I have been conducting after my Ph.D. The bulk of the text is based on existing and ongo-
ing publications, but I have also added many new results, an introductory chapter summarizing
all the works and putting them in context to each other, a chapter on the critical issues in cloud
radio access network, and a conclusion chapter elaborating on my research methodology and
giving directions for future work. The second part contains an extended CV, which includes
teaching and supervising activities, project management and acquisition, as well as a selectedlist of my post-Ph.D. publications.
8/17/2019 Cm Publi 4513
4/167
8/17/2019 Cm Publi 4513
5/167
Contents
1 Introduction 5
1.1 Synopsis and Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.1 OpenAirInterface: An Open Cellular Ecosystem . . . . . . . . . . . . 6
1.1.2 LTE Unified Scheduler Framework . . . . . . . . . . . . . . . . . . . 8
1.1.3 Low Latency Contention-Based Access . . . . . . . . . . . . . . . . . 8
1.1.4 Evolving UEs for Collaborative Wireless Backhauling . . . . . . . . . 9
1.1.5 Closer to Cloud Radio Access Network: Study of Critical Issues . . . . 10
1.1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 OpenAirInterface : An Open Cellular Ecosystem 11
2.1 Software Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Hardware Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Build-in Emulation Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Experiment Design Workflow . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 Discrete Event Generator . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.3 Protocol Vectorization and Emulation Data Transport . . . . . . . . . . 19
2.3.4 PHY Abstraction [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Comparison of OAI with Other Platforms and Approaches . . . . . . . . . . . 24
2.5 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3 Unified Scheduler Framework for LTE/LTE-A 31
3.1 Scheduling Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.1 Packet-Level Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.2 Logical Channel-Level Parameters . . . . . . . . . . . . . . . . . . . . 33
3.1.3 User-level parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8/17/2019 Cm Publi 4513
6/167
2 CONTENTS
3.1.4 System-level parameters . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Scheduling Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.1 MAC-layer Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.2 MAC-layer Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 Comparative Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.1 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 Initial Experimentation and Validation . . . . . . . . . . . . . . . . . . . . . . 42
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4 Low Latency Contention-Based Access 45
4.1 Latency in LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.2 Analysis [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.3 Measurements [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 General Idea of Contention Based Access . . . . . . . . . . . . . . . . . . . . 54
4.3 Implementation of Contention Based Access in LTE . . . . . . . . . . . . . . . 57
4.3.1 Enhancements to the RRC Signaling Related to 3GPP TS 36.331 . . . 574.3.2 Enhancement to the PHY Signaling Related to 3GPP TS 36.212 . . . . 57
4.3.3 Enhancement to the PHY Procedures related to 3GPP TS 36.213 . . . . 59
4.3.4 CBA Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.4 Resource Allocation Scheme for Contention Based Access . . . . . . . . . . . 62
4.4.1 Estimation of the Probabilities of Events in Step 3 . . . . . . . . . . . 64
4.4.2 Estimation of the Latency in Step 4 . . . . . . . . . . . . . . . . . . . 67
4.5 Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.5.1 Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.5.2 Performance of the Resource Allocation Scheme . . . . . . . . . . . . 70
4.6 Experimental Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.6.1 Experiment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.6.2 Applied Grouping Scheme and Scheduling Algorithm . . . . . . . . . 74
4.6.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.6.4 General CBA Latency Trend . . . . . . . . . . . . . . . . . . . . . . . 74
4.6.5 Uncoordinated Traffic Pattern . . . . . . . . . . . . . . . . . . . . . . 76
4.6.6 Coordinated Traffic Pattern . . . . . . . . . . . . . . . . . . . . . . . . 81
8/17/2019 Cm Publi 4513
7/167
CONTENTS 3
4.7 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5 Evolving UEs for Collaborative Wireless Backhauling 87
5.1 Design Challenges and Contribution . . . . . . . . . . . . . . . . . . . . . . . 88
5.2 Explore for New Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.2.1 Moving Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.2.2 Small Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.3.1 LTE Mesh Network Topology . . . . . . . . . . . . . . . . . . . . . . 92
5.3.2 Virtual Overlay - Enable Mesh Networking . . . . . . . . . . . . . . . 93
5.3.3 PHY Layer Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3.4 MAC Layer Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.4 Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.4.1 Experimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.5 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6 Closer to Cloud Radio Access Network: Study of Critical Issues 111
6.1 From Analog to Virtual Radio . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.3 Cloud Radio Access Network Concept . . . . . . . . . . . . . . . . . . . . . . 113
6.4 C-RAN Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.5 C-RAN Critical Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.5.1 Fronthaul Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.5.2 BBU Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.5.3 Real-time Operating System and Virtualization Environment . . . . . . 117
6.5.4 Candidate Architectures . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.6 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.6.1 Experiment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.6.2 CPU Architecture Analysis . . . . . . . . . . . . . . . . . . . . . . . . 122
6.6.3 CPU Frequency Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.6.4 Virtualization Technique Analysis . . . . . . . . . . . . . . . . . . . . 124
6.6.5 I/O Performance Analysis . . . . . . . . . . . . . . . . . . . . . . . . 124
8/17/2019 Cm Publi 4513
8/167
4 CONTENTS
6.6.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.7 Modelling BBU Processing Time . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7 Conclusion 131
7.1 Open-Source Tools for 5G Cellular Evolution . . . . . . . . . . . . . . . . . . 131
7.2 RANaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
7.3 Software-Defined Wireless Networking . . . . . . . . . . . . . . . . . . . . . 133
7.4 Mobile Cloud and Edge Computing . . . . . . . . . . . . . . . . . . . . . . . 134
7.5 Dynamic Meshing of the Base stations . . . . . . . . . . . . . . . . . . . . . . 135
Bibliography 136
Appendices
A CBA Protocol Validation 149
B Virtual Link Validation 153
List of Tables 156
List of Figures 157
8/17/2019 Cm Publi 4513
9/167
Chapter 1
Introduction
The main volume of the work presented here considers protocol and algorithm design and
validation through experimentation for radio access networks (RAN) in a cellular, mesh, and
cloud settings.
Protocol and algorithm are the essential part of the wireless communication system allowing
two or more nodes to communicate with each other according to a set of predefined communi-
cation messages and rules. It is generally divided into a control plane and a data-plane, whose
signalling determines (a) the type of communication and the resulted network topology, and (b)
the efficiency of communication on the top of what is achievable by the physical link. However
new application scenarios found in namely machine-type communication, public safety net-
works, interactive online gaming, moving cells, and device-to-device communication, requiremore complex and dynamic protocols and algorithms. While in 4G systems, this represents
an opportunity to limit the modifications in the physical layer and redesign the radio access
protocols and algorithm to obtain the desired features, in 5G it rather calls for a new MAC/-
PHY co-design that exploits new waveform, frame structure, and advanced (non-orthogonal)
multiple access schemes among the others [4, 5].
Experiment is also an integral part of wireless communications. An experiment is a procedure
carried out with the goal of verifying, refuting, or establishing the validity of a hypothesis in a
real-world.1 One of the very first experiments in this field was carried out by Heinrich Hertz
in 1887, proving the fact that electromagnetic waves can travel over free space. Another more
recent example is the concept of cloud RAN that decouples the baseband unit (BBUs) fromthe radio units by locating a pool of BBUs at the high performance cloud infrastructure. The
concept was first proposed by Y. Lin et al. IBM Research Division, China Research Laboratory
in 2010 [6], and was partially proven (only centralization) by experiments some years later by
Chih-Lin I et al. in 2014 [7]. Experiments can also be used to characterize the behaviour of
the system and/or analyse a specific phenomenon not yet very well understood. For example,
processing time measurement of RAN functions can be used to analyse the required computa-
tional power as a function bandwidth, modulation and coding scheme and assess the feasibility
of RAN virtualization in the cloud infrastructure.
Because wireless communications systems have become very complex and comprise many
1en.wikipedia.org/wiki/Experiment
http://localhost/var/www/apps/conversion/tmp/scratch_2/en.wikipedia.org/wiki/Experimenthttp://localhost/var/www/apps/conversion/tmp/scratch_2/en.wikipedia.org/wiki/Experiment
8/17/2019 Cm Publi 4513
10/167
6 Chapter 1. Introduction
different fields, ranging from information and communication theory, signal processing to pro-
tocols and networking, performing a reliable experiment is becoming an expensive and time
consuming task. There are three main approaches to perform an experiment [8]:
• Simulation: typically done in a controlled laboratory environment, where some or allparts of the system and protocol stack are modeled. In addition, the execution environ-
ment is not that of the real system and the interactions with external entities (e.g. real
application) are limited. This makes simulation reproducible and highly scalable but not
applicable as the use of (simplified) models may deviate results from the real system be-
haviour. Moreover, it can hide important issues when the software is implemented and
deployed on a large scale in a real environment.
• Emulation: also performed in a controlled laboratory environment, where at least onelement is modelled. The decision on which element is real or modelled depends on the
use case and purpose of the experiments. However, emulation is often based on the realexecution environment and opens up the interaction with external elements and their I/O
streams. This makes emulation reproducible with high-level of applicability at the cost
of less scalability.
• Real testbeds: typically performed in a quasi-controlled environment, where almost allthe elements of the system are real. The execution environment is also real and open to
external entities with their IO streams making this approach applicable. However, real
testbed is often expensive and not scalable and the measurements produced on them are
hard to predict and reproduce.
It is also possible to combine the benefits of each approach into one platform, which is exactlythe intention of the Eurecom OpenAirInterface wireless technology platform. It is designed to
provide a complete experiment life-cycle spanning from a unitary link-level simulation, system-
level emulation, to real-time testbeds. The main differences between the methodology used
with respect to existing open-source simulation/emulation/real testbed are that firstly it is built
with a real-time framework in mind, secondly it is based on real software implementation of the
protocol stack (L1/L2/L3), thirdly it is designed with a system approach and interoperability
with the commercial equipments. The platform includes a radio transceiver card combining
radio front-end and analogue/digital converters and an open-source software defined radio that
runs in real-time on common x86 Linux machines.
This thesis gives some examples of how the OpenAirInterface emulation and testbed platformcan be used to perform experimental research. The following section gives a summary of the
thesis highlighting my key contributions and explorations to the field of experimental wireless
communication protocols and networking.
1.1 Synopsis and Contributions
1.1.1 OpenAirInterface: An Open Cellular Ecosystem
Cellular systems are among one of the last industries expected to converge from a slow-moving
proprietary and expensive HW/SW platforms towards an open SW platforms leveraging com-
8/17/2019 Cm Publi 4513
11/167
1.1 Synopsis and Contributions 7
modity hardware. This is required to build an open cellular ecosystem and foster innovations
in the wireless world as already produced in OpenStack for cloud services and Android for
mobile OS. Currently, the only open cellular ecosystem is OpenBTS, which provides an open
development kit for 2G systems [9]. However, due to the lack of open cellular ecosystem forthe subsequent wireless communication systems, applied research in this field is limited within
the boundaries of vendor and operator R&D groups. Furthermore, several new approaches and
technologies are being considered as potential elements making up such a future mobile net-
work, namely cloudification and programmability of radio network, dynamic meshing among
the base stations, and native support of machine-type communication. Research on these tech-
nologies requires realistic and flexible experimentation platforms that offer a wide range of
experimentation modes from real-world experimentation to controlled and scalable evaluations
while at the same time retaining backward compatibility with current generation systems.
Chapter 2 presents some results of LOLA2 and FLEX3 projects among the others, in which we
develop the OpenAirInterface (OAI) wireless technology platform as a suitably flexible cellular
ecosystem and playground for 4G and 5G research. OAI software platform provides a standard-
compliant implementation of a subset of Release 10 LTE for UE, eNB, MME, HSS, S-GW and
P-GW on standard Linux-based computing equipment (Intel x86 PC architectures). It can be
used in conjunction with standard RF laboratory equipment (i.e. National Instruments/Ettus
USRP and PXIe platforms) in addition to custom RF hardware provided by EURECOM to
implement these functions to a sufficient degree to allow for real-time interoperation with com-
mercial devices.
One of the challenges was to build a reliable yet scalable emulation platform that can be rapidly
used for the performance evaluation and at the same time as a validation tool during the design-
phase of a new technology. This allows an experimenter to seamlessly transit between real ex-
perimentation and repeatable, scalable emulation. This has been achieved by the usage of real
protocol stack (L1/L2/L3) for the emulation platform. However, to preserve reproducibility,
scalability, and applicability properties, the emulation is built based on three main principles:
(1) hybrid discrete event generator to respect the frame/subframe timing and handle both peri-
odic and user-defined events in a timely manner, (2) protocol vectorization (or virtualization)
to allow different instances of the protocol stack share the same operating system, and (3) PHY
abstraction to predict the modem performance as in a real physical layer.
Another main challenge we faced when targeting LTE standard compatibility was the interop-
erability with the commercial equipments at both ends and across all the layers. This has been
achieved for 4G following a series of interoperability verification strategy to guarantee that the
OAI soft eNB and EPC are able to connect with the commercial equipments at both ends (i.e.
UE and EPC). An example usage of the platform to deploy a low cost LTE network on the top
of commodity hardware is also provided in the chapter.
More details about this work can be found in Chapter 2, which is based on the publications [1,
8, 10].
2www.ict-lola.eu/3www.flex-project.eu/
http://www.ict-lola.eu/http://www.flex-project.eu/http://www.flex-project.eu/http://www.ict-lola.eu/
8/17/2019 Cm Publi 4513
12/167
8 Chapter 1. Introduction
1.1.2 LTE Unified Scheduler Framework
Mobile devices have evolved remarkably over the last decade and their capability to simultane-
ously run many applications has significantly transformed the traffic characteristics of mobilenetworks. Quality of service (QoS) is a fundamental component associated with these applica-
tions and network should be able to support multiple QoS requests from the same user at the
same time. This requires complex buffer management and simultaneous dynamic scheduling
of resources to multiple users with multiple services.
Chapter 3 presents a unified scheduler framework (USF), design and developed in the con-
text of FLEX project for LTE system.3. It enables more efficient allocation of resources to
users running multiple internet applications in parallel while satisfying the user-driven, service
driven and operator-driven requirements. Analytical studies have shown that the framework
significantly enhances the performance of existing scheduling algorithms by increasing the res-
olution of scheduling. The framework is applied to the OpenAirInterface uplink and downlink
scheduler, and the resulted schedulers were tested and validated under real conditions.
More details about this work can be found in Chapter 3, which is based on the publications [11,
12].
1.1.3 Low Latency Contention-Based Access
One of the key issues for which network operators are seeking solutions is that of determin-
ing applications and subsequently defining services which require very low latency and shortchannel acquisition times. This will provide scenarios for LTE-Advanced and 5G system ar-
chitecture development and study. However, the majority of consumer applications will not
benefit much from lower latency than that offered by LTE, or at least users would likely not be
willing to accept increased subscription rates for this feature. Important exceptions to this are
interactive multi-player gaming applications which, from an operator’s perspective, represent
a very strategic application area with respect to revenue potential. In addition, for machine-
to-machine (M2M) applications, there will likely be cases for lower latency, namely sensing
and actuation, alarm and event detection, vehicular communication, but they are not yet fully
exploited.
Chapter 4 presents some results obtained in the context of LOLA2
project, in which latency isstudied both analytically and experimentally to assess the achievable end-to-end latency perfor-
mance in the current LTE/LTE-A systems. The results have shown that the delay requirements
for certain delay sensitive applications are not met. To lower the latency, Chapter 4 introduces a
new contention based access (CBA) method for uplink synchronized devices. The main feature
of CBA is that the eNB does not allocate resources for a specific UE. Instead, the resources
allocated by the eNB are available to all or a group of UEs and that any UE which has data
to transmit randomly uses resource blocks among the available resources within the group(s) it
belongs to. As the resources are not UE specific, collision happens when multiple UEs within
a group select the same resources. To address the problem of collision, UE identifiers are pro-
tected and transmitted along with the data on a randomly selected resources. This will enable
eNBs to decode the control information if collision occurs (in most cases based on MU-MIMO
techniques), and consequently to interpret such a collision as a scheduling request, which in
8/17/2019 Cm Publi 4513
13/167
1.1 Synopsis and Contributions 9
turn triggers a scheduling grant for the collided UEs. Simulation results validate the rationality
of the CBA method and demonstrate the achievable performance with respect to the random
access method. To validate and assess the latency performance of CBA in a LTE/LTE-A under
real conditions, the method has been implemented in the OpenAirInterface emulation platformfor both eNB and UE, and an exhaustive set of experiments have been carried out confirming
significant latency gain with the proposed method.
Although the development and validation have been done based on an LTE release 10 frame-
work, they have a strong relevance for future cellular systems, where network-controlled device-
to-device communication, and massive coordinated and uncoordinated access, grant-free and
stateless uplink channel access are discussed.
More details about this work can be found in Chapter 4, which is based on the publications
[2, 3, 13, 14], as well as newly generated experimental results.
1.1.4 Evolving UEs for Collaborative Wireless Backhauling
The proliferation of 4G deployments has been increasing worldwide, promising to offer to car-
riers the capabilities to keep up with the increasing traffic growth. Moreover, the requirements
for 5G technologies render new communication trends for seamless connectivity, heteroge-
neous networking and interoperability highly attractive. This implicates an extensive use case
span from static to moving cell scenarios applicable to public and private networks. In thisperspective, two limiting factors have been identified. First, re-establishment of (non-ideal)
mobile X2 backhauling when it cannot be effectively utilized to inter-connect eNBs or wired
interfaces are infeasible or too costly to be deployed. Second, dual or multiple UE connec-
tivities to secondary base stations when the required performance cannot be achieved by the
serving base station (interference, outage or high mobility) or when the serving base station is
overloaded.
Chapter 5 presents a new paradigm for wireless link virtualization through cooperative L2/MAC
information (packet) forwarding enabled by a group of UEs, which is investigated in the con-
text of CONECT and LOLA projects. To build a virtual link, legacy UEs are leveraged as
active network elements being capable of operating simultaneously over multiple base stations(eNBs). Through cooperation, they enable reliable multi-hop operation for the over-the-air re-
establishment of X2 interface. The benefit for the UEs is that they can increase the aggregated
data rate by exploiting data connection to multiple eNBS at the expense of extra power con-
sumption. Through extensive experimentations with OpenAirInterface emulation platform, the
performance of the proposed architecture is evaluated under realistic conditions and its ratio-
nality validated.
The proposed wireless link virtualization have been developed based on the LTE release 8
framework. However, it has a strong relevance for future cellular systems, where non-ideal
backhauling and dual UE connectivity are discussed.
More details about this work can be found in Chapter 5, which is based on the project deliver-
ables [15, 16] and the recently submitted paper [17].
8/17/2019 Cm Publi 4513
14/167
10 Chapter 1. Introduction
1.1.5 Closer to Cloud Radio Access Network: Study of Critical Issues
Cloud radio access network is a novel architecture which can address the cost, energy, and bit
rate concerns the mobile operators are facing to support explosive growth in mobile data traffic.The main idea behind C-RAN is to perform the required base band and protocol processing on
a centralized computing resources or a cloud infrastructure. This replaces traditional base sta-
tions with distributed (passive) radio elements with much smaller footprints than the traditional
base station and a remote pool of base band units allowing for simpler network densification.
Deploying C-RAN for mobile operators has the benefit of cost reduction due to fewer number
of sites, easy software upgrade, performance improvement with coordinated multi-cell signal
processing, and multiplexing gain by exploiting processing load variations to fewer resources
in terms of computing, networking and storage.
Chapter 6 investigates three critical issues for the cloudification of the current LTE/LTE-A ra-
dio access network, as a part of work carried out in the context of MCN4 project. Extensiveexperimentations have been performed based on the OpenAirInterface unitary simulators to
characterise the base band processing time under different conditions. Based on the results,
an accurate model is proposed to compute the total uplink and downlink processing load as
a function of bandwidth, modulation and coding scheme, and virtualization platforms. The
results also reveal the feasible virtualization approach to enable radio access network cloudifi-
cation.
More details about this work can be found in Chapter 6, which is mainly based on the newly
generated results.
1.1.6 Conclusion
Future directions on the selected topics of interest in the perspective of 5G research are given
Chapter 7.
4http://www.mobile-cloud-networking.eu
http://www.mobile-cloud-networking.eu/http://www.mobile-cloud-networking.eu/
8/17/2019 Cm Publi 4513
15/167
Chapter 2
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 [18–20]. 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 issimilar to other software-defined radio (SDR) prototyping platforms in the wireless network-
ing research community such as SORA [21]. Other similar approaches combining PCs and
FPGA-based processing make use of NI LabVIEW software [22] or using the WARP [23] ar-
chitecture. 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 plat-
forms provides eNB and core-network functionality on standard Linux-based PCs [24]. OAI
is written in standard C for several real-time Linux variants optimized for x86 and released
as free software 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 re-
alistic emulation 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, andreconfigure 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
8/17/2019 Cm Publi 4513
16/167
12 Chapter 2. OpenAirInterface : An Open Cellular Ecosystem
cloud-RAN and massive MIMO.
2.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) [25];
• Channel-aware proportional fair scheduling [11, 12];
• 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 [26];
• 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 Gatewayare necessary). Configurable access point name, IP range, DNS and E-RAB QoS;
• IPv4 and IPv6 support.
8/17/2019 Cm Publi 4513
17/167
2.2 Hardware Platform 13
Figure 2.1: OpenAirInterface LTE software stack.
Figure 2.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, profiling tools
and soft scope. It also provide tools for protocol validation, performance evaluation 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
2.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
8/17/2019 Cm Publi 4513
18/167
14 Chapter 2. OpenAirInterface : An Open Cellular Ecosystem
completely open (GNU GPL), both at the hardware and software level. Figure 2.2 shows the
ExpressMIMO2 hardware platform.
RF RX
(4 way)
RF TX
(4 way)
GPIO for external
RF controlSpartan 6 LX150T 12V from ATX
power supply
PCIe (1 or 4 way)
4xLMS6002D RF ASICs
250 MHz – 3.8 GHz
Figure 2.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. 2.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. 2.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
8/17/2019 Cm Publi 4513
19/167
2.3 Build-in Emulation Platform 15
Spartan 6
AHB Bus
Leon 3
uProcessorAHB Controller AHB RAM
ADC/DAC Interface &
TX and Rx Buffers
(Lime)
AHB PCIeDirect Bus
AHB ROM
Control
GTP3 GTP2 GTP1 GTP0
DMA
I/O
MasterMaster/
Slave
Master/
Slave
L0L1L2L3L4L5L6L7
PCIe Connectors
Figure 2.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 [27, 28]. This development is now delivered as part of the
publicly-available software package from the OAI website and SVN server [18]. EURECOMwill 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.
2.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. 2.4) [29]. 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/17/2019 Cm Publi 4513
20/167
16 Chapter 2. 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.
Channel ModelChannel ModelChannel Model
Web Portal
Scenario
Descriptor Dispatcher
Console Results
Message Seq.L2 Protocols
PHY Procedures
Emulation Medium
Network Interface
L3 Protocols
PHY Abstraction
External
Application
External
Traffic GenOAI Emulator
Result Gen.
Log Gen.
Packet Tracer Config Gen.
Traffic Gen.
Channel Gen.
Mobility Gen.
eNB0
NOT SYNCHED
CONNECTED
ATTACHED
SYNCHED
UE0 UE1
UEn
Channel Descriptor
Channel Trace
Mobility Gen
EMOS
S m
a l l S c a l eF a d i n g
P a
t h L o s s
L a
r g e S c a l eF a d i n g
Figure 2.4: Built-in Emulation Platform.
The OAI emulation platform is based on a hybrid discrete event generator in that it handlesperiodic 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) [30]. 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 fur-
ther details about the three main design principles of the emulation platform.
8/17/2019 Cm Publi 4513
21/167
2.3 Build-in Emulation Platform 17
2.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 2.5.
Analysis
Performance Evaluation Protocol Validation System Testing
MonitoringLogs and Stats Wireshark Signal Analyzer Timing analyzer
ExecutionDebug Mode Soft Realtime Mode Hard Realtime Mode
Models & ConfigurationNetwork Interface Traffic/Mobility Protocol Stack PHY/RF Abstraction
Scenario DescriptionEnvironment/System Network Topology Application EMU IO Parameters
Figure 2.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 interms 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.
8/17/2019 Cm Publi 4513
22/167
18 Chapter 2. 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 systemas a whole is analysed and tested.
2.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 2.1.
1
2 s t a t i c voi d m y f u n c t i o n ( M ode l ∗ model ) {3 / /
4 }5
6 i n t m ai n ( ) {7 mod model ;
8 e v e v e n t ;
9 i n i t i a l i z e (&mod,& ev ) ;
10 c o nf ig ur e (&mod,&e v ) ;
11 s c h e d u l e e v e n t ( e v o p , e v t y p e , t i m e , &m y f un c , &mod ) ;12 . . .
13 s c h e d u l e e n d s i m u ( e v ) ;
8/17/2019 Cm Publi 4513
23/167
2.3 Build-in Emulation Platform 19
14 r u n ( ) ;
15 r e l e a s e ( ) ;
16 r e t u r n 0 ;
17 }18
19 v o i d r u n ( ) {20 w h i l e ( ! e n d o f s i m u l a t i on ( ) ) {21 t i m e = g e t t i m e s t a m p ( ) ;
22 / / u se r −d e f i n ed e v e n t s23 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 ( e v . t i m e == t i m e )
25 e x e c ut e ( e v ) ;
26 }27 / / e x e c u t e p e r i o d ic e v e nt s
28 p r o c e s s s u b f r a m e ( t i m e ) ;
29 }30 }
Listing 2.1: Example of discrete event generator
In OAI, the emulation events are divided into two types. Periodic events are those events occur-
ring at each period and must be executed in the current timestamp (e.g. MAC/PHY subframe
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, reconfiguration,
or changes in the state of a simulation/emulation entity. These events are stored in a timely-
ordered event list.
Fig. 2.6 illustrate main components of DEG in OAI. It can be seen that there is top level emula-
tion scheduler that controls the emulation progress and coordinates the execution of all the com-
ponents. 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 emu-
lator scheduler proceeds with the execution of the user-defined events followed by the periodic
events.
2.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. 2.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. 2.7. Either
nodes communicate via direct memory transfer (shared memory) or via IP multicast (over Eth-
ernet) depending on whether they are part of the same physical machine or not. From the point
8/17/2019 Cm Publi 4513
24/167
20 Chapter 2. OpenAirInterface : An Open Cellular Ecosystem
Emulation
DEG
Event Handler
(consumer)
Event Scheduler
(producer)
User Event List EVi
t=200ms
EV jt=500ms ...
EVnt=900ms
addremove
Periodic
EV1
Periodic
EV2
Periodic
EVm...
Emulation Scheduler
Figure 2.6: Discrete event generator of OAI emulation.
of view of the protocol stack, the data flow is transparent and that the network connectivity is
independent from the node distribution on a physical machine.
Real Application Client
Real Protocol Stack
PHY/RF Abst ract
Emulation Medium
Network Interface
Channel realization
Shared memory
…
Inst0
Inst1 Inst K
Real Application Client
Real Protocol Stack
PHY/RF Abstract
Emulation Medium
Network Interface
Channel realization
Shared memory
…
Inst0
Inst1 Inst K
Real Protocol Stack
PHY/RF Abstr act
Emulation Medium
Traffic/Mobility
Real Protocol Stack
PHY/RF Abstract
Emulation Medium
Traffic/Mobility
Real Protocol Stack
PHY/RF Abstr act
Emulation Medium
Traffic/Mobility
Real Protocol Stack
PHY/RF Abstract
Emulation Medium
Traffic/Mobility
Emulated data transport
through IP Multicast
Physical Machine 0 Physical Machine k…
Emulated or Real Network
Real Application Server
Shared Kernel (Host+ virtual instances) Shared Kernel (Host+ virtual instances)
Figure 2.7: Protocol vectorization and complex network experimentation based on the OAI emulation-
platform.
8/17/2019 Cm Publi 4513
25/167
8/17/2019 Cm Publi 4513
26/167
22 Chapter 2. OpenAirInterface : An Open Cellular Ecosystem
bandwidth than that of the signal bandwidth giving rise to the multi-state channel at the re-
ceiver. 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 [31, 32].
In OpenAirInterface the required parameters for large scale system simulations are highly dy-
namic 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. 2.9.
L2 ProtocolsPHY Procedures
OAI Network Interface
L3 Protocols
PHY AbstractionF(SNR, MCS)=P(BLER)
L2 Protocols
OAI Network Interface
L3 ProtocolsChannelRealization:
ENB2UE
Same IF
Uncoded msg
Channel DescriptorMobility Gen
C h a n n e l M o d e
l
P a t h L o s s
Same IF as
with RF
roce ures
PHY
Mod.
Coding Decoding
Demod.
Convolution
Signal
UE2ENBUncoded msg
Channel TraceEMOS
Parameterization
Processing
Figure 2.9: PHY Abstraction in System Performance Evaluation in OpenAirInterface
It can be seen from the Fig. 2.9 that there are two important steps in any evaluation using Ope-
nAirInterface, parameterization and processing. It is important to note that parameterizationis independent of the knowledge about the PHY abstraction. The output (channel realizations)
from parameterization step is given to the processing where the comparison between 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 probability from the instan-
taneous 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 thisBLER for taking the decision on the successful or unsuccessful transmission. Then the out-
come of this probabilistic experiment is passed to the higher layers which perform their tasks
8/17/2019 Cm Publi 4513
27/167
2.3 Build-in Emulation Platform 23
Table 2.1: SIMULATION TIMES DIFFERENT TRANSMISSION M ODES
Time in minutes and seconds
Full PHY PHY AbstractionTM 1
Total time 2m26.602s 0m6.794s
user CPU time 2m25.633s 0m6.480s
system CPU time 0m0.924s 0m0.328s
TM 2 Total time 4m1.607s 0m9.085s
user CPU time 3m59.079s 0m8.753s
system CPU time 0m1.940s 0m0.364s
TM 6 Total time 2m19.320s 0m7.027s
user CPU time 2m18.473s 0m6.752s
system CPU time 0m0.824s 0m0.300s
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 eN-
odeB 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 2.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 emulation.
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 throughputof the system over a given number of frames in Fig. 2.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 aspect
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.
8/17/2019 Cm Publi 4513
28/167
24 Chapter 2. OpenAirInterface : An Open Cellular Ecosystem
0 50 100 150 200 250 300 350 400 450 5000
500
1000
1500
2000
2500
Frames
T h r o u g
h p u t
[ k b p s
]
Full PHY
PHY ABSTRACTION
0 50 100 150 200 250 300 350 400 450 5000
200
400
600
800
1000
1200
1400
1600
1800
Frames
T h r o u g h p u t
[ k b p s ]
Full PHY
PHY ABSTRACTION
0 50 100 150 200 250 300 350 400 450 5000
500
1000
1500
2000
2500
Frames
T h r o u g h p u t
[ k b p s ]
Full PHY
PHY ABSTRACTION
Figure 2.10: Accumulated average system throughput over given number of frames: LTE Transmission
Mode 1 (left), Transmission Mode 2 (middle), and Transmission Mode 6 (right).
2.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 [33], like
Berlin LTE-advanced testbed [34] 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 [35] 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 theirsignal 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 [27],
Nuand bladeRF [36], and hackRF [37]. Hydra [38] is one such wireless testbed that is
implemented using GNU Radio and Ettus USRP [27]. 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 softwarein 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 [39] is a base station software that simulates an LTE core network with all the pro-
cessing 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 [40] 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 [41] is a MIMO waveform development platform that is capable of establishing
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 LTE UEs but
8/17/2019 Cm Publi 4513
29/167
2.5 Validation 25
it does not scale well and can only support low data rates. Recently, the PicoSDR has been
used at INRIA [41] 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 con-
sists 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) [42] is a wireless platform architecture for future mobile
handsets and battery operated devices as well as base stations for small cells. The architecture
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) [43] radio platform is an open development platform devel-
oped 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 2.3 provides a comparison among the commonly used platforms.
2.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 2.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
8/17/2019 Cm Publi 4513
30/167
26 Chapter 2. OpenAirInterface : An Open Cellular Ecosystem
Table 2.2: COMPARISON BETWEEN SDR S
Feature SORA WARP GNU Radio
+ USRP
(OpenLTE)
LTEENB Nutaq
PicoSDR
OAI
Open-
Source
Partial (for
academic
purposes
only)
Yes Yes No No Yes
Work with
commercial
LTE UEs ?
No No Yes No, Yes
for the
commercial
version
Yes Yes
Emulation
Capability
Yes Yes Yes Yes Yes Yes
Cost $8000 ;
Multi-corePC: $1000
,4x4 MIMO
Kit: $7000
$ 6000 $2000 $2000 $ 11000 $3200 4x4
MIMO, $1000 NI/Ettus
B210 without
host PC
Performance Upto 300
Mbps
54 Mbps 12 Mbps Downlink
60 Mbps ;
Uplink 25
Mbps
Upto 300
Mbps
Downlink 20
Mbps ; Up-
link 2 Mbps 1
Features Supports
802.11
a/b/g/n in
full data-
rate with4x4 MIMO
Supports
802.11
Supports
some features
of LTE
Implements
LTE release
8 with FDD
and a core
network emulation
Supports
LTE PHY
only
Supports
802.11n, LTE
E-UTRAN
(Rel. 8 and
10) and EPC(Rel. 9 and
10) in both
FDD and
TDD
Project Ac-
tive
Yes Yes Currently in
development
Yes (Com-
mer-
cialised by
Amarisoft)
Commercial Yes
Community
Size
50 aca-
demic
institutions
and several
ongoing
projects
Very pop-
ular with
several ac-
tive projects
( headed
by Mango
Communic-
tions)
Small com-
munity, avg 2
new threads
per week in
the forum
(low traffic)
No commu-
nity
No Com-
municty
30 academic
and industrial
institutions
and sev-
eral active
projects
Power Con-
sumption
450 W 200 W
(180+20)
USRP’s USRP’s 220 W 30W
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.
8/17/2019 Cm Publi 4513
31/167
2.6 Conclusion 27
Table 2.3: COMPARISON BETWEEN RF FRONTEND
Feature HackRF BLADERF-
FX40
BLADERF-
FX15
USRP-
B210
USRP-
X300
EXMIMO2
Radio
Spectrum
30Mhz -
6GHz
300 MHz –
3.8 GHz
300 MHz –
3.8 GHz
50MHz – 6
GHz
50MHz – 6
GHz
300 MHz – 6
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
Chip
MAXIntegratedLIME LIME AD AD LIME
Sample
Size (AD-
C/DAC)
8 bits 12 bits 12 bits 12 bits 14 bits 16 bits
Sample
Rate (AD-
C/DAC)
20MS/s 40MS/s 40MS/s 61Ms/s 200 MS/S ?
Interface USB2 USB3 USB3 USB3 SFP,ETH,PCIex4
PCIe x 1
FPGA
Logic
Elements
Yes CPLD 40K 115K 150K 325K -
400K
30K ?
Opensource all all all host code host code all?
Cost 300$ 400$ 650$ 1100$ 4000$ 4000$
Fig. 2.12 shows the two screen-shots of the connection manager of the dongle. It can be ob-
served 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 differ-
ent traffic patterns generated by D-ITG [44], namely 32, 125, 512, 1408 packet sizes (PS), and
1, 0.5, 0.25, and 0.1 inter-departure time (IDT).
Fig. 3.6 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.
2.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.2Video can be found at https://plus.google.com/+OpenairinterfaceOrg
https://plus.google.com/+OpenairinterfaceOrghttps://plus.google.com/+OpenairinterfaceOrg
8/17/2019 Cm Publi 4513
32/167
28 Chapter 2. OpenAirInterface : An Open Cellular Ecosystem
Internet
OAI Soft EPC
S+P-GW
SGi
OAI Soft eNBHSS MME
EXMIMO II
COTS UE
GPP
App
Server
OAI soft eNB in a PC(PC+EXMIMO II)
FDD TX/RXfilters Antenna
(2.6GHz)
Received constellationat eNB
Received Wiresharkmessages at eNB
Figure 2.11: Experiment setup and eNB hardware components and tools.
Figure 2.12: Validation Results
8/17/2019 Cm Publi 4513
33/167
2.6 Conclusion 29
1 2 4 1037.5
38
38.5
Number of Packets per Second
R T T ( m s )
RTT vs PS and IDT for setup 1
Packet Size 32
Packet Size 128
Packet Size 512
Packet Size 1408
1 2 4 1037.5
38
38.5
Number of Packets per Second
R T T ( m s )
RTT vs PS and IDT for setup 2
Packet Size 32
Packet Size 128
Packet Size 512
Packet Size 1408
Figure 2.13: Experiment 1
8/17/2019 Cm Publi 4513
34/167
30 Chapter 2. OpenAirInterface : An Open Cellular Ecosystem
8/17/2019 Cm Publi 4513
35/167
Chapter 3
Unified Scheduler Framework for
LTE/LTE-A
Modern mobile devices are capable of simultaneously running multiple internet applications.
Consider for example a user having video call on the mobile device. At the same instant
of time, there is a possibility of running several other applications such as video buffering,
online gaming, voice recognition, and email services. Each of this services has a respective
QoS requirement and therefore a dedicated radio bearer is established for each data flow and
mapped to a corresponding logical channel. As a result, a single user has buffer queued in
several logical channels in the same transmission time interval (c.f Fig. 3.1). Furthermore, the
queued buffer will expand into two dimensions (N × K ) when there are multiple active users inthe system requesting for several services. Here N and K refer to total number of active usersand total number of logical channels for each user, respectively. Each buffer element (n, k)has a specific QoS requirement and is characterized by several parameters with specific values
that are described in Section 3.1. All these parameters are crucial for buffer management and
scheduling algorithm.
User 2
Logical channel 1
(video call)
Logical channel 2
(video buffering)Logical channel 3
(Email service)
- - -Logical channel K
User 1
Logical channel 1
(video call)
Logical channel 2
(video buffering)
Logical channel 3
(Email service)
- - -Logical channel K
User N
Logical channel 1
(video call)
Logical channel 2
(video buffering)
Logical channel 3
(Email service)
- - -Logical channel K
-
-
-
-
Figure 3.1: Example of buffer queue for Multi-service offering
8/17/2019 Cm Publi 4513
36/167
32 Chapter 3. Unified Scheduler Framework for LTE/LTE-A
Most of the traditional scheduling frameworks have been designed to deal with users having
single service offering, meaning that they classify a user belonging to only one specific QoS
class and therefore apply the scheduling algorithm at the user level [45–47]. Such framework
would lead to inefficient buffer management and resource allocation, and achieve a sub-optimalsystem performance in multiple-service offering scenario. In the traditional MAC, the schedul-
ing algorithm optimally allocates resources to users based on the assumption of user belonging
to a single QoS. The proposed scheduler considers a multi-service users and as a result improve
the performance of MAC schedulers.
In this section, a scheduling framework that deals with the shortcomings of traditional static
MAC-layer scheduling is proposed to provide a more dynamic approach to satisfy the operator-
driven, technology driven and service-driven requirements through reconfigurable APIs. for the
analysis, the framework is applied to downlink resource allocation, but it can be easily extended
to uplink.
3.1 Scheduling Parameters
The scheduler is designed for all-IP packet switched networks and applied to the 3GPP LTE
eNB scheduler in downlink. In such networks, the buffer of a logical channel consists of packets
and the scheduling algorithm is applied to N users having K logical channels. Every logicalchannel is associated with a service belonging to specific QoS class. Depending up on the
service requests, there is a buffer queue in the respective logical channel of a user. In the
analysis, each user requests multiple services at the same time. Therefore, there can be multiplebuffer queues waiting to be scheduled. Each buffer queue is identified by a set of parameters
that are utilized for designing an optimal scheduling algorithm. The parameters are categorized
in four different groups depending up on their association.
3.1.1 Packet-Level Parameters
Packets are the data units that constitute the logical channels. Every packet has a set of prede-
fined parameters as follows:
• Average packet size in byte (APS): Packet size is dependent up on the type of servicebeing served such as ftp packets, browsing. For the analysis, average packet size for each
kind of service is considered.
• Packets inter-arrival time in ms (PIT): This gives the frequency of packets arrival inthe buffer queue which is also dependent up on the type of service.
• Packet arrival time in ms (PAT): It is the time-stamp of when the packet arrived in thebuffer queue.
• Packet maximum-allowable delay in ms (PMD): This is a predefined value for eachservice type. It is also referred to as the latency constraint.
8/17/2019 Cm Publi 4513
37/167
3.1 Scheduling Parameters 33
• Packet remaining time in ms (PRT): This is the time remaining before the packet willbe dropped from the buffer queue. It is dependent up on the packet arrival time, packet
maximum-allowable delay and current time.
3.1.2 Logical Channel-Level Parameters
These parameters characterizes the logical channel/service of a user.
• Number of protocol data units (NPDU): Every logical channel is composed of a num-ber of packets referred to as protocol data units (PDU).
• Head-of-line delay in ms (HOD): It is the time in buffer for the first packet in the buffer
queue of a logical channel.
• Buffer size of a logical channel in bytes (BS): This is the sum of the all the packet’ssize in a logical channel.
• Guaranteed bit-rate in Kbps (GBR): This is the minimum required bit-rate for eachservice type. There are few services that have non-guaranteed bit-rate.
• Traffic load (TL): This is factor for traffic modeling of a given service. It varies from 0to 1 where 0 means there is no traffic and 1 indicates continuous flow of traffic.
3.1.3 User-level parameters
The parameters associated with user are:
• Total buffer size in bytes (TBS): The sum of the buffer sizes for all logical channels of a user.
• Number of logical channels (NLC): It is the total number of active logical channelsor services of a user. Please note that NLC could also be represented by the number of
logical channel groupd (NLCG).
• Channel quality indicator (CQI): This is the channel quality feedback received fromphysical layer. It is an important factor for all channel aware schedulers.
• Subscription type (ST): When a user subscribed to a network operator, it has the optionof selecting one of the many subscriptions. Usually, the better the subscription type,
better is the promised data-rate. Three subscription types are considered in this analysis:
basic, silver and gold.
3.1.4 System-level parameters
These are the global parameters of a system.
8/17/2019 Cm Publi 4513
38/167
34 Chapter 3. Unified Scheduler Framework for LTE/LTE-A
• Number of active users (NU): It indicates the number of users that are active for trans-mission/reception in that particular transmission time.
•
Recommended