2017-ENST-0058

EDITE - ED 130

Doctorat ParisTech

THÈSE
pour obtenir le grade de docteur délivré par

TELECOM ParisTech
Spécialité « Electronique et Communications »

présentée et soutenue publiquement par

Romain FAVRAUD
le 22 Novembre 2017

Réseau d’accès radio LTE/LTE-A autonome et maillé pour

environnements contraints

Directeur de thèse : Navid NIKAEIN

Jury
M. Christian BONNET, Professeur, Eurecom, France Président
Mme Carla-Fabiana CHIASSERINI, Professeur associé, Politecnico di Torino, Italie Rapporteur
M. Riku JÄNTTI, Professeur associé, Aalto University, Finlande Rapporteur
M. Tommy SVENSSON, Professeur, Chalmers University of Technology, Suède Examinateur
M. Klaus MOESSNER, Professeur, University of Surrey, Royaume-Uni Examinateur
TELECOM ParisTech
école de l’Institut Mines-Télécom - membre de ParisTech
ABSTRACT

Performance of military communication systems is nowadays im-

proving slowly compared to commercial systems which puts inter-
ests in evolving mature commercial systems for military usage. In
parallel, Public Safety (PS) communication systems are changing due
to emergence of Long Term Evolution (LTE) as a mature solution
to replace the legacy ones while providing new services. However,
LTE is initially designed for commercial cellular network and need
to be further evolved to tackle the substantial requirements of pub-
lic safety use cases. For instance, opportunistic deployments require
modifications to enable the autonomous operation and meshing of
moving base stations while satisfying heterogeneous frequency band
availability. In this thesis, we develop a complete solution to answer
constrained PS and military use cases allowing to wirelessly mesh
mobile network nodes and to provide access to standard user equip-
ment while only requiring a single radio/LTE band.
Starting from PS and military communication systems landscape
and use cases, we present the potential scenarios and derive func-
tional requirements for future wireless communication systems to al-
low new services and coverage of these use cases. We further un-
derline the specific constraints applying to these communication sys-
tems due their specific environment of use, especially limited avail-
ability of frequency resources. This leads to the selection of LTE as
the Radio Access Technology (RAT) for both backhaul and access of
the wireless system. We then review current LTE state of the art
and LTE systems and compare them against these requirements. Un-
derlining the limitations of such systems, we detail the challenges
faced by a LTE solution that would answer these requirements. Then,
we present a novel network infrastructure architecture that enables
multi-hop LTE mesh networking for nomadic and autonomous base
stations via in-band self-backhauling relying on a new base station:
the enhanced evolved Node B (e2NB). We detail the building blocks
of the architecture to answer the multiple challenges. Specifically, we
investigate the coordination and orchestration functionality within
the proposed architecture and propose a cross layer hierarchical re-
source scheduling algorithm in order to efficiently meet Quality of
Service (QoS) requirements for real-time traffic while maximizing the
throughput for elastic flows. To demonstrate the feasibility and relia-
bility of our proposed architecture, we implement the corresponding
self-backhauling air interface based on Open Air Interface (OAI) plat-
form and compare with the legacy LTE air-interface. We then evaluate
the efficiency and adaptability of our proposed resource scheduling

iii
iv

algorithm in various network topologies and heterogeneous traffic

flows with QoS requirements. Finally, we summarize the remaining
uncertainties concerning real-field deployments and we conclude this
study.
RÉSUMÉ

Comparées à celles de systèmes de communications civils, les per-

formances des systèmes de communication militaires s’améliorent
lentement aujourd’hui. Cela rend intéressant l’évolution de systèmes
de communication civils matures pour un usage militaire. En paral-
lèle, les systèmes de communications pour les réseaux de sécurité
publique sont en train d’évoluer suite à l’émergence de la techno-
logie Long Term Evolution (LTE) comme une solution fiable et ma-
ture pour remplacer les systèmes précédents. Cependant, le LTE a
initialement été conçu pour les réseaux cellulaires commerciaux et
nécessite des adaptations pour répondre aux exigences des réseaux
de sécurité publique. Par exemple, la réalisation de déploiements op-
portunistes nécessite des modifications afin de permettre le fonction-
nement autonome et maillé de stations de base mobile qui tiennent
compte et s’adaptent aux bandes de fréquences disponibles. Dans
cette thèse, nous développons une solution complète permettant de
répondre aux cas d’utilisation contraints auxquels font face les organi-
sations de sécurité publique et militaires. Cette solution permet, sur
une seule bande de fréquence LTE, le maillage sans fil de stations
de base mobiles tout en maintenant l’accès au réseau de terminaux
mobiles standards.
Nous commençons par présenter les cas d’utilisation et les sys-
tèmes de communications utilisés par les autorités militaires et de
sécurité publique. Nous présentons alors les scénarios associés et en
dérivons des exigences fonctionnelles afin de concevoir un nouveau
système de communication couvrant ces cas d’utilisations et appor-
tant de nouveaux services. Nous soulignons ensuite les contraintes
spécifiques qui s’appliquent à ces systèmes de communication dues
aux environnements spécifiques dans lesquels ils sont utilisés, en par-
ticulier les contraintes limitant l’accès aux ressources spectrales. Ces
contraintes influencent la conception du système et mènent au choix
du LTE pour réaliser à la fois le réseau d’accès sans fil pour terminaux
mobiles et les interconnexions entre les stations de base du système.
Nous présentons alors un état de l’art rapide du LTE et comparons
les fonctionnalités actuellement disponibles avec les exigences précé-
demment définies. Soulignant les limitations des systèmes standards,
nous détaillons les défis auxquels doit faire face une solution basée
sur le LTE pour répondre aux dites exigences. Ensuite, nous présen-
tons une nouvelle architecture d’infrastructure réseau qui permet la
création de réseaux maillés LTE multi-bonds. Celle-ci s’appuie sur
une nouvelle station de base autonome et mobile qui dispose d’une
fonctionnalité de maillage intra-bande : l’enhanced evolved Node B

v
vi

(e2NB). Nous détaillons ensuite les composants de cette architecture

et de cette station de base pour répondre aux multiples défis identi-
fiés. Plus particulièrement, nous évaluons le besoin de coordination
entre stations de base et nous proposons un algorithme d’ordonnance-
ment de ressources radio inter-couches afin de satisfaire les exigences
de qualité de service des flux temps réel tout en maximisant le débit
des flux élastiques. Pour démontrer la faisabilité de l’architecture pro-
posée, nous implémentons l’interface sans fil inter stations de base
sur la plateforme de radio logicielle OpenAirInterface et la compa-
rons avec l’interface LTE classique. Ensuite, nous évaluons l’efficacité
et l’adaptabilité de l’algorithme d’ordonnancement proposé sur diffé-
rentes topologies auxquelles nous appliquons des flux hétérogènes en
termes d’exigences de qualité de service. Finalement, nous résumons
les incertitudes restantes concernant les déploiements sur le terrain
et nous concluons cette étude.
ACKNOWLEDGMENTS

This has not been an always easy journey. "Learn the hard way!"
they said. I guess I somehow did, and I am quite happy that this
journey was successful and is finally, as I am writing, coming to an
end. But even though pursuing a PhD degree may look like a long
and solitary walk, it cannot be started and surely not finished alone.
That is why I would like to take these few lines to thank all the
people that made this possible.
First, I would like to thank Franck Andreani and Cyril Gazzano
from Naval Group who offered me this opportunity, as well as Joël
Caravetta, Jean-Hugues Chauvot, Patrick Saretti and all the other peo-
ple in Naval Group I had the chance to work with.
I, of course, thank my PhD advisor, Navid Nikaein, first for accept-
ing to supervise this thesis, and mostly, for having been able to guide
me successfully through it.
I would like to thank all members of the thesis committee for tak-
ing the time to read this thesis and providing their constructive and
helpful feedback.
I would like to thank my colleagues and friends from Eurecom,
who greatly helped me getting over the difficulties and provided a
lot of interesting discussions and ideas, as well as many laughs: Lau-
rent Gallo, Konstantinos Alexandris, Jingjing Zhang, Chia-Yu Chang,
Irfan Khan, Paolo Viotti, Pierre-Antoine Vervier, Xiwen Jiang, Qian-
rui Li, Yongchao Tian, Shengyun Liu, Haifan Yin, Ruggero Schiavi,
Anta Huang, Francesco Pace, Daniele Venzano, Kurt Cutajar, Elena
Lukashova and many others that made that journey enjoyable!
I sincerely thank my friends Colin, Jawad, Sammy and Lucas, who
were far away but more than supportive and helpful all along, as well
as Agnès for providing me the necessary joy over the final steps.
Finally, I thank my parents and my sister for continuously support-
ing me in my life, and in that maybe not so crazy idea this was!

vii
CONTENTS

Abstract iii
Résumé v
Acknowledgments vii
Contents viii
List of Figures xiii
List of Tables xv
1 introduction 1
1.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . 2
2 state of the art and problem statement 5
2.1 Uses cases and current solutions . . . . . . . . . . . . . 5
2.1.1 Military and Naval uses cases . . . . . . . . . . . 5
2.1.2 Public Safety uses cases . . . . . . . . . . . . . . 8
2.2 Network topologies . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Scenarios . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 Scenarios of reference . . . . . . . . . . . . . . . 12
2.3 Problem Statement . . . . . . . . . . . . . . . . . . . . . 13
2.3.1 High level requirements . . . . . . . . . . . . . . 14
3 design constraints and rat choice 17
3.1 External constraints . . . . . . . . . . . . . . . . . . . . . 17
3.2 RAT of autonomous network . . . . . . . . . . . . . . . 18
3.2.1 LTE state of the art . . . . . . . . . . . . . . . . . 19
3.2.2 Backhaul link consideration . . . . . . . . . . . . 24
4 architecture of the autonomous bts 27
4.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.1 Support of Legacy UEs . . . . . . . . . . . . . . 27
4.1.2 Autonomous operation . . . . . . . . . . . . . . 27
4.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 e2NB states . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 e2NB network topologies . . . . . . . . . . . . . . . . . 33
5 design elements and procedures of e2nb 35
5.1 Physical layer interfaces . . . . . . . . . . . . . . . . . . 35
5.1.1 Background LTE information . . . . . . . . . . . 35
5.1.2 Uu interface . . . . . . . . . . . . . . . . . . . . . 36
5.1.3 Un relay interface . . . . . . . . . . . . . . . . . . 38
5.2 Physical layer design issues . . . . . . . . . . . . . . . . 43
5.2.1 Synchronization . . . . . . . . . . . . . . . . . . . 43
5.2.2 Range limitation . . . . . . . . . . . . . . . . . . 45
5.2.3 HARQ modifications for Un interface . . . . . . 46
5.3 e2NB procedures and parameters configuration . . . . 47
5.3.1 eNB parameters . . . . . . . . . . . . . . . . . . . 48

ix
x Contents

5.3.2 vUE attach procedure . . . . . . . . . . . . . . . 48

5.3.3 e2NB operation flow . . . . . . . . . . . . . . . . 51
5.4 Core Network logical connectivity . . . . . . . . . . . . 55
5.4.1 MME . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.4.2 HSS provisioning and cooperation . . . . . . . . 56
5.4.3 S/P-GW . . . . . . . . . . . . . . . . . . . . . . . 56
5.4.4 Routing . . . . . . . . . . . . . . . . . . . . . . . 56
5.4.5 Application and services . . . . . . . . . . . . . 57
6 coe algorithms 59
6.1 Problem overview . . . . . . . . . . . . . . . . . . . . . . 59
6.2 COE role and proposed hierarchical approach . . . . . 60
6.3 COE Controller Scheduling Algorithm . . . . . . . . . . 62
6.3.1 Superframe duration computation (LSuF ) . . . . 64
6.3.2 SF allocation for inter-e2NB self-backhauling . . 64
6.3.3 Distributed link scheduling . . . . . . . . . . . . 68
6.4 Relaying direction selection . . . . . . . . . . . . . . . . 69
6.5 Extensions to TDD system . . . . . . . . . . . . . . . . . 70
6.6 Extensions to multi-antenna and multi-sector BTS . . . 71
6.6.1 Analysis of the approach complexity . . . . . . 72
6.7 Interference management . . . . . . . . . . . . . . . . . 73
6.8 Discussion on security issues . . . . . . . . . . . . . . . 74
7 experimentations 75
7.1 Physical channel performance evaluation . . . . . . . . 75
7.1.1 Computation time . . . . . . . . . . . . . . . . . 76
7.1.2 Link-level performance . . . . . . . . . . . . . . 78
7.2 Evaluation of the proposed approach . . . . . . . . . . 80
7.2.1 Simulation environment . . . . . . . . . . . . . . 81
7.2.2 Considered Algorithms . . . . . . . . . . . . . . 83
7.2.3 Simulation Results . . . . . . . . . . . . . . . . . 84
7.2.4 Summary . . . . . . . . . . . . . . . . . . . . . . 97
7.3 Performance comparison of in-band and out-band de-
ployment . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.4.1 Limitations of the experiments . . . . . . . . . . 102
7.4.2 Potential improvements of the proposed approach103
8 conclusion 105
8.1 Perspectives and future work . . . . . . . . . . . . . . . 106
9 bibliography 109
Appendices 117
a additional figures 119
b résumé en français 123
b.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 123
b.1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . 123
b.1.2 Contributions . . . . . . . . . . . . . . . . . . . . 124
b.2 État de l’art et définition de la problématique . . . . . . 126
b.2.1 Cas d’utilisation militaires . . . . . . . . . . . . . 126
 Contents xi

b.2.2 Communications pour la sécurité publique . . . 128

b.2.3 Topologies réseaux associées . . . . . . . . . . . 128
b.2.4 Énoncé du problème . . . . . . . . . . . . . . . . 128
b.3 Contraintes de conception et choix de la technologie
d’accès radio . . . . . . . . . . . . . . . . . . . . . . . . . 130
b.3.1 Contraintes externes . . . . . . . . . . . . . . . . 130
b.3.2 Choix de la technologie d’accès radio . . . . . . 130
b.4 Architecture de station de base autonome . . . . . . . . 134
b.4.1 États de l’e2NB . . . . . . . . . . . . . . . . . . . 136
b.4.2 Topologies réseaux possibles . . . . . . . . . . . 136
b.5 Conception détaillée et procédures de l’e2NB . . . . . . 137
b.6 Algorithmes d’ordonnancement . . . . . . . . . . . . . 138
b.6.1 Rôle du COE et approche hiérarchique proposée 139
b.7 Expérimentations . . . . . . . . . . . . . . . . . . . . . . 140
b.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 141
b.8.1 Perspectives et travaux futurs . . . . . . . . . . . 142
c acronyms 147
LIST OF FIGURES

Figure 1 Overview of military and naval communications 6

Figure 2 Network topologies - scenarios 1, 2 and 3. . . . 11
Figure 3 Network topologies - scenarios 4, 5 and 6. . . . 11
Figure 4 Network topologies - scenarios 7 and 8. . . . . 11
Figure 5 Network topologies - scenarios 9, 10, 11 and 12. 11
Figure 6 Evolution of cellular system standards. . . . . 19
Figure 7 LTE nominal architecture (Release 8). . . . . . 20
Figure 8 3GPP PS oriented work items. . . . . . . . . . . 21
Figure 9 Topologies based on standard LTE BTS (1,2,3)
and the envisioned LTE network (4). . . . . . . 23
Figure 10 e2NB stack. . . . . . . . . . . . . . . . . . . . . . 30
Figure 11 Main e2NB states. . . . . . . . . . . . . . . . . . 32
Figure 12 Example of different network topologies based
on e2NBs. . . . . . . . . . . . . . . . . . . . . . . 33
Figure 13 LTE resource grid for a 1.4MHz (6 PRBs) chan-
nel width. . . . . . . . . . . . . . . . . . . . . . . 36
Figure 14 Symbol allocation in a SF for Uu and Un inter-
faces. . . . . . . . . . . . . . . . . . . . . . . . . 39
Figure 15 Resource allocation example of DL at DeNB/RN. 41
Figure 16 Non-synchronized e2NB transportation. . . . . 44
Figure 17 Connection procedure. . . . . . . . . . . . . . . 49
Figure 18 Startup phase operation flow. . . . . . . . . . . 52
Figure 19 Isolated state operation flow. . . . . . . . . . . 53
Figure 20 Meshed state operation flow. . . . . . . . . . . 54
Figure 21 vUE relay state operation flow. . . . . . . . . . 55
Figure 22 Coordination and Orchestration Entity archi-
tecture. . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 23 R-PDCCH and PDCCH computational time. . 77
Figure 24 TX/RX time for PDCCH/PDSCH and R-PDCCH/R-
PDSCH. . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 25 Minimum SNR level to decode 75% of the TBs. 78
Figure 26 Minimum SNR level for several aggregation
levels. . . . . . . . . . . . . . . . . . . . . . . . . 80
Figure 27 Considered network topologies. . . . . . . . . . 82
Figure 28 Hexagonal topology with 7 e2NBs and 70 UEs
using 10MHz in FDD mode. . . . . . . . . . . . 85
Figure 29 Hexagonal topology with 7 e2NBs and 70 UEs
using 10MHz in TDD mode. . . . . . . . . . . . 87
Figure 30 Hexagonal topology with 7 e2NBs and 70 UEs
using 10MHz in TDD mode or 5MHz in FDD
mode. . . . . . . . . . . . . . . . . . . . . . . . . 88

xiii
xiv List of Figures

Figure 31 Line topology with 7 e2NBs and 70 UEs using

5MHz in FDD mode. . . . . . . . . . . . . . . . 89
Figure 32 Line topology with 7 e2NBs and 70 UEs using
10MHz in TDD mode. . . . . . . . . . . . . . . 91
Figure 33 Line topology with 7 e2NBs and 70 UEs using
10MHz in TDD mode or 5MHz in FDD mode. 92
Figure 34 Hexagonal topology with 19 e2NBs and 190
UEs using 5MHz in FDD mode. . . . . . . . . . 94
Figure 35 vUE UL transmission successful rate of hexag-
onal topology with 19 e2NBs and 190 UEs us-
ing 5MHz radio bandwidth of FDD mode un-
der UL. 2V. . . . . . . . . . . . . . . . . . . . . . 95
Figure 36 Hexagonal topology with 19 e2NBs and 190
UEs using 10MHz in FDD mode. . . . . . . . . 96
Figure 37 Hexagonal topology with 19 e2NBs and 190
UEs using 10MHz in TDD mode. . . . . . . . . 97
Figure 38 Network topology for in/out-band comparison. 100
Figure 39 Data rate of traffic flow of in/out-band deploy-
ments. . . . . . . . . . . . . . . . . . . . . . . . . 100
Figure 40 Cumulated data rate of two traffic flows. . . . 101
Figure 41 Hexagonal topology with 7 e2NBs and 70 UEs
using a 10MHz FDD configuration. . . . . . . . 119
Figure 42 Hexagonal topology with 7 e2NBs and 70 UEs
using a 10MHz TDD configuration. . . . . . . . 119
Figure 43 Hexagonal topology with 7 e2NBs and 70 UEs
using a 10MHz TDD and a 5MHz FDD config-
uration. . . . . . . . . . . . . . . . . . . . . . . . 120
Figure 44 Line topology with 7 e2NBs and 70 UEs using
a 5MHz FDD configuration. . . . . . . . . . . . 120
Figure 45 Line topology with 7 e2NBs and 70 UEs using
a 10MHz TDD configuration. . . . . . . . . . . 121
Figure 46 Line topology with 7 e2NBs and 70 UEs using
a 10MHz TDD or a 5MHz FDD configuration. 122
Figure 47 Aperçu des communications sans fil militaires
et navales . . . . . . . . . . . . . . . . . . . . . . 127
Figure 48 Architecture nominale du LTE (Release 8). . . 132
Figure 49 Travaux du 3GPP orientés sécurité publique. . 132
Figure 50 Topologies réseaux réalisables à parti des spé-
cifications LTE (1,2,3) et réseau LTE visé (4). . . 133
Figure 51 Architecture de l’e2NB. . . . . . . . . . . . . . . 134
Figure 52 États principaux de l’e2NB. . . . . . . . . . . . 136
Figure 53 Exemples de topologies réseaux obtenues grâce
aux e2NBs. . . . . . . . . . . . . . . . . . . . . . 137
Figure 54 Architecture du COE (Coordination and Or-
chestration Entity). . . . . . . . . . . . . . . . . 139
L I S T O F TA B L E S

Table 1 Medium range ship-to-ship communication sys-

tems vs military satellite . . . . . . . . . . . . . 7
Table 2 Possible network scenarios . . . . . . . . . . . . 10
Table 3 Considered scenarios . . . . . . . . . . . . . . . 13
Table 4 Comparison of different LTE meshing solutions 25
Table 5 Comparison of LTE meshing solutions . . . . . 42
Table 6 Comparison of centralized and distributed sched-
ulers . . . . . . . . . . . . . . . . . . . . . . . . . 62
Table 7 Compared algorithms with corresponding no-
tations . . . . . . . . . . . . . . . . . . . . . . . . 84
Table 8 Summary of the evaluation results . . . . . . . 98
Table 9 Systèmes de communication navals à moyenne
portée et système de communication par satellite127

xv
INTRODUCTION
1
Wireless communications have never been so widely used by hu-
mans. While the frequency spectrum is limited, new technologies
enabling faster or more energy efficient wireless communications are
emerging every year, pushing forwards the possibilities and the ex-
pectations of end users.
In such a crowded landscape, Long Term Evolution (LTE) is be-
coming the technology reference for 4G cellular networks, as it is
increasingly adopted by all major operators all over the world. Cur-
rently, LTE is rising to the challenge of addressing several issues (e.g.
cellular networks’ capacity crunch, ultra-high bandwidth, ultra-low
latency, massive numbers of connections, super-fast mobility, diverse-
spectrum access) that speed up the pace towards 5G. Moving cells
have been envisioned to expand the coverage and provide higher
data-rates at low cost thus enabling several new use cases in Intel-
ligent Transportation System (ITS), Unmanned Aerial Vehicle (UAV)
and drones communications, etc. Moreover, LTE is expected to be an
important part of the 5G solution for future networks and also play
an essential role in advancing Public Safety (PS) communications.

1.1 motivations

In the United States of America (USA), LTE has been chosen up as

the next appropriate communication technology to support PS com-
munications and it is likely to be the same in Europe. Moreover,
several vendors (e.g. Ericsson, Nokia, Huawei, Cisco) are now start-
ing to propose LTE-based PS solutions and some of them have been
put to real field experimentation.
While existing PS solutions (e.g. Project 25 (P25) and Terrestrial
Trunked Radio (TETRA)) are mature and provide reliable mission-
critical voice communications, their designs cannot meet the new re-
quirements and the shift to higher bandwidth applications. In addi-
tion, LTE system is a commercial cellular network and was not suited
in the initial 3rd Generation Partnership Project (3GPP) releases to
support PS services and the corresponding requirements like reliabil-
ity, confidentiality, security, group and Device-to-Device (D2D) com-
munications. Therefore, the raising question is whether LTE suffices
to be an appropriate solution for PS networks. To address those is-
sues, 3GPP has started to define the new scenarios that LTE will have
to face and it has released several studies on proximity-based services
(Proximity Services (ProSe)), group and D2D communications, Mis-

1
2 introduction

sion Critical Push-To-Talk (MCPTT), and Isolated Evolved Universal

Terrestrial Radio Access Network (E-UTRAN). These studies define
the requirements regarding User Equipments and evolved Node Bs
(eNBs) to provide PS services depending on the E-UTRAN availabil-
ity and architecture. Particularly, the studies on isolated E-UTRAN
target use cases when one or several eNBs have limited or no access
to the Core Network (CN) (Evolved Packet Core (EPC) in LTE) due
to a potential disaster, or when there is need to rapidly deploy and
use a LTE network outside of the range of the existing infrastructure.
In these situations, the isolated E-UTRAN must maintain relevant
services accessible for the PS UEs despite the lack of full EPC con-
nectivity (e.g. local routing and frequency resource management).
However, 3GPP studies do not define how such isolated eNBs of a
single set should communicate together, and leave that to the use of
other technologies and vendor specific solutions.
On another hand, military communication systems have for long
been the driver of new advancements in the wired and wireless com-
munication landscape. However, this has changed. Indeed, the dig-
ital revolution has been relying on communication systems and has
greatly increase the involvement of private companies to provide reli-
able and high performance communication systems. Nowadays, most
innovations are coming from these companies targeting a massive
consumer market. Moreover, if the military budgets are not getting
shrinked, the missions ensured by military authorities are becoming
larger at iso-budget. This fact leads military entities to rely more and
more on Commercial Off-The-Shelf (COTS) equipment, even for com-
munication systems. Thus, simmering interest has arisen around the
use of LTE to provide high data rate and flexible communications for
military operations on land or at sea. However, these specific use
cases requires support of network topologies and constraints that are
absent in the commercial market.

1.2 contributions

To the best of our knowledge, there have not been extensive re-
search and contributions to extend the LTE connectivity to more than
two wireless hops from a base station that has access to the CN with-
out making use of out-band radios. However, as we will detail in this
work, this is of interest for several use cases that have strict require-
ments on frequency resources or hardware availability such as PS and
military communications. In this thesis, we study how to evolve the
LTE communication systems to enable new use cases in constrained
environments relying on autonomous moving cells.
In the first chapter, we introduce the use cases that we are target-
ing in our study by reviewing the operational situations encountered
by military, navy and PS entities. We show the limitations of their
 1.2 contributions 3

current wireless communication systems. Then, we present the net-

work topologies common to PS, military and other entities that arise
in their respective use cases. In light of the previously mentioned lim-
itations, we formulate the main problem that this study is targeting
to solve: how to enable high data rate autonomous wireless networks
based on moving cells able to serve mobile users in constrained envi-
ronments. We conclude this first chapter by drawing the functional
requirements of a potential solution based on this target. Three con-
tributions have enlighten these problems:
— R. Favraud and N. Nikaein, "Wireless mesh backhauling for
LTE/LTE-A networks," MILCOM 2015 - 2015 IEEE Military Com-
munications Conference, Tampa, FL, 2015, pp. 695-700.
— R. Favraud, A. Apostolaras, N. Nikaein and T. Korakis, "Toward
moving public safety networks," in IEEE Communications Mag-
azine, vol. 54, no. 3, pp. 14-20, March 2016.
— R. Favraud, A. Apostolaras, N. Nikaein and T. Korakis, "Pub-
lic safety networks: Enabling mobility for critical communica-
tions," in Wireless Public Safety Networks 2 : A systemic ap-
proach, Wiley-ISTE, 2016.
In the second chapter, we start from these requirements that we
extend with the external constraints applying to communication sys-
tems for PS and military use, such as limitations in available fre-
quency resources. We then select LTE as the Radio Access Technol-
ogy (RAT) to be used to provide wireless access to mobile users as
it is the current RAT of choice for future PS communication systems.
Thus, we review the current LTE state of the art and we discuss on
the selection of the RAT to realize the wireless backhaul to be used
by a potential solution. While meshing the Base Transceiver Station
(BTS) using a dedicated RAT seems the easiest, LTE for both access
and backhaul arise as the solution for the most constrained use cases.
This has been discussed in the following contribution:
— R. Favraud and N. Nikaein, "Analysis of LTE Relay Interface for
Self-Backhauling in LTE Mesh Networks," 2017 IEEE 86th Vehic-
ular Technology Conference (VTC-Fall), Toronto, ON, Canada,
2017.
Using LTE for both access and backhaul is challenging. In the third
chapter, we detail the challenges faced by a LTE solution that would
answer both the functional requirements defined in the first chapter
and the external constraints underlined in the second chapter. Then,
we present a novel network infrastructure architecture that enables
multi-hop LTE mesh networking for nomadic and autonomous base
stations via in-band self-backhauling relying on a new BTS: the en-
hanced evolved Node B (e2NB). We present the e2NB building blocks,
such as the eNB and CN components as well as the newly defined vir-
tual UEs (vUEs) enabling the self-backhauling. We then present the
4 introduction

e2NB internal states that allow the dynamic meshing of the BTS and
finish this chapter with examples of resulting network topologies.
Then, we detail on the specific e2NB design elements and proce-
dures in the fourth chapter. Especially, we explore the choice of the
physical layer interfaces by first underlining the limitations of the
legacy User to UTRAN (Uu) interface before analytically comparing
Half Duplex (HD) and Full Duplex (FD) approaches justifying the use
of the LTE relay (Un) interface. We then present the main features and
procedures of the e2NB to enable the discovery and initial connection
of the BTSs. We then present in details the e2NB operation flow and
states allowing for node discovery and network split-and-merge be-
fore discussing on the specific CN features that are required. This
operation flows and states have been first presented in the following
contribution:
— R. Favraud, C. Y. Chang and N. Nikaein, "Autonomous Self-
Backhauled LTE Mesh Network With QoS Guarantee," in IEEE
Access, vol. 6, pp. 4083-4117, 2018.
In the fifth chapter, we investigate the coordination and orchestra-
tion functionality within the proposed architecture. As we are tar-
geting an applicable solution with constrained resources suitable for
both Frequency Division Duplexing (FDD) and Time Division Du-
plexing (TDD) operation, we propose a cross layer hierarchical re-
source scheduling algorithm in order to efficiently meet Quality of
Service (QoS) requirements for real-time traffic while maximizing the
throughput for elastic flows. This problem is tackled in two contribu-
tions:
— R. Favraud, N. Nikaein and C. Y. Chang, "QoS Guarantee in
Self-Backhauled LTE Mesh Networks," GLOBECOM 2017 - 2017
IEEE Global Communications Conference, Singapore, 2017.
— R. Favraud, C. Y. Chang and N. Nikaein, "Self-backhauled au-
tonomous LTE mesh networks," 2017 IEEE 13th International
Conference on Wireless and Mobile Computing, Networking
and Communications (WiMob), Rome, 2017.
Finally, in the sixth chapter, we aim to demonstrate the feasibility
and reliability of our proposed architecture, We first implement the
corresponding self-backhauling air interface (Un interface) on Open
Air Interface (OAI) platform and compare with the legacy LTE air-
interface on both computing requirements and spectral efficiency. We
then evaluate the efficiency and adaptability of our proposed hierar-
chical resource scheduling algorithm in various network topologies
and heterogeneous traffic flows with QoS requirements to show its
adaptability and limitations in both FDD and TDD configurations.
In the conclusion, we summarize the remaining uncertainties con-
cerning real-field deployments and we conclude this study drawing
the required steps to push the proposed solution forward to a func-
tional Radio Frequency (RF) wireless communication system.
S TAT E O F T H E A R T A N D P R O B L E M S TAT E M E N T
2
In this chapter, we introduce the specific use cases that we are tar-
geting in our study. We first briefly review the operational situations
encountered by military and navy entities and give a brief overview
of medium range naval communication systems. Then, we review PS
use cases and requirements as well as current PS communication sys-
tems. We present the common network topologies that can arise for
both military and PS communication systems depending on the op-
erational situation. Then, summarizing the discovered shortcomings,
we formulate the main goal of this study. Finally, we define the high
level requirements for a communication system to answer the consid-
ered use cases and we review the associated external constraints.

2.1 uses cases and current solutions

In this section, we briefly review the operational situations that can

be encountered by both PS and military organizations and present
the associated communication systems and shortcomings.

2.1.1 Military and Naval uses cases

Military authorities are in charge of a very broad range of missions

that require use of all possible communication media. Indeed, Mili-
tary authorities rely on Command, Control, Communications, Com-
puters, and Intelligence (C4I) to effectively address their missions.
Communications for the military forces are very strategic for control-
ling and information sharing in real time among different forces to
enable fast reaction to an event, as General Dempsey explains: “In-
formation systems and networks provide the means to send, receive, share,
and utilize information. The synthesis of advanced communications system
capabilities and sound doctrine leads to information superiority, which is
essential to success in all military operations” [1].
In most environments, deployed military forces have to rely heavily
on wireless communications to answer their communication needs as
there is either no fixed infrastructure available (i.e hostile territory) or
their mobile behavior prevents them to use any.
For instance, navies are operating at sea, from the sea side to high
sea where there is no available infrastructure. Nevertheless, fleet ma-
rine forces have to communicate to several entities that can be close
or very far away: civil surface ships; military surface ships and sub-
marines; airplanes; UAVs and Unmanned Surface Vehicles (USVs);

5
 6 state of the art and problem statement

operational centers at land, etc. Figure 1 provides an overview of

some communication needs of military and Naval Forces.

Legend
VLF
HF/VHF/UHF Satellite
SHF/EHF

Aircraft
Helicopter Aircraft
UAV Air
Land Sea Sea Land

Ship
Tank Ship Ship

USV Ship
Head
Troops Quarters
Aircraft
carrier Submarine
Speed boat Ship

Figure 1 – Overview of military and naval communications

To this end, several communication systems are embedded in navy

surface ships, leveraging the whole radio spectrum from Very Low
Frequency (VLF) to Extremely High Frequency (EHF) to provide com-
munications from close to far entities. However, communication sys-
tems for military and navies are not evolving as fast as civilian com-
munication systems while new use cases requiring better performance
are emerging.

Current naval medium range communication systems

Particularly, systems for medium range communications from ship

to ship, from ship to shore or from ship to drones in optical visi-
bility are currently not able to meet the increasing needs of navies
regarding data-rate and latency. Indeed, currently deployed commu-
nication systems for medium range communications rely on Ultra
High Frequency (UHF) radios using dedicated protocols with limited
bandwidth. For instance, for ship-to-ship data communications, the
French Navy uses a proprietary UHF RAT deployed in the Réseau
Intranet des Forces Aéro-Navales 2 (RIFAN 2) communication sys-
tem [2] while North Atlantic Treaty Organization (NATO) navies can
cooperate using the UHF SubNetwork Relay (SNR) system [3]. Perfor-
mance of these two systems are similar and are compared in Table 1
to the French military satellite communication system that provides
a global coverage and can also be used to transfer data from one ship
to another.
These communication systems are keys for successful operations in
Naval Forces (group of 3 to 10 navy ships) where many information
can be shared between ships. Their automatic setup and easy main-
tenance is highly appreciated by the sailors. However, there is a need
 2.1 uses cases and current solutions 7

Table 1 – Medium range ship-to-ship communication systems vs military

satellite
System UHF SNR [4] / RIFAN 2 Satellite (Syracuse [5])

UHF
Frequency band SHF, EHF
(500 KHz wide channel)

5 Mbps unprotected
Maximum data-rate < 2 Mbps
2 Mbps protected

240 ms on spot
Minimum latency > 100 ms
480 ms otherwise

Range Radio visibility (UHF) Satellite coverage

for more bandwidth, lower latency and more flexibility to improve

the situation awareness, to decrease the operating response time to
events and to meet new use cases such as video streaming and high
volume data transfers between ships.
While satellite communications can be leveraged for latency flexi-
ble data transfers, military satellites are shared among all forces and
temporary use of commercial services is expensive.
Moreover, there are also needs for middle range high bandwidth
data links for mobile entities (e.g. UAVs, USVs, commandos on board
of inflatable boats, etc.) hosted by ships or going around the navy
fleet. Nowadays, there is no common solution that answers these var-
ious needs: dedicated radios with limited interoperability are often
used and WiFi is being experimented for opportunistic links [6].
Last but not least, there is currently no wireless high data rate com-
munication system available when sailing close to shore or in port
while fast access to land hosted services could be leveraged by the
sailors in these situations.
To summarize, a list of requirements for a new wireless medium
range naval communication system leveraging the aforementioned
problems can be drawn:
— Wireless communications between several ships, between ship
and mobiles entities (drones, sailors, etc.), between ship and
shore
— Tens of kilometers of range (UHF radio visibility)
— High maximum data rates (> 1Mbps)
— Low latency (< 100ms)
— High spectral efficiency
— Frequency adaptability to fit with currently deployed systems
and bands
8 state of the art and problem statement

— Easy or ideally automatic set-up, use and maintenance

— Low Capital expenditure (CAPEX) and Operating expense (OPEX)

2.1.2 Public Safety uses cases

PS users and first responders encounter a wide range of operational

conditions due to their broad range of missions that can happen at
the local, regional or national level: Law Enforcement, Emergency
Medical and Health Services (EMHS), Border Security, Environment
protection, Search and rescue, Fire-fighting and Emergency Crisis. To
effectively address them, they need to rely on sufficient voice and
data communications services.
In 2006, the United States (U.S.) department of Homeland Security
published a PS statement of requirements. The first volume "describes
the public safety environment and the kinds of communication applications
and services public safety practitioners might expect to use in the future"
[7]. It defines several operational requirements to be supported by PS
networks to support the various operational use cases:
— Support to Command and Control hierarchy
— Support to interactive and non-interactive voice and data com-
munication
— Inter-agency interoperability
— Security
— Support to new data applications
The second volume of the U.S. department of Homeland Secu-
rity PS statement of requirements "provides specific performance require-
ments and metrics to ensure a quality of service level that is satisfactory or
higher for the applications and services identified in [the first] volume" [8].
Specifically, it defines technical requirements for:
— Speech transmission performance
— Video transmission performance
— QoS (packet loss, jitter, latency)
— Timeliness in the delivering messages
— Radio coverage
— Call prioritization
— Robustness of PS equipment
— Energy consumption
— Security
— Resilience/Availability of the networks
The survey from Baldini et Al. [9] provides a complete overview
of the PS environment by surveying the use cases, the current state
 2.2 network topologies 9

of wireless communication technologies and the current regulatory,

standardization and research activities related to PS communications.
Contrary to military communications, most PS communications re-
lies on fixed infrastructures and cellular networks as they operate on
friendly territory and on short to medium ranges. However, PS mis-
sions can take place in several different environments which affect
network availability and network topologies: in urban or suburban ar-
eas with high-density of people and limited area of operations, where
PS networks are usually deployed and provide sufficient coverage to
PS officers; in rural environment with remote areas and natural obsta-
cles where network availability can be scarce. Moreover, major events
such as natural disasters may damage the network equipment and
make it unavailable which calls for fallback procedures.

Current PS communication systems

Baldini et Al. survey [9] summarizes how current and potential

PS communication systems can provide the services and answer the
technical requirements from above.
Currently in use PS communication systems rely mostly on P25
(USA) [10], TETRA [11] or TETRAPOL (Europe) for the wireless ac-
cess. All three systems rely on fixed infrastructure based on fixed
BTS deployments that form a coherent cellular network. While these
systems are mature and can provide reliable mission-critical voice
communications, their designs cannot meet the requirement of high-
bandwidth applications like real-time video streaming or exchanges
of large amounts of data [12]. Indeed, the maximum data rate per
user is in the order of tens of kilobit per second (kbps) for P25 and
TETRAPOL and of hundreds of kbps for the last versions of TETRA
[9]. Moreover, there fixed deployment designs cannot sustain major
outage such as large natural disaster in a rural area due to the cen-
tralized architecture.

2.2 network topologies

In this section, we present the scenarios and common network

topologies that can arise for both military and PS communication sys-
tems depending on the operational situation. Moreover, this topolo-
gies also correspond to some moving cell scenarios that can appear
for instance in ITS and UAV use cases [13].

2.2.1 Scenarios

Normally, a nation-wide wireless PS network relies on a wired net-

work supporting fixed BTSs providing planned coverage and bring-
ing services to mobile entities (e.g., hand-held UEs or vehicle inte-
10 state of the art and problem statement

Table 2 – Possible network scenarios

UE-to-BTS BTS-to-CN BTS-to-BTS
Scenario BTS mobility
connectivity connectivity connectivity

1 In BTS coverage Complete Fixed Complete

2 In BTS coverage Limited Fixed Complete

3 In BTS coverage Limited Fixed Limited

4 In BTS coverage None Fixed Complete

5 In BTS coverage None Fixed Limited

6 In BTS coverage None Fixed None

7 In BTS coverage Limited Moving Complete

8 In BTS coverage Limited Moving Limited

9 In BTS coverage None Moving Complete

10 In BTS coverage None Moving Limited

11 In BTS coverage None Moving None

12 Out-of-coverage - - -

grated devices) that requires a seamless access to the CN. Such a de-
ployed network can support a variety of use cases; however, stringent
requirements shall be considered when utilizing it for PS communica-
tions, namely robustness, reliability, and non-prone to malfunctions
and outages [14]. Despite aforementioned deployment requirements,
such fixed BTSs may still not survive against unexpected events such
as earthquake, hurricane, tsunami, and wildfire. Moreover, it may not
cover distant lands due to costly deployment. Nevertheless, first re-
sponders still need efficient PS communications in all circumstances
even in harsh environments that require some large area opportunis-
tic BTSs deployments. In that sense, the PS wireless communications
cannot rely solely on the planned network and must be able to ensure
minimum services and sufficient level of quality when the planned
network is not fully available or not possible to deploy [14]. Such a
network architecture could also answer military use cases that do not
fit with the classical cellular architecture.
In view of the above limitations, Table 2 captures twelve scenarios
that can arise depending on four criteria: (i) UE-to-BTS connectivity,
(ii) BTS-to-CN connectivity, (iii) BTS mobility, and (iv) BTS-to-BTS
connectivity. These twelve situations are also illustrated in Figures 2,
3, 4 and 5. In the following, we go through these cases in more details.

— UE-to-BTS connectivity: In the nominal cases, users are under

BTS coverage (Scenario 1 to 11). When combined with all other
ideal factors, Scenario 1 is the nominal and ideal case with planned
and fixed BTS coverage and BTSs having complete access to the
 2.2 network topologies 11

PS / Mil PS / Mil PS / Mil

CN CN CN
Services Services Services
UE UE UE

Slow Slow
Nominal
Backhaul Link
BTS UE Backhaul Link BTS UE Backhaul Link BTS UE

UE UE UE UE UE UE
BTS BTS BTS relay
UE relay UE relay 2 UE 3
UE 1 UE Fixed BTS and relays UE Fixed BTS and relays
Fixed BTS and relay Limited backhaul access Limited backhaul access
Full backhaul access Full interconnectivity Slow interconnectivity

Figure 2 – Network topologies - scenarios 1, 2 and 3.

PS / Mil PS / Mil PS / Mil

Services
CN Services
CN
Services
CN
UE UE UE

BTS UE BTS UE BTS UE

UE UE UE UE
UE UE
BTS BTS BTS relay
UE relay 4 UE relay 5 UE 6
UE Fixed BTS and relay UE Fixed BTS and relay UE Fixed BTS and relay
No backhaul access No backhaul access No backhaul access
Full interconnectivity Slow interconnectivity No interconnectivity

Figure 3 – Network topologies - scenarios 4, 5 and 6.

PS / Mil PS / Mil
CN CN
Services Services
UE UE
Slow Backhaul
Moving Slow Backhaul Moving BTS
Fast
interconnection BTS
UE UE
UE UE
UE 7
UE 8
BTS UE Moving BTS BTS UE Moving BTS
Limited backhaul access Limited backhaul access
Full interconnectivity Limited interconnectivity

Figure 4 – Network topologies - scenarios 7 and 8.

Moving BTS UE Moving BTS UE Moving BTS UE UE

Fast D2D
UE
Slow
interconnection interconnection

UE UE UE
Moving BTS Moving BTS Moving BTS
9 10 11
UE UE
Moving BTS Moving BTS Moving BTS
No backhaul access No backhaul access No backhaul access 12
Full interconnectivity Limited interconnectivity No interconnectivity No BTS coverage

Figure 5 – Network topologies - scenarios 9, 10, 11 and 12.

CN that allows to provide services with no intermissions to in-

coverage UEs (e.g., continuous link connectivity with operation
center, monitoring, billing) [15]. Such scenario happens in the
covered cities and (sub)-urban environments where the network
deployment has been previously designed and planned. However,
users may be out-of-coverage of the service area or fail to maintain
any connection to BTSs due to their mobility (scenario 12). Hence,
users may rely on ProSe based on D2D communications [16] with
nearby users.
12 state of the art and problem statement

— BTS-to-CN connectivity: When the backhaul link (i.e., links be-

tween BTS and CN) disruption or failure happens, the CN may
not be fully accessible from BTSs. If it can only provide some con-
trol plane functionalities, i.e., BTSs can still accept PS UEs connec-
tions but need additional mechanisms to provide data transporta-
tions (e.g., local routing [17]), it is referred as limited BTS-to-CN
connectivity (scenarios 2 and 3). Otherwise, it is referred as un-
available BTS-to-CN connectivity (scenarios 4, 5 and 6) and some
local CN functionalities at BTS is required to serve PS UEs.
— BTS-to-BTS connectivity: We can observe that the BTS-to-BTS
connectivity does not necessarily rely on the backhaul connectiv-
ity. For instance, a full connectivity between BTSs (scenarios 2
and 4) can allow to form a large network even with limited BTS-
to-CN connectivity. 1 Note that the limited BTS-to-BTS connectiv-
ity (scenarios 3 and 5) case can only exchange partial information
between BTSs and may restrict certain features such as inter-BTS
handover.
— BTS mobility: Moving BTSs can be utilized in a dynamic fashion
(e.g., during fight against forest wildfire or using vehicular BTS be-
ing on land or at sea [18, 19]). In such cases, it is difficult to main-
tain a good connectivity between BTS and CN (scenarios 7 to 11)
and it is complicated to inter-connect these moving BTSs in terms
of different areas (coverage region, propagation condition) and
embedded equipments (dedicated or shared wireless backhaul).
In that sense, the network topology will split and merge dynam-
ically and it shall be maintained properly to provide the widest
service area to covered UEs. Furthermore, the interference be-
tween BTSs will become a performance-limiting factor when two
BTSs are getting closer and an interference management scheme
is mandatory.
New solutions need to be developed to tackle aforementioned non-
idealities of classical cellular networks.

2.2.2 Scenarios of reference

In the following, we consider two main scenarios to describe typical

use cases.
For naval communications, as we can see in Figure 1, ships are usu-
ally sailing in small groups, except in aeronaval groups where there
can be up to seven or eight ships at most. Distance between ships vary
from a few kilometers to tens of kilometers. Information is shared di-
rectly between ships to maintain the necessary operational awareness
which may require large data file transfers. There are usually not

1. The Performance-Enhancing Proxy (PEP) in IETF RFC 3135 and RFC 3449 can
be adapted to improve performance.
 2.3 problem statement 13

many mobile UEs around ships but some may require high band-
width to transmit real time videos or photos. Voice communications
are currently handled by dedicated systems and usually restricted to
each ship with few calls going from ship to ship.
For PS, communications are for the moment mostly voice commu-
nications due to the lack of high data rate service. In situation of
mobility without a fixed deployment, the number of involved BTSs
can vary from one to a few tens depending the area to cover. In
these cases, transmissions are mostly voice group communications
with potential records or transmissions to centralized BTSs and head
quarters.
We can summarize the considered scenarios and their characteris-
tics in Table 3.

Naval Mobile PS
Scenario
communications communications

Number of BTSs Less than ten Up to tens

Distance Up to tens of Hundreds to

between BTSs kilometers thousands meters

Number of UEs
Tens Tens to hundreds
per BTS

Traffic type Data file transfers Group audio calls

between BTSs Few audio calls Few data file transfers

Slowly moving compared Not moving to

BTS mobility
to inter-BTS distance tens of km/h

Channel type Maritime Urban, Suburban, Rural

Table 3 – Considered scenarios

2.3 problem statement

We have seen in sections 2.1.1 and 2.1.2 that current military and
PS communication systems are not up to the requirements of new use
cases, especially regarding maximum achievable data rates.
Moreover, we have seen in section 2.2.1 that several similar network
topologies can arise in PS and military use cases. However, as under-
lined in Baldini et Al. [9] study and in section 2.1.2, most PS commu-
nication systems are based on fixed deployed cellular networks and
cannot support all these network topologies as they require a steady
access to a common CN.
Thus, we see that both PS and military authorities could benefit
from new communication systems that would address their evolving
14 state of the art and problem statement

needs (high data rates, low latency, etc.) and match these use cases
(adaptability to various network topologies).
The goal of this study is to define a wireless communication sys-
tem to cover the network centric scenarios (ranging from 1 to 11 in
Table 2) that would provide better performance than current sys-
tems presented in section 2.1.1 and 2.1.2. Such a system would al-
low providing services to mobile users around BTS without requiring
connectivity to other external entities, while aiming for the widest
network coverage through BTSs interconnections to form a joint au-
tonomous network or several disjoint autonomous networks. Note that
while our initial targeted use cases are related to the PS and military
communications requiring emergency or opportunistic deployments,
such solution remains applicable to other use cases, e.g., moving ve-
hicular, ITS, drone networks, UAV communications, etc. [13, 18].

2.3.1 High level requirements

Based on aforementioned scenarios, an eligible solution shall be

capable of dealing with all related non-idealities. Hence, we provide
several high-level requirements regarding the system architecture and
the required features.
Firstly, each BTS should provide service to its local UEs even when
it is isolated, i.e., not connected to other BTSs or to the common CN.
This means that each BTS shall be an autonomous node and must at
minimum incorporate the following components and functions to be
able to able to provide services in autonomy:

(a) A radio stack to serve local UEs as a BTS;

(b) A subset of CN entities to provide policy control, local UEs
mobility management, authorization and authentication among
the others;
(c) A set of services/applications to allow for the minimum re-
quired services (i.e., voice, location, etc.) to be available at
served UEs.

Secondly, we aim to efficiently and seamlessly interconnect BTSs in

order to expand the network and to create an autonomous network.
An autonomous network is a network that integrates self-organizing
features in that it should detect, configure and maintain connection
with new joining nodes to provide the best performance in all situ-
ations regardless of the mobility of nodes. Moreover, it should not
rely on any entity external of the network to provide its services. Cre-
ation of an autonomous network is an enabler of several use cases in
military communications such as ship-to-ship communications pre-
sented in section 2.1.1. Thus, some additional elements and functions
are listed on top of the autonomous node requirements:
 2.3 problem statement 15

(d) A wireless communication interface to establish inter-BTS con-

nections;
(e) Neighboring BTSs detection and connection mechanisms to en-
able network split and merge;
(f) Self-reconfiguration capability to dynamically adapt to network
topology;
(g) Interference management schemes to limit interference impact
on UEs as well as BTSs;
(h) Connections between CNs that are hosted by different BTSs to
enable seamless inter-CN or inter-Mobility Management Entity
(MME) handover;
(i) An efficiently inter-BTS traffic routing mechanism to route traf-
fic in the network;
(j) Cooperation between services/applications of different network
nodes to enable the network-wide service.
To sum up, these requirements are mandatory to build and oper-
ate the envisioned autonomous network that provides the required
services with sufficient quality for PS and military users.
D E S I G N C O N S T R A I N T S A N D R AT C H O I C E
3
In the previous chapter, we defined the high level requirements
to be matched by a solution that would answer the considered use
cases for military and PS communications. In this chapter, we dis-
cuss briefly on the external constraints applying to communication
systems for military and PS use cases before discussing on the choice
of the RATs for the solution.

3.1 external constraints

Additionally to the high-level requirements regarding the required

features drawn in section 2.3.1, the PS and military authorities as well
as other organizations that require similar services will face other con-
straints when deploying the solution. These constraints are external
to the aforementioned scenarios but are essential to enable the solu-
tion for autonomous network.
Firstly, the constraint on the cost of the solution shall minimize the
requirement of CAPEX and OPEX. To reduce the CAPEX and OPEX,
infrastructure sharing is viewed as a beneficial approach to enable the
national PS network deployment [20]. In that sense, a solution that
only has limited hardware infrastructure requirement and integrates
automatic procedures for their exploitation such as self-configuration,
self-organization and self-healing is highly-anticipated.
Secondly, another constraint comes regarding the radio spectrum
access and can be severely dimensioning. Due to a high utilization of
the available spectrum, nowadays only few frequency bands and nar-
row bandwidth are available to enable the PS communications. Note
such available bands are managed by the state regulation and can be
limited and different from country to country. Moreover, the known
Industrial, Scientific, and Medical (ISM) frequency bands can be uti-
lized freely but suffer from power limitation and high interference.
Furthermore, in some use cases such as military operations, new wire-
less systems shall not disrupt previously deployed systems that are
still in use which may also limit the available frequency bands even
with legally access to several frequency bands. For instance, navy sur-
face ships are equipped with several radio frequency equipment for
communication but also for detection and surveillance such as radar
and radio detectors which occupy part of the radio spectrum.
In summary, a solution shall firstly be designed to cover the use
cases in section 2.2.1 and fulfill the aforementioned high-level require-
ment in section 2.3.1. Moreover, its cost shall be minimized in terms

17
18 design constraints and rat choice

of required hardware resource. Lastly, it shall be capable of deal-

ing with heterogeneous frequency band availability and reaches high
spectral efficiency.

Thus, we target to design a wireless communication system that

would allow the creation of various BTSs network topologies while
supporting mobiles entities and requiring minimum hardware and
frequency resources.

3.2 rat of autonomous network

Before designing a proper solution, we need to firstly select the

underlying RATs to enable the solution.

Baldiny et Al. survey from 2013 [9] compares the following com-
munication systems for PS use: Analog Professional Mobile Radio
(PMR); Digital Mobile Radio (DMR); P25; TETRA V.1; TETRA V.2;
TETRAPOL; Global System for Mobile communications (GSM) / Gen-
eral Packet Radio Service (GPRS)/ Universal Mobile Telecommunica-
tion System (UMTS) / 3G; LTE; Satellite Networks; WiFi / Worldwide
Interoperability for Microwave Access (WiMAX); Ad-hoc Networks;
Marine Communications; Avionics Communications. In their conclu-
sion, the authors notice that "LTE has emerged as the technology of
choice and future solution in PS". Indeed, 4G LTE is designed with
a number of interesting properties, namely high spectral efficiency,
frequency flexibility, large coverage area through high power support
and native support of variety of Internet Protocol (IP)-based services
thanks to the flat IP architecture. Ferrus et Al. [21] come to the same
conclusion, noting that LTE has reached the required maturity level
and wide adoption to replace the previous PS communication sys-
tems. However, both articles observe that LTE faces several challenges
to be adopted as the next PS wireless access technology as it is initially
designed for commercial markets.

However, some improvements have been achieved since 2013. 3GPP

has started to address specific PS requirements from Release 11 due
to growing demand for PS communications as we will show in the
next subsection, and LTE has been officially selected as the next RAT
for PS wireless access in the USA [22]. Moreover, LTE will serve as
the technology basis for future 5G systems and should continue to
evolve and to remain in use for commercial and private networks for
a long period thanks to it wide deployment and co-existence features
for use in unlicensed bands such as Licensed Assisted Access (LAA).

Based on these considerations, we only focus on LTE as the main

candidate RAT to provide the service on access link to PS and mili-
tary mobile users.
 3.2 rat of autonomous network 19

3.2.1 LTE state of the art

The LTE term is mainly used to refer to the Evolved Packet System
(EPS) while it originally corresponds only to the Radio Access Net-
work (RAN) part of the EPS, called the E-UTRAN that corresponds
to the deployed BTSs [23]. The EPS, that we will call LTE hereinafter,
is the new terrestrial cellular network specificied by the 3GPP to re-
place 2G and 3G cellular systems as shown on Figure 6.

802.11ac
802.11b 802.11a 802.11g 802.11n
802.11ad

802.16d
Fixed WiMAX WiBRO
IS-95A IS-95B IS-95C
CDMA CDMA cdma2000
802.16e
1xEV-DO Mobile WiMAX2
Release 0, A, B WiMAX
PDC iMode
802.16m
E-GPRS Commercially
EDGE 4G 4G+
EDGE
IS-136 Evolution
TDMA LTE
Rel - 8/9
LTE-Advanced
GPRS TD-SCDMA Rel - 10 ++
HSDPA
HSPA+
HSUPA
GSM HSCSD W-CDMA
4G
2G 2.5G 3G 3.5G 3.9G IMT-Advanced

Figure 6 – Evolution of cellular system standards.

The first version of LTE was released in 2008 in 3GPP Release 8. It

did not meet the requirement from International Telecommunication
Union (ITU) to be qualified as a 4G RAT, but Release 10 finalized
in 2011 did. LTE was designed with several goals in mind: high
spectral efficiency; high maximum data rate; low latency; bandwidth
and frequency flexibility. This, alongside some general motivations
to ensure competitiveness of 3GPP systems [23]:

— Provide higher data rates and better quality of service than pre-
vious cellular systems

— Deliver a packet switched optimized system

— Answer continuous demand for cost reduction (both CAPEX

and OPEX)

— Deliver a low complexity system

— Avoid unnecessary fragmentation of technologies for paired and

unpaired band operation
20 design constraints and rat choice

LTE architecture

LTE is a cellular communication system by design. Figure 7 presents

its nominal architecture.
It relies on fixed set of BTS, called eNB, that form the E-UTRAN
and are used to wirelessly serve mobile entities (UEs) through the
Uu interface. Each eNB is solely responsible of managing the radio
resources it can allocate to its multiple connected UEs on the Uu inter-
face. The Uu interface is the only interface on which the LTE network
is implementing all network layer starting from the physical layer up
to providing an IP connectivity to the UEs. Indeed, all other inter-
faces represented on Figure 7 (S1, S5, S6a, S7, S8, S11, X2) are taking
place on top of IP and can rely on any underlying wired or wire-
less technology that would provide an IP connectivity given some
minimum latency and/or data rate requirements. The eNBs are con-
nected to the CN, named EPC, through the S1 interfaces. Moreover,
the eNBs can be connected directly together through the X2 interface
which can be used for instance to ease handover of UEs. We stress
that the X2 interface is a high layer interface taking place over an ex-
isting IP connectivity through Stream Control Transmission Protocol
(SCTP) and GPRS Tunneling Protocol (GTP) tunnels established be-
tween eNBs. It cannot be used without any pre-existing physical and
higher layer interfaces bringing IP connectivity between eNBs.
The EPC is composed of several elements that are used to man-
age the control and user planes of UEs to provide end-to-end com-

SGi
EPC
HSS PCRF S7 P-GW

S6a S5-S8

MME S11 S-GW

E-UTRAN S1-MME S1-MME S1-U

S1-U S1-U
S1-MME X2

X2 X2

Uu Uu Uu Uu
Uu
eNodeB eNodeB eNodeB

UE UE
UE UE UE
Figure 7 – LTE nominal architecture (Release 8).
 3.2 rat of autonomous network 21

munications, authentication, handover and billing among other fea-

tures. The MME is the key control node for the LTE access network,
supporting security procedures for UE and network authentication,
ciphering and integrity protection. It handles all signaling proce-
dures related to session establishment and management as well as
associated QoS. It is part of the tracking area update process that
provides user location knowledge to the network for incoming ses-
sions. The MME is connected through S6a interface to the Home
Subscriber Server (HSS). The HSS is responsible for authenticating
and authorizing user access via forming the database that contains
user subscription and authentication context (through International
Mobile Subscriber Identity (IMSI) and Mobile Subscriber Integrated
Services Digital Network Number (MSISDN)) and transmitting the
security information and authentication keys to the MME and eNB.
The Serving Gateway (S-GW) and Packet Data Network Gateway (P-
GW) allows terminating UE data plane bearers. The P-GW is the
termination point toward external packet data networks such as In-
ternet through the SGi interface.
Finally, the Policy and Charging Rules Function (PCRF) server make
policy decisions based on the network operator rules and manages
charging of service data flows if necessary.

LTE standards development for PS

The simmering interest of public authorities in LTE for public-safety

use have encouraged 3GPP to tackle this subject. Especially, signifi-
cant standardization activities have been conducted after the creation
of the First Responder Network Authority (FirstNet) in the USA. As it
is illustrated in Figure 8, the first work dedicated on PS was launched

Features Isolated E-UTRAN

22.346 22.897 23.797 23.798 33.897

Mission Critical Mission Critical

Services Services
24.481 24.482 24.483 22.280 23.280 23.780
24.484 33.180 33.880

Mission Critical Mission Critical Data

Push To Talk 22.282 22.880 23.282
22.179 23.179 23.379 24.282 24.582
24.379 24.380 24.980
26.179 26.879 26.989
33.179 33.879 Mission Critical Video
22.281 22.879 23.281
Group Communications 24.281 24.581 26.281
22.468 23.768 36.868
High Power UE
(band 14) Proximity-based Services
36.521 36.837 22.803 23.303 23.703 32.844 33.833

Release 11 Release 12 Release 13 Release 14

Figure 8 – 3GPP PS oriented work items.
22 design constraints and rat choice

in 3GPP Release 11 along with the introduction of high power de-

vices operating in Band 14 (which is used in USA and Canada for
PS) and extending the possible coverage servicing area. Since then,
several work items have been defined in Release 12 and later to study
and address the specific requirements of a broadband PS wireless
network.
Nevertheless, the gaining momentum of LTE networks around the
globe has relied on its architecture to provide packet-based network
services which are independent from the underlying transport related
technologies. A key characteristic of this architecture is the strong
dependency of every BTS (also known as eNB) on the packet core
network (also known as EPC) for all the type of services that are pro-
vided to the covered UEs. However, this feature prevents UEs from
a seamless communication service when an eNB is getting discon-
nected of the EPC. Thus, eNB service to the UEs is interrupted even
for local communications which is essentially required by first respon-
ders. To tackle the aforementioned shortcoming, 3GPP has launched
two series of work items: the first one refers to device-to-device com-
munications for enabling ProSe, and the second one refers to the con-
tinuity of service for PS UEs by the RAN and eNBs in the case of
backhaul failure for enabling operation on “Isolated E-UTRAN”.
As it has been defined in Technical Specification (TS) 22.346, Iso-
lated E-UTRAN aims at the restoration of the service of one eNB or a
set of connected eNBs without addressing their backhaul connectiv-
ity. Therefore, Isolated E-UTRAN operation focuses on adapting to the
failure of the connectivity to the EPC and maintaining an acceptable
level of network operation in three cases: “no backhaul” case, “lim-
ited bandwidth signalling only backhaul” case and “limited band-
width signalling and user data backhaul” case (TS 22.346). Addition-
ally, in the case when there is no coverage from the wireless cellular
network or when it is no longer present due to unexpected disaster,
Isolated E-UTRAN can take place on top of Nomadic eNodeBs (NeN-
odeBs) deployments. NeNodeBs are intended for PS use providing
complementary coverage or additional capacity where service was
previously unavailable. In all cases, the goal of Isolated E-UTRAN
Operation for Public Safety (IOPS) is to maintain the maximum level
of communications for public safety users and TS 22.346 defines the
associated requirements. It should support voice and data commu-
nications, MCPTT, ProSe and group communications for PS UEs un-
der coverage as well as their mobility between BTSs of the Isolated
E-UTRAN, all while maintaining appropriate security (TS 33.897).
Subsequent to TS 22.346, Technical Report (TR) 23.797 provides
an answer to the “no backhaul” IOPS case relying on the availabil-
ity of a local EPC co-located with an eNB or on the accessibility of
a set of eNBs. If an eNB cannot reach such local EPC, it must re-
ject UE connection attempts. PS UEs should use a dedicated Uni-
 3.2 rat of autonomous network 23

versal Subscriber Identity Module (USIM) application for authentica-

tion and use classical Uu interface to connect to these IOPS networks.
However, the aforementioned solution does not address issues on
scenarios related with limited backhaul connectivity. Moreover, re-
quirements on the inter-eNB link connectivity are not specified, even
though the operation for group of inter-connected eNBs is defined.

LTE network topologies

In nominal condition, LTE is used to deploy a nationwide broad-

band wireless network that relies on fixed eNBs to provide planned
coverage to UEs through the Uu interface as shown in Figure 9.(1).
Such topology can be mapped to the scenario 1 in Table 2. All these
planned eNBs can have full access to the EPC through backhaul links
without any interruptions.
Figure 9.(2) extends the normal one-hop case (i.e., UE ↔ eNB) to
the two-hop case utilizing LTE relay node (i.e., UE ↔ relay ↔ eNB)
with the new Un interface towards eNB. The Un interface and relay
node is firstly standardized in 3GPP Release 10. However, relays
can be frequency inefficient when handling local communications as
the data has to go through the Donor evolved Node B (DeNB) to
reach centralized EPC as shown on Figure 9.(2). Moreover, these two
aforementioned topologies do not handle any mobility of BTS or CN
and thus can not cover all scenarios in Table 2, i.e., no common CN
access case (scenario 2 to 6) or mobile BTS cases (scenario 7 to 11).
To specifically address some PS scenarios, we have seen that 3GPP
defined the Isolated E-UTRAN concept and NeNodeB as shown in Fig-
ure 9.(3) [24]. Hence, such topology can be mapped to the scenarios
with no common CN connectivity, i.e., scenario 1 to 6 in Table 2. Nev-
ertheless, it can solely serve local UEs and can not establish any con-

1 – Nominal architecture 2 – Relay Self Backhauling (two hops)

EPC EPC

eNodeB
UE
UE
UE eNodeB
eNodeB
UE
UE relay UE

4 – Envisionned LTE Mesh architecture

UE
e2NB
e2NB
UE eNodeB + UE
local EPC
functions UE e2NB
UE UE
UE UE
UE e2NB e2NB
3 – Isolated E-UTRAN

Figure 9 – Topologies based on standard LTE BTS (1,2,3) and the envisioned
LTE network (4).
24 design constraints and rat choice

nection between BTSs to form an autonomous mesh network as shown

in Figure 9.(4).
To realize such topology in Figure 9.(4), which is one of our target
topologies, both access links (i.e., UE ↔ eNB) and backhaul links
(i.e., eNB ↔ eNB) shall be jointly considered in the design of the
architecture.

3.2.2 Backhaul link consideration

Several solutions can be envisioned for the wireless links that can
realize the mesh to interconnect the mobile BTSs. Note that what we
use the backhaul term hereinafter for the wireless links between the
BTSs and not only to name the connection of a BTS to a CN.
The most straightforward approach is to rely on a dedicated RATs
for the inter-connection of the BTSs. In nominal cellular architecture
with fixed deployments, wireless backhauling is often used relying on
Point To Point (PTP) or Point To Multi-Point (PTMP) RAT using direc-
tional antennas. Taipale T. studies the feasibility of a wireless mesh
for LTE small-cell backhauling [25] and details a new wireless mesh
solution developed by Nokia Networks (NN) and VTT Technical Re-
search Centre of Finland (VTT) as 802.11 (WiFi) and 802.16 (WiMAX)
mesh features and other available mesh networks were found not to
be suitable for this use case. However, the requirements of such a
backhaul are quite different from the one of PS use cases where some
communications can be handled locally, plus it relies on fixed BTS
which is not adequate. The 911-NOW proposal from Bell Labs [26] de-
tails a PS architecture that relies on meshing of moving BTS and inves-
tigates several problems that arise independently of the meshing RAT.
Thus, it does not really address the radio perspective and associated
problems (limited frequency resources, scheduling, etc.). The Abso-
lute FP7 project developed autonomous eNBs and new aerial LTE BTS
and multi-mode UEs for emergency PS communications, supporting
communications between eNBs through a satellite network or using
dedicated WiFi links [27, 28].
While some of these solutions might cover the use cases we identi-
fied, none matches the external requirements we draw in section 3.1.
Indeed, using a dedicated RAT requires dedicated frequency bands
and the associated hardware for the backhaul links while we target
a solution that minimizes the hardware and frequency resource re-
quirements and have already selected LTE as the access RAT. Even
if some hardware resources can be shared (such as antennas), isola-
tion between the access and backhaul bands at each BTS is required,
which might not be possible due to regulatory constraints on getting
frequency resources for each distinct band (PS use cases) or due to
other systems (military use cases). For instance, dividing a 10MHz
channel bandwidth into two 5MHz sub-bands to isolate access and
 3.2 rat of autonomous network 25

backhaul will put high requirements on filters and amplifiers at each

node to avoid self-interference or will require split in smaller sub-
bands. Furthermore, the split of the bandwidth will not scale with the
spatio-temporal traffic variability as access and backhaul resources
are completely separated, which in turn may reduce the overall per-
formance. Use of ISM bands to avoid regulatory constraints may
limit the coverage due to the power limitations and interference, es-
pecially as the mobile behavior prevents the use of highly directional
antennas. However, evolution of antenna tracking and beam forming
techniques might solve this specific problem, at a higher cost due to
more complex power and antenna systems.
Taking these constraints into account, we focus on the use LTE
for both access and inter-BTS connectivity. However, we have seen
that its current standard specifications and architecture needs to be
modified to answer all the considered scenarios shown in Table 2.
To reuse LTE for backhauling, there exist two possible deployments,
namely in-band or out-band. Relying on out-band LTE to realize a
wireless backhaul is a feasible yet simple solution via using different
frequency bands or component carriers between access and backhaul
links. However, this approach exhibits the same drawbacks as using
different RATs. These observations lead us to consider in-band LTE
backhauling as the most promising solution to effectively address all
the constraints and requirements at the cost of extra computational
complexity and overhead for control and coordination. In addition,
it provides the required flexibility to exploit the multiplexing gain
by sharing the resources across access and backhaul links as we will
show in section 7.3 as summarized in [29].. To briefly sum up, Table 4
compares all aforementioned backhaul link candidates in several as-
pects.

Table 4 – Comparison of different LTE meshing solutions

BTS meshing Out-band LTE or
In-band LTE
solution Out-band other RATs
Backhaul/access
Dedicated bands Shared band
frequency bands
Backhaul/access
Low Medium
flexibility
Scheduling
Medium Medium to High
complexity
Self-backhauling + to +++
+++
coverage (depends on RAT)
Hardware + to +++
+
cost (depends on RAT and bands)
ARCHITECTURE OF THE AUTONOMOUS BTS
4
Considering all previous requirements including the mobility of
BTSs as well as the selection of LTE RAT for both access and backhaul
links, we present in this chapter an autonomous BTS concept, namely
e2NB, that covers fixed and moving cell scenarios in order to support
new topologies as shown in Figure 9.(4) while respecting the stringent
constraints of section 3.1. Such BTS concept relies on LTE to enable
UE access and multi-hop self-backhauling capability through the use
of vUEs that allows to create autonomous mesh network enabling all
network-centric scenarios in Table 2. Moreover, the proposed e2NB is
able to utilize a single radio chain, reducing the cost of BTSs and al-
lowing to cope with the limited frequency bands availability case. We
first present the challenges this BTS is confronted to, then its architec-
ture and components before presenting its operational states and the
network topologies it can achieve through handling of network split
and merge mainly due to mobility as well as inter-BTS traffic routing.

4.1 challenges

Realizing an autonomous network based on meshing of enhanced

LTE eNB with in-band backhauling rises several challenges.

4.1.1 Support of Legacy UEs

Maintaining an in-band mesh network with shared access and back-

haul resources while supporting legacy UEs is not straightforward.
Indeed, there is no LTE standard feature to enable the multi-hop
wireless network. We have seen in section 3.2.1 that the legacy Uu
interface (cf. Figure 9.(1)) can only support a single hop. The Un in-
terface can extend to two LTE hops (cf. Figure 9.(2)). However, there
is no clear view on whether such Un can be used as a self-backhauling
interface to enable meshing the LTE BTSs (see Figure 9.(4)) due to the
requirements of the Uu interface on the access to the radio interface
and on the specification of Un that was engineered for single hop.

4.1.2 Autonomous operation

While legacy LTE system is designed to deploy fixed BTSs with

proper planning and Self Organizing Network (SON) capability [30],
the LTE BTSs are moving in the considered scenarios and are required
to be autonomous.

27
28 architecture of the autonomous bts

Self-configuration and self-organization extensions

Moving e2NBs can affect the behavior of other neighboring e2NBs

due to significant variations in perceived interference. Moreover, net-
work topology changes such as split and merge of nodes and net-
works are required as e2NBs are moving. Thus, some extensions are
required to continuously detect and resolve configuration conflicts
(for instance, Physical Cell Identity (PCI) conflicts), to manage in-
terference between e2NBs and to manage state changes as network
nodes are moving.

Coordinated scheduling

Because the radio resources are shared between access and back-
haul links, scheduling shall guarantee end-to-end QoS, in particular
for real-time traffics [31]. However, due to network mobility, wire-
less medium characteristics, and multi-hop nature of the traffic flows,
legacy scheduling algorithms (i.e. in LTE and ad-hoc network) are not
directly and efficiently applicable. Moreover, due to the characteris-
tic of concurrent radio resource accesses from different e2NBs over
backhaul and access link, the coordinated scheduling is required to
avoid blocking issues. However, a fully centralized scheduling may
suffer from scalability issues due to significantly higher overhead and
complexity making such approach not applicable.

Security

While LTE already provides specific security features such as au-

thentication and ciphering, some adaptations are needed to main-
tain the end-to-end security in time-varying network topologies for
e2NBs and UEs. Additional considerations have to be taken when
inter-networking (e.g., network of e2NBs or eNBs belonging to dif-
ferent authorities) is required. For instance, the context and security
token of a UE belonging to one e2NB should be transfered if this UE
is moving to another e2NB.

Service continuity

Maintaining user services and applications as network nodes are

moving is very challenging and require tight interactions among dif-
ferent components including topology management, routing, and ap-
plications. Service discover, registry and automatic reconfiguration
are required in the deployed services and applications as well as re-
active routing and dedicated CN procedures to handle the network
expansion and UE handover.
 4.2 architecture 29

4.2 architecture

Figure 10 presents the proposed e2NB stack, designed to fully sat-

isfy the requirements delineated in section 2.3.1 to enable an au-
tonomous LTE mesh network. In corresponding to the requirements
(a), (b) and (c) of section 2.3.1, the e2NB shall integrate:
— Legacy LTE eNB protocol stack;
— Transmitter (TX) / Receiver (RX) radio chain;
— LTE MME;
— LTE HSS;
— LTE S-GW;
— LTE P-GW;
— Set of applications and services (voice, data, video, etc.).
Such entities in e2NB allow to obtain an autonomous node that can
serve UEs locally and provide required services. Note that S-GW
and P-GW are only required if inter-networking with legacy eNB is
required and can be safely omitted from the proposed architecture
without any UE service interruption (i.e. relying on X2-based han-
dover and on an embedded routing module for packet marking and
forwarding). In addition, some remaining LTE entities like PCRF 1
can also be included in the e2NB if required.
In corresponding to the requirements from (d) to (h) in section 2.3.1
to establish a autonomous network, some additional elements are
integrated in the e2NB:
— UE/Relay Node (RN) stacks as a service, denoted as vUEs;
— Routing service;
— Coordination and Orchestration Entity (COE) agent.
These included vUEs are intuitively utilized to establish connections
with neighboring e2NBs. The routing service marks and forwards
traffic between e2NBs while bypassing legacy S-GW and P-GW enti-
ties based on the policy rules enforced by the COE. The COE agent
acts as a local controller in charge of managing routes, network topol-
ogy in accordance with other COE agents for optimization purposes,
and connectivity to coordinate inter-e2NB connections.
In the following, we describe the role of each component making a
single e2NB.

eNB
It provides the same operations as in a legacy LTE eNB in that it
communicates with UEs through the legacy Uu interface and with
MME and optionally S-GW through the legacy S1 interface [32].
1. Some related services and application can also be included such as IP Multi-
media Subsystem (IMS).
30 architecture of the autonomous bts

Coordination & Orchestration Entity Controller To other

networks
Applications & Services

e2NB
Coordination & Orchestration Entity Agent
Routing

eNB

Local EPC
HSS P-GW
vUE MME S-GW
NAS

IP RRC RRC IP
PDCP PDCP
RLC RLC
MAC MAC
PHY PHY

TX/RX Radio Chain

Uu/Un Uu/Un Uu

e2NB x vUE y UE z

Figure 10 – e2NB stack.

MME and HSS

These entities allow the autonomous node functionality at each

e2NB and function as described in 3.2.1. The MME is the key con-
trol node for the LTE access network and is connected through S6a
interface to the HSS. The HSS is responsible for authenticating and
authorizing user access via forming the database that contains user
subscription and authentication context.

S-GW and P-GW

The S-GW and P-GW allow terminating UE data plane bearers

as in a legacy LTE network. While they are used to ensure inter-
networking of legacy UEs, they are bypassed for communications
with vUEs to reduce the latency over the mesh network.

vUEs

These vUEs constitute the main differentiation from the legacy ap-
proaches. They are cleverly utilized to establish the inter-e2NB com-
munications. Each single vUE is managed and instructed by the
COE and can report real-time radio information (e.g., received sig-
 4.2 architecture 31

nal power, newly detected eNB information) to the COE. Further-

more, each vUE will include the entire protocol stack of a legacy UE
required to detect and establish communication with an eNB. Addi-
tionally, it includes the LTE RN stack to enable in-band backhauling.

TX/RX radio chain

As the interface towards other network entities (i.e., eNB/vUE of

other e2NBs, UE), such radio chain is shared between embedded eNB
and vUEs under the control of COE. To cover all the scenarios includ-
ing the worst case with a single frequency band, the e2NB shall op-
erate with only one radio chain to provide services to UEs through
Uu and to vUEs through Un as will be explained in section 5.1. Nev-
ertheless, such constraints can be relaxed for certain type of deploy-
ment scenarios to provide the required flexibility in switching TX/RX
radio chains among eNB/vUEs. Example scenarios include Carrier
Aggregation (CA) techniques or band separation between access and
backhaul links in frequency domain.

Routing

Such service enables routing and data forwarding both intra-e2NB

as well as inter-e2NBs. It is able to transmit and receive packets di-
rectly from eNB (e.g., vUE traffic) or from P-GW (e.g., legacy UE
traffic). Contrary to the legacy eNBs, an e2NB can act as the an IP
service end point (e.g., gateway) and have external interfaces toward
other networks. Lastly, the routing path is selected according to the
rules provided by the COE over multiple hops within the mesh net-
work.

Applications and services

Each e2NB is not only providing services to its local UEs but also
to remote UEs (and potentially to other eNBs, e.g., EPC as a service).
Furthermore, it relies on the routing service for discovery and coop-
eration in order to enable network wide UE services. Thus in the
envisioned architecture, the e2NB becomes a true service provider
by publishing the offered services as well as a service consumer by
subscribing to the service of other e2NBs.

COE agent

Following the Software-Define Networking (SDN) principles, the

COE agent is a local controller responsible for self-reconfiguration and
self-reorganization of the underlying e2NB as follows:
— Monitor the e2NB connectivity (via embedded vUEs and eNB)
and network topology;
 32 architecture of the autonomous bts

— Determine the IP addressing space over the mesh network in

cooperation with other e2NBs COE agent;
— Manage the entire life-cycle of each vUE from the initialization
(e.g., International Mobile Equipment Identity (IMEI), IMSI and
cryptographic functions), (re-)configuration , runtime manage-
ment and disposal;
— Control the radio chain access and configure the corresponding
network layers of embedded eNB and vUEs;
— Coordinate with the centralized COE controller and other COE
agents to enable the cross-layer control and management among
e2NBs.

4.3 e2nb states

Under the proposed e2NB architecture, a node can transit between

states as shown in Figure 11. The transition between states are man-
aged by the COE controller and the COE agents depending on the
e2NB environment evolution due to the mobility such as e2NBs in
reach and induced interference. In all states, the e2NB relies on a
vUE to periodically scan the network and detect new e2NBs. In the
Isolated state, the e2NB is not connected to any other e2NB and pro-
vides local service to its served UEs. In the Meshed state, the e2NB is
connected to at least one neighboring e2NB allowing it to extend the
network, give access to its services and gateway connectivity (if any)
to the rest of the mesh network, while providing network access to
the UEs under its coverage through its eNB stack. Lastly, in the vUE
relay state, the e2NB is connected to at least two other e2NBs and acts

Relaying on a mesh
Serving local UEs

Connecting to Switching off

neighboring e2NB embedded eNB
e2NB
states Isolated Meshed vUE relay
(vUE,eNB) (vUEs,eNB) (vUEs)
No inter-e2NB Starting
connection left embedded eNB

COE Controller COE Controller COE Controller

Applications & Services Applications & Services Applications & Services
e2NB e2NB e2NB

Corresponding COE Agent COE Agent COE Agent

stack status Routing Routing Routing

and vUE eNB vUE eNB vUE

Local

Local
EPC

EPC

connections
TX/RX Radio Chain TX/RX Radio Chain TX/RX Radio Chain
Uu Uu/Un Uu Uu/Un

UE z e2NB x vUE y UE z e2NB x

Figure 11 – Main e2NB states.

 4.4 e2nb network topologies 33

only as a relay between other e2NBs, potentially shares its services

and gateway access. However, it does not use its embedded eNB to
serve UEs but can keep active the eNB Un support. This state is used
when e2NBs are close enough to each others such that the UE access
can be handled without using all eNB stacks.

4.4 e2nb network topologies

Using this different nodes states and the properties of the described
e2NB, several topologies can be achieved such as the one presented
on Figure 9.(4). As stated in section 4.3, the state of each e2NB is
evolving due to the mobility of e2NBs and changes in the related
channels and traffic. The effective topology and the state of each
e2NB are directly related.
A network example is shown with the three different topologies
and the associated states in Figure 12. Firstly, a mesh network with
six e2NBs (e2NB1 to e2NB6) of which five are in the Meshed state and
serve UEs while one (e2NB2) is in the vUE relay state. Connections be-
tween Meshed state e2NBs have both Downlink (DL) and Uplink (UL)
directions relying on two corresponding vUEs, while connections be-
tween Meshed e2NB to the vUE relay e2NB only rely on the vUE at the
vUE relay e2NB, i.e., no vUE at the Meshed e2NB. Then, e2NB7 and
e2NB8 left the main mesh network but both are still in Meshed state as
they are still connected together. Finally, e2NB9 is in Isolated state as
it is not connected to any other e2NB. Last but not least, we can notice
that there is one extra instantiated vUE at each e2NB, for instance, 4
vUEs at e2NB2, in order to detect potential new neighboring e2NBs
or eNBs due to node mobility.

UE4
UE6

e2NB6 UE7
meshed e2NB7 e2NB8
meshed meshed
e2NB5
UE1 meshed
e2NB1 UE5
meshed UE8
e2NB4 e2NB9
meshed isolated

e2NB2 UE
vUE relay
vUE

eNB

UE2 Backhaul link

e2NB3 meshed UE3 Access link
UE9

Figure 12 – Example of different network topologies based on e2NBs.

DESIGN ELEMENTS AND PROCEDURES OF E2NB
5
In this chapter, we detail the design elements and procedures of
the proposed e2NB architecture to enable the autonomous network.
We firstly tackle several physical layer aspects for the inter-e2NB con-
nectivity. Then, we present the connection related procedures of the
e2NB, the associated specific LTE parameters that enable the auton-
omy, mobility and meshing of the BTS while retaining legacy UE
connectivity. Furthermore, we detail on the e2NB operation flow and
states. Finally, we expand on the CN procedures required to effi-
ciently provide services over the network.

5.1 physical layer interfaces

As mentioned before, the in-band deployment comes with highly-

anticipated characteristics at the cost of extra design issues that need
to be carefully tackled in the physical layer. Hence, we will give some
LTE background information and then elaborate the two key Uu and
Un interfaces.

5.1.1 Background LTE information

Originally, an eNB is composed of TX and RX chain to communi-

cate with UEs using Uu interface in DL and UL directions, respec-
tively. There are two duplexing modes that can be utilized for DL
and UL directions:
— FDD mode: A paired frequency band is divided equally to be
utilized for DL and UL directions separately.
— TDD mode: The same frequency band is shared between DL
and UL direction whereas disjoint time durations are used for
different directions. Such time-domain resource partition is
based on some pre-defined TDD UL/DL configurations.
While DL relies on Orthogonal Frequency Division Multiple Ac-
cess (OFDMA), the UL uses Single Carrier Frequency division Multi-
ple Access (SC-FDMA) that has lower Peak to Average Power Ratio
(PAPR) for better energy efficiency at UE side.
Then, we explain the basic resource element unit of the DL LTE
air interface. Firstly, a LTE frame lasts for 10ms and a frame com-
prises 10 Subframes (SFs) each with 1ms duration that number from
SF 0 to SF 9. Within one SF, we can furthermore decompose the
available resource in both time and frequency aspects. In time as-
pect, there are two slots in each SF and each slot contains several

35
36 design elements and procedures of e2nb

symbols, namely there are fourteen symbols in a SF numbering from

symbol 0 to symbol 14 in the normal cyclic prefix and twelve sym-
bols in the extended cyclic prefix case. In frequency aspect, each SF
is made up of several subcarriers depending on the frequency band-
width. Hence, we can come up with the smallest discrete element in
LTE with 1 subcarrier and 1 symbol as the Resource Element (RE).
Furthermore, the basic unit that can be allocated to a user is termed
as the Resource Block (RB) with 1 slot in time domain and 12 sub-
carriers in frequency domain. Usually, RBs are allocated in pair (a
Resource Block Pair (RBP)) in the same SF. This is summarized on
Figure 13 for a 1.4MHz channel. LTE channel width can be 1.4MHz,
3MHz, 5MHz, 10MHz, 15MHz or 20MHz, being respectively 6 Phys-
ical Resource Blocks (PRBs), 15 PRBs, 25 PRBs, 50 PRBs, 75 PRBs or
100 PRBs wide. The UL uses the same RB resource grid but the car-
rier arrangement is different and depends on the RB allocation due
to the use of SC-FDMA.

1 frame

Subframe 0 1 2 3 4 5 6 7 8 9
Slot 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
PRB 5
PRB 4
PRB 3
PRB 2
PRB 1
PRB 0

1 RB

Symbols 1 RE
0 1 2 3 4 5 6 7 8 9 10 11 12 13

12
subcarriers

1 CRS

Figure 13 – LTE resource grid for a 1.4MHz (6 PRBs) channel width.

5.1.2 Uu interface

To fully enable the Uu interface, BTSs have to broadcast a number

of mandatory control messages and synchronization signals to UEs.
Firstly, the Primary Synchronization Signal (PSS) and Secondary Syn-
chronization Signal (SSS) must be transmitted in the SF 0 and SF 5
(in FDD) to allow the initial synchronization of UEs. Then, the Mas-
ter Information Block (MIB) and a number of SIBs will then be uti-
lized by UEs to retrieve the common system information of the eNB.
Furthermore, each eNB transmits the first several symbols (ranges
from 1 to 3) spanned over all RBs in each SF for the control channels,
 5.1 physical layer interfaces 37

namely Physical Downlink Control Channel (PDCCH), Physical Con-

trol Format Indicator Channel (PCFICH), and Physical Hybrid-ARQ
Indicator Channel (PHICH). Note the Downlink Control Information
(DCI) is contained in the PDCCH with the essential control informa-
tion of DL and UL resource allocation for each UE. Finally, UEs will
use Cell-Specific Reference Signalss (CRSs) for synchronization and
channel estimation 1 in order to receive all previous channels and the
data channel, namely Physical Downlink Shared Channel (PDSCH).
Note the CRSs will take place on specific REs depending on the eNB
configuration.
These mandatory transmissions prevent the radio chain to be used
for both transmission and reception over Uu interface in a time divi-
sion manner (i.e HD) hence prohibits the possibility of in-band Uu
HD deployment as we mentioned in section 4. Indeed, it would re-
quire an eNB to be able to transmit the mandatory signals and the
co-located vUEs to receive the control channels and signals at the
same time which is not possible without FD radios.
Thus, we discuss on the use of FD or HD radios in the solution.

Full Duplex radios for LTE in-band meshing

A FD radio is a radio frequency system that is able to transmit and
receive on the same frequency or frequency band at the same time, i.e.
it does not require separating the transmission and reception neither
in time nor frequency. It was long considered not to be possible to
transmit and receive on the same frequency at the same time, as the
transmission power is several order of magnitude more powerful than
the signal of interest power in reception and acts as interference for
the receiver. However, the study of FD radios is now a trending topic
as some recent advancements in analog and digital RF cancellation
made their usage realistic in some scenarios [33].
Several works have been carried out to study the influence of FD
radios on cellular systems. In [34] and [35], performance of a FD
small-cell or BTS on the access link with HD UEs is compared to the
HD BTS case and show interesting improvements. In [36], perfor-
mance improvements are shown when using FD on small-cell relays
to realize backhaul and access links at the same time.
While FD radios may facilitate the establishment of the inter-BTS
links with a potential performance increase, unfortunately some lim-
itations still exist at the moment keeping FD solutions to be suitable
only for small cells in cellular networks [37]. This is a problem for the
scenarios such as PS and military use cases where high transmit power
is required.
Indeed, all of the previously cited works, such as in [33] and [38],
are realized with relatively low transmit power (23-24dBm). There is
1. Based on the transmission mode, the Demodulation Reference Signal (DMRS)
will be used.
38 design elements and procedures of e2nb

two reasons for that. First, the current analog RF cancellation tech-
niques reaches a maximum of 65-70dB which limits the maximum
transmit power with a fixed a minimum receiving power. Indeed,
assuming a minimum receiving power of -101.5dBm (3GPP require-
ment for a 10MHz channel [39] at a macro cell BTS) and the use
of a high quality 16 bit Analog-to-Digital Converter (ADC) receiver
providing 84dB of dynamic range (2 bits of margin), the maximum ac-
ceptable input signal power that would not saturate the receiver ADC
is -17.5dBm. This puts with a 65dB analog RF cancellation, without
any margin (for instance for PAPR of OFDMA), the maximum BTS
transmit power at 47,5dBm which is quite high but might be limiting
in military operations. Using a lower transmission power ensure that
the ADC will not be saturated after the analog cancellation. Second
and more importantly, current implementations show that combined
analog plus digital cancellation can reach up to 110dB [33–35, 37, 38,
40]. This is far from enough when using high transmission power.
Indeed, using a 46dBm (40W) transmitter, it brings the noise floor of
the receiver to -64dBm, losing tens of dB from a HD case. This will
significantly drain the battery of classical UEs and reduce the cell ra-
dius UL coverage and will also limit the maximum distance for the
backhaul links. This is what can be seen on the estimated crossover
points of [41], showing when FD is beneficial over HD depending
on the transmitting power as [42] shows that the FD approach can
greatly increase the performance subject to a smaller coverage.
A second problem apart from radio performance also arises. It
comes from the incompatibility of FD with respect to the legacy UEs
as it is not part of the standard and additional procedures are needed
on both network and terminal side to support the FD transmission
on the access (e.g. assigning different TDD configurations to different
UEs). However, such procedure could be easily implemented for the
backhaul links.
To sum up, we have first that the Uu interface is not suitable for HD
in-band inter-e2NB communication while maintaining Uu support for
legacy UEs and then that FD radios are not yet suitable for high power
applications. Fortunately, the Uu limitations for HD in-band can be
bypassed thanks to the Un interface.

5.1.3 Un relay interface

As we described in section 3.2.1, 3GPP introduced the Un relay

interface in Release 10 during its work on LTE relay for network ca-
pacity and coverage expansion. It allows to deploy some fixed RNs
in an in-band manner to extend the coverage of standard LTE BTS
through one extra hop (cf. Figure 9.(3)). Each in-band RN needs to
receive from its DeNB [43], through the Un interface and then relay
to the legacy UEs through the Uu interface using the same frequency
 5.1 physical layer interfaces 39

band (in either FDD or TDD). Such in-band characteristic requires a

Time Division Multiplexing (TDM) on the time-domain SFs between
the Un and Uu interfaces. To enable such TDM manner while fully
support Uu, several works aim to define new frame structure [29,
44] for the relay interface. However, these new structures can not be
directly enabled through the LTE system and will request a drastic
change that violates aforementioned external constraints introduced
in section 3.1. In contrast, the Un interface can utilize a mechanism
that is introduced in LTE evolved Multimedia Broadcast Multicast
Service (eMBMS) in 3GPP Release 8 that divides SFs into Multicast
Broadcast Single Frequency Network (MBSFN) SFs and non-MBSFN
SFs. In each frame, up to 6 MBSFN SFs are allowed in FDD more
whereas up to 5 MBSFN SFs for TDD more depending on the TDD
UL/DL configuration. During MBSFN SFs, legacy UEs are expecting
the reference signals only in the first symbols of a SF that are used for
the control channels transmission (PCFICH, PHICH, PDCCH) con-
trary to non-MBSFN SF where UEs expect such reference signals on
both slots of a SF. Via utilizing such characteristic, a RN can switch
between TX (to transmit to served UEs) and RX (to receive from the
DeNB) over MBSFN SFs while following the Uu interface specifica-
tion on its access links.
Furthermore, the Un interface relies on two new physical channels
that leverages the MBSFN SF properties: the Relay Physical Downlink
Control Channel (R-PDCCH) for control information delivery and the
Relay Physical Downlink Shared Channel (R-PDSCH) for data trans-
portation [45]. Such R-PDCCH can deliver downlink scheduling in-
formation (i.e., DeNB to RN) and uplink grant (i.e., for RN to DeNB
data transportation) using the same DCI formats as legacy PDCCH.
Both R-PDCCH and R-PDSCH (to a specific RN) have the same start-
ing position and ending position in a SF and they span 4 to 6 symbols
within the first slot in a SF (i.e., from symbol 0 to symbol 6) and 6 or
7 symbols within the second second in a SF (i.e., from symbol 7 to
symbol 13) as shown in Figure 14. Such flexible symbol duration de-
pends on the higher-layer parameters Downlink StartSymbol (DLSS)
and End Symbol Index (ESI) in order to cope with the transmission

PDSCH
11, 12 or 13 symbols; PRBs are allocated in per-user basis
Symbol
0 1 2 3 4 5 6 7 8 9 10 11 12 13

PDCCH
1, 2 or 3 symbols of all PRBs
R-PDSCH
10, 11 or 12 symbols (13 is forbidden in standard); PRBs are allocated in per-user basis
Symbol
0 1 2 3 4 5 6 7 8 9 10 11 12 13

R-PDCCH R-PDCCH
4, 5 or 6 symbols for DL control info 6 or 7 symbols for UL control info
1 to 8 PRBs depending on aggrega�on level 1 to 8 PRBs depending on aggrega�on level

Figure 14 – Symbol allocation in a SF for Uu and Un interfaces.

40 design elements and procedures of e2nb

of the legacy control channels of UEs (PCFICH, PHICH, PDCCH),

TX/RX switching time or some non-idealities (e.g., propagation de-
lay, synchronization offset, etc.). In following, we elaborate on more
details about the differences between Un and Uu interface.

relay downlink Both R-PDCCH and PDCCH format the DCI

in the same way, but they are mapped to different time-domain sym-
bols (cf. Figure 14). PDCCH is mapped over the first symbols of a SF
and spans over all the RB (in practice, a single DCI covers only some
RBs) while R-PDCCH takes place into the symbols and RBs where
PDSCH is usually carried. There are two main types of DCIs with
different R-PDCCH mapping (see Figure 14 and 15): (1) DCI format
0, that corresponds to UL allocations, are mapped in the second slot
of a SF, and (2) all the other DCIs for DL allocation are mapped on
the first slot of a SF. For the RN to be able to find and decode the
DCI efficiently, the DeNB must give the RN a set of Virtual Resource
Blocks (VRBs) following resource allocation type 0, 1 or 2, where the
DCIs have to be searched for. Interleaving and non-interleaving map-
ping are defined. For non-interleaving mapping, a DCI is mapped
over one, two, four or eight VRBs part of the VRB set for aggregation
level 0, 1, 2 and 3 respectively. The aggregation level defines the re-
dundancy applied to each DCI that is mapped over 72, 144, 288 or
576 bits in aggregation level 0, 1, 2 and 3 respectively. There is a max-
imum of six possible VRB positions for a DCI under aggregation 0 (1
VRB) and under aggregation 1 (2 VRBs), and two possible positions
under aggregation 2 (4 VRBs) and 3 (8 VRBs). This gives a maxi-
mum of sixteen positions to be looked for by the relay for receiving
DL DCI. The same happens for UL DCIs in the second slot. As for
the R-PDSCH, one major difference from the PDSCH is in the avail-
able symbols within a SF for transportation (cf. Figure 14). Since a
fewer number of symbols (i.e., down to 10 symbols in Figure 14) can
be used for R-PDSCH transportation, the channel coding rate of R-
PDSCH will be increased correspondingly. To summarize, Figure 15
provides an example of resource allocation in DL for both DeNB and
RN of a SF with 14 symbols (PCFICH and PHICH are omitted for sim-
plicity). We can see that a DeNB needs to allocate resource to transmit
to 3 UEs (i.e., UE1, UE2, UE3) through PDCCH/PDSCH and to 2 RNs
(i.e., RN1, RN2) via R-PDSCH/R-PDCCH in Figure 15(a). Whereas
both transmission (to UEs) and reception (from DeNBs) are required
at RN2 as depicted in Figure 15(b) to ensure legacy Uu support.

relay uplink The relay UL direction of Un interface is almost

the same as the one of Uu interface with following exceptions. The
main difference is that the last symbol of each UL SF is reserved
to compensate for RX/TX switching time instead of carrying Sound-
ing Reference Signal (SRS). Moreover, there is no Acknowledgment
 5.1 physical layer interfaces 41

(ACK)/Non-acknowledgment (NACK) signal to be transported from

the DeNB to RN to indicate a successful reception or not of RN UL. In
comparison, PHICH is used for such purpose in Uu interface. Hence,
the RN can only depend on the New Data Indicator (NDI) informa-
tion in the DCI 0 of R-PDCCH to decide whether a re-transmission is
needed or not. Lastly, both TX and RX operations are required for a
RN on the UL channel to relay the UL transportation from UEs to its
DeNB.
Symbol
0 1 2 3 4 5 6 7 8 9 10 11 12 13
PRB 0
1
R-PDCCH(DL DCI) for RN1 R-PDCCH(UL DCI) for RN1
2
3 R-PDSCH for RN1
4 R-PDCCH(DL DCI) for RN2
5
6
7
8
9
PDCCH R-PDSCH for RN2
10
11
for
12 UE1,
13
14 UE2, PDSCH for UE1
15
16 UE3
17
18
PDSCH for UE2
19
20
21
22 PDSCH for UE3
23
24
(a) Resource allocation example at DeNB (TX).
Symbol
0 1 2 3 4 5 6 7 8 9 10 11 12 13
PRB 0
1
2
3
4 R-PDCCH(DL DCI) for RN2
5
6
7
8
9 R-PDSCH for RN2
10
PDCCH
11
for
12
UEs
13
14
15
16
TX→Rx RX→Tx
17
18 switching time switching time
19
20
21
22
23 TX RX
24
(b) Resource allocation example at RN2 (TX/RX).

Figure 15 – Resource allocation example of DL at DeNB/RN.

 42 design elements and procedures of e2nb

relay link scheduling DL and UL transmissions on the Un

interface are scheduled by the DeNB, but a RN can only listen to the
DL channel during its MBSFN SFs it defined to its local UEs. The
configuration of the MBSFN SFs is broadcasted in SIB 2 to the local
UEs [46]. Thus, a RN and its DeNB must agree on which SFs the RN
defines as MBSFN so that the DeNB does not transmit when the RN is
not listening. Moreover, a RN cannot schedule its UEs in the UL SFs
corresponding to its DL MBSFN SFs as these UL SFs are used for the
backhaul transmission to the DeNB (or if its does, it cannot transmit
to the DeNB if it receives an UL grant). Parameters SubframeConfig-
urationFDD and SubframeConfigurationTDD are used by the DeNB to
indicate to the RN which MBSFN SFs can be used for Un transmis-
sions between the DeNB and the RN [16]. For FDD, SubframeConfigu-
rationFDD is a bitmap vector of length 8 corresponding to the legacy
Hybrid Automatic Repeat reQuest (HARQ) processes cycle. When an
activated bit aligns with a MBSFN SF, this SF can be used for Un from
the DeNB to the RN. UL SFs to be used from the RN to the DeNB are
located 4ms after potential DL SFs as for the legacy Uu interface. For
TDD, a specific table is available showing the DL and UL subframes
for the Un transmissions on a frame basis depending on the Subframe-
ConfigurationTDD value. We can note that TDD UL/DL configuration
0 and 5 are not supported as TDD. Indeed, TDD UL/DL configura-
tion 0 does not have MBSFN SF while TDD UL/DL configuration 5
has only one complete UL SF for UEs that cannot be used by the RN
for the backhaul.

To summarize, special cares shall be taken to enable the Un inter-

face. In FDD mode, RN needs to be able to receive and transmit on
both DL and UL directions whereas legacy BTS only do transmission
(on DL) and reception (on UL) in each direction. Within TDD mode, a
faster switching than the one of legacy TDD mode is required as there
are two switching time between TX and RX in a SF (cf. Figure 15.(b)).

Table 5 – Comparison of LTE meshing solutions

BTS meshing solution HD out-band Uu FD in-band Uu HD in-band Un
Backhaul/access
Dedicated bands One shared One shared
frequency bands
Backhaul/access
Low Medium Medium
flexibility
Scheduling complexity Medium Medium to High Medium to High
Self-backhauling + (limited by
+++ +++
coverage RF cancellation)
+ to +++ depending None (TDD)
Hardware Cost ++
on band separation + (FDD)
Legacy UE support Yes No Yes
 5.2 physical layer design issues 43

Comparison of LTE meshing solution

To conclude on the choice of the backhaul solution, a comparison

between the LTE meshing solutions relying either on the out-band Uu
interface, on the in-band Un interface or on the in-band Uu with FD
radios is presented in Table 5. It can be inferred that the in-band Un
approach represents an opportunity to limit the modifications in the
Physical (PHY)/Medium Access Control (MAC) layer and design a
joint backhaul and access coordinated scheduling while retaining the
flexibility in terms of radio resources sharing between the backhaul
and access, the compatibility with the legacy UEs, and the cost of
BTS.

5.2 physical layer design issues

We have seen that a combination of Uu and Un can allow a RN

to use one radio chain for both backhaul (to the DeNB) and access
(to the UEs) link. Hence, we advocate that the Un interface can be
leveraged for the in-band inter-e2NB communications to mesh the
e2NBs. However, there are still some considerations to be resolved in
the physical layer as elaborated in following.

5.2.1 Synchronization

Within the backhaul links, synchronization issue has already been

studied to minimize disturbance between BTSs and to be compli-
ance with the frequency accuracy requirements [47]. Hence, both
frequency and time synchronization of e2NBs in the mesh network
are crucial for the use of the Un interface.

Time synchronization

Adjacent e2NBs need to be time synchronized; otherwise, some

transported physical channels of Un interface can not be properly
handled. A simple example with two e2NBs is shown in Figure 16
without time synchronization where some durations are reserved to
TX/RX switching. We can observe that R-PDCCH/R-PDSCH from
e2NB1 to e2NB2 of Figure 16.(a) can occupy 11 symbols (i.e., symbol
2 to 12); however, it is not possible to transport from e2NB2 to e2NB1
in Figure 16.(b) since the last symbol (i.e. symbol 12) will overlap
with the TX/RX switching duration at e2NB1. Such case violates the
possible 11 to 13 symbol duration of R-PDCCH/R-PDSCH as shown
in Figure 14. In that sense, it is not feasible to have a Un interface
in both directions with a propagation time in the order of one Or-
thogonal Frequency Division Multiplexing (OFDM) symbol duration
(around 66.67 micro-seconds) that corresponds to around 20km phys-
ical distance (which can be realistic for high powered maritime and
44 design elements and procedures of e2nb

PDCCH R-PDCCH/R-PDSCH (From e2NB1 to e2NB2)

e2NB1 0 1 2 3 4 5 6 7 8 9 10 11 12 13
OK
e2NB2 0 1 2 3 4 5 6 7 8 9 10 11 12 13

PDCCH TX→RX switching time RX→TX switching time

Timing offset between e2NB1 and e2NB2
(a) From early e2NB to late e2NB.
PDCCH TX→RX switching time RX→TX switching time

e2NB1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 Fail

e2NB2 0 1 2 3 4 5 6 7 8 9 10 11 12 13

PDCCH R-PDCCH/R-PDSCH ( From e2NB2 to e2NB1)

Timing offset between e2NB1 and e2NB2
(b) From late e2NB to early e2NB.

Figure 16 – Non-synchronized e2NB transportation.

PS use cases). Last but not least, 3GPP specified the minimum re-
quirement for TDD time synchronization to be up to 10 (large cell) or
3 (small cell) micro-seconds [48].
In the case of FDD network, UL timing synchronization also mat-
ters. A fixed RN that connects to a DeNB can adjust its UL timing
advance to its DeNB before starting its own eNB stack. However, as
an e2NB may start independently from other nodes, it will not be able
to update its UL reference timing. A global UL SF synchronization
will in average maximize the number of symbols that can be used for
UL as it does for DL.

Frequency synchronization

As the in-band characteristic, each e2NB shall transmit at the same

carrier frequency of both Un and Uu interfaces. Hence, frequency
synchronization is mandatory to build up a self-backhauling network
and avoid extra inter-carrier interference due to the Carrier Frequency
Offset (CFO) which is regulated to be within 0.05 parts-per-million
(ppm) to 0.25 ppm by 3GPP [39].
To address both synchronization issues, a Global Positioning Sys-
tem Disciplined Oscillator (GPSDO) can be utilized as a clock ref-
erence for the local oscillator at each e2NB to guarantee extremely
high frequency (sub-parts-per-billion (ppb) level) and time (<20 ns)
synchronization [49]. However, when the Global Positioning System
(GPS) signal is not available (e.g., tunnel), the Rubidium oscillators
can provide holdover capability to steer synchronization [50].
 5.2 physical layer design issues 45

5.2.2 Range limitation

The time synchronization between e2NBs will limit the maximum

distance between e2NBs to have a backhaul link as current standard
only allows Un interface to strip out up to the last symbol as shown
in Fig. 14 in order to propagate the Un interface channels and tran-
sition to the Uu interface. In specific, both R-PDCCH and R-PDSCH
can either finish at symbol 12 or symbol 13 within a SF. Finishing
at symbol 13 makes an e2NB unable to receive all symbols when us-
ing perfect time synchronization, while finishing at symbol 12 allows
for a theoretical maximum range of 21,4 kilometers distance between
e2NBs without considering the RX→TX switching time at the receiv-
ing e2NB. This range is too short for some high power and long range
use cases such as naval communications and it calls for modifications
in the usable symbol range to further increase the maximum reach-
able distance. Possible values of DLSS and ESI can be extended to
allow using less than 10 symbols for the transmissions of R-PDCCH
and R-PDSCH.
However, any changes to use less than 10 symbols will impact the
available bits to carry the Transport Block Size (TBS) that defines the
number of information bits to be transported by the physical layer.
Such TBS computation is originally the same for Uu and Un interface
as stated before, except for the case with 1.4MHz radio bandwidth.
The TBS values defined in [51] do not depend on the number of avail-
able symbols for PDSCH/R-PDSCH transportation, but the number
of bits that can be carried by available REs shall be larger than the
value of TBS to guarantee a possibly successful reception, i.e., coding
rate shall be less than 1, at the first transmission. Take the case of sin-
gle antenna Transmission Mode (TM) 1 as an example, the maximum
value of TBS is 18336 bits shown in [51] when using the largest Mod-
ulation and Coding Scheme (MCS) 28 with 25 PRBs (i.e., NP RB = 25).
On the other hand, the number of bits that can be carried by available
REs can be formulated as:

Nbits = Qm ∗ (Nsubcarriers ∗ Nsymbols − NCRS ) ∗ NP RB (1)

where Nsubcarriers is the number of subcarriers in a PRB which is

equal to 12, Qm is the modulation order, i.e., the number of bits per
RE, which equals to 6 when MCS is 28, NCRS is the number of RE
used by CRS in the data region within a PRB which equals to 6 in TM
1, Nsymbols is the number of symbols for PDSCH/R-PDSCH transmis-
sion. With Nsymbols = 11, Nbits = 18900 > 18336 in the considered
case (MCS 28, 25 PRBs), the coding rate will be 0.97. However, when
Nsymbols becomes 10, then Nbits = 17100 < 18336, and the coding rate
will be 1.07.
To this end, reducing the number of symbols of R-PDSCH (i.e.,
Nsymbols ) will further prohibit some more combinations of MCS/PRB
46 design elements and procedures of e2nb

or either calls for a new TBS table to be defined in order to enable

possibly successful decoding at the first transmissions. Both methods
are feasible, but the second approach can take the extra advantage to
allow for a wider range of code rates.

Uneven UL and DL SFs in TDD mode

As described in section 5.1.3, UL SFs of the Un interface for TDD

mode are determined through a specific parameter, SubframeConfig-
urationTDD in [45]. Unlike the 1-to-1 mapping between the DL SFs
and UL SFs for FDD mode, such ratio can be larger than one for TDD
mode, i.e., a single UL SF for the UL transmission from RN to the
DeNB can correspond to several DL SFs. For instance, there are one
UL SFs (SF 3) and four DL SFs (SF 4, 7, 8, 9) within one frame when
SubframeConfigurationTDD is 17 [45]. While this is not a problem for
a legacy LTE network with RNs, it now becomes one main problem
of the proposed e2NB network architecture.
In contrast to a classical LTE RN that is connected only to one
DeNB, an e2NB can be connected to several other e2NBs. As it will
be presented in section 6, the DL SF allocation of Un interface can be
done in a dynamic way for efficient utilization in the mesh backhaul.
Such dynamics highlight that an e2NB can receive from several dif-
ferent e2NBs over different MBSFN SFs within a single frame. For
instance, in SubframeConfigurationTDD 17, an e2NB can receive from
up to four other e2NBs during a frame as there are four DL available
DLs; however, it only has one UL SFs to access. Hence, the Physical
Uplink Shared Channel (PUSCH) allocation of such e2NB toward dif-
ferent e2NBs will overlap. To avoid such overlapping, some allocation
strategies can be utilized by the COE controller and will be discussed
in chapter 6.

5.2.3 HARQ modifications for Un interface

As the adoption of Un interface for the multi-hop in-band backhaul-

ing, the mechanism of HARQ shall be examined correspondingly.

FDD mode

The HARQ mechanism in DL direction of Un interface is unchanged

in FDD mode and there are up to 6 HARQ process in support of
at most 6 MBSFN SFs in a frame to enable the retransmission ap-
proach. As for UL direction, since there is no PHICH-like channel
in Un interface to transport the ACK/NACK information, hence the
Un interface shall uses the NDI in UL DCI of R-PDCCH to decide if
a re-transmission is necessary or not relying on a fixed loop around
HARQ processes over SFs. However, as it will be presented in section
6, the SF allocation of Un interface can be done in a more dynamic
 5.3 e2nb procedures and parameters configuration 47

way for efficient resource utilization in the mesh backhaul, and the
corresponding HARQ process will not follow aforementioned fixed
loop over SFs. To tackle with such dynamic HARQ process scenario,
we propose to add the HARQ process information in UL DCI 0 of
R-PDCCH to identify which HARQ process shall be re-transmitted.

TDD mode

In the TDD modee, HARQ feedback for DL transmissions is also

problematic as the UL PUSCH collisions described in section 5.2.2
as Physical Uplink Control Channel (PUCCH) will also collide and
prohibit feedback information delivery. To handle such problem, we
propose the following mechanism assuming that the COE controller
is handling which e2NBs can use the UL SF allocation as mentioned
in section 5.2.2. Firstly, if the following UL SF is available to deliver
the UL feedback on the Un interface to the considered e2NB, then the
legacy HARQ mechanism is applied. Otherwise, the ACK/NACK
feedback of such e2NB will be delayed until the next DL SF alloca-
tion to this e2NB. To this end, such delayed ACK/NACK feedback
with the Channel Quality Indicator (CQI) report will be transmitted
over the message taking place at the UL DCI of the R-PDCCH (cf.
Fig. 14). Given the small size of ACK/NACK messages, several ACK-
s/NACKs can be multiplexed if several DL transmissions have been
received from the specific e2NB since the last DL transmission op-
portunity. Unfortunately, such method requires large buffers at the
e2NB DL queues and might increase latency of transmissions depend-
ing on the SF allocation for inter-e2NB transmissions. To cope with
such side effect, inter-e2NB transmissions can use more conservative
MCS index (e.g., lower modulation order, smaller coding rate) to re-
duce the probability of re-transmission at the cost of lower spectral
efficiency.
On the other hand, the HARQ process for DL direction can follow
the same mechanism as the one used in FDD with the re-transmission
indication relying on the NDI value within the UL DCI.

5.3 e2nb procedures and parameters configuration

In this subsection, we first list the eNB parameters that require

specific configuration to enable the backhaul link while supporting
legacy UEs at the meantime. Then, we introduce the attach procedure
as used by vUEs to establish the connection of inter-e2NB link. Fi-
nally, we present the e2NB operation flows that comprises the startup
phase, and the three aforementioned major states in Figure 11.
48 design elements and procedures of e2nb

5.3.1 eNB parameters

As the legacy eNB, the eNB stack of e2NB relies on an extensive

set of parameters regarding all the spanned network layers. Some
of these parameters require specific configuration to allow the e2NB
meshing capability. We can separate such parameters into two dif-
ferent groups: (a) parameters that can be configured depending on
configuration of adjacent eNBs, and (b) parameters that require spe-
cific values to allow the inter-e2NB communication through the Un
interface while supporting the Uu interface to serve local UEs. In
the group (a), we find the PCI, Tracking Area Identity (TAI), radio
resource configuration information like random access channel con-
figuration and MBSFN information in SIB2 with the related prerequi-
site information to receive SIB2 such as MIB and SIB1, as well as all
parameters related to enhanced Inter Cell Interference Coordination
(eICIC) and Further enhanced Inter Cell Interference Coordination
(FeICIC). Whereas in the group (b), we find parameters related to
neighboring cell information in other SIBs, and more generally to the
initial connection setup as well as parameters related to UL schedul-
ing requests.

While some parameters can be updated when the eNB is serving

local UEs, others cannot and must be configured before starting the
eNB stack otherwise leading to local UEs being disconnected for the
update. This is especially the case for the PCI that can be obtained by
UEs when receiving the PSS and SSS from eNB. Furthermore, it will
impact the generation of a pseudo-random sequence used to scramble
specific LTE channels (e.g., PDCCH, PDSCH, etc.) and it defines the
position of the REs for CRS. Note the CRS is crucial and used by UEs
for synchronization and channel estimation. While the PCI can have
504 different values, the CRS have only 6 different mapping positions.
This means that two different PCI values with P CI1 and P CI2 such
that P CI1 ≡ P CI2 mod 6 lead to the same CRS positions over REs.
Such same CRS positions will make difficulties for UEs to do any
channel estimation and cell detection. Thus, PCI values should be
configured carefully among adjacent eNBs.

5.3.2 vUE attach procedure

As introduced beforehand, we utilize both Uu and Un interfaces

for the inter-e2NB backhaul link. Hence, the attach procedure is pro-
vided in Figure 17 and we detail the overall procedure in this sub-
section. To enable such procedure, we rely on some specific parame-
ter configuration that allows e2NB to connect to new e2NB using its
vUEs without disconnecting locally served UEs.
 5.3 e2nb procedures and parameters configuration 49

vUE Uu eNB

PSS / SSS
MIB
SIBs
PRACH Preamble
RACH Response
RRC Connection Request
RRC Connection Setup
RRC: RRC Connection Setup Complete +
NAS: Attach request
RRC: dlInformationTransfer +
EMM: Authentication Request
RRC: ulInformationTransfer +
EMM: Authentication Response
RRC: dlInformationTransfer +
EMM: Security Mode Command
RRC: ulInformationTransfer +
EMM: Security Mode Complete
RRC: Security Mode Command
RRC: Security Mode Complete
RRC Connection Reconfiguration +
EMM: Attach Request +
ESM: Activate Default EPS Bearer Context Request
RRC Connection Reconfiguration Complete
RRC: ulInformationTransfer +
EMM: Attach Complete +
ESM: Activate Default EPS Bearer Context Accept
Proprietary message exchange
Proprietary message exchange
Switch to Un

Figure 17 – Connection procedure.

Detection procedure

There are two ways to detect adjacent eNBs, being e2NBs or legacy
eNBs. The first one relies only on the e2NB (autonomous detection)
while the second one leverages UEs connected to the e2NB (assisted
detection).

autonomous detection Firstly, a problem comes out as the

embedded eNB and vUEs are sharing the radio interface which im-
plies that the vUE cannot naturally receive and detect the PSS/SSS
broadcasted by neighboring eNB.
Thanks to the time and frequency synchronization previously de-
scribed, it is simple for a vUE to detect PSS and SSS from adjacent
50 design elements and procedures of e2nb

BTSs via only listening to some small time duration close to the SF
0 and SF 5 in a frame. Nevertheless, the co-located eNB will need
to blank some eNB transmissions to enable such detection and thus
impacts the local UE in terms of detection, synchronization and fail-
ure in radio link. To better depict such impact, we can first see that
the vUE does not need to continuously detect neighboring e2NBs but
only periodically to check whether there is a new neighboring eNB.
Furthermore, the corresponding parameter in SIB can be configured
to make the link more prone to be in-sync state. For instance, the
eNB can blank SF(s) or even frame(s) without making its served UEs
be out-of-synch state if N310, T310 and N311 in the SIB2 are config-
ured adequately larger. Hence, a controlled blanking (sub-)frames is
feasible to allow vUE to detect PSS/SSS of neighboring e2NBs and
get their PCIs.
After receiving a new PCI, the vUE will start to receive MIB and
SIBs to confirm the Public Land Mobile Network (PLMN) identity as
well as the E-UTRAN Cell Identifier (ECI) to form the E-UTRAN Cell
Global Identifier (ECGI). This will uniquely identify the e2NB during
the configuration procedure using a predefined hash function. While
MIB and SIB1 have fixed position in frames, other SIB positions in
time are defined by each eNB. To optimize such reception of SIBs
at vUE, the eNBs shall configure the position of SIBs 2 to be always
in non-MBSFN SFs, for instance in SF 4 or SF 9 for FDD mode, to
limit the vUE access time to the radio chain. Furthermore, the COE
agent should properly allocate non-MBSFN SFs to the vUE for SIB
decoding.

assisted detection To help detecting adjacent e2NBs and eNBs,

the e2NB can instruct connected UEs to perform measurements on
their RF interface. This is usually used to populate the Neighbour
Relation Table (nrt) of the eNBs through the Automatic Neighbour
Relation (ANR) function [46, 52]. Specifically, the UEs measure and
reports PCIs, and the eNB can order specific UEs to report the ECGI
corresponding to specific PCIs. Using that feature, the e2NB can de-
tect other nodes faster or it can detect nodes that are not in its detec-
tion range.

Connection procedure

Based on the e2NB identity (ECGI), the COE agent can determine
from its topology knowledge if such detected e2NB is already part
of the mesh to decide whether to establish the connection to such
neighboring e2NB.
Then, the random access process will be initiated by vUE to trans-
port the Physical Random Access Channel (PRACH) preamble. Note

2. Based on the schedulingInfoList in SIB1.

 5.3 e2nb procedures and parameters configuration 51

the PRACH configuration index in SIB2 should be set such that the
possible SFs for a UE/vUE to transmit the Random Access Channel
(RACH) preamble duration and position do not overlap with MBSFN
SFs as the eNB might not be listening to the UL channel due to the
backhaul transportations. Once the eNB successfully receives the
RACH preamble, it can transmit the RACH response to vUE in a
predefined window size between 2 and 10 ms long. However, the
vUE should not continuously listen to a such long duration to limit
perturbation of served UEs; hence we can set the eNB to always trans-
mit the response after a fixed amount of time over a non MBSFN SF
and to allocate UL SFs for this procedure over non MBSFN SFs.
The vUE then follows the legacy attach procedure used by UEs [53]
to establish the connection until reaching the Radio Resource Control
(RRC) Reconfiguration Complete step in Figure 17. It is noted that
similarly to the Random Access (RA) message exchange, the eNB
should be configured to transmit messages in a pre-configured timely
manner over non MBSFN SFs. Then, the Un interface will be con-
figured and used after finishing the attach complete and activating
default EPS bearer procedure in order to exchange between vUE and
eNB. Note the RRC connection shall be maintained during message
exchange in Un interface and it will be released when such connec-
tion can not be maintained, for instance, radio link failure case.
The complete detection and connection procedure is limited by the
frequency and tile the COE can allocate for listening the channel,
which depends on the current traffic on the considered e2NB. How-
ever, these procedures can be realized on all the bands available to
the e2NB. If the e2NB has several radio chains, it can dedicate some
for discovery and initial connection. However this can be efficient
only if the other e2NBs are not selecting the same bands for the same
purpose.

5.3.3 e2NB operation flow

In this paragraph, we detail on the operation flows among the

startup phase and the running phase that comprises three main states
(i.e., Isolated, Meshed and vUE relay) in Figures 18, 19, 20 and 21.
Before introducing the operation flow, it is noted that at least one in-
stantiated vUE is required to detect adjacent e2NBs or eNBs. This
operation flow ensures that the e2NB provides the best connectivity
service to its UEs and achieves the largest coverage through connec-
tivity to other e2NBs by managing the embedded radio chains and
turning on or off the embedded eNB.

Startup phase
Such startup phase only happens when we just (re-)start the e2NB.
It is used to configure eNB parameters before starting the eNB proto-
52 design elements and procedures of e2nb

col stack with the operation flow in Figure 18. In the legacy LTE sys-
tem, the initial configuration phase includes choosing the PCI value
through the self-configuration processes relying on the common CN
[30, 52, 54].
However, in our case, the newly startup e2NB do not have the ac-
cess to a common CN. Hence, following the e2NB architecture, a spe-
cific vUE is firstly orchestrated and instantiated by the local COE
agent to detect adjacent e2NBs or eNBs as shown on Figure 18. Such
BTS detection mechanism can follow the common cell search scheme
of legacy UE defined by 3GPP [55]. When detecting the neighbor-
ing BTS, the local COE agent will notify whether a connection shall
be established or not based on the broadcasted PLMN identity in
SIB1. If yes, the vUE will follow the aforementioned attach procedure
shown in Figure 17 for connection establishment to the e2NB. Such
connection between the vUE and e2NB can exchange the higher-level
information to agree on the R-PDCCH and R-PDSCH configuration
before using Un. Then, the e2NB will continue to orchestrate another
vUE in order to detect and connect to another neighboring e2NBs. Fi-
nally, after connecting to all selected neighboring e2NBs, such newly
startup eNB will be into one of the three main states depending on
the number of connected e2NBs.
Before stating the operation flow of other states, we detail on how
to configure parameter at startup phase. Based on all detected BTSs

Startup
(no vUE, no eNB)
Initialize new vUE

e(2)NB detection New eNB

procedure detected
No new e(2)NB
detected New e2NB detected
e2NB connection
procedure Fail

Success

Update embedded
eNB parameters

No connected e2NB Number of One connected e2NB

connected
e2NB(s)
Start embedded Start embedded
eNB More than one eNB
connected e2NB
To isolated state To vUE relay state To meshed state

Figure 18 – Startup phase operation flow.

 5.3 e2nb procedures and parameters configuration 53

and connected e2NBs, the COE agent can derive an adequate PCI
value to be used by the embedded eNB. Furthermore, it will also
configure parameters related to the eICIC/FeICIC and SIBs as the
parameters listed in group (a) of section 5.3.1. Whereas if no other
eNB/e2NB is detected by the vUE, the e2NB parameter will be self-
configured by its local COE. Such self-configuration can be based on
some hash functions relying on a suitable unique identity configured
by the vendor or by the responsible authority to statistically reduce
parameter colliding probability [56].

Isolated state

Such e2NB state is with one instantiated eNB and vUE in order
to serve local UEs and detect neighboring e2NBs following the flow
chart in Figure 19.
When the embedded vUE connects to a neighboring e2NB or the
embedded eNB have a new connection to a vUE, the e2NB will then
merge in its topology and go into the Meshed state. Otherwise, the
e2NB will monitor and update its eNB parameters.

pci collision In following, we use the PCI as an example to de-

pict how it works. Firstly, the conflicting e2NBs must realize that
there is a conflict. Such realization is not a problem when the conflict-
ing e2NBs are meshed due to the maintenance of topology at COE
Controller. However, it will become a problem when the conflict-
ing e2NBs are isolated or in different meshes. In that case, conflict-
ing e2NBs need to rely on the measurement done by its embedded
vUEs or served UEs. Even if the local UEs may not be able to re-
port directly such a situation, the monitoring on the inconsistencies

Isolated state
(vUE, eNB)
No new e(2)NB e(2)NB detection New eNB detected
detected procedure
Remote vUEs New e2NB detected
supervision
New e2NB connection Update embedded
Fail
No change Remote procedure eNB parameters
vUE Success
Conflict eNB connection
Initialize new vUE
parameters
No Yes Update topology
and routes
Update embedded
eNB parameters
Merge procedures

To isolated state To meshed state To isolated state

Figure 19 – Isolated state operation flow.

 54 design elements and procedures of e2nb

between the DL and UL directions can potentially disclose such hid-

den e2NB problem since only DL direction should be affected by the
PCI conflict. Secondly, the e2NB needs to resolve the PCI conflict.
A straightforward solution is to reconfigure the PCI and change all
related parameters. However, it will disconnect UEs and hence all
served UEs need to be firstly handovered to other e2NBs for service
continuity. If such solution is not feasible or improper due to high
priority traffics, another approach is to reconfigure parameters for a
late re-start.

Meshed state
(vUEs, eNB)
No new e(2)NB e(2)NB detection
Loss Remote detected New eNB detected
procedure
vUE connection Remote vUEs New e2NB
supervision detected
Otherwise New Remote e2NB connection Update embedded
vUE connection Fail
procedure eNB parameters
Embedded vUE
Success
Otherwise supervision
Initialize new vUE
Loss Embedded
vUE connection No new
Destroy Update topology reachable e2NB
corresponding vUE and routes

Interference New reachable e2NB(s)

High interference & Loss Previously
management Update topology
all UEs can be HO Reachable e2NB
and routes Merge procedures
Otherwise
Split procedures
Handover UEs Conflict eNB
parameters
No Yes Number of
Turn off eNB Update embedded connected No connected e2NB To meshed state
eNB parameters e2NB(s)
At least one
connected e2NB

To vUE relay state To meshed state To meshed state To isolated state

Figure 20 – Meshed state operation flow.

Meshed state
Such e2NB state is with one instantiated eNB and several vUEs to
serve local UEs, connect to neighboring e2NBs, and detect neighbor-
ing e2NBs with flow chart in Figure 20. Within such state, the e2NB
can remain in meshed state or transit to isolated state with possible
split or merge if the topology is changed. Note in the specific case
that satisfies: (a) all local UEs can be handovered to other e2NBs,
(b) no local UE requires direct access to the embedded applications
or to the gateway, and (c) high interference to neighboring e2NB; an
e2NB can turn off its embedded eNB and work as the vUE relay to
mesh backhaul links. Transition from Meshed state to vUE relay state
should be confirmed by the COE Controller.

vUE relay state

As shown in Figure 21, the e2NB can solely rely on the vUEs to
relay traffics. The COE controller handles the re-start of the eNB stack
 5.4 core network logical connectivity 55

when there is no vUE disconnection based on the network topology

and mobility. However, if connections to neighboring e2NBs are lost
such that the e2NB is only connected to one neighbor, it may transit to
the Meshed state by itself and turn on the eNB again. Such e2NB will
not go directly in the isolated state as it must have two neighboring
e2NBs before coming to vUE relay state. Such eNB re-start can base
on parameters decided by the approach stated in the startup phase
or instructed by the COE controller.
The vUE relay is used when the density of e2NBs increases and
when it becomes more efficient to shutdown some eNB stacks to re-
duce interference between adjacent e2NBs. In this state, the e2NB is
connected to at least two other e2NBs thanks to its embedded vUEs
and can relay traffic between those e2NBs, while the other e2NBs are
close enough to provide coverage and service to the legacy UEs that
were initially served by that e2NB.

vUE relay state

(vUEs)
No new e(2)NB e(2)NB detection New eNB detected
detected procedure

vUEs Loss Embedded New e2NB detected

No change
supervision vUE connection e2NB connection Update embedded
Fail
Destroy procedure eNB parameters
corresponding vUE Success
eNB start
instruction from Loss Previously Initialize new vUE
COE Controller Update topology
Reachable e2NB No new
and routes
Update topology reachable e2NB
Split procedures
and routes
Yes New reachable(s)
Number of e2NB(s)
No connected Otherwise
Start embedded e2NB(s) Merge procedures
Start embedded
eNB At least two eNB
connected e2NBs

To meshed state To vUE relay state To meshed state To vUE relay state

Figure 21 – vUE relay state operation flow.

5.4 core network logical connectivity

To effectively mesh several e2NBs and provide services over the

mesh network, the CN of each e2NB cannot be completely agnostic
of the presence of other e2NB. We detail here on some of the specific
behavior of CN elements to obtain a functional autonomous network.

5.4.1 MME

As legacy LTE access network, MME is a key controlling entity that

supports various functionalities to enable logical connectivity and ser-
vice continuity. Firstly, each MME shall maintain its own TAI, do
56 design elements and procedures of e2nb

the Tracking Area Update (TAU) for connected UE, and collaborate
with each other to enable the paging mechanism at the corresponding
e2NB to reach target vUE/UE. Secondly, the MME shall be changed
and the access context shall be exchanged during the S1 handover
of UE between e2NBs. Thirdly, the MME will maintain a unique S-
GW/P-GW for each UE and manage the bearer for UE to enable the
corresponding service.

5.4.2 HSS provisioning and cooperation

To allow inter-connection between e2NBs, the vUE and the embed-

ded eNB shall be able to authenticate each other. Thus, each HSS
must incorporate records of at least one authenticated vUE per e2NB
to enable inter-connections. Moreover, mechanisms to update/syn-
chronize the HSS databases from records of HSS belonging to other
e2NBs should be integrated to allow the handover of local UEs and
potentially the automatic update of the deployed and authorized e2NBs
in the mesh network. Security requirements of such procedures should
be carefully evaluated, but are deferred to future work.

5.4.3 S/P-GW

These two entities may be utilized to allow the IP-based communi-

cation of UEs (mainly between legacy eNBs and e2NBs). The S-GW
is served as the local mobility anchor which forwards UE data-plane
packets during the handover to another e2NB. Based on the network
topology and the location of the corresponding P-GW, the S-GW will
do data forwarding. Whereas the P-GW is served as the IP anchor of
the corresponding service and allocates IP address to the legacy UE.

5.4.4 Routing

There exists several routing algorithms that can be deployed on the

top of the mesh network leading to different metric optimization, for
instance an adaptive distributed mesh routing can be used to cope
with different traffic patterns and network topologies [57]. Our pro-
posal does not rely on any hypothesis of a specific routing algorithm
but the routes should be updated at each topology change and propa-
gated over the network. Note that network split and merge operation
will impact the routing decision, and can potentially trigger the han-
dover and gateway change for UEs.
 5.4 core network logical connectivity 57

5.4.5 Application and services

Such high-layer applications and services is used to retain the min-

imal user services regardless of e2NB states and can be used for fol-
lowing purposes:
— Embed applications to enable standalone operation (e.g., Voice
over IP (VoIP), file transfer to local server, etc.);
— Embed applications to enable cooperative network services (e.g.,
collaborative map/event, vital information broadcast, service
delegation, etc.);
— Enable cross-layer optimization and application-level access con-
trol (e.g., Flow control policies of real-time traffic flow, load bal-
ancing within the meshed network, access to the shared con-
tent).

summary In this chapter, we detailed on the building blocks and

approaches of the e2NB to enable the autonomous self-backhauling
LTE network in a bottom-up approach. All these blocks and e2NB
operation flow shall be coherently managed by the local COE agent.
However, we do not describe in detail how to control the topology,
schedule resource and manage interference efficiently to enable the
autonomous mesh network and QoS support via utilizing the COE agents
and controller. Hence, we continue on detailing our proposed ap-
proach to deal with these problems in the next chapter.
COE ALGORITHMS
6
As outlined in previous chapters, realizing an efficient inter-e2NB
mesh backhaul requires careful resource scheduling among links. In
this section, we firstly give an overview of the considered resource
allocation problem for self-backhauling. Then, we introduce the pro-
posed hierarchical approach that comprises a centralized scheduler, a
distributed scheduler and the way to utilize the COE architecture. Fi-
nally, we detail on the algorithms for both centralized and distributed
schedulers.

6.1 problem overview

Using the Un interface to realize the backhaul links of a LTE net-

work in a mesh fashion is similar to the Time Division Multiple Ac-
cess (TDMA) based wireless mesh network in order to utilize all MB-
SFN SFs. However, realizing an efficient wireless mesh network on a
single frequency band is still an open research problem. As all nodes
share the resources of the same frequency band, each transmitter be-
comes a potential interferer which limits the achievable rate. Further-
more, there exist more related issues that need to be considered in
the meantime as summarized in [58], including (a) topology control,
(b) routing, (c) link scheduling, (d) interference measurement, and (e)
power control. As all these issues are highly inter-dependent across
different network layers to provide suitable QoS of each traffic flow,
they can not be solved separately. For instance, in [59], the authors
jointly consider resource allocation and relay selection in a multi-hop
relay network to maximize total user satisfactions. Several routing
and scheduling or combined algorithms have been proposed for wire-
less mesh networks [58]. However, most of them are suited for 802.11
that relies on Carrier Sense Multiple Access with Collision Avoidance
(CSMA/CA) that has different constraints. WiMax integrates mesh
capabilities through the 802.16j amendment. It has been evaluated
for maritime mesh network next to shore in the Triton project [60]. A
summary of algorithms for scheduling and routing for WiMax mesh
networks can be find in He et Al. study [61]. However, WiMax mesh
network relies on the presence of specific BTSs, called Base Station
(BS), that act as gateway and are the point of convergence of all flows
coming from other BTSs called Subscriber Stations (SSs). In our use
cases, each BTS is hosting some services and providing local rout-
ing, thus there is no a priori preferred route to a specific gateway for
flow going through each BTS. Similar limitations can be drawn from

59
60 coe algorithms

other work investigating wireless LTE backhaul for other use cases.
For instance, Sapountzis evaluates the use of flexible TDD to realize
the wireless backhaul of LTE BTS [62]. However, while backhaul and
access are considered together to optimize the network, playing for
instance on user association, backhaul and access are using disjoint
bands and all flows are directed towards or from a common gateway.
Hence, we propose a coordinated and cross-layer approach to un-
leash the performance barriers when meshing e2NBs in order to guar-
antee the QoS in per-flow basis of the self-backhauling LTE mesh net-
work. As distributed scheduling is generally inefficient in QoS guar-
antee, it is based on an hybrid centralized and distributed scheduling
relying on centralized routing. It is designed to be lightweight with
low complexity to allow for fast computation and easy implementa-
tion. Last but not least, such approach will rely on the coordination
between COEs of meshed e2NBs that will be described in next sec-
tion.

6.2 coe role and proposed hierarchical approach

To enable such cross-layer coordination, we rely on the COEs that

can serve two different logical roles: COE controller and COE agent.
The COE controller is a logically centralized entity that is connected
to a number of COE agents [63], one per e2NB in a typical case (re-
fer to Figure 10). The COE controller manages and orchestrates the
mesh network through policy enforcement over the COE agents [19, 22].
The COE agent can either act as a local controller delegated by the
centralized controller, or in coordination with other agents and cen-

Coordination & Orchestration Entity Controller

Routing Topology Management

COE Controller Scheduling Algorithm

Centralized Node Scheduler (CNS) Flow controller

Flow properties
SuperFrame Performance indicator (source/destination node,
TX/RX Routes and e2NB status datarate,
allocations latency requirements)

Local interference Local flow

Local routing
management management
Distributed Link Scheduler (DLS)
Coordination & Orchestration Entity Agent
Figure 22 – Coordination and Orchestration Entity architecture.
 6.2 coe role and proposed hierarchical approach 61

tralized COE controller. The communication protocol between the cen-

tralized controller and agents is done through bi-directional message
exchange over the backhaul links. In one direction, the COE agent
sends measured performance indicators and e2NB status to the cen-
tralized controller and other agents, while in the other direction the
centralized controller enforces policies that define the operation to be
executed by the agents and the underlying eNB and vUEs, as shown
on Figure 22. Such COE coordination provides substantial flexibility
to realize the hierarchical approach, and is able to reduce the control
overhead by delegating more functions to the COE agent at the cost
of less coordination.
Then, all related cross-layer parameters shall be scheduled by the
centralized COE controller that include (a) next e2NB hop for back-
haul relaying, (b) MBSFN SFs for backhaul transportation, (c) relay-
ing transportation direction (DL/UL), and (d) low-layer transporta-
tion resource (e.g., PRBs, MCS) for both access and backhaul links.
However, due to the limitation of real deployment and time-scale
separation between COE controller and COE agents, the propagation
of control messages over the backhaul links cannot be instantaneous.
Thus, we can group parameters that shall be scheduled in a real-time
manner (i.e., (c), (d)) to be handled in a distributed manner whereas
some others are allocated centrally in a larger time-scale benefiting
from a whole network view (i.e., (a), (b)). To enable such hierarchical
approach, network information shall be abstracted by COE agent, for
instance, the Signal to Interference and Noise Ratio (SINR) is derived
from the Reference Signal Received Power (RSRP) measurement, in
order to provide a simple but sufficient network information to the
centralized COE controller.
The topology management unit in the centralized COE controller
will enforce policies to e2NBs in the mesh in order to decide to which
adjacent e2NBs they should connect to using their embedded vUEs.
Note the network topology is denoted via the standard graph nota-
tion G = (Ve2N B , Elink ). The vertex set Ve2N B comprises e2NBs in
the mesh, and the edge set Elink comprises directional edge (u, v ) in
the mesh where e2NB u acts as an eNB and e2NB v as a vUE. A
neighboring vertice set of e2NB u is defined as Nu that comprises
all its adjacent e2NBs. Based on the graph formation, we use the
Dijkstra’s shortest path algorithm in terms of the number of hops
to route traffics in the backhaul links. Such algorithm can signifi-
cantly reduce the per-flow latency generated by extra hops; however,
it can also be adapted to different edge weights to cope with different
traffic patterns and network topologies [57]. After routing, we fur-
thermore compute the link load for real-time traffic over edge (u, v )
as loadu,v in terms of the number of real-time traffic bits to be trans-
ported within a SF. It is based on the flow information available at
the flow controller entity at COE controller provided by COE agents. A
 62 coe algorithms

set L = {loadu,v : ∀ (u, v ) ∈ Elink } is defined to comprise all link load

of edges in the mesh that will be used for resource scheduling of real-
time traffic at the Centralized Node Scheduler (CNS). In contrast, the
non-real-time traffic, i.e., elastic traffic, will be served in a best-effort
manner.
After gathering all necessary information, the scheduling problem
aims to share the time resources (MBSFN SFs) and frequency re-
sources (PRBs) between e2NBs. Hence, a hierarchical scheduling
algorithm is proposed that is composed of a Controller Scheduling
Algorithm (CSA) that hosts a CNS and a Distributed Link Scheduler
(DLS). Note the centralized and distributed schedulers are executed
in different time-scales for several purposes: (i) reduce excess control-
plane overhead of full centralization, (ii) reuse the legacy SF-based
link adaption scheduler, and (iii) flexible network management and
orchestration. Then, Table 6 summarizes these two schedulers in sev-
eral aspects (detail later). To sum up, the hierarchical approach not
only shows its practical usage and implementation but also is compli-
ant with legacy SF-based schedulers.

Table 6 – Comparison of centralized and distributed schedulers

Characteristic CNS DLS
Central view Local view of
Network view
of mesh e2NBs neighboring vUE/UE
Large time-scale Small time-scale
Periodicity
(e.g., frame, superframe) (e.g., subframe)
Considered link Backhaul link Backhaul and Access link
Scheduled resource Time-domain MBSFN SF Frequency-domain PRB
Legacy compliance No legacy design Compliant with Uu scheduler
Interference impact Interference coordination Link adaptation
Prioritize e2NB with
Node prioritization Prioritize vUE over UE
high real-time demand
Traffic prioritization Prioritize real-time traffic over elastic traffic

6.3 coe controller scheduling algorithm

Firstly, we present the CSA at the centralized COE controller in Al-

gorithm 1. It periodically computes the backhaul SF allocation that
will be transmitted to each COE agent.
Here, as the centralized COE controller cannot allocate the e2NBs
on per Transmission Time Interval (TTI) basis (i.e. per single SF dura-
tion), we introduce the SuperFrame (SuF) concept. The duration of a
SuF is denoted as LSuF as computed in Algorithm 1; however, such
duration value is not fixed and can be updated after a period of time
PSuF or triggered via some events like a newly-added real-time traffic
 6.3 coe controller scheduling algorithm 63

Algorithm 1: COE Controller Scheduling Algorithm (CSA)

Input : PSuF is the SuperFrame update periodicity
Ve2N B is the set of e2NBs
L is the set of link load
Output : SFT X is the backhaul SF allocation for e2NBs
begin
SF _CN T = 0 ; /* Logical SF index at COE controller */
N = 0 ; /* Logical update index at COE controller */
while COE controller active do
SF _CN T = SF _CN T + 1 ; /* Current SF index */
U pdate = F alse ;
if event(f lows, topology, ...) then
U pdate = T rue ;
if SF _CN T ≡ 0 (mod PSuF ) ∨ U pdate then
N D=N+  1 ; /* Current update index */
Su , SuU = getSat(Ve2N B ) ; (cf. Eq. 2)
rtDisSat = 1 ;
while rtDisSat == 1 do
M axLat, Mhops = getInf os(f lows) ;
LN
 
SuF = M axLat/ (Mhops + of f set) ;
D = f (L
SFrt SuF , Ve2N B , L) ; (cf. Alg. 2)
−1 N
SFeD = g (LN D
SuF , LSuF , SFrt , Ve2N B , · · · · · · , Su ) ; (cf.
Eq. (3))
−1 N
SFeU = h(LN U
SuF , LSuF , SFrt , Ve2N B , · · · · · · , Su ) ; (cf.
 Eq.N(3))
SFT X , rtDisSat = CN S (LN

SuF , Ve2NB , ...
D , SF D , SF U ) ; (cf. Alg. 3)
· · · , Elink , SFrt e e
if rtDisSat == 1 then
/*Too many real-time flows*/
f lows = removeF low (f lows) ;

flow (event() in Algorithm 1). Normally, the duration of a SuF lasts

for tens of TTIs whereas the update period will be larger as hundreds
on TTIs. Then, the goal of CSA is to allocate the SFs (SFT X in Algo-
rithm 1) within the SuF duration to each inter-e2NB link to fulfill the
bandwidth requirement of real-time traffic via using the CNS (CN S
in Algorithm 1). If that is not possible, a dissatisfaction indicator is
used (rtDisSat in Algorithm 1) to enable the flow control operation
via rejecting or removing some traffic flows based on their priorities
and call admission control policies (removeF low () in Algorithm 1).
The COE controller is responsible to manage all real-time flows via
the integrated flow controller. Afterwards, each DLS will base on the
outcomes of the CSA (i.e., SFT X ) to distributively allocate the trans-
portation resources at each SF (DLS as presented in section 6.3.3 and
Algorithm 5).

In the following, we detail on the CSA operation.

64 coe algorithms

6.3.1 Superframe duration computation (LSuF )

As its centralized manner, the CSA can retrieve following informa-

tion regarding all real-time traffic flows from the flow controller:
— M axLat: The maximum acceptable latency for the real-time flows
(e.g., 150 ms for VoIP as detailed in section 7.2).
— Mhops : The expected maximum number of hops of all active real-
time traffic flows.
— of f set: A stretch factor of Mhops to deal with the mobility pattern
(i.e., vehicular speed) and network topology.
Based on aforementioned information, the CSA computes the SuF
duration (LSuF ) as shown in Algorithm 1. Then, all time-domain MB-
SFN SFs within such SuF duration are considered for the allocation
to inter-e2NB links for self-backhauling as we detail below.

6.3.2 SF allocation for inter-e2NB self-backhauling

After getting the duration of SuF, we then use Algorithm 2 to com-

pute the number of DL SFs required by each e2NB to transport real-
time flows within this duration as SFrt D u , ∀u ∈ V
[ ] e2N B . Note the
D
main operation to get the SFrt [u] is to divide the number of required
DL PRBs (i.e. rP RB D [u]) to the total number of PRBs in a single DL
SF (i.e., NPDRB ). In the computation of the number of required PRBs,
we firstly multiply the link load within a SF (i.e., LLu,v ) by the du-
ration of a SuF (i.e., LSuF ) to get the number of real-time bits to be
transported in the SuF duration. Then, we introduce P RBu,v D/U x
( )
as the functions that compute the number of required DL/UL PRBs
to transport x bits over link (u, v ) based on the measured channel
quality information reported from COE agents to the COE controller.
Furthermore, to respect the Uu and Un specifications in FDD mode,
an UL SF n will be allocated accordingly if the DL SF (n − 4) is allo-
cated. We observe that such correspondingness can be leveraged to
allocate the link loads in reverse direction (i.e., (v, u)) to the PRBs
of the corresponding UL SFs (i.e., nP RB u [u]). Hence, a portion (i.e.,
T ransportedRatio) of the corresponding link load in reverse direction
(i.e., LLv,u ) is reduced and more spare SFs in the SuF duration can
be utilized to allocate other traffic flows. Finally, if the CSA is able to
allocate SFrt D u DL SFs at each e2NB u over MBSFN SFs in the SuF
[ ]
duration, then the real-time traffics can be transported by the mesh
network.
After getting the number of SFs required by the real-time traffics,
there might be some remaining MBSFN SFs in the SuF duration that
are not utilized. Thus, we aim to carefully allocate these SFs to the
elastic traffic in the backhaul links. Firstly, we introduce the “satu-
rated” concept to know the bottleneck links of elastic traffics over the
 6.3 coe controller scheduling algorithm 65

D = f (L
Algorithm 2: SFrt SuF , Ve2N B , L)
Input : Ve2N B is the set of e2NBs
LSuF is the superframe duration
L is the set of link load with loadu,v of edge u → v
Nu is the neighboring e2NB set of u from Ve2N B
Output : SFrtD is the set of the number of SFs required by each e2NB for

real-time traffic transportation

begin
foreach u ∈ Ve2N B do
nP RB U [u] = 0 ; /* Initialize allocated UL PRBs of u */
foreach v ∈ Nu do
LLu,v = loadu,v ; /* Initialize each link load */

foreach u ∈ Ve2N B do
rP RB D [u] = v∈Nu P RBu,v
D (LL
P
  u,v · LSuF ) ;
D
D [u] = rP RB [u] ;
SFrt ND P RB
nP RB U [u] = SFrt D [u] · N U
P RB ;
foreach v ∈ Nu do
D
LLu,v = 0 ; /* allocated over DL in SFrt [u] */
U U
rP RB = P RBv,u (LLv,u · LSuF ) ;
if rP RB U 6= 0 then
tP RB U = min(rP RB U , nP RB U [u]) ;
nP RB U [u] = nP RB U [u] − tP RB U ;
T ransportedRatio = (1 − rP tP RB U ) ;
RB U
LLv,u = LLv,u · T ransportedRatio ;

mesh network. Here, for each link (u, v ), we independently consider

DL direction (DL (u, v )) and UL direction (U L (u, v )). A SF over DL
or UL direction (DL (u, v ) or U L (u, v )) is viewed as a “saturated SF”
when it can only transport less bits than the queued bits of all ag-
gregated elastic traffic flows after transporting the real-time traffic.
Furthermore, a direction (DL (u, v ) or U L (u, v )) is considered to be
“saturated” if the ratio of the number of “saturated SF” among all al-
located backhaul SFs in this direction is higher than a threshold value,
for instance, 90%. Finally, saturated neighboring sets of e2NB u in DL
and UL directions are defined in Eq. (2).

SuD , {v : v ∈ Nu , DL (u, v ) is saturated} (2a)

SuU , {v : v ∈ Nu , U L (v, u) is saturated} (2b)

Based on aforementioned definitions, we compute two values, i.e.,

SFeU [u] and SFeD [u], to represent the relative needs of the number of
UL/DL SFs by e2NB u to transport the elastic traffic to its saturated
neighbors in SuD and SuU as detailed in Eq. (3). As the first step, we
estimate the Average Frequency Reuse (AFR) factor from the previ-
−1 N −1
ous scheduling results (i.e., LNSuF , SFT X [u] in Algorithm 1) where
Nmbsf n (LSuF ) returns the set of MBSFN SF during the SuF duration
66 coe algorithms

LSuF . Such AFR indicates the level of resource reusing within the
whole network and cannot be smaller than 1. Then, as the second
step, we get an estimate of the number of “free SFs” in a SuF duration
as SFf ree via excluding SFs that are already reserved for real-time
traffic from all MBSFN SFs. Thirdly, we compute BeD [u] and BeU [u]
as the sum of average TBS per PRB of all saturated DL and UL di-
rections from u, respectively. These two summations use T BS (a, b)
function which outputs the TBS when applying MCS index a with
b PRBs. Here, M CSu,v D represents the applied MCS index on DL di-

rection DL (u, v ) whereas M CSu,v U is the applied MCS index on UL

direction U L (u, v ). Finally, the number of SFs that are required by

u for elastic traffic of UL/DL directions are derived as SFeU [u] and
SFeD [u].

P N −1
u∈Ve2N B SFT X [u]
AF R = (3a)
−1
Nmbsf n (LN )

SuF
 
X
SFf ree =  Nmbsf n (LN D

SuF ) − SFrt [u] · AF R (3b)

u∈Ve2N B
X
BeD D


[u] = T BS M CSu,v ,1 (3c)
v∈SuD
& '
BeD [u] · SFf ree
SFeD [u] = P D
(3d)
v∈Ve2N B Be [v ]
X
BeU [u] = U


T BS M CSv,u ,1 (3e)
v∈SuU
& '
B U [u] · SFf ree
SFeU [u] = Pe U
(3f)
v∈Ve2N B Be [v ]

Based on the above derivations, the CNS is shown in Algorithm 3

in order to allocate backhaul SFs for both real-time and elastic traffics.
SFT X [u] [v ] and SFRX [v ] [u] are the set of SFs used for transmission
and reception on edge (u, v ), respectively. The wildcard character
in algorithm 3 represent all possible e2NBs. The main design prin-
ciple of this algorithm is to allocate SFs based on the prioritization
of real-time traffic over elastic traffic 1 such that there is no collisions
between e2NBs that would be interfering too much. As the output,
SFT X contains all transmitting SFs for all links over a SuF duration
and rtDisSat indicates if the scheduler can satisfy all required SFs
for real-time traffic or not. Such dissatisfaction indicator is used for
aforementioned flow control operation in Algorithm 1.
Last but not least, the interference blocking set Iu,v comprises the
e2NBs which shall be blocked due to the transmission on edge (u, v )
1. sort_descend (V, a, b, · · · ) is to sort V in descending order following the metric
ordering from a, b and so on.
 6.3 coe controller scheduling algorithm 67

Algorithm 3: Centralize Node Scheduler (CNS)

CN S (LN D D U
SuF , Ve2N B , Elink , SFrt , SFe , SFe )
Input : LN SuF is the superframe duration
D , SF D , SF U .
Ve2N B , Elink , SFrt e e
Output : SFT X , rtDisSat
SFM BSF N = Nmbsf n LN


SuF ; /*Initialize the MBSFN SF set*/
foreach u ∈ Ve2N B do
foreach v ∈ Ve2N B ∧ (u, v ) ∈ Elink do
T x(u, v ) = 0 ; /* Initialize the DL SF temporary number */
SFT X [u][v ] = SFM BSF N ; /* Initialize transmit SFs */
SFRX [v ][u] = SFM BSF N ; /* Initialize receive SFs */
rtDisSat = 0 ; /* Initialize dissatisfaction indicator */
foreach SF ∈ SFM BSF N do
sort_descend(Ve2N B , SFrt D , SF D , SF U ) ;
e e
Ae2N B = ∅ ; /* Initialize active e2NB set */
foreach u ∈ Ve2N B do
D [u] + SF D [u] + SF U [u] ≥ 1 then
if SFrt e e
if SF ∈ SFT X [u][∗] then
T ransmit = 0 ; /* Initialize transmit indicator */
foreach v ∈ Ve2N B ∧ (u, v ) ∈ Elink do
if SF ∈ SFRX [v ][u] then
Iu,v = genIntf (u, v, Ae2N B ) ; (cf. Alg. 4)
T
if ∃ w ∈ Ae2N B Iu,v then
/* Cannot transmit to vUE v that would receive
too much interference from e2NBs already
activated in Ae2N B */
remove(SF, SFRX [v ][u]) ;
remove(SF, SFT X [u][v ]) ;
else
T ransmit = 1 ;
T x(u, v ) = T x(u, v ) + 1 ;
remove(SF, SFRX [u][∗]) ;
remove(SF, SFT X [v ][∗]) ;
foreach w 6= u ∈ Ve2N B and (v, w ) ∈ Elink do
remove(SF, SFRX [v ][w ]) ;
foreach w ∈ Iu,v do
remove(SF, SFT X [w ][∗]) ;

else
remove(SF, SFT X [u][v ]) ;
if T ransmit ==S1 then
Ae2N B = u Ae2N B ;
if min(T x(u, ∗)) ≥ 1 then
foreach v ∈ Ve2NB ∧ (u, v ) ∈ Elink do
T x(u, v ) = T x(u, v ) − 1 ;
D [u] ≥ 1 then
if SFrt
SFrtD [u] = SF D [u] − 1 ;
rt
else if SFeD [u] ≥ 1 then
SFeD [u] = SFeD [u] − 1 ;
else if SFeU [u] ≥ 1 then
SFeU [u] = SFeU [u] − 1 ;

foreach u ∈ Ve2N B do
D [u] 6= 0 then
if SFrt
rtDisSat = 1 ;
68 coe algorithms

as shown in Algorithm 4. Note the decision is made based on the

received signal power (i.e., Pu,v and Pw,v ) and a pre-specified block-
ing criterion denoted as criteria (a, b). Such criteria (a, b) can be the
difference of two input signal power (i.e., like A3 event of LTE han-
dover), the decreasing of mapped MCS index due to the interferer, or
other criteria. Finally, the output of such algorithm will be utilized in
the CNS of Algorithm 3 for interference coordination at centralized
COE controller.

Algorithm 4: Generate interferer e2NB (genIntf (u, v, Ae2N B ))

Input : (u, v ) is the edge of the graph from u to v
Px,w is received signal power at w from x
criteria (a, b) is blocking criteria with input a, b
Output : Iu,v
begin
Iu,v = ∅ ;
foreach w ∈ Ae2N B ∧ w 6= u do
if criteria(Pu,v , Pw,v ) then
/* Add interferer when meet blocking criteria */
S
Iu,v = w Iu,v ;

6.3.3 Distributed link scheduling

The results of CSA (i.e., SFT X ) are transported to each COE agent
for a distributed link scheduling. Such DLS aims to allocate the fre-
quency domain resource (i.e., PRB) and transport bits (i.e., TBS) of
the e2NB u in per-SF basis as shown in Algorithm 5. Here, a local
network view is maintained by each e2NB via forming the vUE set
(i.e., VvU E ) and UE set (i.e., VU E ) for its link scheduling purpose. Our
designed algorithm is to prioritize backhaul links (i.e., vUEs using
U n interface) over access links (i.e. UEs using U u interface) as the
former one can only reach 60% of peak rate (max number of MBSFN
SFs per frame) compared to 100% for the legacy UE while also prior-
itizing real-time traffics over elastic ones. Among vUEs/UEs in the
same set (i.e., VvU E /VU E ), we firstly sort them based on the number
of queued real-time traffic bits and then provide P RMmin PRBs in
a round-robin way. Furthermore, in the PRB provisioning, the num-
ber of requested bit (i.e. ReqBit) within the corresponding queues
is used to derive the allocated PRBs, and thus prevent resource over-
provisioning. It has to be noted that Algorithm 5 can be adapt to
apply priorities among UEs/vUEs.
 6.4 relaying direction selection 69

Algorithm 5: Distributed Link scheduler (DLS)

Input : u is current e2NB identifier
SF is current subframe identifier in the superframe
VU E is set of UEs at u with non-empty queue
VvU E is set of vUEs at u with non-empty queue
Q[x][p] is queue size of (v)UE x with priority p
NP RB is the number of available PRBs in SF
SFT X is transmit SFs from Algorithm 3
M CS [x] is the applied MCS index of vUE/UE x
P RBmin is the minimum number of allocated PRBs for each
user
Output : PRB, TBS
sort_descend(VU E , Q[∗][0]) ; /*sort UE based on queue size*/
sort_descend(VvU E , Q[∗][0]) ; /*sort vUE based on queue size*/
S
foreach x ∈ VU E VvU E do
P RB [x] = 0 ; /* Initialize allocated PRB */
T BS [x] = 0 ; /* Initialize allocated TBS */
TP RB = NP RB ; /* Initialize available PRBs in a SF */
priority = 0 ; /* 0: real-time, 1: elastic */
while TP RB > 0 ∧ priority < 2 do
satisf y = 1 ; /* Indicate flow of current priority is satisfied */
foreach x ∈ VvU E do
if SF ∈ SFT X [u] [x] then
ReqBit = priority
P
p=0 Q [x] [p] ;
if TP RB > 0 ∧ T BS [x] < ReqBit then
P RB [x] = P RB [x] + P RBmin ;
TP RB = TP RB − P RBmin ;
T BS [x] = T BS (M CS [x], P RB [x]) ;
satisf y = 0 ;

if satisf y == 1 then
/* Schedule UEs after satisfying all vUEs */
foreach x ∈ VU E do
ReqBit = priority
P
p=0 Q [x] [p] ;
if SF ∈ SFT X [u] [∗] then
if TP RB > 0 ∧ T BS [x] < ReqBit then
P RB [x] = P RB [x] + P RBmin ;
TP RB = TP RB − P RBmin ;
T BS [x] = T BS (M CS [x], P RB [x]) ;
satisf y = 0 ;

if satisf y == 1 then
/* Schedule elastic traffics after fulfilling real-time ones */
priority = priority + 1 ;

6.4 relaying direction selection

As mentioned beforehand, both DL and UL directions can be se-

lected during relaying in backhaul links. It means that each packet
can go over the DL or UL direction to reach the next hop. However,
70 coe algorithms

the selection of direction highly depends on the traffic QoS require-

ment, for instance, an ultra reliable traffic will select the one with
better signal quality whereas the mobile broadband traffic prefers the
one with higher throughput. Since our considered real-time traffic is
sensitive to the latency, we use the expected waiting time of both UL
and DL queues as the metric to decide which queue (DL or UL) is
more preferred.

6.5 extensions to tdd system

All aforementioned algorithms are designed for FDD system; how-

ever, a joint operation of heterogeneous FDD/TDD network is en-
visioned as an efficient deployment to utilize available spectrum re-
sources [64]. Moreover, the e2NB solution targets worst case scenar-
ios with limited radio bandwidth to which the TDD case is applicable.
Hence, our proposed approach shall also support TDD mode.
Firstly, the maximum number of MBSFN SFs within a TDD frame
is reduced to 5 since SF 0, 1, 2, 5, 6 can not be used for MBSFN pur-
pose in TDD mode. Furthermore, the FDD characteristic cannot be
leveraged to allocate resource also for reverse link when computing
SFrt in Algorithm 2. As fewer MBSFN SFs can be used for backhaul
link but with more required SFrt for real-time traffic transportation,
we can anticipate a smaller number of free SFs can be used for elastic
traffic (i.e., SFf ree in Eq. (3)).
Secondly, different TDD UL/DL configurations will bring uneven
number of UL/DL SFs within a frame as well as different UL/DL
relations among SFs. As explained in section 5.2.2, in some configu-
rations, a single TDD UL SF may have to multiplex several allocation
from various e2NBs coming from different DL SFs. A first solution
to avoid this problem is to rely only on DL transportation of the Un
interface over MBSFN SFs with the proposed adaptations for HARQ
handling. With guarantee from the above approach that each e2NB
gets at least one DL SF per SuF duration, it will provide the full con-
nectivity between e2NBs. However, it may not be the best approach
in terms of satisfying different traffic flows as the induced latency for
HARQ process and CQI report in a scenario with highly heteroge-
neous DL SF allocations between e2NBs. The second solution is to
enable the COE controller to allocate the UL SFs just after the alloca-
tion of DL SFs. Here, several strategies can be enforced as to allocate
UL SFs to minimize the average time until there is a possible SF that
can be used for the feedback, no matter it is along DL or UL direc-
tion. However, we might not be able to ensure the presence of a fast
feedback opportunity for every DL transmission. The last solution is
to modify the number of UL SFs in a frame for the self-backhauling
to make a more even ratio between DL and UL SFs. This is not di-
rectly possible using legacy UL SFs; however, some MBSFN SFs can
 6.6 extensions to multi-antenna and multi-sector bts 71

be selected by the COE controller to be used as UL-like SFs, i.e., the

allocation of these SFs is managed by UL DCIs transmitted in previ-
ous DL SFs. Even with fewer DL SFs to be allocated, such method
can ensure a fast feedback and leverage the benefit of the proposed
UL SF allocation in terms of the computation of SFrt for FDD mode.

6.6 extensions to multi-antenna and multi-sector bts

The proposed approach was designed and presented with single

antenna BTS as a target to match the use case requirements of a low
complexity and affordable solution. In general, multi-antenna BTS
can greatly improve performance in a wireless mesh network as the
extra dimension (i.e., number of antennas) is being added to further
reuse the available frequency spectrum. For instance, authors of [44]
propose to use the massive Multi Input Multi Output (MIMO) system
for in-band backhauling based on multi-antenna transceiver.
Apart from the multi-antenna BTS that can directly apply the pro-
posed approach without any drastic changes, the multi-sector BTS
can also be supported but with some necessary changes. As all sec-
tors are unlikely to be isolated sufficiently from each other, it is fair
to consider the blocking issue between adjacent sectors, i.e., a sector
that is transmitting will disable any receptions at its adjacent sectors
in the mean time. Such blocking issue can happen especially on high-
power BTS. In that sense, we propose two approaches to remedy this
issue.
A simpler approach is to consider that all sector on an active BTS
will always be transmitting when the BTS is active. In such a case, the
interferer generation (Algorithm 4) does not change and CNS (Algo-
D,i
rithm 3) is still valid as it is. However, different values of SFrt can
D
be further computed for antenna i based on the value of SFrt as the
maximum value for all antennas of such BTS. The same approach can
be applied in the computation of SFeD,i and SFeU,i at antenna i with
the value of SFeD and SFeU reflecting the maximum value among all
antennas at this BTS. Such approach would allow for a better satisfac-
tion to different traffic flows due to a higher number of links being
activated at the same time from a BTS. However, it leverages only
the highest number among antennas in terms of transmission aspect
without considering the highest number among antennas in reception
aspect.
More changes are required to leverage for both aspects of trans-
mission and reception. Ideally, each sector can be considered equiva-
lently as an e2NB with independent SFrt D , SF U , SF D in Algorithm 4
e e
and 3 but with one additional constraint to block adjacent sectors
when it is being allocated. Such constraint can lead to a better fre-
quency re-use; however, it will require each BTS to know for all its
sectors the interference contributed from other sectors of adjacent
72 coe algorithms

BTSs. Such information shall be reported to the COE controller but

may be complicated to be measured.

6.6.1 Analysis of the approach complexity

We then discuss on the complexity of the proposed approach.

Algorithm 1 is running at the centralized COE controller and it loops
until there is no more dissatisfaction for real-time flows. The number
of loops highly depends on the selected flow control algorithm which
is not detailed here as it depends on the traffic patterns and QoS
requirement. In each loop, it computes SFrt D , SF D , SF U and executes
e e
the CNS.
D computation in Algorithm 2 loops on the e2NB u within e2NB
SFrt
set Ve2N B (containing N e2NBs), where each e2NB u further loops on
the number of its adjacent e2NBs (i.e., Nu ) in FDD mode. While
the set Ve2N B can contain a large number of e2NBs, the set of adja-
cent e2NBs for each e2NB stays limited and will most likely never be
higher than a constant value c which is not proportional to N . So,
in a topology with few e2NBs where the number of e2NBs is com-
parable to the number of adjacent neighbors, D
the complexity of SFrt
computation is equivalent to O N 2 while for a larger network with

a higher number of nodes, it tends toward O (N ).

The computational complexity of SFeD and SFeU are equivalent to
O (N ) due to the summation over the set Ve2N B .
The CNS in Algorithm 3 loops firstly on the number of MBSFN
SFs which depends on the lowest latency requirements of the real-
time flows but is staked in all cases. Inside this first loop, it loops
on the e2NBs u in the set Ve2N B (equivalent to O (N )). Inside the
second loop, it loops on the edge set of connected neighbors to e2NB
u: v ∈ Ve2N B ∧ (u, v ) ∈ Elink which is equivalent to Nu . Inside this
third loop, it computes the interferers of the edge (u, v ) through Al-
gorithm 4 which loops on an equivalent of N in the worst case as the
considered activated e2NB set (Ae2N B ) is a subset of Ve2N B . How-
ever, the set Ae2N B considered in each run of Algorithm 4 can be
further restricted in a large network where far away nodes will for
sure not be interfering enough to meet the blocking criteria. Hence,
it will be fair and practical to consider the case that there will be no
interference between two nodes when there are more than x-hops in
between, with x ranges for instance from 3 to 10 depending on the
selected conservativeness. Finally,
the computational complexity of
CNS can be summarized as O (N 3 in its worst cases. However, it is
rarely behaving in such condition. Indeed, in small networks where
each Nu can be considered equivalent to N , the set Ae2N B will most
probably be very small compared to Ve2N B as most links will inter-
fere each other (i.e., low frequency re-use factor). In a larger network,
each Nu will be an order of magnitude smaller than N and will most
 6.7 interference management 73

probably be bounded by a constant value c which is not proportional

to N , while Ae2N B will tend toward the frequency re-use factor for
the last iteration in each second loop. Including these considerations,
Algorithm 3 should show a complexity more closer to O N 2 .

To conclude, the CNS is showing to be the most complex operation

that is executed by Algorithm 1. It leads Algorithm 1 to be O N 3
when considering the worst case in a very rare condition; however,
its computational complexity is mostly equal to O N 2 following our

previous discussion.

6.7 interference management

Interference in the proposed network is of four types:

1. Backhaul-backhaul interference, where transmission for or from a
vUE is interfering with transmission for or from another vUE;
2. Backhaul-access interference where transmission for or from a
vUE is interfering with transmission for or from a UE;
3. Access-backhaul interference where transmission for or from a
UE is interfering with transmission for or from a vUE;
4. Access-access interference, where transmission for or from a UE
is interfering with transmission for or from another UE.
Different mechanisms are used to cope with these four types of inter-
ference.
Backhaul-backhaul interference on DL is directly managed by the
proposed approach that enables e2NBs to transmit simultaneously
only if they are not interfering or interfering below a given threshold.
Backhaul-backhaul interference on UL can sometimes happen in FDD
mode and we give hints on how to manage it in section 7.2.3.
Backhaul-access interference can happen but should not be strong
as adjacent e2NBs are not activated at the same time. Moreover, on
DL the interference power profile should repeat over SuF as e2NB
allocations repeat, which can be used to estimate the interference in
advance and take it into account in power control and MCS choice
algorithms.
Access-backhaul interference on DL cannot happen as it is also di-
rectly managed and taken into account by the proposed approach.
Access-backhaul interference on UL can happen if e2NBs are schedul-
ing both UEs and vUEs in MBSFN SFs. In such a case, concurrent
transmission of a UE transmitting to a e2NB A and of a vUE from
e2NB B transmitting to e2NB C is possible. However, this should not
lead to strong interference as e2NB A and e2NB C should not be too
close to have been activated at the same time by the global algorithm.
Finally, Access-access interference exists as in other LTE networks.
eICIC or FeICIC mechanisms are used to reduce it. Moreover, if cov-
erage of adjacent e2NBs are severely overlapping, the COE controller
74 coe algorithms

can decide to put an e2NB or more in vUE relay mode which will
stop the Access-access interference that could be the result of that node
transmissions.

6.8 discussion on security issues

Based on the proposed solution, we can enable the autonomous

self-backhauled LTE mesh networks; however, cyber adversaries may
launch attacks against the LTE network. In [65], several attacks in LTE
networks are categorized: (a) security and confidentiality attacks, (b)
IP-based attacks, (c) signaling attacks, and (d) jamming attacks. Un-
fortunately, our proposal still suffer from these attacking threats as it
inherits not only the network architecture and components but also
the network vulnerabilities. For instance, the jamming attacks [66]
can interfere the radio communications via blasting a high powered
signal to saturate the control channels (i.e., PDCCH, R-PDCCH in
Fig. 14), pilot signals, or feedback channel state information. To rem-
edy such attack, there are several manners that can be applied. Firstly,
we can dynamically change the SuF update periodicity (i.e., PSuF ) to
avoid the illegal jamming device easily perceiving the exact transport-
ing SuF duration. We can also randomly allocate SFs within a SuF be-
tween access link and backhaul link to better protect the vulnerable
physical channels of these two links. Moreover, for entities hosting
the e2NB such as navy ships that have access to other RATs, we can
leverage such other RATs, for instance satellite communications, to
send part of the control channels related to inter-e2NB communica-
tions.
Nevertheless, more resilience performance analyses shall be taken
when dealing with other attacking threats in several threat spaces [67],
e.g., attack venue, plane of attack, and security services.
E X P E R I M E N TAT I O N S
7
In this chapter, we evaluate the proposed approach at different lev-
els. First, we evaluate if the Un interface that we suggest to use in
chapter 5 is performing sufficiently good compared to the legacy Uu
interface on both spectral efficiency, maximum throughput and com-
puting requirements to ensure its usefulness. Then, we evaluate the
cross-layer approach proposed in chapter 6 over several mesh topolo-
gies to understand its behavior and to evaluate its efficiency.

7.1 physical channel performance evaluation

Even with several aforementioned merits when adopting Un inter-

face for self-backhauling purpose in chapter 5, there is still no pre-
vious work endeavored to compare its performance with the legacy
Uu interface. In this sense, we evaluate if the Un interface is perform-
ing sufficiently good compared to the legacy Uu interface in terms
of spectral efficiency, maximum throughput and computing require-
ments to ensure its usefulness in this section.

We implement a subset of the R-PDCCH and R-PDSCH of the Un

interface in OAI [68], a software-based LTE/LTE Advanced (LTE-A)
system implementation spanning the full 3GPP protocol stack. We
then experiment this subset in DL direction between a DeNB and a
RN. The subset includes R-PDCCH encoding and decoding of DCI
for DL allocation in the first slot and UL allocation in the second slot
with resource allocation type 0 mapping over resource elements (see
section 7.1.6 in [51] for explanations on resource allocation types). It
also includes R-PDSCH encoding and decoding with resource allo-
cation type 0. Both support all DLSS and ESI configurations (see
section 5.1.3). However, one unimplemented feature defined in 3GPP
specification [45] is the possible R-PDSCH allocation at the second
slot when only the first slot of a SF is used to deliver R-PDCCH.

In our evaluation, extensive experiments have been carried out to

analyze the impact of different parameters on link-level performance
and computation time [69]. To guarantee the consistency of results,
all experiments were conducted in a single thread on a Intel Xeon
E5-2640v4 processor running at a fixed 2.4GHz core clock frequency
with both HyperThreading and Turbo being disabled.

75
76 experimentations

7.1.1 Computation time

We examine the computation time of both control channel (PD-

CCH/R-PDCCH) and data channel (PDSCH/R-PDSCH) of Uu and
Un interfaces in order to address the hardware constraint mentioned
in section 3.1. These experiments aim to reflect the extra expenditures
to deploy our proposed e2NB architecture with the extra Un interface
when comparing with legacy eNB.
Firstly, we compare the computation time required to perform DCI
encoding/decoding of PDCCH and R-PDCCH with different aggre-
gation levels (from 0 to 3) and different DCI positions under 10 MHz
radio bandwidth. On the Uu side, a DL DCI (DCI format 1) is gen-
erated and the full process from Cyclic Redundancy Check (CRC) at-
tachment to RE mapping of this DCI is done. We can see in Figure 23a
that the DCI positions affects only marginally the computation time
on aggregation level 0, 1 and 2 while it has an impact on aggregation
level 3. This is because when using aggregation level 3, generating
a DCI on the second position requires the use of a second symbol
for PDCCH allocation. On the Un side, two DCIs are generated with
one DL DCI format 1 mapped to the first slot of the advertised VRB
resource set and one UL DCI format 0 mapped to the second slot of
the VRB set. It can be observed from Figure 23a that the computation
time of R-PDCCH encoding procedure is almost doubled compared
to PDCCH of all aggregation levels. This is expected because we gen-
erate only one DCI in the PDCCH case while we generate two DCIs
in the R-PDCCH case. We can observe that in both cases, the com-
putation time increases as the aggregation level increases, although
R-PDCCH seems to be more affected. Furthermore, in Figure 23b,
the computation time for the DCI decoding is presented. Results for
PDCCH and R-PDCCH are quite different as the aggregation level
increases due to different decoding strategies. Indeed, for PDCCH,
all possible symbols corresponding to the PDCCH indicated by the
PCFICH are examined, which is the most time-consuming part of the
process, before applying the DCI decoding procedures that look for
a compatible CRC which are quite fast. This explains the decoding
processing time being twice as large in the case of aggregation level
3 and DCI in second position as the Control Format Indicator (CFI)
value is different, requiring to estimate more symbols. On the other
side, we can observe that the R-PDCCH decoding procedure is faster
for small aggregation levels but increases with higher aggregation
level especially for DL DCI decoding. There are two reasons for that.
Firstly, the DCI decoder at RN knows the VRB set, but the possible
positions of a potential DCI in this VRB set are multiples. In aggre-
gation level 0, there are at most six possible positions (if the VRB set
contains at least six VRBs) occupying a total of six VRBs of which
REs are initially evaluated. If nothing is found by the DCI decoder
 7.1 physical channel performance evaluation 77

50 200
PDCCH dci position 1
PDCCH dci position 2
DL dci

Processing time (us)

R−PDCCH dci position 1

Processing time (us)

40 R−PDCCH dci position 2
150 R−PDCCH dci position 3
R−PDCCH dci position 4

30
100
20
DL dci

50
10
UL dci
UL dci

0 0
0 1 2 3 0 1 2 3
Aggregation level Aggregation level

(a) DCI encoding and mapping (b) DCI search and decoding

Figure 23 – R-PDCCH and PDCCH computational time.

Tx PDCCH + DLSCH
2000 Rx PDCCH + DLSCH
Tx R−PDCCH + R−PDSCH
Rx R−PDCCH + R−PDSCH

1500
Processing time (us)

1000 20MHz

500
5MHz

0
0 4 910 13 1617 22 2728
MCS
Figure 24 – TX/RX time for PDCCH/PDSCH and R-PDCCH/R-PDSCH.

(i.e., no matching CRC), then it moves to the next aggregation level, 1

in this case, which has six possible positions of DCIs spanning over
two VRBs, covering twelve VRBs. This requires the estimation of new
REs before looking for DCI at a higher aggregation level. Then, the
DL DCI decoding part will search for several DCI formats at each
aggregation level while the UL DCI decoding will only look for DCI
format 0 which explains the difference between DL and UL DCI de-
coding processing time.
Then, we vary the MCS value and compare the total processing
time of the transmission procedure or reception procedure when us-
ing either PDCCH/PDSCH or R-PDCCH/R-PDSCH. Such compar-
isons are taken under both 5MHz and 20MHz radio bandwidth. A
static resource allocation is used, which includes 25 (5MHz channel)
and 100 PRBs (20MHz) for the Uu channel, and 24 PRBs (5MHz chan-
nel) and 96 PRBs (20MHz) for the relay channel with a R-PDCCH
VRB set containing only one (5MHz) or four (20MHz) PRBs. It can
78 experimentations

be seen from Figure 24 that TX procedures take slightly longer, in the

order of 25 us, for all MCS when using the Un interface over the Uu in-
terface. This is mainly due to extra DCI encoding time for R-PDCCH
(one for DL and one for UL) compared to PDCCH (only 1 DL DCI)
as shown in Figure 23a. For RX procedures, the Un interface shows
a shorter computation time as the increasing of bandwidth and MCS
when compared with the Uu interface due to a lower DCI decoding
time for R-PDCCH and to the lower number of PRBs allocated. Last
but not least, the results reveal that the HARQ deadlines of the Un
interface can be met in all cases (including 100 PRBs and MCS 28) as
the sum of TX and RX processing remains below 3ms [70].
To conclude this section, we see that at equivalent bandwidth us-
age, the required processing capability for the Un interface is equiv-
alent to the one for the Uu interface. It means that mixing Uu and
Un interfaces at e2NB will not require extra processing capabilities
than enabling only the Uu interface. Such characteristic enables the
feasibility of implementing the e2NB architecture in a fully software
architecture (i.e. OAI) executed on commodity hardware rather than
requiring a specialized hardware infrastructure and additional expen-
ditures.
4
x 10
8
PDSCH 25PRBs 5MHz
R−PDSCH 24PRBs DLSS1 ESI5 5MHz
7 R−PDSCH 24PRBs DLSS3 ESI5 5MHz
PDSCH 50PRBs 10MHz
R−PDSCH 48PRBs DLSS1 ESI5 10MHz
6 R−PDSCH 48PRBs DLSS3 ESI5 10MHz
PDSCH 100PRBs 20MHz
R−PDSCH 96PRBs DLSS1 ESI5 20MHz
5 R−PDSCH 96PRBs DLSS3 ESI5 20MHz
TBS (bits)

0
0 5 10 15 20 25
SNR (dB)
Figure 25 – Minimum SNR level to decode 75% of the TBs.

7.1.2 Link-level performance

As a link-level performance metric, we examine the minimum Sig-

nal to Noise Ratio (SNR) level to successfully decode 75% of Trans-
port Blocks (TBs) for both PDSCH/R-PDSCH in Figure 25 using ag-
 7.1 physical channel performance evaluation 79

gregation level 0. This metric can reflect the reliability and justify the
utilized effectiveness of the interface. 75% is chosen as a tighter value
than usual reference test values for 3GPP systems that uses 70% (see
Table 8.2.1.1.1-2 [71]). Such experiment is taken under different radio
bandwidth (5, 10, 20 MHz), different values of DLSS and ESI that
modify the number of symbols used by the Un interface as explained
in section 5.1.3, and varying MCS values (0,4,9,10,16,17,22,27,28).
Either 12 symbols (DLSS = 1, ESI = 5) or 10 symbols (DLSS = 3,
ESI = 5) are available for R-PDSCH. The 10-symbol configuration
can not actually be successfully decoded when only receiving the first
transmission as stated in section 5.1.3 when the code rate is larger
than 1 (i.e., MCS 28). Since there are fewer symbols for R-PDSCH
transportation, a higher code rate is experienced and a slightly higher
SNR level is required to reach 75% of successful decoding. We can see
that the difference between the required SNR over Uu and Un inter-
face increases as the MCS increases, reaching around 1.5dB between
PDSCH and R-PDSCH with 12 symbols when using MCS 28, and
almost 5dB between PDSCH and R-PDSCH with 10 symbols when
using MCS 27. This is due to the required SNR increasing non lin-
early with the increase of code rate. Moreover, we can see that due
to our current implementation that does not allow for the second slot
of a PRB to be used for a R-PDSCH if its first slot is used for R-
PDCCH, the achieved TBS at equivalent bandwidth usage (including
R-PDCCH) is smaller using the Un interface. Finally, we can observe
that for higher TBS values (resulting from high MCS), no result are
available for the R-PDSCH configuration relying on 10 symbols for
the transportation. This is due to the code rate being higher than
1 in these configuration, as explained in section 5.2.2, preventing to
transmit and decode.
To sum up, the spectral efficiency of the R-PDCCH/R-PDSCH is
slightly lower than the one of PDSCH due to the fewer number of
available symbols. R-PDSCH also reaches slightly lower maximum
data rate (especially for large MCS that leads to large TBS) due to the
lower number of assignable PRBs, however this is due to the current
implementation limitations. Moreover, we can see that using fewer
than 11 symbols for R-PDSCH leads to impossible MCS values, low-
ering the maximum achievable throughput. This calls for the use of
dedicated TBS tables to optimize these cases or to restrict the usable
ranges in the common TBS table.
We also examine the results under different aggregation levels in
Figure 26 under 10MHz radio bandwidth when modifying the used
MCS value. It can be observed that the required SNR level to achieve
75% successful transportation is similar in both R-PDCCH/R-PDSCH
and PDCCH/PDSCH cases with a small difference on the achieved
TBS when using a smaller MCS. However, the gap between the achiev-
able TBS of R-PDCCH/R-PDSCH and PDCCH/PDSCH increases when
80 experimentations

4
x 10
4
PDSCH 50PRBs Aggreg 0
PDSCH 50PRBs Aggreg 1
3.5 PDSCH 50PRBs Aggreg 2
PDSCH 50PRBs Aggreg 3
R−PDSCH 48PRBs Aggreg0
3 R−PDSCH 48PRBs Aggreg1
R−PDSCH 44PRBs Aggreg2
R−PDSCH 41PRBs Aggreg3
2.5

TBS (bits) 2

1.5

0.5

0
−5 0 5 10 15 20
SNR (dB)
Figure 26 – Minimum SNR level for several aggregation levels.

using larger MCS and higher aggregation level due to the limitations
of our implementation (no use of the second slots of PRBs used for R-
PDCCH to carry R-PDSCH). However, the complete implementation
would see the SNR difference between R-PDSCH and R-PDCCH to
increase as it would slightly increase the code rate. Moreover, we can
see as expected that starting from 5dB of SNR, aggregation level 0 is
sufficient and higher aggregation levels are not useful. In such a case,
the differences between R-PDCCH/R-PDSCH and PDCCH/PDSCH
efficiency is comparatively small.

To sum up, our examinations prove that the performance of the Un

interface is close to the legacy Uu one, supporting the idea of using
it as an efficient and reliable backhaul interface for the mesh network
as claimed in section 5.1. Furthermore, a software implementation of
Un interface is feasible that makes our proposed e2NB architecture
attractive for the emerging 4G/5G use cases as stated in Table 2.

7.2 evaluation of the proposed approach

Based on the aforementioned link-level performance examination

on Un interface, we further evaluate the system-level performance
of the envisioned network in this section. Hence, we compare sev-
eral resource scheduling approaches on different network topologies
experiencing various traffic flows.
 7.2 evaluation of the proposed approach 81

7.2.1 Simulation environment

A complete LTE simulator is developed in MATLAB allowing to

create a 2D-map representing a desired network topology of e2NBs
with their associated UEs and to generate arbitrary flows between
nodes (e.g., UE to UE, UE to e2NB, e2NB to e2NB traffic). To model
the processing time for each incoming packet at e2NB, we assume
that it takes 5ms to finish all processing before pushing it to queue
(DL or UL) for relaying to next hop. Such assumption is realistic
considering the less than 3ms is required for the physical layer as
shown in section 7.1.

Simulation parameters

Our simulation parameters applied to UEs and eNBs are mostly

taken from 3GPP documents ([72–74]) with each e2NB operating in
TM 1 (Single Input Single Output (SISO)) using a single omnidirec-
tional antenna. To characterize the in-band characteristic, we use the
same carrier frequency (2.1GHz, band 4) through the network with ei-
ther a 5MHz FDD, 10MHz FDD or 10MHz TDD channel bandwidth.
In TDD, UL SFs are not used for the Un interface but only MBSFN
DL SFs are as described in section 6.5. Furthermore, to evaluate the
interference impact, we do not assume any applied interference can-
cellation scheme and use the omni-directional antenna at both e2NB
and UE. Between e2NBs, a freespace path loss model of coefficient
2.1 is applied with Claussen shadow fading and Extended Pedestrian
model A (EPA) channel type. This relates to the maritime channel in
naval communications while a suburban or rural channel in PS com-
munications would reduce the maximum distance between e2NBs.
Between e2NBs and UEs, a rural (from [74]) path loss model is used
with Claussen shadow fading and EPA channel type. The above chan-
nel model is selected to limit the interference effects between UEs
served by adjacent e2NBs as no interference mitigation or coordina-
tion method is assumed for the access links (i.e., eICIC) are consid-
ered in the simulator as we are mainly interested in characterizing the
behavior of the proposed schemes for the backhaul links. Moreover,
in urban scenarios, inter-BTS channels are usually of better quality
than BTS-UE channels due to the position of antennas and the higher
Line of Sight (LOS) air propagation probability. Moreover, the HARQ
mechanism is not completely implemented in the simulator but work
as an Automatic Repeat reQuest (ARQ) mechanism: ACK/NACK
are handled but there is no benefit taken from the previously failed
transmission. UEs are only scheduled for UL/DL transmission over
non-MBSFN SFs. In Algorithm 4, e2NB w is considered an interferer
of link (u, v ) if the expected SINR over DL link (u, v ) when e2NB w
is concurrently activated is expected to reduce the expected MCS by
more than 7 (for instance, if reported SINR over link (u, v ) is expected
82 experimentations

(a) Hexagonal topology with 7 e2NBs and 70 UEs.

(b) Line topology with 7 e2NBs and 70 UEs.

(c) Hexagonal topology with 19 e2NBs and 190 UEs.

Figure 27 – Considered network topologies.

to allow for MCS 22 without any interferer, w is considered an inter-

ferer and is blocked if the expected SINR at v becomes too small to
allow for M CS > 15 over link (u, v ) when w is transmitting). More-
over, the of f set parameter for LSuF computation is set to 1 and PSuF
is set to 400ms. Finally, the simulations are performed for a duration
of 10000 SFs.

Network topologies
Here, we consider three different representative network topologies
as shown in Figure 27(a), 27(b) and 27(c). These topologies echo back
to what was presented in Table 3 with less than ten BTSs for naval
and PS scenarios and more than ten BTSs for the PS scenario. In
each topology, all e2NBs have 10 attached UEs and are connected to
adjacent e2NBs as indicated by the bi-directional arrows as shown in
Figure 27.

Traffic patterns
Depending on the scenarios, both real-time and elastic traffic flows
are continuously generated during the simulations. These traffic pat-
terns simulates to what is presented in Table 3. For real-time traf-
fic flows, we randomly pair all UEs to establish bi-directional VoIP
 7.2 evaluation of the proposed approach 83

calls. Each call generates 20 bytes payload packets with a 20ms ar-
rival rate in fixed distribution. Each packet represents a 40 bytes
final transport size on the physical layer that includes all the protocol
headers from User Datagram Protocol (UDP) to MAC layer relying
on Robust Header Compression (ROHC). For QoS requirement of
the real-time traffic, we use the maximum one-way-delay of 150ms
for 95-percentile of the packet to ensure a quality call with a Mean
Opinion Score (MOS) of 3.5 using a G.729 codec [75]. Whereas the
elastic traffic is set between BTSs to represent the inter-site data trans-
fers that often happen in military and public safety scenarios. Each
elastic traffic is served in the best effort manner to maximize its data
rate. It behaves as a buffer saturating flow, continuously generating
packets at the initial node such that the buffer is never empty.

7.2.2 Considered Algorithms

In our previous work [76], we compared a first version of the hi-

erarchical approach to a legacy link scheduling algorithm for mesh
networks that optimizes the network throughput and frequency reuse
but uses only PTP transmissions in each SF that is not as the preferred
multi-PTP transmission used in LTE thanks to OFDMA characteristic.
The results showed that our approach is superior to the legacy one.
Hence, in this section, we compare three realistically implementable
variant algorithms of our proposed approach:
1. A baseline algorithm which is unaware of the required SF of both
D [u] = 1 and SF D [u] = k > 1,
real-time and elastic traffics, i.e. SFrt e
U
SFe [u] = k > 1, ∀u ∈ Ve2N B . It only aims to allocate the same
number of backhaul SFs to each e2NB, and is denoted as Basic (or
B.).
2. A simplified algorithm which does not leverage the FDD characteris-
tic when computing the required SFs for real-time traffic in Algo-
rithm 2, denoted as DL Alg. (or DL.).
3. The full algorithm proposed in this work that exploits the UL di-
rection of FDD mode, denoted as UL Alg. (or UL.).
However, no dynamic flow control is implemented in our evaluation.
Thus, when dissatisfaction happens (i.e. rtDisSat == 1 in Algo-
rithm 1), we increase the SuF duration (i.e. LSuF ) by 10 SFs rather
than rejecting or removing any real-time flow.
Based on these three considered algorithms and the applied traffic
patterns, we can summarize all compared scenarios as listed in Ta-
ble 7. We can firstly see that each algorithm can be applied to tackle
three different types of traffic pattern. The B., DL. and UL. represents
the baseline, simplified and full algorithms when applied to the case
with only elastic traffic flows in the network topology, i.e., no UE pair-
ing for real-time flows. Here, as there is no elastic flows, we forcedly
84 experimentations

set their SuF duration (i.e., LSuF ) to be 150ms and rP RB D [u] to be

1 in order to be applicable in Algorithm 1 and 2. In contrast, B. V,
DL. V and UL. V denote the case where we apply these three algo-
rithms with both elastic and real-time traffic flows. Note that the UEs
can be randomly paired with any others to transport real-time VoIP
flows without any restrictions. Lastly, we consider the case that only
allows UEs to be paired within a maximum number of hops over the
mesh, i.e., Nhop . Take B. 1V as an example, it means that the baseline
algorithm is applied and UEs can only be paired when the number
of hops over the mesh is not larger than 1. Hence, VoIP flows can
only be established between UEs that are served by the same e2NB
(no hop on the mesh as UE2 and UE9 in Figure 12) or by two adjacent
e2NBs (1 hop on the mesh as UE2 and UE3 in Figure 12).

Table 7 – Compared algorithms with corresponding notations

Algorithm Traffic Possible UE pairing Notation

Only elastic - B.
Baseline Real-time Pair users with Nhop ≤ 1/2/3 B. 1V, B. 2V, B. 3V
and elastic No restriction on pairing B. V
Only elastic - DL.
Simplified Real-time Pair users with Nhop ≤ 1/2/3 DL. 1V, DL. 2V, DL. 3V
and elastic No restriction on pairing DL. V
Only elastic - UL.
Full Real-time Pair users with Nhop ≤ 1/2/3 UL. 1V, UL. 2V, UL. 3V
and elastic No restriction on pairing UL. V

7.2.3 Simulation Results

Based on the aforementioned three network topologies in Figure 27,

we compare the following two performance metrics belonging to dif-
ferent types of traffic.
— Satisfaction ratio in terms of the 95-percentile point of per-flow
latency for real-time traffic
— Cumulated throughput of all elastic flows for elastic traffic

Hexagonal topology with 7 e2NBs

Besides the randomly-paired VoIP traffic (35 bi-directional VoIP
calls between the 70 UEs), three different flow scenarios are evalu-
ated for elastic traffic: (i) from e2N B4 to e2N B6 (4 → 6), (ii) from
e2N B1 to e2N B2 (1 → 2) and (iii) both aforementioned two elastic
flows (4 → 6 & 1 → 2). Note that randomness of UE positions and
randomness UE pairing for VoIP flows depends on a seed that is fixed
when changing of evaluated algorithm, ensuring that the VoIP flow
 7.2 evaluation of the proposed approach 85

distribution (source and destination, number of hops) stays the same

when changing the scheduling algorithm.

fdd mode Performance is firstly evaluated using a 10MHz radio

bandwidth in FDD mode (i.e., totally it requires 20MHz bandwidth
separated in one 10MHz for DL and another 10MHz for UL). In Fig-
ure 28(a), we observe that the ones without real-time traffic flows
can have a larger throughput than the ones with real-time traffic, i.e.,
throughputs of B., DL. and UL. are higher than the ones of B. V, DL. V,
and UL. V, respectively. An identical result is displayed for DL. and
UL. as their only difference is in the handling of SFrt D ; hence, they

are identical when there is no real-time flows. Further, we can see

that both full algorithm and simplified algorithm are able to provide
a higher throughput than the basic algorithm in all three scenarios,
with VoIP traffic being enabled or not. And a similar performance is
seen between the full algorithm and simplified algorithm with VoIP
traffic enabled. This is because in this topology, the full algorithm is
not able to optimize SFrt D better than the simplified algorithm due to

the combination of a low number of maximum hops and a high mesh

degree.
Moreover, the throughput of flow 4 → 6 and flow 1 → 2 in their
respective scenario are different as the first one goes over two hops
on the mesh while the second one has only one hop. In the first place,
we could have expected the throughput of the elastic flow from 4 → 6
18000
16000 Elastic flow 1 2 Elastic flow 4 6
Data rate (kbps)

14000
12000
10000
8000
6000
4000
2000
0
B.

B.

B.
V

V
V

L.

L.

L.
/U

/U

/U
L.

L.

L.

L.

L.

L.
B.

B.

B.
D

U
L.

L.

L.
D

(i) Elastic flow: 1 2 (ii) Elastic flow: 4 6 (iii) Elastic flows: 1 2&4 6
(a) Throughput of elastic flows over three elastic traffic scenarios.
1
0.9 B. V
0.8 DL. V
0.7 UL. V
0.6
CDF

0.5
0.4
0.3
0.2
0.1
0
10 20 30 40 50 60 70 80 90 100 110
Latency (ms)
(b) CDF plot of the 95-th percentile of packet latency among real-time flows
with two elastic flows: 1 → 2 and 4 → 6.
Figure 28 – Hexagonal topology with 7 e2NBs and 70 UEs using 10MHz in
FDD mode.
86 experimentations

would be half of the one of 1 → 2 since it requires at least twice the

radio resources to provide the same end-to-end throughput; however,
it is only around 20% lower rather than the expected 50%. This is
because we exploit the UL/DL specificity of FDD mode. In detail,
such FDD characteristic is in that the radio of each e2NB will transmit
on half of its resources and receive on another half even with the
dynamics to modify the number of DL MBSFN SFs to be used for
either TX or RX at each e2NB. Indeed, when a DL MBSFN SF is used
to receive from another e2NB, the corresponding UL SF (4ms later)
is reserved for transmission to that e2NB in case of receiving an UL
allocation. In this sense, a similar throughput can be foreseen for a
directed flow between two hops or one hop. Specifically, when we
consider the flow 4 → 6 that goes through e2N B1 (or either e2N B5 ),
e2N B1 can do the transmission over DL direction to e2N B6 at SF n
and can also transmit to e2N B4 over the UL direction at SF (n + 4).
Thus, the COE controller will utilize such characteristic to allocate DL
SFs toward one e2NB and exploit the corresponding UL SFs toward
another e2NB in order not to use double resources to route the two-
hop elastic flow and can achieve a close throughput as the one-hop
one. To sum up, e2N B1 will be allocated with roughly the same
amount of resources for either one-hop (1 → 2) or two-hop (4 →
6) to serve these two best effort traffic equally and thus a similar
performance on the end-to-end is observed.

Then, Figure 28.(b) shows the Cumulative Distribution Function

(CDF) of the 95-percentile point of per-flow latency over real-time
traffic flow under the scenario with two elastic flows (4 → 6 & 1 → 2).
For better readability, Figure 41 showing the CDF of the 95-percentile
point of per-flow latency over real-time traffic flow under the two
other elastic traffic scenarios is not included here but can be found in
Appendix A. The bottom left portions of Figure 28.(b) correspond to
some VoIP flows between UEs that are under the coverage of a same
e2NB; hence, they experience very low latency and can be properly
allocated by either algorithm as they depend only on the local sched-
uler. It can be observed that all real-time VoIP flows can satisfy the
150ms requirement for 95% of their packets (i.e., satisfaction ratio is
100% for all three algorithms). Nevertheless, we can see that the base-
line algorithm performs better than the others since the maximum
95-percentile delay is around 50ms while it is up to 80ms and even
110ms for some flows when using simplified and full algorithm. This
is because of the trade-off between boosting the throughput of elastic
traffic shown in Figure 28.(a) which is achieved by allocating more
SFs to e2NBs that delivers elastic traffic while reducing the period-
icity of transmissions of other e2NBs, thus the average latency and
95-percentile point is increased.
 7.2 evaluation of the proposed approach 87

tdd mode We then evaluate the behavior of the different algo-

rithms over a 10MHz TDD mode using the TDD UL/DL configura-
tion 4 (i.e., 10 SFs in a frame are categorized into 7 DL SFs (with 4
MBSFN SFs), 2 UL SFs, 1 special SF). Using the full algorithm in the
TDD mode does not make any difference to the simplified algorithm
as we are not relying on the UL SFs for the backhaul links in the cur-
rent TDD approach, even though such TDD configuration 4 allows
for one UL SF to be used for Un interface [45].
We can observe in Figure 29.(a) that both full and simplified algo-
rithms can largely outperforms the baseline one no matter the use
of VoIP traffic or not. In contrast to the FDD mode, the throughput
of elastic flows of TDD mode is now reduced by 50% for the two-
hop flow compared to the one-hop flow. This is due to the fact that
there are limited SFs to be allocated for backhaul links as only MB-
SFN DL SFs for TDD mode are utilized for meshing in the considered
approach.
Then, Figure 29.(b) shows the CDF of the 95-percentile point of per-
flow latency over real-time traffic flow under the scenario with two
elastic flows (4 → 6 & 1 → 2). Like the results shown in Figure 28.(b),
both approaches can satisfy the VoIP latency requirements. But the
baseline algorithm provides a lower latency than the other twos as
more SFs are provisioned evenly between e2NBs for VoIP flows as the
trade-off of much worse throughput in Figure 29.(a). Similar results

14000
Elastic flow 1 2 Elastic flow 4 6
Data rate (kbps)

12000
10000
8000
6000
4000
2000
0
B.

B.

B.
L.

L.

L.
V

V
V

V
/U

/U

/U
B.

B.

B.
L.

L.

L.
U

/U

/U
L.

L.

L.
V/

D
V

V
L.

L.

L.
D

(i) Elastic flow: 1 2 (ii) Elastic flow: 4 6 (iii) Elastic flows: 1 2&4 6
(a) Throughput of elastic flows over three elastic traffic scenarios.
1
0.9 B. V
0.8 DL. V/UL. V
0.7
0.6
CDF

0.5
0.4
0.3
0.2
0.1
0
10 20 30 40 50 60 70 80 90
Latency (ms)
(b) CDF plot of the 95-th percentile of packet latency among real-time flows
with two elastic flows: 1 → 2 and 4 → 6.
Figure 29 – Hexagonal topology with 7 e2NBs and 70 UEs using 10MHz in
TDD mode.
88 experimentations

can be observed on Figure 42 in Appendix A for the two other traffic

scenarios.

comparison between fdd mode and tdd mode To have a

fair comparison between these two modes, we now compare the case
of 10MHz TDD mode with a 5MHz FDD mode as they both require
a total 10MHz radio bandwidth. Based on the available MBSFN SFs
within a frame, FDD mode can allocate up to 60% of SFs for the
backhaul links, while TDD of configuration 4 can only allocate up to
40% of SFs. However, FDD has more design constraints. For a one-
hop flow, a maximum of 30% of SFs can be allocated in FDD mode in
one direction as there is always a one-to-one mapping between DL SF
in one direction and UL SF in another direction. To this end, when
the traffic flows over the network topology are highly asymmetric,
i.e., only one direction is the bottleneck, such FDD characteristic will
limit the performance as we can observe in Figure 30.(a) where the
full algorithm in TDD mode provides a higher throughput for the one-
hop flow (1 → 2) than the FDD mode. However, with a balancing over
available SFs in both DL and UL directions for relaying, a comparable
performance is shown between FDD mode and TDD mode in terms
of the two-hop elastic flow scenario and a slightly better performance
of FDD mode is depicted in the scenario with two concurrent elastic
flows.

9000
Data rate (kbps)

7500 Elastic flow 1 2 Elastic flow 4 6

6000
4500
3000
1500
0
)

)
D

D
D

D
(T

(F

(T

(F

(T

(F
V

V
L.

L.

L.

L.

L.

L.
U

(i) Elastic flow: 1 2 (ii) Elastic flow: 4 6 (iii) Elastic flows: 1 2&4 6
(a) Throughput of elastic flows over three elastic traffic scenarios.
1
0.9 UL. V (FDD)
0.8 UL. V (TDD)
0.7
0.6
CDF

0.5
0.4
0.3
0.2
0.1
0
10 20 30 40 50 60 70 80 90
Latency (ms)
(b) CDF plot of the 95-th percentile of packet latency among real-time flows
with two elastic flows: 1 → 2 and 4 → 6.
Figure 30 – Hexagonal topology with 7 e2NBs and 70 UEs using 10MHz in
TDD mode or 5MHz in FDD mode.
 7.2 evaluation of the proposed approach 89

Moreover, in Figure 30.(b), we can see that a lower average VoIP

traffic latency happens for FDD mode than TDD mode as there is
a higher number of MBSFN SFs within a frame (i.e., 60% of SFs are
MBSFN SFs in FDD mode as stated beforehand) and a perfect balance
between DL and UL SFs to support bi-directional VoIP calls. Plots
of latency for the two other elastic traffic scenarios can be found in
Figure 43 in Appendix A and show similar results.

Line topology with 7 e2NBs

Like the hexagonal topology, 35 bi-directional VoIP calls are set-up

between the 70 UEs and we explore three flow scenarios for elastic
traffics: (i) from e2N B2 to e2N B6 (2 → 6), (ii) from e2N B7 to e2N B5
(7 → 5) and (iii) both aforementioned two elastic flows (2 → 6 &
7 → 5).

fdd mode Performance over this topology is firstly evaluated in

FDD mode with a 5MHz radio bandwidth in both directions (i.e., a
total 10MHz radio bandwidth is partitioned into 2 different 5MHz for
DL and UL direction separately).
In Figure 31.(a), we can easily observe that both simplified and full
algorithm provide a higher cumulated throughput of elastic flows
than the baseline algorithm over all three scenarios of elastic traffic
flows. Moreover, the full algorithm outperforms the simplified ver-
8000
7000 Elastic flow 2 6 Elastic flow 7 5
Data rate (kbps)

6000
5000
4000
3000
2000
1000
0
B. V DL. V UL. V B. V DL. V UL. V B. V DL. V UL. V
(i) Elastic flow: 26 (ii) Elastic flow: 7 5 (iii) Elastic flows: 2 6&7 5
(a) Throughput of elastic flows over three elastic traffic scenarios.
1
0.9 B. V
0.8 DL. V
0.7 UL. V
0.6
CDF

0.5
0.4
0.3
0.2
0.1
0
10 20 30 40 50 60 70 80 90 100 110
Latency (ms)
(b) CDF plot of the 95-th percentile of packet latency of real-time flows
with two elastic flows: 2 → 6 and 7 → 5.
Figure 31 – Line topology with 7 e2NBs and 70 UEs using 5MHz in FDD
mode.
90 experimentations

sion since it exploits the full FDD capability and is able to save some
SFs for elastic traffic. However, the difference between the full algo-
rithm and baseline algorithm is smaller than the one shown in the
hexagonal topology of Figure 28. A potential reason is due to fewer
SFs can be shared by e2NBs to deliver elastic flows due to the topol-
ogy. Firstly, as the maximum number of hops over the network as in-
creased from 2 to 6, the SuF duration (i.e., LSuF ) will be reduced by a
factor around 3. However, each e2NB still needs at least one allocated
SF (or an UL opportunity to an adjacent node) within this SuF dura-
tion to deliver real-time traffic and ensure latency requirement. After
allocating SFs for real-time flows within this shorter SuF duration, a
fewer number of unallocated SFs can be shared to deliver elastic traf-
fics and thus the throughput difference between several algorithms
is reduced. Lastly, we can observe that the difference between the
throughput of one-hop flow scenario (7 → 5) and the throughput
of two-hop flow scenario (2 → 6) is similar to the phenomenon we
already explained in the hexagonal topology.
In Figure 31.(b), we show the performance metric of real-time flows
under the two elastic flow scenarios (i.e., 2 → 6 & 7 → 5) in terms
of the CDF plot of 95-percentile packet delay among all real-time
flows. All real-time flows are satisfied as the maximum 95-percentile
delay is about 110ms that is smaller than the requested 150ms, i.e.,
the satisfaction ratio is 100%. Moreover, we can observe that baseline
algorithm provides a slightly lower latency than the others as the
trade-off we already explained in the previous hexagonal topology.
The latency difference is smaller between the baseline algorithm and
the others than the one in the 7 e2NBs hexagonal topology. Such
phenomenon is due to the less flexibility on MBSFN SF allocation of
this topology as explained in the previous paragraph. Similar results
can be observed on Figure 44 in Appendix A for the two other traffic
scenarios.

tdd mode Afterward, we evaluate the TDD mode with a 10MHz

radio bandwidth. Besides the previous examined cases that allow to
randomly pair all users to transport real-time VoIP flows, we further
examine the case that only pairs users within a maximum number of
e2NB hops, i.e., B. 1V, DL. 1V, UL. 1V for 1 e2NB hop in maximum.
Such case is examined to disclose the impact on the performance
of our proposed approach under different traffic patterns. If we pair
UEs with more hops on the mesh in between, the SuF duration (LSuF )
will become smaller to ensure the end-to-end latency of such flows
(see Mhops and Algorithm 1 introduced in section 6.3). Hence, the
throughput of elastic flow will be impacted negatively as much fewer
SFs are available to be used in a shorter LSuF (as explained in pre-
vious FDD paragraph). To quantitatively evaluate such impact, we
restrain the maximum number of hops between UEs during the pair-
 7.2 evaluation of the proposed approach 91

ing process such that the UEs within a pair are either served by the
same e2NB or by one-hop adjacent e2NBs as B. 1V, DL. 1V, UL. 1V
shown in Figure 32.(a). This constraint matches the use cases where
users are mainly communicating with other users in the same area or
vicinity.
We can observe in Figure 32.(a) that both full and simplified algo-
rithms provide a higher throughput of elastic flows than the base-
line algorithm over all considered scenarios: with non-restricted VoIP
flows, with one hop restricted VoIP flows, and without VoIP flow.
Moreover, we can observe that the throughput is higher when VoIP
flows are restricted to a maximum of one hop over the mesh: double
throughput when with a single elastic flow (either 7 → 5 or 2 → 6)
and 30% gain when with two elastic flows (close to the one without
12000
Data rate (kbps)

10000 Elastic flow 2 6 Elastic flow 7 5

8000
6000
4000
2000
0
V

V
1V

1V

1V
L.

L.

L.
/U .V
D 1V

/U .V
D 1V

/U .V
D 1V
D L. V B.

D L. V B.

D L. V B.
/U

/U

/U
B.

B.

B.
1V /UL

1V /UL

1V /UL
B.

B.

B.
L.

L.

L.
L.

L.

L.
D

D
L.

L.

L.
(i) Elastic flow: 2 6 (ii) Elastic flow: 7 5 (iii) Elastic flows: 2 6&7 5
(a) Throughput of elastic flows over three elastic traffic scenarios.
1
0.9 B. V
0.8 DL. V/UL. V
0.7
0.6
CDF

0.5
0.4
0.3
0.2
0.1
0
0 20 40 60 80 100 120
Latency (ms)
(b) CDF plot of the 95-th percentile of packet latency among real-time flows
with two elastic flows: 2 → 6 and 7 → 5.
1
0.9 B. 1V
0.8 DL. 1V/UL. 1V
0.7
0.6
CDF

0.5
0.4
0.3
0.2
0.1
0
10 20 30 40 50 60 70 80 90 100
Latency (ms)
(c) CDF plot of the 95-th percentile of packet latency among real-time flows
under maximum 1-hop mesh with two elastic flows: 2 → 6 and 7 → 5.

Figure 32 – Line topology with 7 e2NBs and 70 UEs using 10MHz in TDD
mode.
92 experimentations

any VoIP flows, i.e., DL./UL.) Such results confirm our intuition. We
can also observe that, as in the TDD modes of the 7 e2NBs hexagonal
topology, the throughput of the one-hop elastic flow (7 → 5) is almost
two times as the throughput of two-hop elastic flow (2 → 6).
In Figure 32.(b), without any restrictions on the maximum num-
ber of hops among inter-UE VoIP flows, the baseline algorithm only
achieves a slightly better latency than the others. We can observe in
Figure 32.(c), where VoIP flows are restricted to a maximum of one
hop over the mesh, that the baseline algorithm performs much better
that the others as it can distribute the MBSFN SFs evenly between
e2NBs and thus reduce the waiting time in queues as well as the la-
tency. Last but not least, all algorithms can provide 100% satisfaction
for all VoIP flows among each case, but both simplified and full al-
gorithms can achieve a higher throughput of elastic flows. Similar
findings can be drawn from observation of Figure 45 in Appendix A
for the other traffic scenarios.

comparison between fdd mode and tdd mode Here, we

regroup our results previously shown in Figure 31 and Figure 32 to
compare the behavior of FDD (5MHz for both directions) and TDD
mode (10MHz) occupying the same aggregated bandwidth on the
line topology. However, the comparison here is in favor of FDD mode
as the performance limiting factor of such topology is on the fewer
SFs of a shorter SuF duration, while the FDD mode can naturally
8000
Data rate (kbps)

7000 Elastic flow 2 6 Elastic flow 7 5

6000
5000
4000
3000
2000
1000
0
)

)
D

D
D

D
(T

(F

(T

(F

(T

(F
V

V
L.

L.

L.

L.

L.

L.
U

(i) Elastic flow: 2 6 (ii) Elastic flow: 7 5 (iii) Elastic flows: 2 6&7 5
(a) Throughput of elastic flows over three elastic traffic scenarios.
1
0.9 UL. V (FDD)
0.8 UL. V (TDD)
0.7
0.6
CDF

0.5
0.4
0.3
0.2
0.1
0
0 20 40 60 80 100 120
Latency (ms)
(b) CDF plot of the 95-th percentile of packet latency among real-time flows
with two elastic flows: 2 → 6 and 7 → 5.
Figure 33 – Line topology with 7 e2NBs and 70 UEs using 10MHz in TDD
mode or 5MHz in FDD mode.
 7.2 evaluation of the proposed approach 93

provide more MBSFN SFs in a frame for backhaul links (i.e., 60%
in FDD than 40% in TDD mode). We can observe in Figure 33.(a)
that with non-restricted VoIP flows, the FDD mode always provides
a higher data rate than the TDD mode. In the mean time, we can
observe in Figure 33.(b) that FDD mode is slightly outperforming the
TDD mode in terms of the latency, although both modes can achieve
100% of satisfaction. This phenomenon is also due to a higher number
of MBSFN SFs in the FDD mode. The observation of Figure 46 in
Appendix A leads to similar findings for the other traffic scenarios.

Hexagonal topology with 19 e2NBs

We further explore a more complicate hexagonal topology with

19 e2NBs and consider the scenario with 3 concurrent elastic flows
and 95 random-paired VoIP flows: one flow from e2N B12 to e2N B11
(12 → 11 with two hops), one flow from e2N B15 to e2N B13 (15 → 13
with three hops), and one from e2N B2 to e2N B16 (2 → 16, with three
hops).

fdd mode Firstly, we check the performance with 5MHz radio

bandwidth of FDD mode. It can be observed in Figure 34.(a) that
the simplified algorithm outperforms the other two algorithms in the
cumulated throughput from all three elastic traffics when there is no
limitation on UEs pairing for VoIP flows, i.e., DL. V. However, we
can immediately observe in Figure 34.(b) that neither approach can
provide a 100% satisfaction to VoIP flows. Specifically, around 92%
of VoIP flows are satisfied when using baseline and simplified algo-
rithm; however, the full algorithm can achieve 98% of satisfaction.
The baseline algorithm cannot meet the requirements because it is
evenly allocating the SFs between the e2NBs within the SuF duration
(around 30ms in this case) but some links cannot be satisfied with
such evenly allocated SFs. As for the simplified algorithm, it is un-
able to satisfy the computed MBSFN SFs requirements in the required
SuF duration (30ms in this case for the highest number of hops (4)).
This leads to an increase of the SuF duration (i.e., as introduced in sec-
tion 7.2.2) to satisfy the VoIP throughput requirements of every link.
But the COE will be incapable of satisfying VoIP flows with a higher
number of hops (up to 4 in this topology) due to the larger value on
the SuF duration (around 40ms in this case). On the other hand, the
full algorithm leverages the FDD characteristic when computing the
MBSFN SF DL requirements such that it can fit these requirements
into the initial 30ms long SuF duration, leading to satisfy most VoIP
flows.
When it comes to restrict the number of maximum hops over the
mesh to be 2 (i.e., Nhop = 2) for VoIP flows, Figure 34.(a) shows that
the full algorithm is the best by around 10% enhancement over the
simplified algorithm. In Figure 34.(c), we still can see that neither ap-
94 experimentations

proach can provide 100% satisfaction, with around 5% of dissatisfac-

tion for the simplified algorithm, 2% for the full one, and less than 1%
for the baseline one. The failure among simplified and full algorithms
to meet the requirements in this case is hard to analyze as they should
allocate enough SFs within the SuF duration. Hence, we analyze 84
vUE transmission behavior in Figure 35 that shows the UL transmis-
sions from some vUEs are subject to a higher failure rate. In DL direc-
tion, the concurrent DL transmissions on MBSFN SFs are mostly from
the same set of e2NBs over several repeated SuF duration allocated
by the COE controller. These characteristic can easily enable a better
measurement on the interferer power as well as channel quality as
vUE. Hence, the accurate feedback information from connected vUEs
will enable the e2NB to efficiently adapt the applied MCS through

4500
4000 Elastic flow 12 11
Elastic flow 15 13
3500
Data rate (kbps)

Elastic flow 2 16
3000
2500
2000
1500
1000
500
0
B. V DL. V UL. V B. 2V DL. 2V UL. 2V B. DL./UL.
(a) Throughput of elastic flows over three concurrent elastic flows.
1
0.9 B. V
0.8 DL. V
0.7 UL. V
0.6 Dissatisfaction flow region:
CDF

0.5 flows in this region have

0.4 less than 95% of their packets
0.3 arriving in less than 150ms
0.2
0.1
0
0 50 100 150 200 250
Latency (ms)
(b) CDF plot of the 95-th percentile of packet latency among real-time flows
with three elastic flows: 12 → 11, 15 → 13 and 2 → 16.
1
0.9 B. 2V
0.8 DL. 2V
0.7 UL. 2V
0.6 Dissatisfaction flow region:
CDF

0.5 flows in this region have

0.4 less than 95% of their packets
0.3 arriving in less than 150ms
0.2
0.1
0
0 50 100 150 200 250
Latency (ms)
(c) CDF plot of the 95-th percentile of packet latency among real-time flows
under maximum 2-hop mesh with three elastic flows: 12 → 11, 15 → 13 and 2 → 16.

Figure 34 – Hexagonal topology with 19 e2NBs and 190 UEs using 5MHz in
FDD mode.
 7.2 evaluation of the proposed approach 95

100
90
80
Percentage (%) 70
60
50
40
30
20 % UL successful transmission
10 % UL channel noise too high
0
1 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 84
vUE id
Figure 35 – vUE UL transmission successful rate of hexagonal topology
with 19 e2NBs and 190 UEs using 5MHz radio bandwidth of
FDD mode under UL. 2V.

adaptive modulation and coding (Adaptive Modulation and Coding

(AMC)) scheme . In contrast, UL transmissions over MBSFN SFs may
not have the same interference sources over different SuF durations
as the DLS at each e2NB will allocate the transmitting vUEs from its
connected vUE set. Hence, it makes harder to accurately estimate the
concurrent UL transmissions and noise power done by the e2NB from
one SF to the corresponding one in next SuF duration. It will lead to a
poor AMC decisions for the upcoming UL transmissions depending
on the conservativeness or aggressiveness characteristic of the adapta-
tion scheme. To tackle this problem, the DL direction should be more
privileged for the real-time traffic even when both DL and UL direc-
tions are available to transport traffic from an e2NB to others. If only
the UL direction is available, the UL scheduler should be designed
to be conservative on AMC decisions (i.e., changing slowly to higher
MCS, expecting more interference than reported, etc.).

We then evaluate the 10MHz in FDD mode without any limitations

on user pairing in Figure 36.(a). The simplified algorithm provides
the best throughput for elastic flows, while the full algorithm per-
forms only slightly better than baseline one. However, we can observe
in Figure 36.(b) that full algorithm is the only approach that can meet
the latency requirements for all VoIP flows over the network; that is
to say, the satisfaction ratio is 100% whereas the satisfaction ratio is
only 90% for other two algorithms. As explained in the 5MHz case,
this is mainly because these two algorithms are unable to allocate
their computed real-time SFs (i.e., SFrt D ) over the MBSFN SFs in the

SuF duration LSuF . As there is no flow control in the simulation,

it leads these two algorithms to increase the duration of SuF; other-
wise flows would be rejected in the CSA of centralized COE controller.
Increasing the duration of the SuF is not desirable as it increases the
average time between hops over some links, introducing extra latency
for VoIP flows. Both baseline and simplified algorithms do not exploit
the FDD characteristics when deriving SFrt D while the full one does

and hence reduces the expected total number of required DL SFs for
96 experimentations

4500
4000 Elastic flow 12 11
Elastic flow 15 13
3500

Data rate (kbps)

Elastic flow 2 16
3000
2500
2000
1500
1000
500
0
B. V DL. V UL. V
(a) Throughput of elastic flows over three concurrent elastic flows.
1
0.9 B. V
0.8 DL. V Dissatisfaction
0.7 UL. V flow region:
0.6 flows in this
CDF

0.5 region have

0.4 less than 95% of
their packets
0.3
arriving in less
0.2 than 150ms
0.1
0
0 30 60 90 120 150 180
Latency (ms)
(b) CDF plot of the 95-th percentile of packet latency among real-time flows
with three elastic flows: 12 → 11, 15 → 13 and 2 → 16.
Figure 36 – Hexagonal topology with 19 e2NBs and 190 UEs using 10MHz
in FDD mode.

real-time traffic. Once again, the full algorithm shows the best trade-
off between throughput and meeting latency requirements.

tdd mode Finally, we examine the TDD mode over the same topol-
ogy using TDD UL/DL configuration 4 on a 10MHz radio bandwidth.
We also evaluated the results when not applying any restrictions on
the maximum number of hops over the mesh; however, all algorithms
fail to handle so many multi-hop VoIP flows and most VoIP packets
are dropped from the queues. Hence, we do not show these results
here and apply the restriction on the maximum number of hops over
the mesh to pair UEs and generate bi-directional VoIP flows.
The results without VoIP flows and with VoIP flows and such con-
straint (i.e., Nhop = 2 or Nhop = 3) are shown in Figure 37. We can ob-
serve in Figure 37.(a) that both simplified and full algorithms outper-
form the baseline one on the throughput over all scenarios, providing
twice as much cumulated throughput when applying the restriction
to two or three hops and around three times as much when without
any VoIP flow. Regarding latency aspect, we can see in Figure 37.(b)
and Figure 37.(c) that these three algorithms have very close perfor-
mance; however, none of them can satisfy 100% of the VoIP flows
when restricting the maximum hops to 3 over the mesh network. In
contrast, 100% satisfaction is achieved with restrictions on the two
hops which was not the case when using a 5MHz FDD channel (cf.
Figure 34(c)) as the trade-off of a lower throughput (cf. Figure 34(a))
 7.2 evaluation of the proposed approach 97

4500
4000 Elastic flow 12 11

Data rate (kbps)

3500 Elastic flow 15 13
3000 Elastic flow 2 16
2500
2000
1500
1000
500
0

B.

L.
3V

2V
3V

2V

/U
B.

B.
L.

L.

L.
/U

/U

D
3V

2V
L.

L.
D

D
(a) Throughput of elastic flows over three concurrent elastic flows.
1
0.9 B. 3V
0.8 DL. 3V/UL. 3V Dissatisfaction
0.7 flow region:
0.6 flows in this
CDF

0.5 region have

less than 95% of
0.4
their packets
0.3
arriving in less
0.2 than 150ms
0.1
0
0 30 60 90 120 150 180
Latency (ms)
(b) CDF plot of the 95-th percentile of packet latency among real-time flows
under maximum 3-hop mesh with three elastic flows: 12 → 11, 15 → 13 and 2 → 16.
1
0.9 B. 2V
0.8 DL. 2V/UL. 2V
0.7
0.6
CDF

0.5
0.4
0.3
0.2
0.1
0
0 20 40 60 80 100 120 140
Latency (ms)
(c) CDF plot of the 95-th percentile of packet latency among real-time flows
under maximum 2-hop mesh with three elastic flows: 12 → 11, 15 → 13 and 2 → 16.

Figure 37 – Hexagonal topology with 19 e2NBs and 190 UEs using 10MHz
in TDD mode.

following the same discussion done in section 7.2.3. We also notice

that the maximum data rate of the full algorithm when without any
VoIP flows is similar to what was achieved by the same algorithm
when using 5MHz FDD channel (cf. Figure 34).

7.2.4 Summary

To summarize our findings in every scenario, Table 8 provides sev-

eral important results in this section. We can observe that the full al-
gorithm using FDD approach can provide the best trade-off between
meeting the latency requirement while achieving the highest data rate
for the elastic flows in most of the evaluated scenarios. Whereas
98 experimentations

Table 8 – Summary of the evaluation results

Best VoIP Best elastic Best data rate /

Scenario
latency data rate latency trade-off
7 e2NBs hexagonal Baseline Alg. Full Alg. Full Alg.
1→2 in FDD in TDD in TDD
7 e2NBs hexagonal Baseline Alg. Full Alg. Full Alg.
4→6 in FDD in TDD in FDD
7 e2NBs hexagonal Baseline Alg. Full Alg. Full Alg.
1→2&4→6 in FDD in FDD in FDD
7 e2NBs line Baseline Alg. Full Alg. Full Alg.
2→6 in FDD in FDD in FDD
7 e2NBs line Baseline Alg. Full Alg. Full Alg.
7→5 in FDD in FDD in FDD
7 e2NBs line Baseline Alg. Full Alg. Full Alg.
1→2&7→5 in FDD in FDD in FDD
19 e2NBs hexagonal Full Alg. Simplified Alg. Full Alg.
no hop restriction in FDD in FDD in FDD
19 e2NBs hexagonal Full Alg. Full Alg. Full Alg.
two hops restriction in TDD in FDD in TDD

TDD mode can provide the best trade-off in two specific scenarios:
(a) a unique one hop elastic flow over the 7 e2NBs hexagonal topol-
ogy, and (b) two hops restriction on VoIP flows over the 19 e2NBs
hexagonal topology. In the later case, the runner-up is the same algo-
rithm in FDD mode since it does not perform as expected due to a
higher interference along the UL directions. Using a more conserva-
tive scheduler for UL transmissions will potentially further improve
its results and allows the FDD to outperform the TDD mode. More-
over, our proposed full algorithm always achieves the best trade-off
as it takes into account the network topology, considered real-time
traffic characteristics and it leverages FDD characteristics. Thus, it
has a better estimation on the number of required SFs for real-time
D . Last but not least, the simplified algorithm can be
traffic, i.e., SFrt
used in TDD mode as it has the same performance as the full version,
We have observed that the FDD mode performs generally better
than the TDD mode thanks to the higher number of available MBSFN
SFs for the self-backhauling. It is also easier to manage HARQ and
other feedback reports in FDD mode as explained in chapter 5 and 6.
We have also seen that the conservativeness of the DLS on the applied
AMC strategy is of importance to well utilize the UL direction in FDD
mode. We can conclude that the FDD approach performs better at
equivalent aggregated bandwidth usage than the TDD approach in
7.3 performance comparison of in-band and out-band deployment 99

most scenarios, with the exception of scenarios with a single or a low

number of elastic flows generated by a single node and going over
a single hop. However, the TDD mode stays of interest as it is the
only one able to match the most stringent requirements on frequency
resource availability.
To conclude this section, we have been able to show that our pro-
posed approach achieves the trade-off between guaranteeing the la-
tency requirements for the real-time flows and providing the largest
throughput for elastic flows among all considered topologies. Such
algorithm performs adaptively depending on the network topology
and considered real-time traffic characteristics and thus has a better
estimation on the number of required SFs for real-time traffic, i.e.,
SFrtD . Via exploiting such benefit, we cannot only meet the real-time

traffic requirements in different topologies but also enable higher

throughput for the elastic traffic flows. Moreover, when comparing
the scenarios and results of these experiments with Table 3, we can
see that naval applications with less than ten BTS were covered with
simulated data file transfer and on going voice communications. We
have been able to see that the provided data rates out-perform what
was possible with previous RAT described in chapter 2 while allow-
ing more complex topologies. PS scenario with only real-time audio
transfers were also covered with up to 19 e2NBs were we showed
that real-time communications are possible if enough bandwidth is
available or if the maximum number of hops does not exceed some
threshold.

7.3 performance comparison of in-band and out-band

deployment

Apart from aforementioned in-band deployment, the out-band de-

ployment is another possible approach for self-backhauling network.
We discussed in section 3.2.2 that the out-band backhaul was not com-
plying with bandwidth limited scenarios as it requires at least another
dedicated frequency band that is separated from the band for access
link. Furthermore, we can also show that in-band self-backhauling
is more flexible and provides better throughput performance than
out-band deployment.
Hence, we compare these two possible deployments in terms of
the cumulated data rate using the full proposed scheduling algorithm.
Here, we consider a simple network topology consisting of three BTSs
in a line topology. In the in-band case shown in Figure 38(a), each
e2NB shares the same frequency band for both Uu and Un interfaces
with 10MHz channel bandwidth in FDD mode. Whereas the e2NBs
of the out-band case in Figure 38(b) requires two radio chains for two
different FDD bands each with 5MHz radio bandwidth each: one is
used to serve UEs on Band A using the Uu interface, and another one
100 experimentations

for the backhaul links on Band B relying on the Uu interface. Due to

the out-band characteristic of the second case, there is no interference
between the access and backhaul links; hence, two separated link
schedulers are applied individually. However, the in-band case can
rely on our proposed algorithms in order to allocate SFs for both
access link and backhaul link that can span a whole 10MHz radio
bandwidth.
In the first part of comparison, we consider three scenarios each
with individual elastic traffic flow: (i) From e2N B1 to e2N B2 , (ii)
From e2N B1 to e2N B3 , and (iii) From U E1 to e2N B1 . The data rates
among three scenarios are shown in Figure 39 and we can observe a
higher data rate on both backhaul and access links of the in-band case.
Such result is due to the inefficiency bandwidth utilization when di-
viding the whole 10MHz radio bandwidth into two fixed 5MHz ones
for both Uu interfaces of out-band deployment. Indeed, Un interface
can utilize at maximum 6 MBSFN SFs per frame for the backhaul
links (the actual number of SFs and the use of DL or UL directions
is managed by the COE). On a 10MHz channel bandwidth, it gives
roughly 20% more throughput than using 10 UL SFs per frame on a

e2NB1 e2NB2 e2NB3

Un Band A Un Band A
10MHz 10MHz
Uu band A Uu band A
10MHz vUE Band A vUEs Band A vUE Band A
10MHz

UE1 eNB Band A eNB Band A eNB Band A UE3

Radio Chain UE2 Radio Chain Radio Chain
Band A 10MHz Band A 10MHz Band A 10MHz

(a) Un in-band self-backhauling topology

e2NB1 e2NB2 e2NB3

Uu Band B Uu Band B
vUE Band B 5MHz eNB Band B 5MHz vUE Band B
Radio Chain Radio Chain Radio Chain
Band B 5MHz Band B 5MHz Band B 5MHz Uu band A
Uu band A
5MHz 5MHz

UE1 eNB Band A

Radio Chain UE2
eNB Band A
Radio Chain
eNB Band A
Radio Chain
UE3
Band A 5MHz Band A 5MHz Band A 5MHz

(b) Uu out-band self-backhauling topology

Figure 38 – Network topology for in/out-band comparison.

×104
3.5
3 Out-band Uu deployment
Data rate (kbps)

In-band Un deployment
2.5
2
1.5
1
0.5
0
e2NB1 e2NB 2 e2NB1 e2NB3 UE 1 e2NB1
Figure 39 – Data rate of traffic flow of in/out-band deployments.
7.3 performance comparison of in-band and out-band deployment 101

5MHz channel bandwidth as done by the Uu backhaul. With a traf-

fic flow transmitted from e2N B1 to e2N B3 over two backhaul hops,
the data rate over Uu backhaul does not change from the e2N B1 to
e2N B2 case, as it is limited by the UL direction from e2N B1 to e2N B2
(PRBs reserved for PUCCH makes it slightly slower than DL). On the
other hand, Un backhaul links perform slightly worse in e2N B1 to
e2N B3 case than in e2N B1 to e2N B2 because it has to rely on UL
SFs for half of its transmissions while it mainly use DL SFs in the lat-
ter case. When transmitting only a single flow from U E1 to e2N B1 ,
the Un backhaul architecture performs much better as almost all the
10MHz bandwidth can be used by the U E1 for the UL (almost no SF
are reserved for backhaul links as there is no traffic) while the Uu
case is limited to a 5MHz UL channel bandwidth.
Furthermore, we compare two scenarios each with two concurrent
traffic flows: (i) from U E2 to e2N B2 and from e2N B2 to e2N B1 , and
(ii) from U E2 to e2N B2 and from e2N B1 to e2N B2 . In Figure 40a, the
cumulated data rate is shown for the first scenario and we can observe
a higher data rate for the in-band case. In that case, most of the
MBSFN SFs are allocated as backhaul DL SFs for e2N B2 . As there is
no traffic coming from other e2NBs, U E2 gets the full UL bandwidth
(10MHz UL for local UEs), which allows the in-band Un deployment
to outperform the out-band Uu one (5MHz UL for local UEs). Such
result shows e2N B2 can properly transmit (i.e., to e2N B1 ) and receive
(i.e., from U E2 ) at the same time, and our proposed approach can
efficiently schedule all available resources. Moreover, the cumulated
date rate of the second scenario is shown in Figure 40b and we can see
that both deployments show close performance. Such phenomena is

×104
7 Elastic flow e2NB 2 e2NB1 Elastic flow UE 2 e2NB2
Data rate (kbps)

6
5
4
3
2
1
0
In-band Un deployment Out-band Uu deployment
(a) First scenario
×104
5
Elastic flow e2NB1 e2NB2 Elastic flow UE 2 e2NB 2
Data rate (kbps)

4
3
2
1
0
In-band Un deployment Out-band Uu deployment
(b) Second scenario
Figure 40 – Cumulated data rate of two traffic flows.
102 experimentations

due to the concurrent reception at e2N B2 from both e2N B1 and U E2 .

While the in-band Un solution allows more flexibility in sharing the
radio resources between backhaul and access links than the out-band
Uu solution, it is still limited by the FDD characteristic that the radio
chain do 50% TX and 50% TX. As most MBSFN SFs are allocated to
e2N B1 for backhauling in DL direction, the e2N B2 has on average
only 4 UL SFs available for its UE. This reduces the UL data rate and
the global throughput on the network slightly behind the Uu case
that has complete backhaul/access separation.
To sum up, the in-band deployment can properly and more effi-
ciently utilize available resource over access link and backhaul link
than the out-band deployment. These results further convince that
our proposed algorithm can perform an efficient scheduling for in-
band self-backhauling network.

7.4 summary

In this chapter, we have seen that the Un interface is performing

similarly to the Uu interface on computation requirements and re-
quires slightly higher SINR to provide the same throughput due to
the reduced number of available REs. Then, we have observed the
performance of the proposed approach and we have shown that it
allows to meet specific real-time traffic requirements while increas-
ing the achievable throughput for elastic traffic as close as possible
to the maximum achievable given the topology and activated flows,
this using either FDD or TDD deployments. Finally, we have shown
that the in-band self-backhauling provides better performance than
the out-band backhauling thanks to the higher flexibility regarding
backhaul/access resource allocation.

7.4.1 Limitations of the experiments

The performed simulations are not mimicking a real network in a

perfect way. For instance there is no HARQ handling, no mobility
of the e2NBs and no considered interference between UEs of differ-
ent BTS. HARQ handling has been discussed in sections 5.2.3 and
6.5. It should not be a problem for FDD mode but might be for
TDD mode for which more experiments are needed to understand
its behavior. The mobility of e2NBs has been taken into account in
their design and should not have such an impact on the behavior of
the network as long as the update periodicity of the self-backhauling
MBSFN SFs allocation can cope with the evolution of the RF chan-
nels. Particularly, in naval communications scenarios, the speed of
nodes moving away one from another is quite small compared to the
distance between nodes which also reduces the impact of mobility in
short duration experiments. However, this does not hold for PS sce-
 7.4 summary 103

narios with high speed nodes. UE interference mitigation is expected

to be handled by current interference mitigation techniques such as
eICIC through message exchanges between e2NBs. Moreover, some
techniques that could improve performance over TDD mode were not
experimented such as the use of UL SFs for HARQ or backhauling.
Most importantly, we have not evaluated or taken into account the
message exchanges between the COE agents and the COE controller
while it is of utmost importance, especially for the propagation of
scheduling decisions that needs to be guaranteed otherwise leading
to nodes being disconnected from the mesh. Such guarantee of de-
livery can be partially achieved thanks to the cross-layer approach
and packet differentiation by tagging the control plane packets with
a highest priority, above real-time traffic.

7.4.2 Potential improvements of the proposed approach

Based on all observations delivered in this section, we can further

sum up some potential improvements of our proposed approach to
further enhance its performance. Firstly, an inefficient UL channel es-
timation for the vUE along the backhaul links can degrade the perfor-
mance in FDD mode. This calls for more conservative UL scheduler
or applying more sophisticated interference avoidance schemes.
Moreover, the analysis showed that there is a side effect of the cur-
rently proposed computation of SFeD and SFeU at the COE controller
that is memory-less. Such memory-less characteristic will make the
COE controller take a longer duration to re-recognize the saturation
condition in the end-to-end data transportation. Since once we try
to resolve such saturation phenomena via allocating more resources
(i.e., SFs) to these links through SFeD and SFeU , the COE controller will
think the saturation condition is resolved immediately. Hence, it will
not allocate anymore resources until such link is saturated again; nev-
ertheless, such oscillations behavior has been observed using other
types of elastic flows. We can propose for instance two solutions
to overcome this issue. Firstly, SFeD and SFeU can be computed as
they are, but the values effectively used by other algorithms can be a
moving average over the current value and previous ones. Secondly,
instead of directly setting SFeD and SFeU to a specific value, we can
change their formulations to include the maximum change in each
value update to avoid any drastic changes. Both approaches can bet-
ter smooth the variations of the SFs allocation for the backhaul link
and prevent the observed oscillations.
We also showed that limiting the number of hops for VoIP flows
can ensure a better performance on the network, for both call quality
and elastic flow data rate while not restricting it could impact nega-
tively on every traffic flows in the mesh. The flow control algorithm
can take such condition into account with other metrics to preserve
104 experimentations

the expected network behavior. Otherwise, we can include such con-

dition when doing the handover process to make the source UE closer
in the number of hops toward its destination.
CONCLUSION
8
In this thesis, we propose a new BTS architecture that evolves the
legacy LTE BTS to enable new topologies to answer use cases found
in PS, military communications, and more generally in autonomous
moving cells and vehicular scenarios.
Starting from a review of the operational situations encountered
by military, navy and PS entities, we identified the shortcomings on
the state-of-the-art technology showing the current solutions to be in-
appropriate to sufficiently deliver seamless and continuous backhaul
connectivity in moving cell scenarios, thus making first responders
and tactical forces be deprived of critical communications. Under-
standing the lack of answers to enable high data rate autonomous
wireless mesh networks in constrained environments, we aimed to
propose a solution by first defining functional requirements that we
extended with the external constraints applying to PS and military
authorities such as scarce access to the radio spectrum. We then se-
lected LTE as the RAT for both access and backhaul connectivity of
the envisioned mesh network based on the current status of PS com-
munications and on the limitations of other state-of-the-art solutions
given the previously defined constraints. Then, we expose the chal-
lenges of using LTE for both backhaul and access connectivity, such
as the scheduling problems to realize a mesh network.
To answer the considered use cases taking into account the func-
tional requirements ad the external constraints, we proposed a novel
BTS architecture that enables autonomous mesh networks: the e2NB.
Such e2NB evolves the legacy LTE eNB relying on newly defined
vUEs to enable the in-band self-backhauling. Thanks to its embedded
CN elements and hosted applications, the e2NB is autonomous and
can provide services to legacy LTE UEs. Moreover, leveraging the
Uu and Un interfaces over the vUEs relying on specific procedures
and on the resource management operated by its COE, the e2NB is
able to detect and connect to adjacent e2NBs to form a wireless mesh
network relying on a single LTE bands.
Dealing with the problem of physical layer in depth, we justified
the choice of the in-band HD self-backhauling over FD or out-band
approaches. We then detailed the enablers of inter-e2NB discovery
and connection initialization as well as the main states and the asso-
ciated flow charts governing the e2NB behavior. To specifically an-
swer the dynamic resource allocation problem, we explored and pro-
posed an interference aware cross-layer hierarchical resource schedul-
ing algorithm to efficiently meet QoS requirements for real-time traf-

105
106 conclusion

fic while maximizing the throughput for elastic flows over the mesh
network. This complete architecture allows the designed network and
designed e2NB to be a SON with self-configuration, self-organization
and self-healing features.
We performed several experiments to assess the behavior and per-
formance of the proposed solution. Firstly, we evaluated the pro-
posed mesh physical layer that relies on the Un interface through
link-level emulation over the OAI platform. Secondly, using network
simulations, we evaluated the proposed scheduling approach over
several mesh network topologies with different traffic. We showed
the efficiency of the underlying physical layer on both computing re-
quirements and spectral efficiency using the OAI emulations. We also
demonstrated the effectiveness of the proposed hierarchical schedul-
ing approach to ensure QoS requirements while maximizing through-
put of elastic flows.

8.1 perspectives and future work

At the end of this study, we have shown that the e2NB is the best
candidate to answer the considered use cases that were not yet cov-
ered by current PS and military wireless communication systems. Par-
ticularly, we have detailed many design points and procedures that
are required at the e2NB to realize the self-backhauled LTE mesh net-
work before evaluating the physical layer in emulation as well as the
proposed scheduling approach in simulations.
To better identify the applicability of the proposed network archi-
tecture and of the e2NB in real deployments, the e2NB should be
implemented in a real RF prototype. Several steps are required to
develop a working prototype. Firstly, while we have designed most
of the required features of the e2NB, only part of them were imple-
mented and experimented. Regarding the physical layer, synchro-
nization procedures need to be applied. Moreover, the efficiency
of the channel measurements realized by vUEs should be evaluated
as the measurement window and periodicity can be much smaller
than the ones of a legacy UE. The impact of the proposed HARQ
modification for the TDD backhaul operation should be evaluated.
Lastly, while hardware modifications on the radio are expected to
be very limited, requiring only faster TX/RX switching time on the
radio chain(s) than for legacy BTS, they should be evaluated thor-
oughly. On higher layers, we over-viewed the content of messages
that should be exchanged between e2NB to enable the COE communi-
cations but did not specify any protocol for these message exchanges.
Thus, protocols for message exchanges between COE agents should be
designed and the election process of the COE controller should be de-
fined. Moreover, as we have seen in chapter 7, flow control algorithms
matter to ensure an efficient behavior and the high performance of
 8.1 perspectives and future work 107

the approach in network with either a high number of nodes or a

high number of real-time flows. Thus, the efficiency of flow control
policies applied over the network should be evaluated. Finally, the
requirements on the core network elements and on the higher layer
services to enable the seamless split and merge have only be explored
at a high level point of view and should be studied in details. While
changes on the EPC are not expected to be major, specific security
requirements of PS and military authorities have not been evaluated
and may impact it more deeply.
The proposed approach is not definitive and could undergo some
evolution. For instance, extensions to multi-sector BTSs have been
proposed in chapter 6 but should be evaluated to assess their effec-
tive gain. Similarly, beam forming techniques are known to severely
improve performance in mesh network. However, integrating it effi-
ciently in the proposed scheduling algorithms is not straight forward
and would require more studies. While we targeted a solution work-
ing with minimal available radio resources, the procedures could be
evolved to support CA if accessible. Particularly, the use of Multe-
fire [77] could also be considered to improve the performance of the
solution. Taking a look at the progression of cellular network archi-
tectures, we can observe that the e2NB aligns quite well with the
softwarization (use of Virtual Network Function (VNF) and of Net-
work Functions Virtualization (NFV)) of the RAN as it relies on vUEs
orchestrated by the COE in a flexible fashion. Moreover, the COE
controller and COE agents could be seen as elements part of a SDN ap-
proach. However, in both case, the applicability of generic VNF/NFV
and SDN approaches should be evaluated as the e2NB relies severely
on cross-layer approaches. Finally, while we are confident that the
proposed solution can be evolved for use with future cellular com-
munication systems, compatibility with 5G New Radio (5G NR) and
flexible numerology should be evaluated to determine what are the
necessary modification if any.
BIBLIOGRAPHY
9
[1] Joint Publication 6-0: Joint Communications System. Joint Chiefs of
Staff, June 2015. url: http : / / www . dtic . mil / doctrine / new _
pubs/jp6_0.pdf.
[2] Rifan 2 : un nouveau système de transmission pour les forces aéron-
avales. État-major des armées. url: http://www.defense.gouv.
fr / ema / transformation / actualites / rifan - 2 - un - nouveau -
systeme-de-transmission-pour-les-forces-aeronavales.
[3] SubNet Relay (SNR) brochure. Rockwell Collins. url: https : / /
www.rockwellcollins.com/-/media/Files/Unsecure/Products/
Product _ Brochures / Communcation _ and _ Networks / Modems /
SubNet_Relay_brochure.ashx.
[4] Rockwell Collins VHSM-5000 Modem. Rockwell Collins. url: https:
//www.rockwellcollins.com/Products _ and _ Services/A _ Z/V/
VHSM-5000_V-UHF_Modem.aspx.
[5] Syracuse III. Direction Générale de l’armement. url: http : / /
web.archive.org/web/20160325145240/http://www.defense.
gouv.fr/dga/equipement/information-communication-espace/
syracuse-iii.
[6] DCNS expérimente au large de Toulon un drone de surface. Naval
Group. url: https://www.naval- group.com/fr/news/dcns-
experimente-au-large-de-toulon-un-drone-de-surface/.
[7] The SAFECOM Program. Public Safety Statement of Requirements
for Communications and Interoperability. Vol. 1. U.S. Department
of Homeland Security, Oct. 2006. url: https://www.hsdl.org/
?abstract&did=236086.
[8] The SAFECOM Program. Public Safety Statement of Requirements
for Communications and Interoperability. Vol. 2. U.S. Department
of Homeland Security, Aug. 2006. url: http://www.hsdl.org/
?abstract&did=16170.
[9] G. Baldini, S. Karanasios, D. Allen, and F. Vergari. « Survey of
Wireless Communication Technologies for Public Safety ». In:
IEEE Communications Surveys Tutorials 16.2 (Feb. 2014), pp. 619–
641. issn: 1553-877X. doi: 10.1109/SURV.2013.082713.00034.
[10] TIA. « Project 25 System and Standards Definition ». In: TIA/EIA
Telecommunications Systems Bulletin, TSB102-A (1995).
[11] Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part
1: General network design. European Standard EN 300 392-1. Ver-
sion 1.4.1. ETSI, 2009.

109
110 bibliography

[12] K. Gomez, L. Goratti, T. Rasheed, and L. Reynaud. « Enabling

disaster-resilient 4G mobile communication networks ». In: Com-
munications Magazine, IEEE 52.12 (Dec. 2014), pp. 66–73. issn:
0163-6804. doi: 10.1109/MCOM.2014.6979954.
[13] Malisuwan Settapong, Tiamnara Noppadol, and Suriyakrai Nat-
takit. « Ad Hoc Lte Networks For Small-Scale Uav Applica-
tions ». In: Proceedings of The IRES 21st International Conference.
Paris, FR, 2015. isbn: 978-93-85832-71-6.
[14] Daniel Câmara and Navid Nikaein. Wireless Public Safety Net-
works 2: A Systematic Approach. Elsevier, 2016.
[15] K. Balachandran, K. C. Budka, T. P. Chu, T. L. Doumi, and J. H.
Kang. « Mobile responder communication networks for pub-
lic safety ». In: IEEE Communications Magazine 44.1 (Jan. 2006),
pp. 56–64. issn: 0163-6804. doi: 10.1109/MCOM.2006.1580933.
[16] Study on LTE device to device proximity services; Radio aspects. Tech-
nical Report 36.843. Version 12.0.1. 3GPP, 2014.
[17] Feasibility study for Proximity Services (ProSe). Technical Report
22.803. Version 12.2.0. 3GPP, 2013.
[18] Yutao Sui, J. Vihriala, A. Papadogiannis, M. Sternad, Wei Yang,
and T. Svensson. « Moving cells: a promising solution to boost
performance for vehicular users ». In: Communications Magazine,
IEEE 51.6 (June 2013), pp. 62–68. issn: 0163-6804. doi: 10.1109/
MCOM.2013.6525596.

[19] Romain Favraud and Navid Nikaein. « Wireless mesh backhaul-

ing for LTE/LTE-A networks ». In: IEEE MILCOM 2015. Oct.
2015, pp. 695–700. doi: 10.1109/MILCOM.2015.7357525.
[20] R. Fantacci, F. Gei, D. Marabissi, and L. Micciullo. « Public
safety networks evolution toward broadband: sharing infras-
tructures and spectrum with commercial systems ». In: IEEE
Communications Magazine 54.4 (Apr. 2016), pp. 24–30. issn: 0163-
6804. doi: 10.1109/MCOM.2016.7452262.
[21] R. Ferrus, O. Sallent, G. Baldini, and L. Goratti. « LTE: the tech-
nology driver for future public safety communications ». In:
IEEE Communications Magazine 51.10 (Oct. 2013), pp. 154–161.
issn: 0163-6804. doi: 10.1109/MCOM.2013.6619579.
[22] R. Favraud, A. Apostolaras, N. Nikaein, and T. Korakis. « To-
ward moving public safety networks ». In: IEEE Communica-
tions Magazine 54.3 (Mar. 2016), pp. 14–20. issn: 0163-6804. doi:
10.1109/MCOM.2016.7432142.

[23] Magdalena Nohrborg. LTE. 3GPP. url: http://www.3gpp.org/

technologies/keywords-acronyms/98-lte.
 bibliography 111

[24] Isolated Evolved Universal Terrestrial Radio Access Network opera-

tion for public safety; Stage 1. Technical Specification 22.346. Ver-
sion 13.0.0. 3GPP, 2014.
[25] Tuomas Taipale. « Feasibility of wireless mesh for LTE-Advanced
small cell access backhaul ». en. G2 Pro gradu, diplomityö. 2012.
url: http://urn.fi/URN:NBN:fi:aalto-201212083433.
[26] D. Abusch-Magder, P. Bosch, T. E. Klein, P. A. Polakos, L. G.
Samuel, and H. Viswanathan. « 911-NOW: A network on wheels
for emergency response and disaster recovery operations ». In:
Bell Labs Technical Journal 11.4 (2007), pp. 113–133. issn: 1089-
7089. doi: 10.1002/bltj.20199.
[27] A. Al-Hourani and S. Kandeepan. « Cognitive Relay Nodes for
airborne LTE emergency networks ». In: 2013, 7th International
Conference on Signal Processing and Communication Systems (IC-
SPCS). Dec. 2013, pp. 1–9. doi: 10.1109/ICSPCS.2013.6723940.
[28] K. Gomez et al. « Aerial base stations with opportunistic links
for next generation emergency communications ». In: IEEE Com-
munications Magazine 54.4 (Apr. 2016), pp. 31–39. issn: 0163-
6804. doi: 10.1109/MCOM.2016.7452263.
[29] R. A. Pitaval, O. Tirkkonen, R. Wichman, K. Pajukoski, E. La-
hetkangas, and E. Tiirola. « Full-duplex self-backhauling for
small-cell 5G networks ». In: IEEE Wireless Communications 22.5
(Oct. 2015), pp. 83–89. issn: 1536-1284. doi: 10.1109/MWC.2015.
7306541.

[30] Telecommunication management; Self-Organizing Networks (SON);

Concepts and requirements. Technical Specification 32.500. Ver-
sion 8.0.0. 3GPP, 2008.
[31] Nokia. LTE networks for public safety services. White Paper. 2014.
[32] Stefania Sesia et al. LTE - The UMTS Long Term Evolution. John
Wiley & Sons, Ltd, 2009. isbn: 9780470742891.
[33] Dinesh Bharadia, Emily McMilin, and Sachin Katti. « Full Du-
plex Radios ». In: Proceedings of the ACM SIGCOMM 2013 Con-
ference on SIGCOMM. SIGCOMM ’13. Hong Kong, China: ACM,
2013, pp. 375–386. isbn: 978-1-4503-2056-6.
[34] S. Goyal, P. Liu, S. Panwar, R. A. DiFazio, R. Yang, J. Li, and
E. Bala. « Improving small cell capacity with common-carrier
full duplex radios ». In: 2014 IEEE International Conference on
Communications (ICC). June 2014, pp. 4987–4993. doi: 10.1109/
ICC.2014.6884111.

[35] S. Goyal, P. Liu, S. Hua, and S. Panwar. « Analyzing a full-

duplex cellular system ». In: Information Sciences and Systems
(CISS), 2013 47th Annual Conference on. Mar. 2013, pp. 1–6. doi:
10.1109/CISS.2013.6552310.
112 bibliography

[36] R. A. Pitaval, O. Tirkkonen, R. Wichman, K. Pajukoski, E. La-

hetkangas, and E. Tiirola. « Full-duplex self-backhauling for
small-cell 5G networks ». In: IEEE Wireless Communications 22.5
(Oct. 2015), pp. 83–89. issn: 1536-1284. doi: 10.1109/MWC.2015.
7306541.

[37] S. Goyal, P. Liu, S. S. Panwar, R. A. Difazio, R. Yang, and E.

Bala. « Full duplex cellular systems: will doubling interference
prevent doubling capacity? » In: IEEE Communications Magazine
53.5 (May 2015), pp. 121–127. issn: 0163-6804. doi: 10 . 1109 /
MCOM.2015.7105650.

[38] Dinesh Bharadia and Sachin Katti. « FastForward: Fast and Con-
structive Full Duplex Relays ». In: Proceedings of the 2014 ACM
Conference on SIGCOMM. SIGCOMM ’14. Chicago, Illinois, USA:
ACM, 2014, pp. 199–210. isbn: 978-1-4503-2836-4.
[39] Evolved Universal Terrestrial Radio Access (E-UTRA); Base Station
(BS) radio transmission and reception. Technical Specification 36.104.
Version 8.14.0. 3GPP, 2017.
[40] Kai-Cheng Hsu, Kate Ching-Ju Lin, and Hung-Yu Wei. « Full-
duplex Delay-and-forward Relaying ». In: Proceedings of the 17th
ACM International Symposium on Mobile Ad Hoc Networking and
Computing. MobiHoc ’16. Paderborn, Germany: ACM, 2016. isbn:
978-1-4503-4184-4. doi: 10.1145/2942358.2942370.
[41] J. H. Yun. « Intra and Inter-Cell Resource Management in Full-
Duplex Heterogeneous Cellular Networks ». In: IEEE Transac-
tions on Mobile Computing 15.2 (Feb. 2016), pp. 392–405. issn:
1536-1233.
[42] Ankit Sharma, Radha Krishna Ganti, and J. Klutto Milleth. « Joint
Backhaul-Access Analysis of Full Duplex Self-Backhauling Het-
erogeneous Networks ». In: CoRR abs/1601.01858 (2016). url:
http://arxiv.org/abs/1601.01858.

[43] Oumer Teyeb, Vinh Van Phan, Bernhard Raaf, and Simone Redana.
« Dynamic Relaying in 3GPP LTE-Advanced Networks ». In:
EURASIP Journal on Wireless Communications and Networking 2009.1
(Sept. 2009), p. 731317. issn: 1687-1499. doi: 10 . 1155 / 2009 /
731317. url: https://doi.org/10.1155/2009/731317.

[44] P. Kela, M. Costa, J. Turkka, K. Leppänen, and R. Jäntti. « Flexi-

ble Backhauling With Massive MIMO for Ultra-Dense Networks ».
In: IEEE Access 4 (2016), pp. 9625–9634. issn: 2169-3536. doi:
10.1109/ACCESS.2016.2634039.

[45] Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer

for relaying operation. Technical Specification 36.216. Version 10.3.1.
3GPP, 2011.
 bibliography 113

[46] Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved

Universal Terrestrial Radio Access Network (E-UTRAN); Overall de-
scription; Stage 2. Technical Specification 36.300. Version 8.0.0.
3GPP, 2007.
[47] D. Bladsjö, M. Hogan, and S. Ruffini. « Synchronization aspects
in LTE small cells ». In: IEEE Communications Magazine 51.9
(Sept. 2013), pp. 70–77. issn: 0163-6804. doi: 10 . 1109 / MCOM .
2013.6588653.

[48] Evolved Universal Terrestrial Radio Access (E-UTRA); Requirements

for support of radio resource management. Technical Specification
36.133. Version 8.23.0. 3GPP, 2013.
[49] Michael A Lombardi et al. « Time and frequency measurements
using the global positioning system ». In: Cal Lab: International
Journal of Metrology 8.3 (2001), pp. 26–33.
[50] Michael A Lombardi. « The use of GPS disciplined oscillators
as primary frequency standards for calibration and metrology
laboratories ». In: NCSLI Measure 3.3 (2008), pp. 56–65.
[51] Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer
procedures. Technical Specification 36.213. Version 12.5.0. 3GPP,
2015.
[52] Telecommunication management; Automatic Neighbour Relation (ANR)
management; Concepts and requirements. Technical Specification
32.511. Version 8.0.0. 3GPP, 2008.
[53] Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Re-
source Control (RRC); Protocol specification. Technical Specifica-
tion 36.331. Version 8.0.0. 3GPP, 2007.
[54] Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
Self-configuring and self-optimizing network (SON) use cases and
solutions. Technical Report 36.902. Version 9.0.0. 3GPP, 2009.
[55] Evolved Universal Terrestrial Radio Access (E-UTRA); User Equip-
ment (UE) procedures in idle mode. Technical Specification 36.304.
Version 8.10.0. 3GPP, 2011.
[56] J. Baliosian and R. Stadler. « Distributed auto-configuration of
neighboring cell graphs in radio access networks ». In: IEEE
Transactions on Network and Service Management 7.3 (Sept. 2010),
pp. 145–157. issn: 1932-4537. doi: 10 . 1109 / TNSM . 2010 . 1009 .
I9P0330.

[57] Ian F. Akyildiz, Xudong Wang, and Weilin Wang. « Wireless

Mesh Networks: A Survey ». In: Comput. Netw. ISDN Syst. 47.4
(Mar. 2005), pp. 445–487. issn: 0169-7552. doi: 10 . 1016 / j .
comnet.2004.12.001.
114 bibliography

[58] P. H. Pathak and R. Dutta. « A Survey of Network Design Prob-

lems and Joint Design Approaches in Wireless Mesh Networks ».
In: IEEE Communications Surveys Tutorials 13.3 (Mar. 2011), pp. 396–
428. issn: 1553-877X. doi: 10.1109/SURV.2011.060710.00062.
[59] Abderrahmane BenMimoune, Fawaz A. Khasawneh, Bo Rong,
and Michel Kadoch. « Dynamic joint resource allocation and
relay selection for 5G multi-hop relay systems ». In: Telecommu-
nication Systems 66.2 (Oct. 2017), pp. 283–294. issn: 1572-9451.
doi: 10.1007/s11235-017-0286-3.
[60] M. t. Zhou, V. D. Hoang, H. Harada, J. S. Pathmasuntharam,
H. Wang, P. y. Kong, C. w. Ang, Y. Ge, and S. Wen. « TRITON:
high-speed maritime wireless mesh network ». In: IEEE Wireless
Communications 20.5 (Oct. 2013), pp. 134–142. issn: 1536-1284.
doi: 10.1109/MWC.2013.6664484.
[61] Jianhua Hey, Xiaoming Fuz, Jie Xiangx, Yan Zhangx, and Zuoyin
Tangy. « Routing and Scheduling for WiMAX Mesh Networks ».
In: WiMAX Network Planning and Optimization. CRC Press, 2009.
isbn: 9781420066630.
[62] Nikolaos Sapountzis. « Network layer optimization for next gen-
eration heterogeneous networks ». PhD thesis. Thesis, Dec. 2016.
url: http://www.eurecom.fr/publication/5084.
[63] Xenofon Foukas, Navid Nikaein, Mohamed M. Kassem, Ma-
hesh K. Marina, and Kimon Kontovasilis. « FlexRAN: A Flex-
ible and Programmable Platform for Software-Defined Radio
Access Networks ». In: Proceedings of the 12th International on
Conference on Emerging Networking EXperiments and Technologies.
CoNEXT ’16. Irvine, California, USA: ACM, 2016, pp. 427–441.
isbn: 978-1-4503-4292-6. doi: 10 . 1145 / 2999572 . 2999599. url:
http://doi.acm.org/10.1145/2999572.2999599.

[64] Huawei. The second phase of LTE-Advanced. White Paper. 2013.

[65] Silvere Mavoungou, Georges Kaddoum, Mostafa Taha, and Georges
Matar. « Survey on threats and attacks on mobile networks ». In:
IEEE Access 4 (2016), pp. 4543–4572.
[66] Sulabh Bhattarai, Sixiao Wei, Stephen Rook, Wei Yu, Robert F
Erbacher, and Hasan Cam. « On Simulation Studies of Jamming
Threats Against LTE Networks ». In: Computing, Networking and
Communications (ICNC), 2015 International Conference on. IEEE.
2015, pp. 99–103.
[67] Sulabh Bhattarai, Stephen Rook, Linqiang Ge, Sixiao Wei, Wei
Yu, and Xinwen Fu. « On Simulation Studies of Cyber Attacks
against LTE Networks ». In: Computer Communication and Net-
works (ICCCN), 2014 23rd International Conference on. IEEE. 2014,
pp. 1–8.
 bibliography 115

[68] The OpenAirInterface Platform. url: http://www.openairinterface.

org.

[69] Romain Favraud and Navid Nikaein. « Analysis of LTE Relay

Interface for Self-backhauling in LTE Mesh Networks ». In: 2017
IEEE 86th Vehicular Technology Conference (VTC-Fall). Sept. 2017.
[70] Navid Nikaein. « Processing Radio Access Network Functions
in the Cloud: Critical Issues and Modeling ». In: Proceedings
of the 6th International Workshop on Mobile Cloud Computing and
Services. MCS ’15. Paris, France: ACM, 2015, pp. 36–43. isbn:
978-1-4503-3545-4. doi: 10.1145/2802130.2802136. url: http:
//doi.acm.org/10.1145/2802130.2802136.

[71] Evolved Universal Terrestrial Radio Access (E-UTRA); User Equip-

ment (UE) radio transmission and reception. Technical Specifica-
tion 36.101. Version 10.0.0. 3GPP, 2010.
[72] Evolved Universal Terrestrial Radio Access (E-UTRA); Further ad-
vancements for E-UTRA physical layer aspects. Technical Report
36.814. Version 9.0.0. 3GPP, 2010.
[73] Radio Frequency (RF) system scenarios. Technical Report 25.942.
Version 10.1.0. 3GPP, 2012.
[74] Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Fre-
quency (RF) system scenarios. Technical Report 36.942. Version 10.3.0.
3GPP, 2012.
[75] Alexander F. Ribadeneira. « An analysis of the MOS under con-
ditions of delay, jitter and packet loss and an analysis of the
impact of introducing piggybacking and reed solomon FEC for
VoIP ». MA thesis. Georgia State University, 2007.
[76] Romain Favraud, Navid Nikaein, and Chia-Yu Chang. « QoS
guarantee in self-backhauled LTE mesh networks ». In: GLOBE-
COM 2017, IEEE Global Communications Conference, December 4-8,
2017, Singapore, Singapore. Dec. 2017.
[77] About MulteFire Technology. MulteFire Alliance. url: https://
www.multefire.org/technology/.
Appendices

117
ADDITIONAL FIGURES
A
This appendix gathers figures that were not displayed in section 7.2
to improve readability.

Hexagonal topology with 7 e2NBs

1
Basic
DL.
UL.
CDF

0,5

0
10 20 30 40 50 60 70 80 90 100 110
Latency (ms)
(a) CDF plot of the 95-th percentile of packet latency among real-time flows.
1 → 2 elastic flow scenario.
1
Basic
DL.
CDF

0,5
UL.

0
10 20 30 40 50 60 70 80 90 100 110
Latency (ms)
(b) CDF plot of the 95-th percentile of packet latency among real-time flows.
4 → 6 elastic flow scenario.
Figure 41 – Hexagonal topology with 7 e2NBs and 70 UEs using a 10MHz
FDD configuration.
1
Basic
DL.
CDF

0,5

0
10 20 30 40 50 60 70 80 90
Latency (ms)
(a) CDF plot of the 95-th percentile of packet latency among real-time flows.
1 → 2 elastic flow scenario.
1
Basic
DL.
CDF

0,5

0
10 20 30 40 50 60 70 80 90
Latency (ms)
(b) CDF plot of the 95-th percentile of packet latency among real-time flows.
4 → 6 elastic flow scenario.
Figure 42 – Hexagonal topology with 7 e2NBs and 70 UEs using a 10MHz
TDD configuration.

119
120 additional figures

1
UL. FDD
DL. TDD

CDF
0,5

0
10 20 30 40 50 60 70 80 90
Latency (ms)
(a) CDF plot of the 95-th percentile of packet latency among real-time flows.
1 → 2 elastic flow scenario.
1
UL. FDD
DL. TDD
CDF

0,5

0
10 20 30 40 50 60 70 80 90
Latency (ms)
(b) CDF plot of the 95-th percentile of packet latency among real-time flows.
4 → 6 elastic flow scenario.
Figure 43 – Hexagonal topology with 7 e2NBs and 70 UEs using a 10MHz
TDD and a 5MHz FDD configuration.

Line topology with 7 e2NBs

1
Basic
DL.
UL.
CDF

0,5

0
0 20 40 60 80 100 120 140
Latency (ms)
(a) CDF plot of the 95-th percentile of packet latency among real-time flows. 2 → 6
elastic flow scenario.
1
Basic
DL.
UL.
CDF

0,5

0
0 20 40 60 80 100 120 140
Latency (ms)
(b) CDF plot of the 95-th percentile of packet latency among real-time flows. 7 → 5
elastic flow scenario.
Figure 44 – Line topology with 7 e2NBs and 70 UEs using a 5MHz FDD
configuration.
 additional figures 121

1
Basic
DL.
CDF

0,5

0
0 20 40 60 80 100 120 140
Latency (ms)
(a) CDF plot of the 95-th percentile of packet latency among real-time flows.
2 → 6 elastic flow scenario without VoIP hop limitation.
1
Basic
DL.
CDF

0,5

0
10 20 30 40 50 60 70 80 90 100
Latency (ms)
(b) CDF plot of the 95-th percentile of packet latency among real-time flows.
2 → 6 elastic flow scenario with VoIP 1 hop constraint.
1
Basic
DL.
CDF

0,5

0
10 20 30 40 50 60 70 80 90 100 110
Latency (ms)
(c) CDF plot of the 95-th percentile of packet latency among real-time flows.
7 → 5 elastic flow scenario without VoIP hop limitation.
1
Basic
DL.
CDF

0,5

0
10 20 30 40 50 60 70 80 90 100
Latency (ms)
(d) CDF plot of the 95-th percentile of packet latency among real-time flows.
7 → 5 elastic flow scenario with VoIP 1 hop constraint.

Figure 45 – Line topology with 7 e2NBs and 70 UEs using a 10MHz TDD
configuration.
122 additional figures

1
UL. FDD
DL. TDD
CDF

0,5

0
0 20 40 60 80 100 120 140
Latency (ms)
(a) CDF plot of the 95-th percentile of packet latency among real-time flows.
2 → 6 elastic flow scenario without VoIP hop limitation.
1
UL. FDD
DL. TDD
CDF

0,5

0
0 20 40 60 80 100 120 140
Latency (ms)
(b) CDF plot of the 95-th percentile of packet latency among real-time flows.
7 → 5 elastic flow scenario without VoIP hop limitation.

Figure 46 – Line topology with 7 e2NBs and 70 UEs using a 10MHz TDD or
a 5MHz FDD configuration.
RÉSUMÉ EN FRANÇAIS
B
Cette section en français résume de manière courte les travaux
menés dans le cadre de cette thèse. Le lecteur est prié de consul-
ter les sections originales correspondantes s’il souhaite obtenir plus
de détails.

b.1 introduction

Les communications sans fil sont de plus en plus utilisées pour

répondre à de multiples cas d’utilisation. Bien que le spectre électro-
magnétique soit fixe et que les fréquences disponibles se fassent de
plus en plus rares, de nouvelles technologies émergent continuelle-
ment, améliorant les performances et les services rendus et poussant
de plus en plus les attentes des utilisateurs.
Dans cet environnement radio surchargé, le Long Term Evolution
(LTE) est devenu la technologie 4G de référence et a été adoptée par
tous les opérateurs majeurs de téléphonie mobile de par le monde.
Aujourd’hui, le LTE continue d’évoluer pour répondre à de nombreux
défis (forte augmentation des usages mobiles et des besoins de bande
passante, ultra haut débit, ultra faible latence, nombre massif de con-
nexions, mobilité ultra rapide, flexibilité en fréquence, etc.) qui se
trouvent sur le chemin de la 5G. Les stations de base mobiles ou
cellules mobiles ont été perçues comme à même d’étendre la couver-
ture réseau et d’améliorer le débit utile à faible coût, permettant de
nouveaux cas d’utilisation pour les systèmes de transport intelligents,
les drones autonomes et communicants, etc. De plus, le LTE tiendra
une place importante dans l’environnement 5G et sera une des pièces
principales de l’évolution des communications au sein des autorités
de sécurité publique.

b.1.1 Motivation

Aux Etats-Unis, le LTE a été choisi comme technologie support des

futurs réseaux de sécurité publique et il est fort probable qu’il en
soit de même en Europe. De nombreux équipementiers proposent
aujourd’hui des solutions de sécurité publique et plusieurs expéri-
mentations ont eu lieu.
Les solutions actuelles de communication pour la sécurité publique
(Project 25 (P25) et Terrestrial Trunked Radio (TETRA)) sont matures
et fournissent des services de communications vocales fiables. Cepen-
dant, leur conception ne leur permet pas de répondre aux nouvelles

123
124 résumé en français

exigences et notamment aux besoins croissants de bande passante.

D’un autre côté, le LTE a été conçu initialement comme un réseau cel-
lulaire grand public à usage commercial et n’était pas adapté, dans
les spécifications initiales publiées par le 3rd Generation Partnership
Project (3GPP), au support des services nécessaires aux réseaux de
sécurité publique, tels que les communications de groupe et de prox-
imité, ainsi qu’aux exigences de sécurité, de confidentialité et de fi-
abilité accrues. Ainsi, il est d’importance de déterminer si le LTE
peut s’avérer une solution satisfaisante pour l’évolution des réseaux
de sécurité publique. Pour régler les problèmes précédemment évo-
qués, le 3GPP a commencé à définir les scénarios auxquels le LTE va
devoir répondre et a publié différentes études pour concernant les
communications de proximité, de groupe, la disponibilité de fonction
de Push-To-Talk (PTT) et de station de base isolée (Isolated Evolved
Universal Terrestrial Radio Access Network (E-UTRAN)). Cependant,
ces études sur la possibilité de stations de base isolées sont restées
assez limitées et aucun moyen d’interconnexion des stations de base
n’a été proposé en l’absence de connectivité préalable à un cœur de
réseau commun.
Du côté des instances militaires, celles-ci ont longtemps été précur-
seurs des avancées techniques dans le domaine des télécommunica-
tions. Cela a changé et la révolution numérique actuelle passe aussi
par des communications filaires et sans fil de plus en plus évoluées
dans le domaine civil, bénéficiant des investissements massifs réalisés
par des acteurs privés. Aujourd’hui, la plupart des innovations tech-
nologiques sont initialement développées pour des systèmes grands
publics, ou tout au moins visant le marché civil. De plus, les budgets
militaires n’augmentent plus alors que les périmètres d’interventions
s’étendent. Cela amène les autorités militaires à étudier la possibilité
d’utiliser des technologies civiles à leur profit. Ainsi, l’intérêt autour
du LTE a aussi grandi auprès des autorités militaires pour des com-
munications sur terre ou en mer. Cependant, ces cas d’utilisations
spécifiques sont assez éloignés des cas civils classiques et présentent
des contraintes et des topologies réseaux qui ne se retrouvent pas
dans le domaine civil.

b.1.2 Contributions

L’utilisation de stations de base mobiles et autonomes est très in-

téressante pour les scénarios militaires et de sécurité publique. A ce
jour, il y a eu peu de recherches pour faire évoluer les stations de base
LTE, dénommées evolved Node B (eNB), pour permettre leur mobil-
ité et leur autonomie, et plus particulièrement pour autoriser plus de
deux bons sans-fil utilisant l’interface radio LTE sur une seule bande
radio. Pourtant, comme nous le détaillons dans cette thèse, cela est
d’intérêt pour plusieurs cas d’utilisation. Ainsi, nous étudions dans
 B.1 introduction 125

cette thèse comment améliorer et comment faire évoluer les systèmes

de communication LTE pour permettre de répondre à de nouveaux
cas d’utilisation dans des environnements contraints en utilisant des
stations de base mobiles.
Dans le premier chapitre, nous introduisons les cas d’utilisation
que nous considérons dans notre étude en décrivant des scénarios
rencontrés par les autorités militaires, navales et de sécurité publique.
Nous montrons les limitations des systèmes de communication sans
fil actuellement utilisés. Nous présentons alors des topologies de
réseau qui apparaissent dans ces différents cas d’utilisations. A la
lumière de ces limitations, nous formulons le problème principal que
nous considérons dans cette étude: comment fournir des services de
données à haut débit en mobilité en l’absence d’infrastructures de
réseau existantes en s’appuyant sur l’utilisation de station de base
mobiles capables de fonctionner dans des environnements contraints.
Nous concluons ce premier chapitre en listant les exigences fonction-
nelles auquel un système de communication fournissant un tel ser-
vice doit répondre.
Dans le second chapitre, nous étendons ces exigences aux con-
traintes externes qui s’appliquent sur les systèmes de communica-
tions militaires ou pour la sécurité publique, en particulier la disponi-
bilité limitée de ressources spectrales. Après analyse des contraintes
pesant sur le système, nous sélectionnons le LTE comme technologie
unique permettant la création du système de communication visé,
pour fournir les communications aux entités mobiles (User Equip-
ments) ainsi que les communications entre les stations de base au-
tonomes.
Dans le troisième chapitre, nous détaillons les défis induits par
l’utilisation du LTE comme technologie d’accès et de maillage. Nous
présentons ensuite une nouvelle infrastructure de réseau qui permet
la création de réseaux maillés LTE multi-bonds sur une seule bande
de fréquence grâce à une nouvelle station de base : l’enhanced evolved
Node B (e2NB). Nous décrivons les blocs fonctionnels de l’e2NB et in-
troduisons le Virtual UE (vUE) qui permet l’établissement de liaisons
inter stations de base. Nous présentons ensuite les états internes
de l’e2NB qui permettent l’évolution dynamique du réseau maillé
et finissons ce chapitre avec des exemples de topologies possibles.
Ensuite, nous détaillons les éléments et les procédures spécifiques
introduites dans l’e2NB dans le quatrième chapitre. En particulier,
nous explorons le choix de la couche physique et soulignons les lim-
ites de la couche physique LTE classique (User to UTRAN (Uu)) avant
de la comparer avec la couche physique LTE développée pour les
relais (Un). Nous présentons ensuite de manière détaillée les fonc-
tionnalités et les procédures principales de l’e2NB qui permettent la
découverte des stations de base adjacentes et la connexion initiale à
celles-ci. Nous présentons enfin les états de l’e2NB qui dépendent de
126 résumé en français

la topologie en cours et permettent aux e2NB de joindre ou de quitter

des réseaux maillés.
Dans le cinquième chapitre, nous explorons la fonctionnalité de co-
ordination et d’orchestration nécessaire au fonctionnement du réseau
maillé. Afin d’assurer le fonctionnement à la fois en LTE mode Fre-
quency Division Duplexing (FDD) et en LTE mode Time Division
Duplexing (TDD), nous proposons un algorithme d’ordonnancement
inter-couches et hiérarchique ayant pour objectifs de respecter des
contraintes de qualité de service de certains flux temps réel (voix) et
de maximiser le débit utile de flux élastiques.
Finalement, dans le sixième chapitre, nous démontrons la faisabil-
ité de la solution proposée. Nous implémentons d’abord l’interface
LTE sans fil (interface Un) sur la plateforme de radio logicielle Open
Air Interface (OAI) et comparons ses performances spectrales et sa
complexité avec celles de l’interface LTE classique (Uu). Ensuite, nous
évaluons l’efficacité de l’algorithme d’ordonnancement proposé sur
différentes topologies sujettes à différents types de trafic pour mon-
trer son adaptabilité et les limitations associées aux modes TDD et
FDD.
En conclusion, nous résumons les incertitudes restantes concernant
les déploiements terrains et nous concluons cette étude en évoquant
les étapes suivantes pour amener la solution proposée vers un sys-
tème sans fil réel et totalement fonctionnel.

b.2 état de l’art et définition de la problématique

b.2.1 Cas d’utilisation militaires

Dans la plupart des environnements, les forces militaires ont forte-

ment recours aux communications sans fil pour palier à l’absence
d’infrastructure fixe de télécommunications en territoire hostile ou
en mer. La Figure 47 présente un aperçu des communications sans fil
entre différentes entités qui peuvent être déployées.
Pour réaliser cela, différents systèmes de communications sont em-
barqués et intégrés dans les bâtiments de surface pour utiliser au
mieux le spectre radioélectrique des bandes Very Low Frequency
(VLF) aux bandes Extremely High Frequency (EHF) et fournir des
communications sans fil avec des entités proches ou éloignées. Cepen-
dant, les systèmes de communications militaires n’évoluent pas aussi
rapidement que les systèmes de communications civils.

Systèmes de communications navals

En particulier, les systèmes de communications sans fil à moyenne
portée pour communications de bateaux à bateaux ou de bateaux
à quai (Ultra High Frequency (UHF) SubNetwork Relay (SNR) et
Réseau Intranet des Forces Aéro-Navales 2 (RIFAN 2)) ne sont pas
 B.2 état de l’art et définition de la problématique 127

Legend
VLF
HF/VHF/UHF Satellite
SHF/EHF

Aircraft
Helicopter Aircraft
UAV Air
Land Sea Sea Land

Ship
Tank Ship Ship

USV Ship
Head
Troops Quarters
Aircraft
carrier Submarine
Speed boat Ship

Figure 47 – Aperçu des communications sans fil militaires et navales

en mesure de fournir des débits suffisants ou des latences faibles per-

mettant de répondre aux nouveaux cas d’utilisations. Un résumé des
systèmes utilisés est présenté dans la Table 9.

Table 9 – Systèmes de communication navals à moyenne portée et système

de communication par satellite
Système UHF SNR [4] / RIFAN 2 Satellite (Syracuse [5])

UHF
Bande de fréquence SHF, EHF
(canal de 500 KHz)

5 Mbps non protégé

Débit maximum < 2 Mbps
2 Mbps protégé

240 ms sur spot

Latence minimale > 100 ms
480 ms sinon

Portée Visibilité radio (UHF) Couverture satellite

Ces communications sont essentielle pour le bon déroulement des

missions des forces navales. Leur facilité de mise en œuvre et de
maintenance sont appréciées des marins. Cependant, leurs capacités
limitées et la latence importante ne sont plus suffisantes pour répon-
dre aux nouveaux besoins.
Une liste d’exigences pour un nouveau système de communica-
tions sans fil à moyenne portée qui comblerait les problèmes évoqués
peut être dressée :

— Communications sans fil entre plusieurs bâtiments de surfaces,

entre bâtiments de surface et entités mobiles (drones, marins,
etc.), entre bâtiments de surface et terre
128 résumé en français

— Portée maximales de plusieurs dizaines de kilomètres (visibilité

radio UHF)
— Débits maximum importants (> 1Mbps)
— Latence faible (< 100ms)
— Haute efficacité spectrale
— Adaptabilité en fréquence permettant de s’intégrer avec les sys-
tèmes actuellement déployés
— Configuration, utilisation et maintenance simple ou automa-
tique
— Faible Capital expenditure (CAPEX) et Operating expense (OPEX)

b.2.2 Communications pour la sécurité publique

Contrairement aux communications militaires, les communications

de sécurité publique s’appuient sur des infrastructures fixes. Cepen-
dant, ces infrastructures peuvent être endommagées lors d’évènements
climatiques ou ne pas être présentes dans des régions reculées. L’étude
de Baldini et Al. [9] présente une vue complète des environnements
de sécurité publique et des systèmes de communications associés.
Aujourd’hui, les systèmes P25 et TETRA fournissent des services
voix fiables mais les services de données restent très limités et à faible
débit. De plus, leurs architectures centralisées ne permettent pas de
répondre aisément aux situations de crises et aux déploiements op-
portunistes.

b.2.3 Topologies réseaux associées

Dans la section 2.2, nous présentons les différentes topologies qui

peuvent émerger des réseaux de sécurité publique et des réseaux de
communication militaire à moyenne portée. Il ressort que les sys-
tèmes actuels ne peuvent couvrir les cas où l’accès de toutes les sta-
tions de base à un cœur de réseau commun (Core Network (CN)) ne
peut être assuré, ce qui inclut les scénarios avec mobilité des stations
de base. Ainsi, de nouveaux systèmes de communication doivent être
développés.

b.2.4 Énoncé du problème

Nous avons vu que les systèmes de communication actuels pour les

communications militaires et de sécurité publique ne peuvent répon-
dre à l’évolution des besoins. En particulier, ils ne peuvent s’adapter
à différentes topologies et ne fournissent pas des performances satis-
faisantes.
 B.2 état de l’art et définition de la problématique 129

Ainsi, l’objectif de cette étude est de concevoir un système de com-

munication adaptatif, capable de fournir des performances en hausse
et de répondre aux différents cas d’usage non couverts actuellement.

Exigences fonctionnelles

Nous pouvons identifier plusieurs exigences haut niveau néces-

saires à la réalisation d’un tel système de communication.
Premièrement, ce système doit être en mesure de servir des UEs
locaux sans nécessiter un accès à un cœur de réseau externe ou à un
autre équipement, ceci afin d’être une station de base autonome. Il
doit ainsi disposer de :
(a) Une couche radio pour servir les UEs locaux comme une station
de base classique;
(b) Un ensemble minimal de fonction de cœur de réseau pour as-
surer la gestion des UEs locaux, les fonctions d’authentifications,
etc.;
(c) Un ensemble de services et applications pour permettre la four-
niture minimale de services aux UEs connectés, tels des services
voix, de localisation, etc.
Ensuite, nous souhaitons concevoir un système qui permette l’inter-
connexion efficace et transparente de multiples stations de base pour
étendre le réseau et permettre la création d’un réseau autonome. Un
réseau autonome est un réseau doté de fonctions d’auto-organisation
lui permettant de réagir à la mobilité des nœuds, d’établir et de
relâcher des connexions, d’assurer une routage efficace sur le réseau
créé, cela sans s’appuyer sur des entités externes au réseau. La créa-
tion d’un réseau autonome permet de répondre aux différents cas
d’utilisation précédemment évoqués. Ainsi, un nouveau système de
communication devra supporter les fonctionnalités suivantes :
(d) Une interface de communication sans fil pour établir des li-
aisons sans fil entre stations de base;
(e) Des mécanismes de détection et de connexion aux stations de
base voisines;
(f) Des capacités de reconfiguration automatiques pour s’adapter
aux changements de topologies;
(g) Des schémas de gestion de interférences pour limiter l’impact
des interférences sur les UEs et sur les stations de base;
(h) Des mécanismes de connexion entre les cœurs de réseau des
différentes stations de base pour permettre la mobilité transpar-
ente des UEs sur le réseau créé;
(i) Des mécanismes de routage efficaces pour transporter le trafic
sur le réseau à travers plusieurs bonds sans fil;
130 résumé en français

(j) Des mécanismes de coopération entre services et applications

fournies par différents nœuds pour permettre l’activation de
services au niveau du réseau.
Ces exigences sont nécessaires pour construire un réseau autonome
et répondre aux cas d’utilisation militaires et de sécurité publique.

b.3 contraintes de conception et choix de la technolo-

gie d’accès radio

Nous exposons les contraintes externes qui s’appliquent sur le sys-

tème et procédons au choix des technologies de transmission sans fil
(Radio Access Technologies (RATs)).

b.3.1 Contraintes externes

En plus des exigences fonctionnelles précédemment déterminées,

les autorités militaires et de sécurité publique font faces à certaines
contraintes environnementales. Ces contraintes doivent être prises
en compte pour la conception d’une solution pour réaliser un réseau
autonome.
Les contraintes sont principalement de deux types :
— Contrainte de coût pour limiter CAPEX and OPEX ;
— Contrainte d’accès aux ressources spectrale pour assurer la co-
habitation avec d’autres systèmes et assurer le fonctionnement
dans de multiples situations où la disponibilité de large portion
de spectre n’est pas assurée.
Pour minimiser les coûts, une solution qui nécessite le moins de
matériel supplémentaire possible en comparaison avec les systèmes
actuels sera favorisée. De même, une solution qui nécessiterait peu
de configuration manuelle et de maintenance, en s’appuyant sur des
procédures automatisées, sera favorisée. Enfin, une solution qui serait
capable de réaliser le réseau autonome tout en ne nécessitant qu’une
seule bande de fréquence présenterait un avantage significatif.
Ainsi, nous souhaitons concevoir un nouveau système de commu-
nication sans fil qui permette d’établir un réseau autonome tout en
minimisant le matériel, les interventions humaines et les ressources
spectrales minimales nécessaires.

b.3.2 Choix de la technologie d’accès radio

L’étude de Baldiny de 2013 [9] nous renseigne sur les systèmes de

communication mis en œuvre pour les communications de sécurité
publique : Analog Professional Mobile Radio (PMR) ; Digital Mo-
bile Radio (DMR) ; P25 ; TETRA V.1 ; TETRA V.2 ; TETRAPOL ;
Global System for Mobile communications (GSM) / General Packet
B.3 contraintes de conception et choix de la technologie d’accès radio 131

Radio Service (GPRS)/ Universal Mobile Telecommunication System

(UMTS) / 3G ; LTE ; communications par satellite ; WiFi / Worldwide
Interoperability for Microwave Access (WiMAX) ; réseaux ad-hoc ;
communications spécifiques au monde maritime ; communications
spécifiques à l’aviation. En conclusion de cette étude, les auteurs no-
tent que le LTE a émergé comme la technologie de choix pour les fu-
tures solutions de communications pour la sécurité publique. En effet,
le LTE dispose d’un certain nombre de caractéristiques intéressantes :
haute efficacité spectrale, flexibilité en fréquence, large couverture ra-
dio grâce à des puissances maximales d’émission élevées et support
natif des flux Internet Protocol (IP). Ferrus et Al. [21] arrivent à la
même conclusion et notent que le LTE a atteint la maturité nécessaire
pour être intégré dans les systèmes de communications des autorités
de sécurité publique. Cependant, ces deux articles soulignent aussi
que le LTE, au moment de leur publication, nécessitait encore des évo-
lutions pour répondre aux exigences des réseaux de communication
de sécurité publique.
De nombreuses avancées ont été réalisées sur le LTE depuis ces
deux études et celui-ci a été sélectionné pour les futurs réseaux de
sécurité publique dans de nombreux pays [22].
Ainsi, il fait sens de sélectionner le LTE comme technologie radio
pour permettre la fourniture de service à des UEs standards et pour
assurer une compatibilité avec les futures services et terminaux.

Etat de l’art du LTE

Les spécifications du LTE sont publiées par le 3GPP. La première

version, nommée "Release 8" a été publiée en 2008, et la "Release 10"
a été la première version qui respectait les critères de l’Union Inter-
nationale des Télécommunications (UIT) pour être désignée comme
technologie de quatrième génération (4G).
Le LTE est une technologie d’accès radio pour réseau cellulaire, son
architecture générale est présentée sur la Figure 48.
On peut noter que le LTE, comme les autres technologies d’accès
radio pour réseaux cellulaires, s’appuient sur la présence d’un cœur
de réseau (CN) pour fournir l’accès au service aux UEs. Ce cœur de
réseau est responsable de plusieurs fonctionnalités nécessaires au bon
fonctionnement du réseau tels que l’authentification des utilisateurs,
la facturation, le routage, la gestion de la mobilité, etc. Les spécifica-
tions du LTE spécifie complètement l’interface radio entre les stations
de base (eNBs) et les UEs depuis la couche physique jusqu’à la four-
niture du service IP utilisateur. Cependant, les communications au
sein du cœur de réseau ne sont spécifiées qu’au-dessus de la couche
IP, c’est à dire que n’importe quel type de liaison peut être utilisée
entre les éléments du cœur de réseau tant que celle-ci fournit une
connexion IP entre ces éléments. Ainsi la liaison X2 entre eNBs est
132 résumé en français

SGi
EPC
HSS PCRF S7 P-GW

S6a S5-S8

MME S11 S-GW

E-UTRAN S1-MME S1-MME S1-U

S1-U S1-U
S1-MME X2

X2 X2

Uu Uu Uu Uu
Uu
eNodeB eNodeB eNodeB

UE UE
UE UE UE
Figure 48 – Architecture nominale du LTE (Release 8).

une liaison logique qui s’appuie sur la préexistence d’un lien IP entre
les eNBs connectés.
Comme nous l’avons indiqué, les spécifications du LTE évoluent
continuellement et de nouvelles fonctionnalités sont ajoutées à chaque
nouvelle version. En particulier, le 3GPP a commencé à travailler sur
des fonctionnalités orientées "sécurité publique" à partir de la "Re-
lease 11". La Figure 49 regroupe les principaux travaux.
Cependant, malgré tous ces travaux, un certain nombre de fonction-
nalités d’importances pour les réseaux militaires et pour les réseaux
de sécurité publique ne sont pas traités. Ainsi, bien que le 3GPP
définisse un type d’eNB autonome (Isolated E-UTRAN) et les fonc-

Features Isolated E-UTRAN

22.346 22.897 23.797 23.798 33.897

Mission Critical Mission Critical

Services Services
24.481 24.482 24.483 22.280 23.280 23.780
24.484 33.180 33.880

Mission Critical Mission Critical Data

Push To Talk 22.282 22.880 23.282
22.179 23.179 23.379 24.282 24.582
24.379 24.380 24.980
26.179 26.879 26.989
33.179 33.879 Mission Critical Video
22.281 22.879 23.281
Group Communications 24.281 24.581 26.281
22.468 23.768 36.868
High Power UE
(band 14) Proximity-based Services
36.521 36.837 22.803 23.303 23.703 32.844 33.833

Release 11 Release 12 Release 13 Release 14

Figure 49 – Travaux du 3GPP orientés sécurité publique.

B.3 contraintes de conception et choix de la technologie d’accès radio 133

tions minimales qu’il doit remplir, les liaisons entre eNBs autonomes
ne sont pas spécifiées et ne sont pas possibles même si ceux-ci sont
en portée radio. Il s’agit pourtant d’une fonctionnalité nécessaire à
l’établissement d’un réseau autonome.

Ainsi, le LTE tel que spécifié permet de réaliser les topologies

présentées sur les Figures 50.(1), 50.(2) et 50.(3) mais ne permet pas de
réaliser ce qui est présenté en Figure 50.(4) qui correspond au réseau
autonome visé.

Pour réaliser les liaisons inter stations de base, nous choisissons

pourtant de nous appuyer sur le LTE. En effet, il existe plusieurs pos-
sibilités pour réaliser ces liaisons sans fil en l’absence d’accès à un
cœur de réseau commun. La première est d’utiliser une technologie
radio dédiée. Seulement, cela nécessite l’accès à une bande radio sup-
plémentaire pour ne pas perturber l’accès des UEs aux eNBs déployés,
et cela nécessite du matériel supplémentaire pour la gestion de cette
bande et cette technologie. Ces deux points vont à l’encontre des ob-
jectifs fixés pour le système qui doit permettre de n’utiliser qu’une
seule bande radio et un minimum d’équipement. Ainsi, utiliser le
LTE dans la même bande que celle utilisée pour réaliser les liaisons
eNB - UE est la solution qui permet de minimiser ces deux points.
Cela peut présenter aussi, à utilisation spectrale totale équivalente,
une flexibilité accrue dans la gestion du partage des ressources spec-
trales entre le réseau d’accès (eNB - UE) et le réseau backhaul (eNB -
eNB).

Ainsi, nous choisissons le LTE pour réaliser toutes les liaisons sans
fil du réseau autonome.

1 – Nominal architecture 2 – Relay Self Backhauling (two hops)

EPC EPC

eNodeB
UE
UE
UE eNodeB
eNodeB
UE
UE relay UE

4 – Envisionned LTE Mesh architecture

UE
e2NB
e2NB
UE eNodeB + UE
local EPC
functions UE e2NB
UE UE
UE UE
UE e2NB e2NB
3 – Isolated E-UTRAN

Figure 50 – Topologies réseaux réalisables à parti des spécifications LTE

(1,2,3) et réseau LTE visé (4).
134 résumé en français

b.4 architecture de station de base autonome

Nous avons conçu une nouvelle station de base en tenant compte

des exigences et fonctionnalités précédemment énoncées et permet-
tant de répondre aux cas d’utilisation visés en autorisant la création
de réseaux autonomes. Cette nouvelle station de base, que nous nom-
mons e2NB, s’appuie sur le LTE pour fournir un service d’accès ra-
dio sans fil à des UEs et pour interconnecter les différentes stations
de base entre elles. Pour cela, nous introduisons un nouvel élément,
l’UE virtuel (vUE). Ce vUE permet la création d’un réseau maillé de
station de base adjacentes sur une bande unique. Réaliser un réseau
maillé à bande unique reposant sur le LTE présente certains défis tels
le maintien du support des UEs Commercial Off-The-Shelf (COTS)
standards ; le fonctionnement autonome des stations de base et du
réseau via des fonctions d’auto-configuration et d’auto-organisation,
de gestion de ressources spectrales et temporelles ; la gestion de mo-
bilité des UEs ; le maintien d’un niveau de sécurité adéquat.

Coordination & Orchestration Entity Controller To other

networks
Applications & Services

e2NB
Coordination & Orchestration Entity Agent
Routing

eNB
Local EPC

HSS P-GW
vUE MME S-GW
NAS

IP RRC RRC IP
PDCP PDCP
RLC RLC
MAC MAC
PHY PHY

TX/RX Radio Chain

Uu/Un Uu/Un Uu

e2NB x vUE y UE z

Figure 51 – Architecture de l’e2NB.

L’architecture de l’e2NB est présentée sur la Figure 51. L’e2NB est
conçu, dans un premier temps, comme une station de base autonome.
Ainsi, il intègre les éléments suivants :
 B.4 architecture de station de base autonome 135

— Pile protocolaire de l’eNB classique;

— Chaîne radio Transmitter (TX) / Receiver (RX);
— LTE Mobility Management Entity (MME);
— LTE Home Subscriber Server (HSS);
— LTE Serving Gateway (S-GW);
— LTE Packet Data Network Gateway (P-GW);
— Un ensemble d’applications et de services (voix, donnée, vidéo,
etc.).
Ces éléments permettent à l’e2NB d’être une station de base au-
tonome capable de fournir un service local à des UEs.
De plus, l’e2NB intègre d’autres éléments pour réaliser le réseau
autonome :
— Piles protocolaires UE/Relay Node (RN) en mode service, rassem-
blée sous le concept de vUEs;
— Service de routage;
— Agent Coordination and Orchestration Entity (COE).
Les vUEs sont utilisés intuitivement pour établir les connexions avec
les e2NBs adjacents. L’agent COE agit comme un contrôleur local,
responsable de la gestion des routes, de la topologie du réseau en
accord avec les autres agents COE intégrés dans les autres e2NBs, de
la coordination de l’allocation des ressources.
L’eNB, le MME, le HSS, la S-GW et la P-GW fonctionnent de manière
similaire aux spécifications LTE classiques. La chaîne radio est con-
sidérée unique pour répondre aux contraintes les plus strictes, mais
l’e2NB peut bénéficier et utiliser des chaînes radio supplémentaires
si celles-ci sont disponibles. Les vUEs constituent la différence princi-
pale de l’e2NB avec un eNB classique. Ils sont utilisés intelligemment
pour réaliser les connexions inter-e2NB. Chaque vUE est géré par
l’agent COE auquel il rapporte en temps-réel des informations sur le
canal radio (puissance reçue, présence d’un nouveau nœud à proxim-
ité, etc.). Chaque vUE comprend la pile protocolaire complète d’un
UE classique qui lui permet de détecter et d’établir des communica-
tions avec un eNB. De plus, il comprend la pile protocole du relai
LTE (RN) qui permet le maillage sur une seule bande radio. Le ser-
vice de routage est géré par le COE et permet la transmission des
paquets IP à travers le réseau maillé. L’agent COE est construit selon
les principes de réseau logiciel (Software-Define Networking (SDN))
et est un contrôleur local responsable de la gestion de la configura-
tion de l’eNB. Il gère les connexions de l’e2NB avec d’autres e2NBs
via les vUEs et gère la topologie réseau induite. Il gère le cycle de
vie des vUEs de la création à la destruction, incluant la gestion des
clés de cryptographies pour les procédures de sécurité. L’agent COE
contrôle l’accès de l’eNB et des vUEs à la chaîne radio. Enfin, il se co-
ordonne avec les autres agents d’e2NBs auxquels il est connecté pour
permettre la gestion de ressource inter-couche sur tout le réseau.
 136 résumé en français

b.4.1 États de l’e2NB

Nous avons défini trois états principaux pour l’e2NB. Ceux-ci cor-
respondent aux différents états d’interconnexion possibles. Les tran-
sitions entre les états sont gérées par l’agent COE en fonction de
l’évolution de la topologie du réseau et des connexions avec d’autres
e2NBs.
Les différents états et les transitions possibles sont présentés Fig-
ure 52.
L’état Isolé (Isolated) correspond à l’état dans lequel l’e2NB n’est
connecté à aucun autre e2NB. Il gère ses UEs comme un eNB clas-
sique et maintient un vUE en fonction pour assurer les procédures
de détection d’autres e2NBs. L’état Maillé (Meshed) correspond à
l’état dans lequel l’e2NB est connecté à au moins un autre e2NB via
un ou des vUEs. Toutes les fonctions de l’e2NB sont activées. L’état
vUE relai correspond à un état dans lequel l’eNB de l’e2NB est arrêté.
L’e2NB peut prendre cet état sur décision du COE afin de réduire
les interférences si la couverture radio peut être assurée par d’autres
e2NBs.

b.4.2 Topologies réseaux possibles

Grâce à ces différents états et aux différentes fonctionnalités de

l’e2NB, plusieurs e2NBs peuvent former des topologies réseaux dif-
férentes. La Figure 53 présente différents exemples.

Relaying on a mesh
Serving local UEs

Connecting to Switching off

neighboring e2NB embedded eNB
e2NB
states Isolated Meshed vUE relay
(vUE,eNB) (vUEs,eNB) (vUEs)
No inter-e2NB Starting
connection left embedded eNB

COE Controller COE Controller COE Controller

Applications & Services Applications & Services Applications & Services
e2NB e2NB e2NB

Corresponding COE Agent COE Agent COE Agent

stack status Routing Routing Routing

and vUE eNB vUE eNB vUE

Local

Local
EPC

EPC

connections
TX/RX Radio Chain TX/RX Radio Chain TX/RX Radio Chain
Uu Uu/Un Uu Uu/Un

UE z e2NB x vUE y UE z e2NB x

Figure 52 – États principaux de l’e2NB.

 B.5 conception détaillée et procédures de l’e2nb 137

UE4
UE6

e2NB6 UE7
meshed e2NB7 e2NB8
meshed meshed
e2NB5
UE1 meshed
e2NB1 UE5
meshed UE8
e2NB4 e2NB9
meshed isolated

e2NB2 UE
vUE relay
vUE

eNB

UE2 Backhaul link

e2NB3 meshed UE3 Access link
UE9

Figure 53 – Exemples de topologies réseaux obtenues grâce aux e2NBs.

b.5 conception détaillée et procédures de l’e2nb

Dans le chapitre 5, nous détaillons la conception de l’e2NB et nous

concentrons plus particulièrement sur les aspects liés à la couche
physique, aux procédures de détection et de connexion ainsi qu’aux
états possibles de l’e2NB et aux transitions associées.
Nous avons annoncé que les e2NBs s’appuyaient sur les vUEs pour
s’interconnecter, et qu’ils utilisaient pour cela à la fois l’interface Uu et
l’interface Un. Nous expliquons en détails dans ce chapitre pourquoi
les vUEs ne peuvent pas se servir uniquement de l’interface Uu. En
effet, l’interface Uu a été conçue pour connecter les UEs classiques
aux eNBs. Cette interface possède un certain nombre de caractéris-
tiques et doit respecter certaines contraintes, en particulier au niveau
de l’eNB, tel que l’envoi périodique de signaux de référence et de con-
trôle, pour assurer une communication efficace et sans perturbation
longue avec les UEs connectés. Or, nous montrons dans le chapitre 5
et plus particulièrement dans la section 5.1 que ces contraintes du
côté de l’eNB empêchent la réalisation de liaisons inter-e2NB basées
uniquement sur l’interface Uu. Nous étudions ensuite l’interface Un
qui a été spécifiée par le 3GPP pour permettre l’émergence de re-
lais LTE. Nous montrons alors que cette interface peut être modi-
fiée légèrement pour être utilisée par les e2NBs afin de réaliser les
liaisons inter-nœuds. Nous expliquons aussi pourquoi une approche
dite "half-duplex" est plus pertinente dans les cas d’utilisation visés
qu’une approche basée sur le nouveau type de radio "full-duplex",
138 résumé en français

principalement à cause de la puissance maximale d’émission limitée

de ce type de radios.
Ensuite, nous détaillons les contraintes de synchronisation en temps
et en fréquence nécessaires au bon fonctionnement de l’interface Un
employée pour des liaisons multi-bonds ainsi que les limites de portée
inhérente à cette interface et nous proposons des méthodes pour s’en
affranchir. Nous discutons aussi du fonctionnement du mécanisme
Hybrid Automatic Repeat reQuest (HARQ) et proposons des modifi-
cations pour le rendre plus efficace lors de l’utilisation de l’interface
Un en contexte multi-bonds, que ce soit en mode FDD ou en mode
TDD. Nous présentons les paramètres importants relatifs à la couche
physique de l’eNB embarqué dans l’e2NB et qui doivent être efficace-
ment configurés pour maximiser les performances. Ensuite, nous dé-
taillons les procédures complémentaires nécessaires au niveau de la
gestion du partage de la chaîne radio entre l’eNB et les vUEs d’un
e2NB pour permettre la détection et la connexion des vUEs sur les
e2NBs en portée. En effet, l’e2NB utilise un vUE par chaîne radio
pour détecter les nœuds adjacents. Cependant celui-ci doit avoir accès
à la chaîne radio de manières continues pendant certaines périodes
de l’ordre d’une trame (de 10ms) et non uniquement durant une sous-
trame (Subframe (SF) de 1ms). Nous expliquons ainsi que nous pou-
vons exploiter certains paramétrages des UEs classiques pour fournir
une fenêtre d’écoute plus longue aux vUEs de détection. Nous abor-
dons aussi la détection assistée par les UEs.
Nous détaillons ensuite la procédure d’initialisation de l’e2NB qui
l’emmène vers un des trois états présentés précédemment suivant
l’environnement dans lequel il se trouve et le nombre d’e2NBs sur
lesquels il peut se connecter. Nous approfondissons ensuite les dia-
grammes de flux qui régissent les opérations de l’e2NB lorsqu’il se
trouve dans l’un des trois états (isolé, maillé, relai vUE).
Enfin, nous concluons ce chapitre en présentant les fonctionnalités
spécifiques que doivent opérer les différents éléments du cœur de
réseau embarqué dans l’e2NB pour permettre les entrées et sorties
d’e2NBs dans les topologies, la continuité de service fourni aux UEs,
la mobilité des UEs, afin d’obtenir le réseau autonome.

b.6 algorithmes d’ordonnancement

Dans le chapitre 6, nous présentons la problématique d’ordonnance-

ment qui se pose dans le réseau maillé à une seule bande radio et
nous proposons un algorithme de gestion des ressources radio au sein
du réseau, qui soit hiérarchique, inter-couches, et qui tienne compte
des interférences et de la qualité de service des flux.
En effet, les e2NBs se connectent les uns aux autres sur une seule
bande radio à l’aide de l’interface Un. Ils doivent donc se partager les
ressources temporelles et spectrales, à la manière d’un réseau maillé
 B.6 algorithmes d’ordonnancement 139

basée sur une interface Time Division Multiple Access (TDMA), de

façon intelligente afin de réduire les interférences subies. De nom-
breuses études s’attaquent aux problèmes d’allocations des ressources
dans les réseaux maillés. Cependant, le réseau que nous proposons
est spécifique dans son utilisation de l’Orthogonal Frequency Divi-
sion Multiple Access (OFDMA) qui permet un multiplexing et des
transmissions Point To Multi-Point (PTMP) sans interférences. Ainsi,
nous proposons un nouvel algorithme pour gérer les allocations de
ressources sur le réseau maillé et optimiser les transmissions inter-
e2NB.

b.6.1 Rôle du COE et approche hiérarchique proposée

Notre approche s’appuie deux composants principaux, les agents

COE intégrés dans chaque e2NB et un contrôleur COE. Celle-ci est
résumée sur la Figure 54.

Coordination & Orchestration Entity Controller

Routing Topology Management

COE Controller Scheduling Algorithm

Centralized Node Scheduler (CNS) Flow controller

Flow properties
SuperFrame Performance indicator (source/destination node,
TX/RX Routes and e2NB status datarate,
allocations latency requirements)

Local interference Local flow

Local routing
management management
Distributed Link Scheduler (DLS)
Coordination & Orchestration Entity Agent
Figure 54 – Architecture du COE (Coordination and Orchestration Entity).

Le contrôleur COE est unique sur une sous partie du réseau maillé
et est élu par les agents COE qui en font partie. Il est chargé d’agréger
les informations qui lui sont remontées par les agents COE, en par-
ticulier les caractéristiques des flux temps réel générés par les UEs
locaux (exigences de qualité de service, débit, etc.) ainsi que des indi-
cateurs de qualité de canal et d’interférence avec les nœuds adjacents.
Le contrôleur COE se charge alors, par le biais des algorithmes décrits
dans le chapitre 6 et en particulier du Controller Scheduling Algo-
rithm (CSA) (Algorithme 1), de déterminer pour chaque e2NB dont
il a la charge, sur quelles sous-trames cet e2NB pourra transmettre à
ses voisins et sur quelles sous-trames celui-ci devra se placer en mode
140 résumé en français

réception. Ces algorithmes tiennent compte de l’état des canaux ra-

dio entre les e2NBs, des interférences générées lors de la transmission
par un e2NB, des besoins en bande passante ou en latence des flux
prioritaires et des besoins en débit supplémentaires des liens saturés.
Si les éléments en possession du contrôleur COE ne lui permettent
pas de définir une allocation de ressource qui permette de satisfaire
les exigences de Quality of Service (QoS) des flux, il dispose d’une
entité de gestion des flux et peut décider de refuser l’établissement
d’un flux ou peut en terminer un autre, pour pouvoir déterminer une
nouvelle allocation. Ces allocations sont déterminées de manière péri-
odique de manière à limiter la surcharge de messages de contrôle. Le
contrôleur COE détermine aussi la topologie du réseau et transmet les
routes adéquates aux différents e2NBs.
Chaque e2NB, par le biais de son ordonnanceur interne, le Dis-
tributed Link Scheduler (DLS) (Algorithme 5), peut alors décider
pour chaque sous-trame qui lui est attribuée à quels e2NBs il trans-
mettra, qui constitue l’aspect hiérarchique de l’approche proposée où
chaque e2NB garde la gestion de l’ordonnancement au niveau des
SFs.
Les algorithmes proposés peuvent tirer bénéfice des caractéristiques
du mode FDD mais sont aussi conçus pour fonctionner en mode
TDD. De plus, nous proposons dans ce chapitre des pistes pour éten-
dre ces algorithmes aux Base Transceiver Stations (BTSs) disposant
d’antennes multiples ou de chaînes radio multiples.

b.7 expérimentations

Afin de valider la faisabilité du système de communication pro-

posé, nous menons plusieurs évaluations dans le chapitre 7.
La première évaluation consiste en une comparaison de l’interface
LTE relai Un et de l’interface LTE Uu d’un point de vue efficacité
spectrale et complexité calculatoire au travers d’une implémentation
sur la plateforme de radio logicielle OAI. Les résultats montrent une
efficacité spectrale légèrement inférieure pour l’interface Un à cause
du nombre réduits de Resource Elements (REs) utilisables par sous-
trame. La complexité, mesurée par le biais des temps de codage et
décodage des canaux de contrôle et de données des interfaces Uu et
Un, est similaire. Cela confirme la possibilité d’une implémentation
simple d’un e2NB.
Ensuite, nous implémentons l’approche d’ordonnancement hiérar-
chique dans un simulateur développé sur MatLab et nous simulons
plusieurs topologies de réseaux maillés avec 7 ou 19 e2NBs qui cha-
cun servent 10 UEs locaux. Nous appliquons ensuite des flux temps
réel (i.e., Voice over IP (VoIP)) entre les UEs et des flux élastiques
entre certains e2NBs. Nous comparons des versions simplifiées de
notre approche qui ne tiennent pas compte des besoins de QoS des
 B.8 conclusion 141

flux ou ne tirent pas profit des caractéristiques du mode FDD. Enfin,

nous testons le comportement en mode TDD et en mode FDD.
Les résultats obtenus montrent que l’algorithme complet que nous
proposons permet d’offrir le meilleur compromis entre respect des
contraintes de QoS des flux temps réel et maximisation des débits
des flux élastiques. Cependant, sur des topologies complexes avec un
nombre important d’e2NB, il n’est pas possible de satisfaire les flux
VoIP qui doivent faire le plus de bonds sur le réseau et cela dégrade
aussi le ressenti utilisateur sur les autres flux temps réel. L’entité
de contrôle et d’acceptation des flux temps réel montre ici son im-
portance, en permettant, par le rejet de ces flux, l’amélioration de
l’expérience utilisateur globale. Enfin, ces simulations permettent de
mettre au jour certaines limitations de l’approche qui sont discutés
en section 7.2.4. Nous proposons de plus des améliorations en sec-
tion 7.4.1.
Finalement, nous comparons la solution de maillage intra-bande
avec une solution de maillage par ajout de bande et montrons la
supériorité du maillage intra-bande à bande passante cumulée équiv-
alente grâce à une flexibilité accrue dans la gestion des ressources
pour l’accès et le backhaul.
Ces résultats confirment la potentialité et la pertinence du système
de communication proposé et incitent à poursuivre son développe-
ment.

b.8 conclusion

Dans cette thèse, nous proposons une nouvelle architecture de sta-

tion de base qui évolue la station de base LTE en autorisant la création
de nouvelles topologies permettant de répondre aux cas d’utilisation
des autorités militaires et de sécurité publique.
À partir d’une revue des situations opérationnelles rencontrées par
les entités militaires, navales et de sécurité publique, nous avons iden-
tifié les lacunes des solutions techniques actuelles, montrant qu’elles
ne sont pas adaptées à des scénarios de cellules en mouvement. Con-
statant le manque de réponses pour permettre la création de réseaux
sans fil maillés et autonomes dans des environnements contraints,
nous avons d’abord défini les exigences fonctionnelles d’une telle so-
lution, que nous avons ensuite étendues en fonction des contraintes
externes auxquelles font faces les autorités militaires et de sécurité
publique tel que l’accès limité au spectre radioélectrique. Nous avons
ensuite sélectionné le LTE comme technologie d’accès radio unique
pour fournir le service aux UEs locaux mobiles et la connectivité en-
tre stations de base. Ensuite, nous avons détaillé les défis d’utiliser le
LTE pour la connectivité sans fil de backhaul et d’accès, tels que les
problèmes d’ordonnancement dans un réseau maillé et le maintien
de la compatibilité avec les UEs COTS.
142 résumé en français

Pour répondre aux cas d’utilisation considérés en tenant compte

des exigences et des contraintes externes, nous avons proposé une
nouvelle architecture de station de base qui permet la création de
réseaux maillés autonomes : l’e2NB. L’e2NB évolue l’eNB LTE grâce
à l’introduction du vUE qui permet le maillage intra-bande. L’intégra-
tion de fonctions de cœur de réseau et l’hébergement de services au
sein de l’e2NB lui confère son autonomie et permet de servir des UEs
classiques en tout situation. De plus, en tirant parti des interfaces
Uu et Un, les vUEs peuvent, en s’appuyant sur des procédures spéci-
fiques et sur la gestion des ressources opérée par le COE, détecter et
se connecter aux e2NBs adjacents pour former un réseau maillé sans
fil utilisant une seule bande LTE.
Traitant des problèmes de la couche physique en profondeur, nous
avons justifié le choix du backhaul intra-bande half-duplex. Nous
avons ensuite détaillé les fonctions et procédures permettant la dé-
tection et l’initialisation de la connexion aux e2NBs adjacents ainsi
que les principaux états régissant le comportement de l’e2NB. Pour
répondre spécifiquement au problème de l’allocation dynamique des
ressources, nous avons proposé une méthode d’ordonnancement des
ressources hiérarchique et inter-couches pour répondre efficacement
aux exigences de qualité de service pour le trafic en temps réel tout en
maximisant le débit pour les flux élastiques sur le réseau maillé. Cette
architecture complète permet au réseau conçu et d’être autonome et
rejoint les objectifs initiaux grâce aux fonctionnalités de configuration,
d’organisation et de réparation automatique.
Nous avons effectué plusieurs expérimentations pour évaluer le
comportement et la performance de la solution proposée. Première-
ment, nous avons évalué la couche physique proposée pour le mail-
lage du réseau, qui repose sur l’interface Un par émulation du lien
physique sur la plate-forme OAI. Deuxièmement, en utilisant des
simulations de réseaux maillés réalistes, nous avons évalué notre ap-
proche d’ordonnancement sur plusieurs topologies de réseau maillé
avec différents trafics. Nous avons montré l’efficacité de la couche
physique de l’interface Un d’un point de vue efficacité spectrale et
calculatoire grâce aux émulations OAI. Nous avons aussi démontré
l’efficacité de la méthode d’ordonnancement hiérarchique proposée
pour assurer les exigences de qualité de service tout en maximisant
le débit des flux élastiques.

b.8.1 Perspectives et travaux futurs

A la fin de cette étude, nous avons montré que le2NB est un bon
candidat à répondre aux cas d’utilisation considérés qui n’étaient
pas encore couverts par les systèmes actuels de communication sans
fil militaires et pour la sécurité publique. Particulièrement, nous
avons détaillé de nombreux points de conception et procédures qui
 B.8 conclusion 143

sont nécessaires à l’e2NB pour réaliser le réseau maillé LTE sur une
bande. Nous avons évalué la couche physique en émulation ainsi que
l’approche d’ordonnancement proposée par des simulations.
Pour mieux identifier l’applicabilité de l’architecture de réseau pro-
posée et de l’e2NB dans des déploiements réels, l’e2NB devrait être
implémenté dans un vrai prototype radiofréquence. Plusieurs étapes
sont nécessaires pour développer un prototype fonctionnel. Première-
ment, alors que nous avons conçu la plupart des fonctionnalités requi-
ses par l’e2NB, seulement une partie d’entre elles ont été mises en œu-
vre et expérimentées. Concernant la couche physique, la synchronisa-
tion et les procédures doivent être appliquées. De plus, l’efficacité des
mesures de canaux réalisées par les vUEs doit être évaluée compte
tenu de la possibilité pour les intervalles de mesure d’être beaucoup
plus petites et moins fréquentes que celles d’un UE classique. L’impact
des modifications proposées concernant l’HARQ pour le mode TDD
doit être évalué. Enfin, bien que les modifications matérielles de la
chaîne radio devraient être très limitées, ne nécessitant a priori qu’un
temps de commutation TX/RX plus court que sur la chaîne radio
d’un eNB, il est nécessaire de les évaluer minutieusement. Concer-
nant les couches supérieures, nous avons défini le contenu des mes-
sages qui devrait être échangés entre e2NBs pour permettre les com-
munications entre COEs mais nous n’avons pas spécifié de protocole
pour ces échanges de messages. Ainsi, les protocoles d’échange de
messages entre agents COE doivent être conçus ainsi que le proces-
sus d’élection du contrôleur COE. De plus, comme nous l’avons vu
au chapitre 7, les algorithmes de contrôle de flux sont nécessaires
pour assurer un comportement efficace et des hautes performances
du réseau maillé lorsqu’il y a un nombre élevé de nœuds ou un nom-
bre élevé de flux en temps réel. Ainsi, l’efficacité des politiques de
contrôle des flux devraient être évaluées. Finalement, les exigences
sur les éléments du cœur de réseau et sur la couche supérieure de
services pour permettre la séparation et la fusion transparente des
réseaux maillés ont seulement été décrites à haut niveau et devraient
être étudiés dans les détails. Tandis que les modifications sur le cœur
de réseau ne devraient pas être majeures, les exigences de sécurité
spécifique aux autorités militaires et de sécurité publiques n’ont pas
été évaluées et pourrait avoir un impact plus important.
L’approche proposée n’est pas définitive et pourrait subir quelques
évolutions. Par exemple, des extensions de l’approche pour le fonc-
tionnement avec les stations de base multi-sectorielles ont été pro-
posées au chapitre 6, mais leur efficacité devrait être évaluée. De
même, les techniques de formation de faisceaux sont connues pour
améliorer fortement les performances dans les réseaux maillés. Cepen-
dant, l’intégration efficace de cette fonctionnalité dans les algorithmes
d’ordonnancement n’est pas simple et nécessiterait plus d’études. Bien
que nous visions une solution fonctionnant avec un minimum de
144 résumé en français

ressources fréquentielles, les procédures pourraient être améliorées

pour tenir compte des capacités de Carrier Aggregation (CA). En
particulier, l’utilisation de Multefire [77] pourrait également être en-
visagée pour améliorer les performances de la solution. Enfin, nous
pouvons observer que l’architecture de l’e2NB s’aligne assez bien avec
les procédés actuels d’implémentation logicielle des fonctions réseaux
(utilisation de Virtual Network Function (VNF) et de Network Func-
tions Virtualization (NFV)) du Radio Access Network (RAN) car il
repose sur l’utilisation des vUEs orchestrés par le COE de manière
flexible. De plus, le contrôleur COE et les agents COE pourraient être
considérés comme des éléments faisant partie d’une approche SDN.
Cependant, l’applicabilité d’approches génériques VNF/NFV et SDN
devrait être évaluée car l’e2NB dépend fortement d’interactions inter-
couches. Enfin, bien que nous soyons confiants sur la possibilité
d’adapter la solution proposée pour une utilisation avec les futurs sys-
tèmes de communication cellulaire, la compatibilité avec la nouvelle
radio 5G (5G New Radio (5G NR)) et la numérologie multiple asso-
ciée devrait être évaluée afin de déterminer les modifications néces-
saires.
B.8 conclusion 145
ACRONYMS
C
3GPP 3rd Generation Partnership Project.
5G NR 5G New Radio.

ACK Acknowledgment.
ADC Analog-to-Digital Converter.
AFR Average Frequency Reuse.
AMC Adaptive Modulation and Coding.
ANR Automatic Neighbour Relation.
ARQ Automatic Repeat reQuest.

BS Base Station.
BTS Base Transceiver Station.

C4I Command, Control, Communications, Computers,

and Intelligence.
CA Carrier Aggregation.
CAPEX Capital expenditure.
CDF Cumulative Distribution Function.
CFI Control Format Indicator.
CFO Carrier Frequency Offset.
CN Core Network.
CNS Centralized Node Scheduler.
COE Coordination and Orchestration Entity.
COTS Commercial Off-The-Shelf.
CQI Channel Quality Indicator.
CRC Cyclic Redundancy Check.
CRS Cell-Specific Reference Signals.
CSA Controller Scheduling Algorithm.
CSMA/CA Carrier Sense Multiple Access with Collision
Avoidance.

D2D Device-to-Device.
DCI Downlink Control Information.

147
148 Acronyms

DeNB Donor evolved Node B.

DL Downlink.
DLS Distributed Link Scheduler.
DLSS Downlink StartSymbol.
DMR Digital Mobile Radio.
DMRS Demodulation Reference Signal.

e2NB enhanced evolved Node B.

ECGI E-UTRAN Cell Global Identifier.
ECI E-UTRAN Cell Identifier.
EHF Extremely High Frequency.
eICIC enhanced Inter Cell Interference Coordination.
eMBMS evolved Multimedia Broadcast Multicast Service.
EMHS Emergency Medical and Health Services.
eNB evolved Node B.
EPA Extended Pedestrian model A.
EPC Evolved Packet Core.
EPS Evolved Packet System.
ESI End Symbol Index.
E-UTRAN Evolved Universal Terrestrial Radio Access Net-
work.

FD Full Duplex.
FDD Frequency Division Duplexing.
FeICIC Further enhanced Inter Cell Interference Coordina-
tion.
FirstNet First Responder Network Authority.

GPRS General Packet Radio Service.

GPS Global Positioning System.
GPSDO Global Positioning System Disciplined Oscillator.
GSM Global System for Mobile communications.
GTP GPRS Tunneling Protocol.

HARQ Hybrid Automatic Repeat reQuest.

HD Half Duplex.
HSS Home Subscriber Server.

IMEI International Mobile Equipment Identity.

 Acronyms 149

IMS IP Multimedia Subsystem.

IMSI International Mobile Subscriber Identity.
IOPS Isolated E-UTRAN Operation for Public Safety.
IP Internet Protocol.
ISM Industrial, Scientific, and Medical.
ITS Intelligent Transportation System.
ITU International Telecommunication Union.

kbps kilobit per second.

LAA Licensed Assisted Access.

LOS Line of Sight.
LTE Long Term Evolution.
LTE-A LTE Advanced.

MAC Medium Access Control.

MBSFN Multicast Broadcast Single Frequency Network.
MCPTT Mission Critical Push-To-Talk.
MCS Modulation and Coding Scheme.
MIB Master Information Block.
MIMO Multi Input Multi Output.
MME Mobility Management Entity.
MOS Mean Opinion Score.
MSISDN Mobile Subscriber Integrated Services Digital Net-
work Number.

NACK Non-acknowledgment.
NATO North Atlantic Treaty Organization.
NDI New Data Indicator.
NeNodeB Nomadic eNodeB.
NFV Network Functions Virtualization.
NN Nokia Networks.
nrt Neighbour Relation Table.

OAI Open Air Interface.

OFDM Orthogonal Frequency Division Multiplexing.
OFDMA Orthogonal Frequency Division Multiple Access.
OPEX Operating expense.
150 Acronyms

P25 Project 25.

PAPR Peak to Average Power Ratio.
PCFICH Physical Control Format Indicator Channel.
PCI Physical Cell Identity.
PCRF Policy and Charging Rules Function.
PDCCH Physical Downlink Control Channel.
PDSCH Physical Downlink Shared Channel.
PEP Performance-Enhancing Proxy.
P-GW Packet Data Network Gateway.
PHICH Physical Hybrid-ARQ Indicator Channel.
PHY Physical.
PLMN Public Land Mobile Network.
PMR Professional Mobile Radio.
ppb parts-per-billion.
ppm parts-per-million.
PRACH Physical Random Access Channel.
PRB Physical Resource Block.
ProSe Proximity Services.
PS Public Safety.
PSS Primary Synchronization Signal.
PTMP Point To Multi-Point.
PTP Point To Point.
PTT Push-To-Talk.
PUCCH Physical Uplink Control Channel.
PUSCH Physical Uplink Shared Channel.

QoS Quality of Service.

RA Random Access.
RACH Random Access Channel.
RAN Radio Access Network.
RAT Radio Access Technology.
RB Resource Block.
RBP Resource Block Pair.
RE Resource Element.
RF Radio Frequency.
RIFAN 2 Réseau Intranet des Forces Aéro-Navales 2.
 Acronyms 151

RN Relay Node.
ROHC Robust Header Compression.
R-PDCCH Relay Physical Downlink Control Channel.
R-PDSCH Relay Physical Downlink Shared Channel.
RRC Radio Resource Control.
RSRP Reference Signal Received Power.
RX Receiver.

SC-FDMA Single Carrier Frequency division Multiple Access.

SCTP Stream Control Transmission Protocol.
SDN Software-Define Networking.
SF Subframe.
S-GW Serving Gateway.
SIB System Information Block.
SINR Signal to Interference and Noise Ratio.
SISO Single Input Single Output.
SNR SubNetwork Relay.
SON Self Organizing Network.
SRS Sounding Reference Signal.
SS Subscriber Station.
SSS Secondary Synchronization Signal.
SuF SuperFrame.

TAI Tracking Area Identity.

TAU Tracking Area Update.
TB Transport Block.
TBS Transport Block Size.
TDD Time Division Duplexing.
TDM Time Division Multiplexing.
TDMA Time Division Multiple Access.
TETRA Terrestrial Trunked Radio.
TM Transmission Mode.
TR Technical Report.
TS Technical Specification.
TTI Transmission Time Interval.
TX Transmitter.

UAV Unmanned Aerial Vehicle.

152 Acronyms

UDP User Datagram Protocol.

UE User Equipment.
UHF Ultra High Frequency.
UIT Union Internationale des Télécommunications.
UL Uplink.
UMTS Universal Mobile Telecommunication System.
U.S. United States.
USA United States of America.
USIM Universal Subscriber Identity Module.
USV Unmanned Surface Vehicle.
Uu User to UTRAN.

VLF Very Low Frequency.

VNF Virtual Network Function.
VoIP Voice over IP.
VRB Virtual Resource Block.
VTT VTT Technical Research Centre of Finland.
vUE Virtual UE.

WiMAX Worldwide Interoperability for Microwave Access.