STUDY OF CLOUD RADIO ACCESS

NETWORK AND EDGE COMPUTING IN

HIGH-ALTITUDE PLATFORMS AND
NANOSATELLITES

Degree Thesis
submitted to the Faculty of the
Escola Tècnica d’Enginyeria de Telecomunicació de Barcelona
Universitat Politècnica de Catalunya
by
Isaac Grau i Nieto

In partial fulfillment
of the requirements for the degree in

Grau en Enginyeria de Tecnologies i Serveis de Telecomunicació

TELECOMUNICATIONS ENGINEERING

Advisor: Riccardo Bassoli and Luis Domingo Velasco Esteban

Barcelona, Date 31 of Jul 2021
Revision history and approval record

Revision Date Purpose

0 20/05/2021 Document creation
1 25/06/2021 Revision of chapter 1 and 2
2 05/07/2021 Revision of chapter 3
3 07/07/2021 Revision of chapter 4 added Abbreviations List
4 10/07/2021 Corrected chapters 1-3 added Appendices
5 14/07/2021 Corrected chapter 4 added chapters 5-6
6 16/07/2021 Final Version

DOCUMENT DISTRIBUTION LIST

Name E-mail
Isaac Grau i Nieto grauisaac57@gmail.com
Riccardo Bassoli riccardo.bassoli@tu-dresden.de
Luis Domingo Velasco Esteban lvelasco@ac.upc.edu

Written by: Reviewed and approved by:

Date 16/07/2021 Date 16/07/2021
Name Isaac Grau i Nieto Name Riccardo Bassoli
Position Project Author Position Project Supervisor

2
Abbreviations
3GPP 3rd Generation Partnership Project
4G Fourth Generation
5G Fifth Generation
6G Sixth Generation
AI Artificial Intelligence
AR/VR Virtual Reality
B5G Beyond 5G
BBU Base-band Unit
BS Base Statiom
CN Core Network
CPRI Common Public Radio Interface
CRAN Cloud Radio Access Network
CSV Comma-Separated Values
CU Central Unit
DDBB Data Bases
DU Distributed Unit
eMBB enhanced Mobile Broadband
eNB E-UTRAN NodeB
EPC Evolved Packet Core
FER Frame Error Rate
HAPS High Altitude Platform Station
HSS Home Subscriber Server
ICT Information and Communication Technologies
IoE Internet of Everything
IoT Internet of Things
KPI Key Performance Indicator
KVM Kernel Virtual Machine
LTE Long Term Evolution
MME Mobility Management Entity

3
NFV Network Functions Virtualisation
NIST National Institute of Standards and Technology
OAI Open Air Interface
OAI-CN Open Air Interface Core Network
ONF Open Networking Foundation
OPEX Operating Expenses
OSA OpenAirInterface Software Alliance
PLMN Public Land Mobile Network
RAN Radio Access Network
RB Resource Block
RF Radio Frequency
RRH Remote Radio Heads
RTT Round-Trip Time
RU Radio Unit
SDN Software-Defined Networking
SPGW Serving Gateway and Packet Data Network Gateway
SSH Secure SHell
STCP Stream Control Transmission Protocol
TDP Thermal Design Power
UAV Unmanned Aerial Vehicle
UE User Equipment
URLLC Ultra Reliable Low Latency Communications
vBBU virtual Base-Band Unit
vCPU virtual Central Processing Unit
VLAN Virtual Local Area Network
VM Virtual Machine
VoIP Voice over IP
VPS Virtual Private Server
WSL Windows Subsystem for Linux

4
Acknowledgments
This project marks the end of one of the most important parts of my life. It fills me with
great pride to say that I was able to accomplish this goal with effort and determination.
During these past four years, I was never alone, and that is why I want to thank all those
people who have helped and accompanied me before and during this crucial journey.
First of all, I would like to thank my parents and brother for believing in me in the most
challenging moments of this degree, for helping me when I needed it the most and, above
all, for encouraging me always to go a little further. Thanks for everything. Without you,
I would not be the person I am today, and this would have never been possible.
Thanks to my friends for supporting me and always being there even when distance
temporarily separated us. It does not matter how much time goes by without seeing
each other because I know I can always count on you.I am grateful to everyone who put
everything aside to help me during this project. I really owe you one.
Thanks to the new friends I made during my stay in Germany. You have been a great
support in this little adventure, and I am very sure that this is only the beginning of a
great friendship. Thanks to all my classmates with whom I shared this degree. I will never
forget all the moments we spent together, from classes to laboratory practices and exams.
I am grateful to all the professors and tutors who guided me during the completion of
this work and throughout my training to achieve this incredible goal.
Last but not least, I would like to express my thanks and appreciation to Riccardo Bassoli,
Stefano Bonafini and Koteswararo Kondepu for their tremendous help and meticulous
attention during this project’s realisation. Thank you, guys, very much. Without you, it
would have never been possible.
A special thank goes to the person who helped me the most during the thesis. Thank you
for the long calls at any time of the day, for always being there to do your best and for
opening the door to me to a world of knowledge in the easiest way possible. Thank you,
Kote, for all the support during these months. Thanks, boss!!

5
Abstract
Nowadays, mobile communication networks are an essential part of our lives. They are
present in both our personal and professional lives. The current networks are not prepared
to support the population’s future needs, such as having a reliable connection anytime
and anywhere.
The project shows an empirical design accompanied by a simulation and emulation plat-
form for 3D networks based on UAVs and nanosatellites using functional virtualization
of split B. In this regard, a completely virtualized test system has been created to attain
the main objective of this study, i.e. to verify the results of previous theoretical studies
on the virtualization of this split. Through a sample of the orbital arcs and the use of
the experimental evaluation platform designed here, it has been possible to promisingly
estimate the virtualization behaviour of this functional split.
This study provides a new experimental tool in research on functional splits and verifies
the operation of a split B in a virtualized 3D network scenario.

6
Contents
List of Figures 9

List of Tables 10

1 Introduction 11
1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Objectives and contribution . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Structure of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 State of the art 15

2.1 Fifth Generation (5G) Technology . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.2 Main Fifth Generation (5G) Targets . . . . . . . . . . . . . . . . . 16
2.1.3 Technology Components . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.4 Fifth Generation (5G) Capabilities . . . . . . . . . . . . . . . . . . 17
2.1.5 Use Cases of Fifth Generation (5G) . . . . . . . . . . . . . . . . . . 17
2.1.6 Evolution Path from Fifth Generation (5G) to Sixth Generation (6G) 18
2.2 Network Softwaritzation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1 Software-Defined Networking (SDN) . . . . . . . . . . . . . . . . . 18
2.2.2 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.3 Network Function Virtualisation . . . . . . . . . . . . . . . . . . . . 19
2.3 Baseband Unit Virtualitsation and Spliting . . . . . . . . . . . . . . . . . . 20
2.4 High Altitude Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 First Approach to 6G Technology . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.1 Specifications and Requirements . . . . . . . . . . . . . . . . . . . . 23

3 Implementation of the Scenario using Open Air Interface (OAI) 25

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 OAI (OpenAirInterface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Implementation of the System in DigitalOcean . . . . . . . . . . . . . . . . 26
3.3.1 Preparation Virtual Machines . . . . . . . . . . . . . . . . . . . . . 26
3.3.2 Installation of Openair-CN . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.3 Installation of Open Air Interface (OAI) . . . . . . . . . . . . . . . 30
3.4 Configuration of EPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.1 Database Installation and Configuration . . . . . . . . . . . . . . . 32
3.4.2 First Initialization of HSS, MME, and SPGW . . . . . . . . . . . . 33
3.5 Configuration of the vBBU split . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.1 CU configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.2 DU configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6 Configuration of UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7 Running and testing the system . . . . . . . . . . . . . . . . . . . . . . . . 38
3.7.1 Conclusion of the preliminary testing . . . . . . . . . . . . . . . . . 40

7
4 Design and Implementation of the Evaluation Platform 41
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Design of the evaluation platform . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.1 Remote Connection to Cloud Servers . . . . . . . . . . . . . . . . . 42
4.2.2 Emulation Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.3 Data Parser Script . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3 Implementation of the evaluation platform . . . . . . . . . . . . . . . . . . 45
4.3.1 Code Structure and Workflow . . . . . . . . . . . . . . . . . . . . . 46
4.3.2 Implementation of the Evaluation Platform . . . . . . . . . . . . . . 47
4.3.2.1 Statics Script Implementation . . . . . . . . . . . . . . . . 48
4.3.2.2 Testing Script Implementation . . . . . . . . . . . . . . . 49
4.3.2.3 Main Script Implementation . . . . . . . . . . . . . . . . . 51
4.3.3 Implementation of the Data Processor Script . . . . . . . . . . . . . 51
4.4 Running and Testing the Evaluation Platform . . . . . . . . . . . . . . . . 52

5 Results 54
5.1 Metrics and Energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.1 CPU and RAM memory Metrics . . . . . . . . . . . . . . . . . . . . 54
5.1.2 Energy Consumption of the System . . . . . . . . . . . . . . . . . . 56
5.2 Split Latency and Throughput . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3 End to End Latency and Throughput . . . . . . . . . . . . . . . . . . . . . 58
5.4 Frame Error Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6 Conclusions and Future Work 61

References 63

Appendices 67
.1 OAI-CN Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . 67
.2 OAI5G Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
.3 Complete code of the developed emulator . . . . . . . . . . . . . . . . . . . 67
.4 Expanded results and raw data of all the experiments performed . . . . . . 67

8
List of Figures
1 Data and Voice comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Key Fifth Generation (5G) technology components. . . . . . . . . . . . . . 16
3 Summary of Fifth Generation (5G) technology capabilities. . . . . . . . . . 17
4 Basic CRAN architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5 Basic requirements of different virtual BBU splitting configurations. . . . . 21
6 A simplified scheme of a CubeSat’s relative movement with respect to a
hovering UAV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7 System to simulate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8 Dashboard of DigitalOcean Project Account with the 4 servers up . . . . . 26
9 Deployment diagram with main connections and interfaces . . . . . . . . . 27
10 Commands for configuring virtual interfaces . . . . . . . . . . . . . . . . . 28
11 Connection scheme with interfaces and IP addresses . . . . . . . . . . . . . 28
12 DockerHub main repo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
13 Kernel 4.71 installation on ubuntu 16.04 . . . . . . . . . . . . . . . . . . . 29
14 Commands to recreate EPC certificates . . . . . . . . . . . . . . . . . . . . 29
15 Openairinterface5G cloned on local computer . . . . . . . . . . . . . . . . . 30
16 Changing the branch on CU, DU and UE VM . . . . . . . . . . . . . . . . 30
17 Commands for the compilation of CU, DU and UE OAI software . . . . . . 31
18 MYSQL installation commands . . . . . . . . . . . . . . . . . . . . . . . . 32
19 MYSQL service check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
20 PHPMYADMIN panel accessed from the internet showing the user database
already loaded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
21 Permissions initialization script and MYSQL and PHPMYADMIN execution 33
22 Command to run HSS component . . . . . . . . . . . . . . . . . . . . . . . 34
23 Command to run MME component . . . . . . . . . . . . . . . . . . . . . . 34
24 Command to run SPGW component . . . . . . . . . . . . . . . . . . . . . 34
25 EPC generated interface for OAI use . . . . . . . . . . . . . . . . . . . . . 34
26 CU configuration for MME connection using Virtual Local Area Network
(VLAN)0 as the interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
27 DU link configured on CU config file as unique DU . . . . . . . . . . . . . 36
28 DU network configuration. Link with CU using Virtual Local Area Network
(VLAN)1 as interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
29 SIM configuration in the UE VM with HSS validated data . . . . . . . . . 38
30 Command to activate the SIM in lte-uesoftmodem . . . . . . . . . . . . . . 38
31 Commands to execute CU and DU functions . . . . . . . . . . . . . . . . . 39
32 MME showing an eNB successful connected to the CN . . . . . . . . . . . 39
33 Commands to execute the UE . . . . . . . . . . . . . . . . . . . . . . . . . 39
34 MME showing a UE successful connected to the CN . . . . . . . . . . . . . 39
35 Interface created by OAI in the UE to connect with the CN . . . . . . . . 40
36 Ping from UE to EPC using the interface created by OAI . . . . . . . . . . 40
37 Delay vector data in orange the worst case, the case studied in this thesis. 41
38 Macro-block structure of the evaluation platform design . . . . . . . . . . . 42
39 Creating an ssh key pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
40 Installation of the public key on a system server . . . . . . . . . . . . . . . 43

9
 41 Extended diagram of blocks 2,3,4 figure 38. Temporal workflow of the em-
ulator code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
42 Output of data parsing script results . . . . . . . . . . . . . . . . . . . . . 45
43 Main script operation diagram . . . . . . . . . . . . . . . . . . . . . . . . . 46
44 Circular workflow of each iteration performed by the system . . . . . . . . 47
45 Files of the source code of the evaluation platform . . . . . . . . . . . . . . 48
46 Recursive process deletion function with delete check . . . . . . . . . . . . 49
47 Function to start a remote process and save the output to a local file . . . 49
48 Function in charge of managing constants definitions . . . . . . . . . . . . 50
49 Main code of the evaluation platform . . . . . . . . . . . . . . . . . . . . . 51
50 Creating the data matrix from the data processing script . . . . . . . . . . 52
51 Evaluation platform running at the top CSV of results on the left folder of
historical data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
52 Satellite movement diagram and communication windows calculation. . . . 54
53 CPU usage for deployed Droplet. . . . . . . . . . . . . . . . . . . . . . . . 55
54 RAM memory usage for deployed Droplet. . . . . . . . . . . . . . . . . . . 56
55 Split B UpLink and DownLink Latency. . . . . . . . . . . . . . . . . . . . 57
56 End-to-end UpLink and DownLink Latency. . . . . . . . . . . . . . . . . . 58
57 End-to-end UpLink and DownLink Latency Throughput. . . . . . . . . . . 59
58 FER Histogram (h=350km). . . . . . . . . . . . . . . . . . . . . . . . . . . 60
59 FER Histogram (h=150km). . . . . . . . . . . . . . . . . . . . . . . . . . . 60

List of Tables
1 Comparison of 6G with 4G and Fifth Generation (5G) communication sys-
tems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

10
1 Introduction
1.1 Context
Today mobile communication systems and data transfers are becoming more and more
important in our lives and our commercial and business relationships. Recently, due to the
pandemic suffered during 2019 and 2020, we have reaffirmed the need to evolve communi-
cation networks. Since December 1998, with the creation of the 3rd Generation Partner-
ship Project (3GPP), experts from all over the world have been developing this technology.
The development of wireless cellular networks has now reached Fifth Generation (5G).
One of the main problems of future communications is to achive high reliability, data-
rates, and network availability, together with very low latency. The 3GPP mentioned above
specifies the deployment time of 5G networks in a short time (90 minutes or less) in remote
and rural areas. Unmanned Aerial Vehicle (UAV)s could be among the key technologies
for this quick deployment in remote areas and in devastated regions in case of emergency
or natural disaster. For example, referring to the last concept, we might use drones as
mobile Base Statiom (BS)s, the edge network realised rid High Altitude Platform Station
(HAPS), (as drones or air balloons delivering backhaul/fronthaul connectivity and service
in the demanded area).
This concept also relies on the edge computing paradigm. This is focused on the dynamic
deployment of services close to the users via network softwaritzation. However, this system
nowadays is not completely standardised, and its worldwide deployment is still on going
work.
This thesis investigates the employments of UAVs and HAPs (specially nanosatellites)
towards the realisation of 3D networks in future systems. As we have seen in this brief
introduction, it will allow for quiet greater network and service availability and resilience
in the future.

11
1.2 Motivation
In the next generation of mobile communications (Sixth Generation (6G)), 3D networks
will be used to guarantee seamless connectivity and network every time and everywhere.
As we know, these 3D networks will allow flexibility in the networks that currently does not
exist. This deployment is not feasible because, as we know in terms of energy, computing,
and other resources, it is not feasible to implement a mobile network in UAVs and HAPS.
The solution could go through a sofwaritzation of the network to create a system deployed
in a network with a structure like the one described in the articles shown below. These
articles are among the first publications to offer a design line for 6G 3D network systems.
1. A Novel Paradigm for On-Demand Anytime/Anywhere Connectivity. Riccardo Bas-
soli, Fabrizio Granelli, Claudio Sacchi, Stefano Bonafini, and Frank H.P. Fitzek
2. Virtual Baseband Unit Splitting Exploiting Small Satellite Platforms. Riccardo Bas-
soli, Fabrizio Granelli, Stefano Bonafini, and Frank H.P. Fitzek
However, the virtualitzation of 5G Radio Access Network (RAN) in 3D scenarios is still
an open issue, which requires further analysis and more experimental results to approach
to its realisation.For this reason, this thesis’s motivation is to investigate this field of
future networks that currently remains, in many aspects, something unknown to most
researchers.

12
1.3 Objectives and contribution
The main scope of this thesis is to provide an experimental evaluation of RAN virtuali-
sation in a 3D networking scenario composed by UAV and nanosatellite.
To be able to make this contribution, the objectives detailed below have been addressed.
1. Creation of a fully virtualised and distributed system in the cloud to simulate the
Network Functions Virtualisation (NFV) capabilities and the specifications of a 3D
network
2. Implementation of the software Open Air Interface (OAI) in the Virtual Private
Server (VPS)s to accurately simulate an entire mobile communication system. At
this point, the objective is to deploy a complete end-to-end system considering all the
components of a mobile network: Mobility Management Entity (MME), Home Sub-
scriber Server (HSS), Serving Gateway and Packet Data Network Gateway (SPGW).
3. Simulation of the propagation delays considering different orbital data of the various
proposed altitudes for the nano-satellite network. Code, implement and test a new
emulation platform to perform the massive test in the cloud system deployed to get
data for later analysis.
4. Development of a system for detailed evaluations of a type B functional split. This
split in 3D networks has never been invested experimentally in the literature.

13
1.4 Structure of the thesis
The outline of the thesis follows.
1. Introduction
This chapter first provides information about the context in which you are going
to work. This is followed by the motivation to realize the project and, finally, the
objectives that we seek to achieve.
2. State of the art
This chapter surveys the current status of the research on 5G and 6G technology
and the underlying systems that make possible a 3D network (virtual Base-Band
Unit (vBBU) functional splits, HAPS).
3. Implementation of the scenario using OAI
This chapter shows how the virtualized system with OAI has been deployed, and
the structure of virtual machines used to make the simulation as faithful to reality
as possible. All the design decisions made during the deployment are also discussed.
A first proof of concept of the system is also provided to test the operational validity
of it.
4. Design and implementation of the evaluation platform
This chapter details the design and coding of the entire evaluation platform. In the
first part, we can find the management of the servers and the collection of metrics
by the program that later in the data analysis phase are processed to obtain the
desired results.
5. Results
A detailed discussion of the results obtained in the previous chapter is carried out.
6. Conclusion
This last chapter overviews the thesis’ achivements in respect to the objectives,
finally showing some possible future research works.

14
2 State of the art
2.1 5G Technology
2.1.1 Introduction
Networks have been experiencing an exponential growth in the amount of traffic carried
through mobile networks. According to the Cisco visual networking index (Figure 1),
mobile data traffic has doubled during 2010–2011. Following the described trend for the
rest of the decade, we can conclude that global mobile traffic will increase 10000x from
2020 to 2030 [1]. The growth rate of mobile data traffic is rising much more than voice
traffic. Global mobile voice traffic was overtaken by mobile data traffic in 2009. And
the forecast is that the Voice over IP (VoIP) traffic will represent an insignificant part
of all mobile data traffic. In 2020, the number of subscriptions reached 9.68 billions [2],
corresponding to a global penetration of 124%, assuming a global population of 7.8 billions
in 2020. The ever-growing global subscriber rate and the world population growth will
place stringent new demands on potential 5G and beyond networks to support one billion
users.

Figure 1: Data and Voice traffic from 2008 to 2015.

5G and beyond networks represent the next step in future communications. Up to now, the
mobile network provided connectivity for smartphones and laptops, among other devices.
5G will take the current mobile network to the next level regarding data rates, availability
and capacity. In addition, 5G will enable new services like industry 4.0 and Internet
of Things (IoT), together with critical communication. The Key Performance Indicator
(KPI)s of the new generation are data rates up to 10 Gbps, and capacity increases up to
1000 times with flexible platforms for device connectivity, ultra-low latency (1-10ms) and
99.9999% reliability.

15
2.1.2 Main 5G Targets
The three groups of verticals considered in 5G are extreme mobile broadband (xMBB),
massive Machine Type Communications (mMTC), and Ultra Reliable Low Latency Com-
munications (URLLC). xMBB focuses on high data rates with a minimum capacity of 100
Mbps. mMTC are focused on providing connectivity to millions of devices. Next, URLLC
mainly aims at providing a very low latency (less than 1ms) with ultra-high 99.9999%
reliability. [1]

2.1.3 Technology Components

The goals of 5G networks exceed the capability of current mobile networks. All of those
goals necessitate the development of several new technologies. Figure 2 depicts the primary
new technology components.

Figure 2: Key 5G technology components. [1]

New Spectrum. 5G is the first mobile radio technology to operate in any frequency
range between 400MHz and 90GHz. The low bands are required for coverage, whereas the
high bands required for high data rates and capacity.
Network Virtualization Thanks to the new Software-Defined Networking (SDN) net-
works and the NFV system, we can implement our communication systems in the cloud
quickly, cheaply and versatile. These two techniques combined create an easy-to-manage
structure that can be adapted to almost any circumstance if the need to make changes to
the 5G network hardware.
Network Slicing. The physical and protocol layers in 5G must be versatile to accom-
modate multiple use cases, various frequency bands and maximise energy and spectrum
efficiency. Network slicing will establish virtual network segments for different services
that will operate within the same 5G network infrastructure.
Dual connectivity and Long Term Evolution (LTE) coexistence. 5G can be in-
stalled as a stand-alone system, but it is more likely to be implemented alongside LTE in
the early stages. A 5G device can have 5G and LTE radio connections active at the same
time.

16
Support for cloud implementation and edge computing. The present LTE network
design is dispersed in the radio and completely centralised in the core network. Because
of the low latency, the material must be carried near the radio, resulting in local breakout
and edge computing. Scalability necessitates bringing cloud benefits to radio networks via
edge cloud architecture.

2.1.4 5G Capabilities
Compared to LTE radio, 5G radio can significantly improve network performance and ef-
ficiency; see Figure 3 for an overview. We anticipate much better data rates, demonstrably
reduced bit costs, more spectrum efficiency, greater network energy efficiency, increased
IoT device power efficiency, and lower latency. Figure 3 shows the 5G KPIs previously
mentioned.

Figure 3: Summary of 5G technology capabilities. [1]

2.1.5 Use Cases of 5G

5G networks offer a slew of new applications for consumers, businesses, residences, and
public spaces. 5G data rate can enhance the video experience, gaming and other appli-
cations, and Virtual Reality (AR/VR) and augmented reality. Lower latency and better
bandwidth can improve the cloud gaming and sports broadcasting experience, the high
data rate, low latency, and extreme dependability enable many industrial applications,
such as industrial automation with low latency robot control, remote control of machines,
and traffic control, including support for autonomous driving. 5G adds new capabilities to
public safety networks, agricultural automation, health care monitoring, and fixed wireless
connectivity for households and small businesses. [3]
Also, thanks to the new implementations offered by 5G, solutions for critical scenarios
have been created. Some of them are natural disasters, where the communication network
can be wholly devastated or the DAVOSS project (DAVOSS is part of NATO Science for
Peace and Security Program) with which this thesis collaborates. The DAVOSS project
aims to develop a multi-layer virtualised system. All the above-mentioned technologies
can operate together to guarantee efficient and effective borders and ports surveillance or
environmental security. Fleets of UAVs can allow border security agencies to deploy fewer

17
agents while keeping the capability to detect intruders, using the freed agents to respond
effectively to newly-detected threats. [4]

2.1.6 Evolution Path from 5G to 6G

When establishing wireless networks, coverage is a significant KPI. Before Fourth Gen-
eration (4G) networks, most efforts were concentrated on expanding connection capacity
while providing adequate coverage in the two-dimensional (2D) plane. With its multi-
dimensional scenarios, 6G imposes stringent KPIs since low latency and high reliability
(URLLC), vast amounts of devices (enhanced Mobile Broadband (eMBB)), range ex-
pansions, and communication infrastructure Operating Expenses (OPEX) [2] should be
reduced in 3D networks. Through the notion of network slicing, 5G enables the coexistence
of heterogeneous services sharing the underlying same infrastructure.
As automation grows and the usage of virtual reality expands, so does the demand for
quicker, more secure communication. Because of the worldwide pandemic [5], hypercon-
nectivity, or the tendency toward online work and communication, has intensified. Entire
businesses and sectors have shifted to online working. People turn from video conver-
sations to online games when the workday is done. Participation in online gaming has
increased dramatically, from virtual reality games to massively multiplayer immersive ex-
periences. Colleagues no longer gather to work in an office building or watch a sports
stadium game. They go online to meet coworkers, drive virtual racing cars, or cheer on
their favourite rock singers at a virtual performance in millions of homes.Robotic surgery,
tele-doc services, and online meetings are just a few instances of how technology is being
used in new and more effective ways. However, each new implementation puts a burden
on available processing power and communication connections.

2.2 Network Softwaritzation

The 5G and 6G networks promise an increase in the number of connected devices and
the capacity of the networks. In addition to traditional voice and data communication,
this communication revolution will enable integrated service delivery of numerous killer
apps, such as AI, AR/VR, and autonomous driving, among others. The 5G network
uses NFV and network slicing to improve its functional and architectural viability in
response to rapidly changing user service requirements and highly mixed traffic. NFV is
a new paradigm that virtualises (softwarizes) network functions that were implemented
in dedicated hardware. [6] [7]

2.2.1 SDN
SDN are a novel technology that has changed the way in which they are designed, and data
networks operate. In SDN, it is software-based applications that determine the behaviour
of the network, being able to modify the state of the same according to your needs [8].
Furthermore, these applications can be created independently of software and network
device development companies.
The Open Networking Foundation (ONF) is the leading organisation dedicated to pro-

18
moting and adopting SDN by developing open standards. The organisation defines SDN
technology as an emerging network architecture, where the control of the network is de-
coupled from forwarding and is directly programmable [7].
SDN enables the implementation of more flexible, scalable, efficient and adaptable net-
works.
An essential element within the SDN architecture is the controllers [9] [10]. Controllers
(centralised or distributed) can be software systems or collection of functionalities which
manage the flows in the data plane. The control protocol used is OpenFlow. The SDN
controller delivers changes to the switch/router flow-table through this interface, allowing
network managers to divide traffic, regulate flows for maximum performance, and begin
testing new configurations and applications. The protocol is made up of a series of mes-
sages sent from the controller to the switch and a similar collection of messages sent in
the other direction. The messages together allow the controller to program the switch
to allow fine-grained control over user traffic switching. Flows are defined, modified, and
deleted in the most fundamental programming [11].

2.2.2 Cloud Computing

Cloud Computing is a model that conveniently enables on-demand access across the net-
work to a shared set of configurable computing resources (e.g., networks, servers, storage,
applications, and services). The cloud computing model promotes availability and com-
prises five essential characteristics: customer self-service on-demand, broadband network
access, resource concentration, rapid elasticity, and accounted service [12].
The cloud runs for example virtualized resources, supported by computational and storage
capacities, provided according to the client’s needs. The National Institute of Standards
and Technology (NIST) [12] proposes a reference architecture based on the action of five
elements: cloud consumer, cloud auditor, cloud provider, cloud mediator and cloud carrier,
which make up the cloud ecosystem.
Cloud computing is an effective resource for the testing and implementation of most of
the network softwaritzation paradigms because of the flexibility of the technology for the
rapid deployment of new services, its easy scalability and because it allows for sharing
resources. This makes cloud computing the best candidate for increasing NFV deployment
while reducing operational and maintenance costs, a goal pursued by telecommunications
service providers.

2.2.3 Network Function Virtualisation

The term virtualisation is widely used in Information and Communication Technologies
(ICT), to mean mainly the softwaritzation of the network operations and functions. Vir-
tualisation can be considered a strategy that allows sharing physical resources and hence
it becomes fundamental in the future multi-tenant and heterogeneous scenarios.
Virtualisation creates a virtual mapping of physical resource. Through this method, it is
possible to improve the flexibility and programmability of a system. With virtualisation,

19
it is possible to start from a single physical set of resources and operate them as several
independent resources [13].
An essential element within virtualisation is the hypervisor or virtual machine monitor.
This consists of a software platform through which various virtualisation control tech-
niques can be applied to allow different operating systems to be used on the same com-
puter simultaneously, where each operating system seems to have the processor, memory,
and others computer resources. However, the hypervisor is actually the one that controls
the central processor and the rest of the resources, allocating what is needed for each oper-
ating system and ensuring that the guest operating systems (within the Virtual Machine
(VM)) cannot interrupt each other. Hypervisors can be classified into two types [14]:
• Type 1: Also called a native hypervisor or bare metal (bare metal), it is software
that runs directly on the hardware to offer the functionality described above. Some
of the most popular type 1 hypervisors are Kernel Virtual Machine (KVM), VMware
ESXi, VMware ESX, Xen, Citrix, XenServer, Microsoft Hyper-V Server and Oracle
VM.
• Type 2: Also called hosted hypervisor, the software runs on top of an operating
system to offer the described functionality. Some of the most used type 2 hypervisors
are Virtual Box, VMware Workstation, VMware QEMU, Microsoft Virtual Server.
Apart from VMs, we can find several types of virtualization, such as containers and uniker-
nels. A container consists of grouping and isolating applications or groups of applications
that run on the same operating system kernel.A unikernel is a single-purpose operating
system and the ideal library operating system, providing the developer with components
from which to build the minimal hardware interfacing layer. A unikernel introduces a
switch from runtime to compile time configuration. It literally employs only the functions
required to make an application work [15].

2.3 Baseband Unit Virtualitsation and Spliting

As we have seen in previous sections, 5G is becoming a reality today, and is preparing to
host several hundred times the current LTE systems capacity. To archive this goal, Cloud
Radio Access Network (CRAN) has a critical role. The most significant part of the RAN
functionalities are performed by the Base-band Unit (BBU), which is connected directly
to the Radio Unit (RU) which has only Radio Frequency (RF) functionalities [16].
The CRAN will request a very high capacity and a low latency from the fronthaul network
that enables the communication between the BBUs and the Remote Radio Heads (RRH).
The network will also need a very high density of access points to meet the demand for
the high data speed expected by users [17].
To solve these problems, several professionals and researchers have worked on studying
various types of split where the lower-layer functions of the RAN protocol stack can be
distributed and outsourced to the cloud. In Figure 4, we can see the basic architecture of
future CRAN [18].

20
 Figure 4: Basic CRAN architecture. [18]

Once virtualised, it is also possible to split the BBU into sub-functions. There are several
functional Split configurations ordered alphabetically from A to E. In Figure 5, we can
see the basic requirements of different BBU splitting configurations.

Figure 5: Basic requirements of different virtual BBU splitting configurations. [16]

21
Throughput and latency constraints are somewhat eased when higher-level functions are
virtualized in the cloud. It is clear that separating lower layer functions (i.e. Split A,
B, and C) [19] [16] need very high throughput and low latency. Figure 5 depicts the
requirements for throughput and latency for the various degrees of vBBU splitting these
requirements are set by the reference standard called the Common Public Radio Interface
(CPRI), which govern the link between the antenna and the BBU in a BS.

2.4 High Altitude Platforms

As we have seen, 6G networks are seeking 100% global coverage and increasingly seek
to be easy to deploy and have the ability to adapt in extreme situations to guarantee
communications wherever and whenever. This implies that the networks must not only
be present in cities and populated areas, but we also have to be able to ensure coverage in
places where there is no terrestrial network and where, in some cases, it will be impossible
to deploy it [20] [5] [17].
Recently, unmanned aerial vehicles and drones have been used to deploy base stations in
complex or difficult-to-access areas. Although this solution fulfils the objective of moving
communications in areas of difficult access, it still requires a terrestrial network to con-
nect [21]. This limits although do not solve the problem of a global network with 100%
coverage that is capable of adapting to any emergency situation or user mobility [17].
As we have said so far, UAVs have been used to ensure cellular coverage in remote areas,
but mounting an entire BS on a drone is not optimal or just functional considering that
the RAN is the most complex part of a system [19].
It is for this reason that during the realization of this project, a 3D communication system
will be used where part of the RAN functionalities will be hosted in a nano-satellite at
different altitudes (Figure 6). In order to simulate a real and functional structure, several
studies define that it would be possible to create a functional split of the BBU between a
satellite and a drone.

Figure 6: A simplified scheme of a CubeSat’s relative movement with respect to a hovering UAV. [20]

22
2.5 First Approach to 6G Technology
Nowadays, we are living in a society looking for fully automated and remote managed
systems, this change with promoting a rise in new technologies like Artificial Intelligence
(AI) or IoT and the new Internet of Everything (IoE). However, as we have seen in the first
part of the chapter, these new technologies will increase traffic volume considerably [2].
The current 5G networks cannot assume the workload of a wholly automated and intel-
ligent way of life. It has to provide everything as a service and a completely immersive
experience. The 5G technology has come out which several new features, but the fast
growth of these data-centric and automated systems will overpass the possibilities of our
system capabilities. For example, specific devices offering Virtual Reality Real-Time Com-
munication need to go over 10 Gbps and they need to have high reliability and availability,
to work with no problems. Because of these, we need to go beyond 5G (B5G) [22] [23].
To deal with the limitations of 5G and develop a new system able to have all the capa-
bilities and the reliability that we need the main point will be, the convergence between
all the actual features, the network densifications, high reliability and capability, and fi-
nally the low consumption of energy. The 6G system also will follow the trends of the
technologies that preceded it [2]. This relation includes new services and the appearance
of new inventions and technologies that will require a more robust, stable and worldwide
network. The main requirement in the new system is to ensure the capability the handle
massive volumes of data while maintaining and improving a high-data-rate connectivity
per device.

2.5.1 Specifications and Requirements

5G technologies have improved in many areas such as throughput, delay, deployment
costs, reliability and hardware complexity. Still, considering the current demand of the
communications market, it is very likely that before 2030 this system will not be able
to supply the demand requested by users. Therefore, looking into previous trends and
forecasting future need, the main objectives for 6G systems are global connectivity using
HAP, as seen in earlier points of this thesis. Also, others main objectives are extremely high
data rates, lowering energy consumption, connected intelligence with machine learning
capability. Table 1 [2] shows a comparison of 6G with current mobile communications
technologies (4G and 5G).
As we know, several studies have anticipated that 6G, although it could maintain many
of the current KPIs of the 5G system, will need many new ones. In the Beyond 5G (B5G)
system, the objective also exceeds the limits of current technology, seeking to increase
the system’s capacities by a factor of 10-100 compared to the previous communications
system.
Some of the leading researchers in 6G technology set the KPIs, named above, in the
following objectives [24] [3]:
• A peak data rate of 1 Tbps
• Traffic increase of 10.00 times

23
 Issue 4G 5G 6G
Per device peak data rate 1 Gbps 10 Gbps 1 Tbps
E2E latency 100 ms 10 ms 1 ms
Maximum spectral efficiency 15 bps/Hz 30 bps/Hz 100 bps/Hz
Mobility support Up to 350 km/hr Up to 500 km/hr Up to 1000 km/hr
Satellite integration No No Fully
AI No Partial Fully
Autonomous vehicle No Partial Fully

Table 1: Comparison of 6G with 4G and 5G communication systems.

• The battery lifetime of 20 years

• Device connectivity of 100/m3
• Radio latency of 0.1 ms
• The energy efficiency of 10 times
• 10 cm indoor and 1 m outdoor precision in positioning
• A maximum outage of 1 out of 1 million
The original 6G KPIs may be divided into technology and productivity-driven KPIs and
sustainability and societal-driven KPIs.
The first category contains KPIs for jitter, connection budget, extended range/coverage,
3D mapping, mobile broadband, positioning accuracy, cost, and energy savings.
The second category has KPIs for various facts, including standardisation, privacy/se-
curity/trust, open-source everything, ethics, intelligence, and global use case. The KPIs
relating to capacity, spectrum efficiency, energy efficiency, data rate, latency, and con-
nection are the fundamental needs of all conventional communication systems [2]. The
main problems that 6G must solve, as we have seen previously, is the creation of a three-
dimensional network that allows us to have continuous availability without interruptions
or cuts of any kind, or for any reason.
We can say each generation of communication system brings new features. However,
we have seen that the current system will be deprecated in terms of usability by 2030.
Therefore, 6G needs to be developed and standardised. Nowadays, it is still in its infancy
and study phase [21].

24
3 Implementation of the Scenario using OAI
This chapter deals with the deployment of the entire infrastructure and its configuration
to carry out the necessary experiments to obtain the results defined in the first chapter
of this document.

3.1 Introduction
The main goal of this chapter was to get a system running simulating a complete end-to-
end mobile network, whereafter, with an automated emulator, we could be able to perform
experiments to test and check the results obtained in previous studies.
The first challenge is to find a platform that allows us to emulate a mobile communications
network within our computer. We do not focus on using native hardware since would be
very costly. To solve this problem, we have decided to use Open Air Interface Core Network
(OAI-CN) and OAI. This system was chosen due to its versatility and possibilities. The
fact that it is an open code widely used by professionals has made it a solid choice to
develop our scenario and test it.

Figure 7: System to simulate.

The second challenge in this part was the simulation of edge computing. To deal with this,
we designed a whole virtualized cloud system using DigitalOcean VPS with a KVM as
the hypervisor. We have chosen this cloud facility because of the simplicity of deploying
and maintaining the VM.

3.2 OAI (OpenAirInterface)

OpenAirInterface is an open software that gathers developers worldwide to build wireless
cellular RAN and Core Network (CN) technologies. [25] It is maintained and developed

25
for the OpenAirInterface Software Alliance (OSA) founded in 2014. OSA is a French
non-profit organization (”Fonds De Dotation”) funded by corporate sponsors.
The software is composed of two main parts:
1. OAI-CN Deploy the different computers that form the core of the network (EPC),
these are the MME, the HSS and the SPGW.
2. OAI5G Implement the access network by implementing the station E-UTRAN
NodeB (eNB) base, and there is also the possibility of simulating several terminals
UE.

3.3 Implementation of the System in DigitalOcean

After analyzing several cloud service providers, it was decided to use Digital Ocean, which
resulted to provide an easy and robust system to deploy the necessary VPS for the com-
plete development of our evaluation platform.
By choosing Digital Ocean, we have facilitated the deployment of the project. This system
detailed below could work without any problem in any cloud platform as long as the
configuration that we will describe below is respected, and the hypervisor of said platform
is KVM. In Figure 8 we can see the main panel of DigitalOcean.

Figure 8: Dashboard of DigitalOcean Project Account with the 4 servers up.

3.3.1 Preparation Virtual Machines

To emulate network behaviours that concern us in this deployment, it has been decided
to deploy four virtual servers.

26
 Figure 9: Deployment diagram with main connections and interfaces.

1. Evolved Packet Core (EPC): We have decided to dedicate a server for the core
network since, although it will be physically located in the same nanosatellite as the
Central Unit (CU), its requirements (as we will see later) imply that they cannot
be mounted on the same VPS. This machine is dimensioned for an installation of
the OAI-CN system inside a container managed by Docker. As we can see in the
previous diagram (Figure 9), the system only requires 2 GB of ram and 1 virtual
Central Processing Unit (vCPU)s, and it is running Ubuntu 16.04 as a requirement
for the OAI [26].
2. CU, Distributed Unit (DU) and User Equipment (UE): For these servers,
3 VPS have been deployed. In these VMs, the OAI system has been installed in
barebone mode on Ubuntu 18.04. As we can see, all servers contain 2 GB of ram
and 1 or 2 vCPUs. This difference is because the split can be changed (different
types A to E as we have seen in the previous chapter) and the resources assigned to
each server can be adjusted. In this work, this adjustment will be made manually.
All machines have been deployed within the same data centre to avoid delays due to data
propagation. As we can see, the connection of the appliances has been made through
Virtual Local Area Network (VLAN)s preconfigured with the following commands.

27
 Figure 10: Commands for configuring virtual interfaces.

We have used this connection between the EPC and the CU and between the CU and
the DU for two main reasons. First, the Stream Control Transmission Protocol (STCP)
used by the OAI software did not work correctly in the public or internal DigitalOcean
network since the low-level protocols are filtered. Secondly, creating a bridge allows us to
introduce delays and modifications to simulate a non-physical link. In this thesis, in the
UAV-nanosatellite link (vxlan1 marked in the Figure 9), only static delays are introduced.
By using this type of link may allow the introduction of more complex delays and losses
in this thesis in the future. Below we can see a network scheme with all the interfaces for
each VM.

Figure 11: Connection scheme with interfaces and IP addresses.

3.3.2 Installation of Openair-CN

For installing the core network in the first test, the barebone mode was used. Still, due
to the system’s complexity, it was decided to use a pre-created Docker image and later
apply the settings for the project. Below we can see the repository currently being used
for the deployment with which we are working.

28
 Figure 12: DockerHub main repo.

Our image is based on modifying the ”opnear/cloudran” image provided by the user
opnear via DockerHub [27]. We have to emphasize that we have had to make a kernel
change on the server for the installation and the correct operation of the EPC system
since, it is required by the OAI-CN specifications the kernel 4.71. We changed it using
the commands in Figure 13.

Figure 13: Kernel 4.71 installation on ubuntu 16.04.

The second modification applied to our image was the change of the certificates. Since
it is an image, the hostnames used by OAI are already configured; since, the certificates
were expired, and a script must be used to re-create them. Otherwise, the system will not
work. To do this, as we see in Figure 14, we needed to execute a few commands in the
terminal of the image console in Docker.

Figure 14: Commands to recreate EPC certificates.

29
With these minor modifications applied, we made the system ready for the configuration.
It should be noted that the system is not yet functional at this point since, without the
configurations that we will see in the next section, the EPC entities (MME, HSS, SPGW)
will not be able to connect to each other or accept external connections.

3.3.3 Installation of OAI

To carry out the configuration of the CU, DU and UE nodes, the OAI software has been
deployed directly in the system without using containers, unlike the CN seen above. The
three VMs contain precisely the same software, and, as we will see below, what gives the
functionality of each of the parts of the network are the configuration files.
The system has been cloned directly from the official repository [28] using the commands
that we find below in Figure 15.

Figure 15: Openairinterface5G cloned on local computer.

For our experiments, we have used the software with version 2020.w16. The following im-
age shows the commands used to directly clone the version that interests us. We have used
this version since, we knew that this version, in particular, supports the BBU funtional
split necessary for the experiments carried out in our thesis [29].

Figure 16: Changing the branch on CU, DU and UE VM.

30
Following the information on the open-air interface page, the last step to finalize the
software installation is to compile the code and see if it does it without any problem. After
executing the commands we see in Figure 17 have the system is installed and configured
in all the machines we have talked about previously [28].

Figure 17: Commands for the compilation of CU, DU and UE OAI software.

• The -I option is to install pre-requisites. You only need it the first time you build
the softmodem or when some oai dependencies have changed. [28]
• The -w option is to select the radio head support you want to include in your build.
The RF simulatorRF simulator is implemented as a specific device replacing RF
hardware, it can be build using -w SIMU option. [28]
• –eNB is to build the lte-softmodem executable and all required shared libraries. [28]
• –UE is to build the lte-uesoftmodem executable and all required shared libraries.
[28]
You can build the eNB and the UE separately, you may not need both of them depending
on your OAI usage. [28]

3.4 Configuration of EPC

During the configuration of the CN, we will mainly use three files located in the path
/usr/local/etc/oai those are:
1. hss.conf
2. mme.conf
3. spgw.conf
As we have seen previously, the CN comprises three components HSS, MME and SPGW.
We must modify the interfaces and IP addresses with which the network will connect to
the CN. In Annex 1, we can see the complete configuration files of the deployed system.
At this point, we must also bear in mind that apart from the interfaces, we must host a
database with the information of the users and nodes of the network to be verified and
authorized.

31
3.4.1 Database Installation and Configuration
A database server has been installed, specifically MYSQL, to manage more efficiently.
The PHPMYADMIN package has also been included. This package allowed us to manage
the databases from a web interface.
First of all, to install the SQL server, the commands in Figure 18 have been used.

Figure 18: MYSQL installation commands.

Once installed, we checked the correct operation by seeing if the service was active and
listening to the requests. This verification can be done with the command shown in Figure
19, and its output indicates the status of the MYSQL service.

Figure 19: MYSQL service check.

Once the service is active and running on our system, we can install the PHPMYADMIN
[30] tool, and we can also access the data server to import the OAI database. To access
the server, we use the public IP of our VM. The thesis has used a database provided by
the Indian Institute of Technology Dharwad [31]. This Data Bases (DDBB) has been
imported using the import tool supplied by PHPMYADMIN. Finally, the result is a fully
functional HSS with data from several subscribers to perform system tests. (Figure 20).

32
 Figure 20: PHPMYADMIN panel accessed from the internet showing the user database already
loaded.

We detect that the services do not start automatically when the server that contains the
EPC is restarted. That is why the small script shown in Figure 21 was programmed to
facilitate the work of initializing the system each time it is has to be performed a series
of experiments.

Figure 21: Permissions initialization script and MYSQL and PHPMYADMIN execution.

3.4.2 First Initialization of HSS, MME, and SPGW

Once the data server is configured, we heed to launch them in separate terminals, to
execute them simultaneously on our server.
The first component that we must always launch is the HSS, and we will use the following
commands in Figure 22.

33
 Figure 22: Command to run HSS component.

Second, we launch the MME. (See Figure 23).

Figure 23: Command to run MME component.

Finally, we launch the SPGW. (See Figure 24).

Figure 24: Command to run SPGW component.

Once we have all the components up and running, we can check that the system has
started successfully. We have a new network interface on our EPC machine, as shown in
Figure 25. We will have the IP address that we specify in the HSS configuration file.

Figure 25: EPC generated interface for OAI use.

Once we have verified that the CN is working correctly, we must begin to connect our
distribution network to this first part of the mobile communication network.

34
3.5 Configuration of the vBBU split
This part, describes the preparation of the two virtual machines CU and DU, to execute
the functions of the split B necessary to carry out the experiments defined in the objectives
of this document.
We will use the lte-softmodem module with a specific configuration for each part [32] of
the split. This configuration is detailed in the following.

3.5.1 CU configuration
The CU, as we know, according to the split used, contains most of the functions, as we
can see in the complete file in Annex 2. In the first part of the file, the base station
configurations are detailed (Public Land Mobile Network (PLMN), Tracking Area, ...).
Next, we can observe the configurations of the carriers and the working frequency of the
eNB. Finally, as an essential part to be highlighted, Figure 26, represents the network
configurations to connect our base station with the EPC. As we can see in the image,
this system uses the virtual interface created between the VM of the EPC and the CU to
connect and thus establish communication.

Figure 26: CU configuration for MME connection using VLAN0 as the interface.

In addition, as we can see in Figure 27, our system only consists of a CU and a DU, so
at the end of the configuration. We see that only a single DU appears configured using,
as seen previously in the deployment of the VMs, the interface vxlan1.

35
 Figure 27: DU link configured on CU config file as unique DU.

3.5.2 DU configuration
As we have said repeatedly in previous sections, split B has its most significant load in the
upper layers of the protocol stack that is the CU. This is why the DU configuration file
is simply a configuration to indicate where this part of the split has to route the packets.
As we can see in Figure 28 and in the complete file in Annex 2, this only contains the
network bridge to be used, in this case, vxlan1 (the interface that communicates CU and
DU), and at the end of the file, we have the log configuration parameters.

36
 Figure 28: DU network configuration. Link with CU using VLAN1 as interface.

3.6 Configuration of UE
In the last step, before we can run our simulation system of a complete network imple-
menting a split B, we need to configure our client to connect to the gNB that we have
configured in previous sections.
As we know, so that the user can access the CN and establish a connection with the
network, the UE sim must be authorized and valid in the HSS. As we have seen in Figure
20, we have several sim cards. Thus, having the necessary information, we only have to
modify the file located in “openair3/NAS/TOOLS/ue-eurecom-test-sfr.conf”.
In this file, we must only modify the UE0 flag to add the HSS configurations, obtaining;
as a result, the configuration shown in Figure 29.

37
 Figure 29: SIM configuration in the UE VM with HSS validated data.

Finally, to include this in the module in charge of simulating the UE, we must execute
the command shown in Figure 30 as indicated in the technical documentation of OAI [28]

Figure 30: Command to activate the SIM in lte-uesoftmodem.

3.7 Running and testing the system

After the configuration, we can execute the complete system to see if we have the expected
end-to-end communication, and it works perfectly. First of all, we run the EPC as we have
seen previously to listen to the new gNB that wants to connect.
With the EPC running, we must execute the split that will form the gNB. For this, we
use the commands shown below to run the system.

38
 Figure 31: Commands to execute CU and DU functions.o

We must bear in mind that, as shown in Figure 31, we must first start the CU and then
the DU. To check the correct operation of the gNB, we will see the MME registers in the
EPC. As we can see in Figure 32 in our MME, the base station appears as active, so we
can say that at this point, we have a mobile communications network simulated perfectly
functional, and we can proceed to attach a UE.

Figure 32: MME showing an eNB successful connected to the CN

With the base station active, we proceed to execute the UE, following the commands in
Figure 33.

Figure 33: Commands to execute the UE.

Once again, to check the correct operation and the connection of the UE with the CN,
we have to look at the MME registration table. As we see in Figure 34, the connected UE
appears and informs us that the tunnel was created satisfactorily.

Figure 34: MME showing a UE successful connected to the CN

39
As a last check, we see if, in our VM that simulates the UE, a new interface appears in
the same subnet as the gtp0 tunnel created by the EPC. We can also communicate with
the CN directly using that tunnel. (Figures 35 and 36).

Figure 35: Interface created by OAI in the UE to connect with the CN.

Figure 36: Ping from UE to EPC using the interface created by OAI.

3.7.1 Conclusion of the preliminary testing

As we have seen, the system has been set up. We have a deployment in the cloud with
a fully operational split B that allows us to carry out the experiments we want for this
thesis and future research. The next chapter describes the creation of a tool to automate
all the processes that we have seen in this chapter. In addition, this tool will also be in
charge of automating the experiments and extracting the necessary results for this thesis.

40
4 Design and Implementation of the Evaluation Plat-
form
This chapter describes the creation of a simulation environment to evaluate the virtuali-
sation and functional split of BBUs on UAVs, and nanosatellites.

4.1 Introduction
As we have seen earlier in this document, our evaluation platform will be prepared to
performs the simulation and emulation of a Split B. For the research carried out in this
thesis, the simulator must run three experiments.
1. Tracking of performance metrics for the entire system.
2. Performance analysis in terms of latency and bandwidth in the Split connection
(vxlan1).
3. Performance analysis in terms of latency and bandwidth of the whole system (end-
to-end).
These metrics will allow us to see the temporal evolution that our connection undergoes
during the communication between the satellite and the HAPs. To carry out the multiple
experiments, we input the delay vectors for each communication and the height at which
the nanosatellite is located. These vectors have been provided by [33]. Figure 37 shows a
sample of an input vector. See the complete document in Annex 3.
Each of the vector samples is an arbitrary position obtained by sampling the communi-
cation arc of the nanosatelite with the drone from the minimum angle to the optimum
angle. The time increment applied between each of the samples is one second.

Figure 37: Delay vector data in orange the worst case, the case studied in this thesis.

4.2 Design of the evaluation platform

For the design of the evaluation platform, several experiments have been thought and
tested manually. As we have seen after several tests, the OAI system needs to be cleaned

41
after each experiment. For this reason, the design of this platform has been divided into
several blocks, as shown in Figure 38.

Figure 38: Macro-block structure of the evaluation platform design.

Due to the complexity of the software and of the system, a modular approach has been
chosen to with the realisation of the code, implemented for this project.

4.2.1 Remote Connection to Cloud Servers

In this first block of development, it was necessary to decide where the evaluation platform
would run. We chose not to install the platform on the servers where the tests are carried
out because having the code running simultaneously with the experiments could affect
the results.
For this reason, a secure way has had to be found to access the servers from the computer
running the evaluation platform. This access method must be fast, secure and allow the
access without need to exchange passwords in plain text.
Taking these considerations into account, it was decided to implement an Secure SHell
(SSH) key pair system. First, using the command shown in Figure 39, a master key pair
has been created. This command will create two files, master key and master key.pub.
The content of the second is the so-called public key.

42
 Figure 39: Creating an ssh key pair.

Second, the pair’s public key has been copied to each of the servers in the ./ssh/autho-
rized keys files so that they can be accessed by our code easily. The process of configuring
the system servers has been done following the commands shown in Figure 40.

Figure 40: Installation of the public key on a system server.

4.2.2 Emulation Platform

Several design decisions have been made for the design of the second, third and fourth
block (Figure 38) of the evaluation platform.
In the first place, because the emulator must work in the lowest layers of the Ubuntu
system, it has been decided to use bash [34] as a programming language. Bash allows us
for executing the code of the programmed script as if it was running directly in a terminal.
Since OAI needs to manage several processes on different machines simultaneously, the
use of this language is very beneficial.
Second, we have to consider that OAI needs to be executed sequentially since, as we
have seen, the order in which its components are executed can lead to a failure of the
experiment. At this point, once again, the fact of using bash in synchronous mode helps

43
us creating a stop-wait effect with which we can effectively and safely avoid these types
of errors.
Third, we must use a tool to simulate the delays calculated in the input vectors. This tool
is traffic control or tc [35]. This tool is native to the system and allows for modifying any
aspect of the link in this thesis, it will be used to add the simulated delay.
Finally, we must define how we will save the results of each of the experiments and what
tools we will use to carry them out. At this point, after an exhaustive investigation, we
have been able to conclude that the best tools are those detailed below:
1. Storage of performance metrics for the entire system
We will use the SAR [36] utility installed by default in the vast majority of Linux
systems for the system metrics. We will use this native tool to reduce the installa-
tion cost, and as it is a lightweight tool, it does not affect the operating system’s
performance. This tool will allow us to save the CPU and the RAM memory usage
every second while the experiment is carried out.
2. Performance analysis in terms of latency and bandwidth in the Split
connection (vxlan1).
We will use two essential tools pre-installed by default in Ubuntu for the latency
and bandwidth analysis these are PING [37] and IPERF [38]. In the first phase, we
will execute a PING from the CU to the DU, and then we will repeat the same test
in reverse, from DU to CU. We will do the same with the IPERF test; it should be
noted that, unlike PING, the IPERF tool uses a client-server system, so we must
always prepare the server before the client.
3. Performance analysis in terms of latency and bandwidth of the whole
system (end-to-end).
In this third pack of experiments, we will repeat the same process described in the
previous point, but the test will be carried out between the EPC and the EU using
the gtp0 tunnel.
The implementation of all the tools detailed in this point is explained in the next chapter.
As a result of the design study carried out in this subsection. Figure 41 depicts the block
diagram of the emulator.

Figure 41: Extended diagram of blocks 2,3,4 Figure 38. Temporal workflow of the emulator code.

44
4.2.3 Data Parser Script
The data obtained after each simulation must be recorded in the same Comma-Separated
Values (CSV). To create the document of results, it has been used Python [39], since in
terms of data management and manipulation, it is a very suitable language due to the
wide variety of libraries, with which it allows to work. In this thesis, the design of the
data parsing script requires two libraries. First the NUMPY library [40] will enable the
manipulation of data vectors. Second, PANDAS [41] library works with data matrices and
thus is able to extract all the results in CSV format.
To obtain the data in the required format, we have to apply some calculations to the
experiments.
1. Metrics
We need to collect the average of all data since we are getting the metrics every
second during the experiment.
2. PING
We need to calculate the Round-Trip Time (RTT).
3. IPERF
We have to evaluate the average of the outputs to obtain the bandwidth every
second, which is averaged during the experiment.
This data management script, apart from formatting the results, will also create a folder
of raw historical data. As shown in Figure 42, we can obtain two types of results.

Figure 42: Output of data parsing script results.

4.3 Implementation of the evaluation platform

In this section, we will see the implementation of all the functions of the code designed in
the previous section. This has been made from a external computer, using the Linux sub-
system integrated into Windows (Windows Subsystem for Linux (WSL)) [42]. Vscode [43]

45
has been used as a programming framework since it allows us for working with several
languages within the same environment. The complete code of the implementation used
in this thesis can be found in Annex 4.

4.3.1 Code Structure and Workflow

First, the functional structure and the workflow of the code has been implemented to
comply with the necessary specifications. For this implementation, a tree structure has
been used, as we see in Figure 43. This structure presents a master script in charge of
managing the loop generated by the list of experiments to be performed. This main script
manages the preparation of the scenario and executes the experiment to be passed to the
data parsing script.

Figure 43: Main script operation diagram.

As a result of the structure seen above, the circular workflow in Figure 44 is obtained.
This workflow ensures the integrity of the experiments since it performs them sequentially.
This means that the OAI system can be cleaned and restarted after each test, so that the
results obtained are not affected by previous data.

46
 Figure 44: Circular workflow of each iteration performed by the system.

4.3.2 Implementation of the Evaluation Platform

Due to the parallelism presented to us in the performance of the experiments, we must
save metrics while carrying out the desired test. It has been decided to divide the code
into three main scripts:
1. Statics Script
This first script is in charge of cleaning the metrics. It executes when the main script
requests it. The script implements the two procedures as functions.
2. Testing Script
This code is the backbone. This script is programmed in functions that are called
from the main program. This file contains the code in charge of executing the sce-
nario, configuring it, carrying out the experiment and cleaning the system.
3. Main Script
As we have said before, this script saves the list of experiments to be carried out
and coordinates the necessary functions to carry out each of the experiments.
The code due to this split structure is structured in several files, as shown in Figure 45.

47
 Figure 45: Files of the source code of the evaluation platform.

4.3.2.1 Statics Script Implementation

This script contains two functions. First, a function has been programmed to search
for SAR processes and stopping them. This type of function will be used several times
throughout the implementation because our programs sometimes run multiple times. The
code shown in Figure 46 is responsible for this process. As we can see, we obtain the list of
program processes and then we save the list to eliminate them one by one. It is important
to note that there are parent and child processes (processes that depend on others). For
this reason, as seen after each deletion, the list is rechecked.

48
 Figure 46: Recursive process deletion function with delete check.

As we can see, the code uses two input parameters, these are the user name and the host.
These data will be previously defined in the main script. The second function of this script
contains the necessary code to start reading the SAR tool and save it in a text document
on the local computer. This process is carried out with the code shown in Figure 47. This
same functionality also applies to the experiments’ functions, as we will see in the next
section.

Figure 47: Function to start a remote process and save the output to a local file.

4.3.2.2 Testing Script Implementation

In this second part of the evaluation platform, we find several functions. First of all, it is

49
necessary to highlight the function in charge of defining the constants used by the system.
With constants, we mean hosts, user names, and exceptionally the name of the EPC
container that we should access. As shown in Figure 48, all these definitions are declared
within the code.

Figure 48: Function in charge of managing constants definitions.

Apart from the function detailed above, the program also contains the following list of
functions that are called from the main script:
• emulate clean
This function is in charge of cleaning all the OAI instances running on any of the
four servers that make up the system. To complete this function, commands like the
one described in Figure 46 are used for each server.
• emulate deltc
This function uses a structure similar to the one observed in Figure 47. It executes
a command on the server to which we want to delete the delay of the interface.
• emulate addtc
This function has similar a structure to the one observed in Figure 47. It executes
a command on the server to which we want to add the delay on the interface. To
carry out its function, it receives as a parameter of the delay in milliseconds that it
has to apply to the link referred to the Split.
• emulate start
This part of our program is responsible for executing the OAI software in an orderly
manner on each of our servers. To do this, use the commands that we have seen in
Chapter 3, launched by SSH directly to each machine. This function also awaits the

50
 confirmation of active service in each of the servers to ensure that everything works
perfectly at the time of the experiment.
• emulate simu
Finally, this function is in charge of executing the experiments. In the first part, it
activates the metric collection. Next it performs the PING and IPERF tests and
finally disconnect the metric recording system. All these data are stored in text files
on the local computer, where they are processed before the subsequent iteration.

4.3.2.3 Main Script Implementation

This script manages the entire workflow of the series of experiments to be carried out.
First of all, this file reads the CSV data that it has received by parameter at the time of
execution and stores them in an array. Second, by using the functions programmed in the
other scripts, the system executes and prepares to carry out the experiment. It performs
the experiment and calls the data processing script to manage the raw data. Finally, the
script repeats the process as many times as necessary until all the CSV lines have been
exhausted. Figure 49 shows the main code.

Figure 49: Main code of the evaluation platform.

4.3.3 Implementation of the Data Processor Script

In this last block of our evaluation platform, a script has been programmed responsible for
collecting the raw data obtained by the code seen in the previous section of this document.

51
To perform this management without consuming excessive resources on the computer,
Python has been used as a language. In addition, as we have seen in the description of
the design, we have employed NUMPY and PANDAS libraries to work efficiently with
the complicated matrix structures.
In the first part of the script, there is a function that reads the input arguments. In this
case, there are: the simulation id, start and end timestamp. Then we find the embedded
function to process the data. This function consists of a loop that goes through all the files
in the raw data directory that we have indicated. Next, there is a conditional statement
that checks through the file’s name what type of data it contains and applies the necessary
calculations.
Finally, using the code shown in Figure 50, we create the data matrix and add it to the
CSV file; if it does not exist, it is created automatically.

Figure 50: Creating the data matrix from the data processing script.

4.4 Running and Testing the Evaluation Platform

Once our evaluation platform was developed to test its correct operation, many tests have
been carried out. As we can see in Figure 51, the platform works correctly, so that we can
obtain as output a CSV file with the calculated measurements and, on the other hand, a
”historical data” folder appears.

52
Figure 51: Evaluation platform running at the top CSV of results on the left folder of historical data.

Figure 51 shows, the test performed is a trial by sampling 1/6 of the delay vector. We
have observed that the platform created allows us to carry out complex and iterative, and
continuous experiments in the OAI software. This platform can manage four servers with
this software remotely with no trouble. This is in line with some of the objectives defined
in the introduction.

53
5 Results
In this chapter, the results are obtained by considering a perpendicular height of 350km for
the functional split B. This experiment has been carried out with the emulation platform
described in Chapter 4.
The experiment assumes discrete orbital states of sixty-four samples, (see explanation in
Chapter 4), (these samples are conceptually depicted in Figure 52). Each sample consists
of a propagation delay, the metrics obtained in each sample are:
• Average CPU usage
• Average RAM memory usage
• Latency UpLink and DownLink between CU and DU
• Latency UpLink and DownLink between EPC and UE
• Throughput UpLink and DownLink between EPC and UE
• Frame Error Rate (FER) of the communication

Figure 52: Satellite movement diagram and communication windows calculation.

5.1 Metrics and Energy

5.1.1 CPU and RAM memory Metrics
To estimate the energy consumed by split B, the CPU and RAM memory user data have
been collected during emulations. These data are important to understand the impact of
computing on the UAV and the satellite.
In Figure 53, the CPU usage can be observed for all the samples which span the orbit of
the satellite from the horizon to the perpendicular position respect of the UAV. In this
graph, we can see how the implementation of the split affects the load generated on the
CPU.

54
The CU, which contains most of the virtualized network functions, has the highest CPU
usage rate. On the other hand, if we look at the radio frequency layers of the split, the DU
is using significantly less resources than the CU. Finally, the EPC that performs users’
authentication and creation of the network bridge, has very low computing on its CPU.

Figure 53: CPU usage for deployed Droplet.

Figure 53 shows that a load of our virtualized systems works in line with the legacy of
split B. Moreover the maximum load of the critical point of the deployment (CU) does not
exceed 45%. This indicates that the system is feasible for being hosted by equipment with
low performance and low consumption, such as the one used in this experiment (1vCPU
and 2GB RAM).
The average consumption of RAM memory in each computer has been also collected. In
Figure 54, we can see that the EPC is the instance that consumes more memory. This
can be caused by the data of the HSS being using a lot of memory to be accessed quickly.
Next, we see that the two devices that consume more memory are the CU and the UE.
Taking into account the type of split used, this metric reaffirms the correct operation of
the system since, as we have seen in Chapter 2, the split B manages the packets sent via
the CU. Due to the necessary buffers, we find similar RAM consumption in the CU and
the UE. Finally, the DU shows a much lower RAM memory usage because it does not
store any packet. It simply forwards them to the CU. Therefore buffering is minimal.

55
 Figure 54: RAM memory for deployed Droplet.

As you can see, Figures 53 and 54 show slight fluctuations. In Figure 53, these are due to
the internal processes of the system since when we are in a virtualized system, we have
other processes running in parallel to the OAI software, which will cause, in some cases,
fluctuations in the CPU usage. These fluctuations are minimal since our system is in a
data centre, dedicated CPUs have been used for it. In Figure 54, instead, we can see that
these fluctuations are much more significant since the RAM cannot be configured to be
dedicated. We can see the clearly linear trend of both resources by which we can say that
the computational resources do not depend on the distance applied in the split. These data
allow us to approximate the computational cost for future functional split virtualization
projects and estimate the energy cost of a system with these characteristics, as we will
see in the next section.

5.1.2 Energy Consumption of the System

In this thesis, cloud third-party servers have been used. But since we do not have physical
access to the servers, we cannot directly measure the energy usage that is why, an estimate
has been calculated considering the type of processor used by the cloud servers (Intel Xeon
Processor 2.40 GHz) its RAM.
Regarding this we have used the processor’s data sheet [44], in which the Thermal Design
Power (TDP) is 65W, and RAM uses approximately 3W every 8GB [45]. With these data
and having measured the time duration and the data sent in one of the experiments, we
can apply the following calculations to estimate the power consumed by the system.

Ttx avg = 120 s (1)

For the energy calculation we have to consider all the servers involved, therefore we
calculate the energy consumed as:

Psystem = 65 W ∗ 6 vCP U s + 0.375 W ∗ 8 GB RAM = 393 W atts (2)

56
 Ttx avg 120 s
Pconsumed = Psystem ∗ = 393 W atts ∗ = 13.1 W h (3)
3600 s 3600 s
As we have calculate, the system uses a power of 13.1 W h.

5.2 Split Latency and Throughput

To verify feasibility of split b and to highlight the potential trade-offs, a crucial KPI is
latency. For the system to work, it is important the compliance with the 3GPP requeri-
ments.
The PING has been used to measure latency, as commented in Chapter 3. The latency
measured includes the propagation delay and the delay caused by the computation of
packets and buffers in both devices (CU and DU). For this reason, it becomes harder to
comply with the delay required between the CU and DU, which should be less than 1ms.
However, as seen in state of the art, a 3ms delay budget can become acceptable if some
constraints are accepted such as fixed/slow-moving UEs.
Figure 55, decipts slight variations of delay measurements because, our emulating system
is virtualized in a data centre, and the connections between servers are subject to load
variations caused by other users of the same data centre.

Figure 55: Split B UpLink and DownLink Latency.

Figure 55, shows the trend of latency as a function of the distance between the CU and DU
(UAV and nanosatellite). We can also observe that although the two trends (UpLink and
DownLink) are similar, UpLink is much more pronounced due to the different modulation
applied by the standard.
In terms of throughput, no graph has been provided since the link used in the split
connection is a 2Gbps symmetric link that is not affected or degraded by the distance
applied in this experiment.

57
The results obtained experimentally confirm the feasibility of split B in our 3D networking
scenario. Although the system is affected by slight variations due to the effects of being
in a shared data centre, these results allow us to design and emulate possible scenarios of
an actual implementation of this system.

5.3 End to End Latency and Throughput

In Figure 56, the end-to-end latency of the complete deployment has been measured, and
in Figure 57, the end-to-end throughput has been measured. These two graphs allow us
for analyzing how the distance affects the quality of communication of split B.

Figure 56: End-to-end and DownLink Latency.

Figure 56 shows that the trend that we obtained during our experiment is linear and
directly proportional to the distance between the UAV and the nanosatellite. The system
has been tested with 25 Resource Block (RB)s. The results obtained, taking into account
those obtained in the previous section, present a strong consistency since it can be seen
how the split delay translates into the end-to-end delay. On the other hand, we can see that
due to the latency obtained (10 ms - 20 ms), this system cannot meet the requirements of
the 5G URLLC. However, we can see that this split allows us to deploy a highly functional
communication network with the possibility of deploying it in a 3D full virtualized network
with the advantages that this entails.
Figure 57, we can see how in terms of throughput, the system is affected differently.
Although in the UpLink channel. We can see that the system has a slight tendency to
degrade with distance, the DownLink channel remains intact, except for slight variations
caused by the measurement. This difference between the channels is due to the protection
applied by the system. The data of the DownLink channel when the communication is
degraded is protected so that the throughput is maintained, but the amount of actual data
should decrease, due to, the coding rate increased. On the other hand, in the upstream
channel, this modification of the coding rate is not applied, so the same is always being
used, and it can be seen the decreasing performance when increasing the distance.

58
 Figure 57: End-to-end UpLink and DownLink Throughput.

5.4 Frame Error Ratio

Finally, the quality of the communication should be measured as it is affected by the dis-
tance. A different experiment has been carried out considering an altitude of 150km apart
from the one carried out at 350km. In these experiments, the FER has been measured
since it is the measure with which the OAI software computes the error. FER measurement
is used to test the performance of a mobile station’s receiver.
As shown in Figures 58 and 59, the result is shown in the form of a histogram since it
allows us for clearly seeing how altitude affects the FER. Figure 58 shows the histogram
generated with the samples collected in the 350km perpendicular orbit. As we can see,
although the error is small (it does not exceed 5% in any case), only 22 of the 64 samples
do not contain any FER. With this, we can see that although communication is viable
at 350 km altitude, the errors that appear in the system are frequent and reduce the
reliability communication.

59
 Figure 58: FER Histogram (h=350km).

Figure 59 of the FER calculated for the experiment at 150km perpendicular altitude shows
how the results are notably better since among the 75 samples that the test contains, 67
have a 0% FER.

Figure 59: FER Histogram (h=150km).

Therefore, we can conclude that the FER is highly affected by the distance between com-
ponents of the functional split, as described inthe theoretical works discussed in Chapter
2 [20] [16].

60
6 Conclusions and Future Work
In this thesis, the main objective was to provide an experimental evaluation of RAN
virtualization in a 3D networking scenario composed of UAVs and nanosatellites. The
virtualization has been carried out on DigitalOcean cloud servers to simulate/emulate the
system’s characteristics and so calculating its performance and feasibility.
To deploy a system close to reality, four different servers have been used. As we have
seen throughout this thesis, the system has accurately emulated the real behaviour of the
actual 3D functional split. With this system running and the split B implemented, several
performance tests were carried out to verify that the operations are realisable, according
to the theoretical studies on which this thesis has been based.
During the deployment and the configuration of the OAI software, the complexity of the
system arose. We can also conclude that the OAI software contains various programming
errors, that we had to correct to our experiments. During the testing stage, we have faced
and solved multiple problems that initially were affecting the system’s stability. Even so,
with the design presented here, we can conclude that we have realized an emulation of
a virtualized split B in multiple servers, with which we can test the operation of a 3D
network to obtain results such as those presented in this thesis.
In the second part of this project, it was required the test of the operations of the split
through a series of experiments. An environment capable of automating the testing with
OAI has been created to carry out the tests. The creation of this system lays the founda-
tions for future large-scale testing platforms with OAI, as nothing similar currently exists.
We can affirm that the development here created offers a significant advancement for fu-
ture experiment on 6G 3D networkings. In this thesis, the system has been tested only
with a user connected to the network and a single node in each part of the softwarized
network. Still, many future lines of action and experimentation in 3D networks are open
thanks to this development.
Finally, as we have observed, it has been possible to extract, thanks to the experiment
carried out, data that have allowed us to verify some of the theoretical results obtained
by the published studies on which this thesis was based.
This thesis has successfully deployed a simulation/emulation and evaluation of a 3D net-
work composed of UAVs and nanosatellites with promising results. It has partially verified
the results obtained in theoretical studies on functional splits, specifically split B, and has
opened the way to future lines of research.
This project has opened important future lines of research. Moreover, further ongoing
experiments will be used to write a scientific article showing the feasibility and constraints
of split B in 6G 3D networks. Several more experiments will be carried out, including
different distances between the split components and another sampling rate of the orbital
characteristics.
Apart from this, new potential researches can be:
• Testing how the increase in UEs affects the system in terms of computational per-
formance and resources.

61
• Investigating how users’ mobility affects 3D networks and split B and how resources
can be relocated based on mobility patterns.
• Testing how the increase in RBs and data rate can affect the performance of the 3D
networks and the effects on the computational performance of the complete system.
• Testing other functional split configurations.

62
References
[1] Takehiro Nakamura (Editor) Harri Holma (Editor), Antti Toskala (Editor). 5G Tech-
nology: 3GPP New Radio. 2020.
[2] Mostafa Zaman Chowdhury, Md. Shahjalal, Shakil Ahmed, and Yeong Min Jang.
6g wireless communication systems: Applications, requirements, technologies, chal-
lenges, and research directions. IEEE Open Journal of the Communications Society,
1:957–975, 2020.
[3] Leonardo Gomes Baltar (INT) Riccardo Bassoli (TUD) Pernilla Bergmark (EAB)
Carlos Bernardos (UC3) Serge Bories (CEA) Giorgio Calchira (TIM) Panagiotis
Demestichas (WIN) Miltiadis Filippou (INT) Frank H.P. Fitzek (TUD) Christian
Gallard (ORA) Azeddine Gati (ORA) Andeas Georgakopoulos (WIN) Marie-Helene
Hamon (ORA) Bin Han (TUK) Marco Hoffmann (NOG) Vasiliki Lamprousi (WIN)
Matti Latva-aho (OUL) Christofer Lindheimer (EAB) Diego Lopez (TID) Marja
Matinmikko-Blue (OUL) Cedric Morin (BCOM) Markus Mueck (INT) Antonio de
la Oliva (UC3M) Aarno Pärssinen (OUL) Antonio Pastor (TID) Cao-Thanh Phan
(BCOM) Pekka Pirinen (OUL) Pawani Porambage (OUL) Rafael Puerta (EAB) Olav
Queseth (EAB) Damiano Rapone (TIM) Björn Richerzhagen (SAG) Patrik Rugeland
(EAB) Berna Sayrac (ORA) Peter Schneider (NOG) Hans Schotten (TUK) Ana
Maria Galindo Serrano (ORA) Aspa Skalidi (WIN) Vera Stavroulaki (WIN) Emilio
Calvanese Strinati (CEA) Serge Bories (CEA) Elif Ustundag Soykan (EBY) Tommy
Svensson (CHA) Emrah Tomur (EBY) Mikko Uusitalo (NOF) Mikko Samuli Vaija
(ORA) Gustav Wikström (EAB) Volker Ziegler (NOG) Yaning Zou (TUD) Giovanna
D’Aria (TIM), Michael Bahr (SAG). A flagship for B5G/6G vision and intelligent
fabric of technology enablers connecting human, physical, and digital worlds. 2021.
[4] Dynamic architecture based on uavs monitoring for border security and safety
(davoss) ”https://www.granelli-lab.org/researches/relevant-projects/davoss”.
[5] Fabrizio Granelli, Cristina Costa, Jiajing Zhang, Riccardo Bassoli, and Frank H.P.
Fitzek. Design of an on-demand agile 5g multi-access edge computing platform using
aerial vehicles. IEEE Communications Standards Magazine, 4(4):34–41, 2020.
[6] R. mijumbi, j. serrat, j.-l. gorricho, n. bouten, f. de turck, and r. boutaba. 2015.
network function virtualization: State-of-the-art and research challenges.
[7] Jianda Wang and Yang Hu. Characterizing and understanding the architectural
implications of cloudnative edge nfv workloads. In 2019 IEEE Conference on Net-
work Function Virtualization and Software Defined Networks (NFV-SDN), pages 1–7,
2019.
[8] H. p. enterprise, ”new virtual application networks innovations advance: Software-
defined network leadership simplifying, scaling and automating the network,” 2012.
[9] D. thomas and k. g. nadeau, ”sdn: Software defined network,” 2013.
[10] M. rischan, ”sdn controller,” advanced network system lab, chonnam national uni-
versity, 2014.

63
[11] Paul göransson,timothy culver, in software defined networks (second edition), 2017.
[12] Nist, ”the nist definition of cloud computing.”.
[13] M. malgosa i broto, ”evaluación de prestaciones mediante nfv,” departamento de
ingenierı́a telemática, universidad politécnica de cataluña, 2015.
[14] Y. fernández romero and k. garcı́a pombo, ”virtualización,” revista telemática, vol.
10, 2011.
[15] Unikernels are specialised, single-address-space machine images constructed by using
library operating systems. ”http://unikernel.org/”.
[16] Stefano Bonafini, Riccardo Bassoli, Fabrizio Granelli, Frank H.P. Fitzek, and Claudio
Sacchi. Virtual baseband unit splitting exploiting small satellite platforms. In 2020
IEEE Aerospace Conference, pages 1–14, 2020.
[17] Gunes Karabulut Kurt, Mohammad G. Khoshkholgh, Safwan Alfattani, Ahmed
Ibrahim, Tasneem S. J. Darwish, Md Sahabul Alam, Halim Yanikomeroglu, and
Abbas Yongacoglu. A vision and framework for the high altitude platform station
(haps) networks of the future. IEEE Communications Surveys Tutorials, 23(2):729–
779, 2021.
[18] Rakibul Islam Rony, Elena Lopez-Aguilera, and Eduard Garcia-Villegas. Optimiza-
tion of 5g fronthaul based on functional splitting at phy layer. In 2018 IEEE Global
Communications Conference (GLOBECOM), pages 1–7, 2018.
[19] F. Giannone, K. Kondepu, H. Gupta, F. Civerchia, P. Castoldi, A. Antony Franklin,
and L. Valcarenghi. Impact of virtualization technologies on virtualized ran midhaul
latency budget: A quantitative experimental evaluation. IEEE Communications Let-
ters, 23(4):604–607, 2019.
[20] Riccardo Bassoli, Fabrizio Granelli, Claudio Sacchi, Stefano Bonafini, and Frank H.P.
Fitzek. Cubesat-based 5g cloud radio access networks: A novel paradigm for on-
demand anytime/anywhere connectivity. IEEE Vehicular Technology Magazine,
15(2):39–47, 2020.
[21] Calvanese, e. [et al.]. 6g in the sky: On-demand intelligence at the edge of 3d networks
(invited paper). ”etri journal”, octubre 2020, vol. 42, núm. 5, p. 643-657.
[22] Mansoor Shafi, Andreas F. Molisch, Peter J. Smith, Thomas Haustein, Peiying Zhu,
Prasan De Silva, Fredrik Tufvesson, Anass Benjebbour, and Gerhard Wunder. 5g:
A tutorial overview of standards, trials, challenges, deployment, and practice. IEEE
Journal on Selected Areas in Communications, 35(6):1201–1221, 2017.
[23] Di Zhang, Zhenyu Zhou, Shahid Mumtaz, Jonathan Rodriguez, and Takuro Sato.
One integrated energy efficiency proposal for 5g iot communications. IEEE Internet
of Things Journal, 3(6):1346–1354, 2016.
[24] H. viswanathan and p. e. mogensen, “communications in the 6g era,” ieee access, vol.
8, pp. 57063–57074, 2020.

64
[25] Openairinterface main webpage ”https://openairinterface.org/”.
[26] Openairsystemrequirements hardware requirements
”https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/openairsystemrequirements”.
[27] opnear/cloudran by opnear ”https://hub.docker.com/r/opnear/cloudran”.
[28] Openairinterface main gitlab repository ” https://gitlab.eurecom.fr/oai/openairinterface5g/-
/tree/master”.
[29] Functional split of 3gpp between the cu (centralized unit: Pdcp,
rrc, sdap) and the du (distributed unit: Rlc, mac, phy) on oai.
”https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/f1-interface”.
[30] Phpmyadmin is a free software tool written in php, intended to handle the adminis-
tration of mysql over the web ”https://www.phpmyadmin.net/”.
[31] Indian institute of technology dharwad (iit dharwad or iit dh) is an autonomous
engineering and technology institute in dharwad, karnataka, india. iit dharwad
”https://www.iitdh.ac.in/”.
[32] How to use oai to setup c-ran -¿ ngfi rcc/rru
”https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/how-to-connect-cots-
ue-to-oai-enb-via-ngfi-rru”.
[33] The university of trento (italian: Università degli studi di trento) is an italian uni-
versity located in trento and nearby rovereto. ”www.unitn.it”.
[34] Bash is an sh-compatible command language interpreter that executes commands
read from the standard input or from a file. ”https://linux.die.net/man/1/bash”.
[35] Tc is used to configure traffic control in the linux kernel.
”https://man7.org/linux/man-pages/man8/tc.8.html”.
[36] The sar command writes to standard output the contents of selected cumulative
activity counters in the operating system. ”https://linux.die.net/man/1/sar”.
[37] ping uses the icmp protocol’s mandatory echo request datagram to elicit an icmp
echo response from a host or gateway. ”https://linux.die.net/man/8/ping”.
[38] iperf is a tool for active measurements of the maximum achievable bandwidth on ip
networks. ”https://iperf.fr/”.
[39] Python is a programming language that lets you work quickly and integrate systems
more effectively. ”https://www.python.org/”.
[40] Numpy brings the computational power of languages like c and fortran to python, a
language much easier to learn and use. with this power comes simplicity: a solution
in numpy is often clear and elegant. ”https://numpy.org/”.
[41] Pandas is a fast, powerful, flexible and easy to use open source data analy-
sis and manipulation tool, built on top of the python programming language.
”https://pandas.pydata.org/”.

65
[42] Windows subsystem for linux installation guide for windows 10.
”https://docs.microsoft.com/en-us/windows/wsl/install-win10”.
[43] Visual studio code is a code editor redefined and optimized for building and debugging
modern web and cloud applications. ”https://code.visualstudio.com/”.
[44] Intel® xeon® processor 2.40 ghz, 512k cache, 533 mhz fsb
”https://ark.intel.com/content/www/us/en/ark/products/27270/intel-xeon-
processor-2-40-ghz-512k-cache-533-mhz-fsb.html”.
[45] How much power does memory use? ”https://www.crucial.com/support/articles-faq-
memory/how-much-power-does-memory-use”.

66
Appendices
.1 OAI-CN Configuration Files
OAI-CN Configuration Files for the project.
In these appendice you will find the configuration files for the EPC. You can also download
the container used in the project from the repository: Here
Link to the Appendice: https://github.com/isigr57/thesisAppendice1

.2 OAI5G Configuration Files

OAI5G Configuration Files for the project.
In these appendice you will find the configuration files for the CU, DU and UE.
Link to the Appendice: https://github.com/isigr57/thesisAppendice2

.3 Complete code of the developed emulator

In this appendice we can find the complete commented code used throughout the project.
This version is a preliminary version with which to work in future works, to carry out
new research on the subject studied in this thesis.
Link to the Appendice: https://github.com/isigr57/thesisAppendice3

.4 Expanded results and raw data of all the experiments per-

formed
In this appendix we can find multiple results that have been obtained through secondary
experiments. You can also find extended results of the subject studied in the thesis.
Finally, we also have the results available in raw format to be able to carry out different
investigations with the results obtained.
Link to the Appendice: https://github.com/isigr57/thesisAppendice4

67