A B S T R A C T

Performance of military communication systems is nowadays improving slowly compared to commercial systems which puts interests 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 public 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 equipment 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 functional requirements for future wireless communication systems to allow new services and coverage of these use cases. We further underline the specific constraints applying to these communication systems due their specific environment of use, especially limited availability 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. Underlining 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 resource 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 reliability of our proposed architecture, we implement the corresponding self-backhauling air interface based on Open Air Interface (OAI) platform and compare with the legacy LTE air-interface. We then evaluate the efficiency and adaptability of our proposed resource scheduling iii 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 É S U M É

Comparées à celles de systèmes de communications civils, les performances 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 parallèle, les systèmes de communications pour les réseaux de sécurité publique sont en train d'évoluer suite à l'émergence de la technologie Long Term Evolution (LTE) comme une solution fiable et mature 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 opportunistes nécessite des modifications afin de permettre le fonctionnement 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 organisations 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 systè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 apportant 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 particulier 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ésentons 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 (e2NB). Nous détaillons ensuite les composants de cette architecture et de cette station de base pour répondre aux multiples défis identifiés. Plus particulièrement, nous évaluons le besoin de coordination entre stations de base et nous proposons un algorithme d'ordonnancement 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 proposée, nous implémentons l'interface sans fil inter stations de base sur la plateforme de radio logicielle OpenAirInterface et la comparons 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.

A C K N O W L E D G M E N T S

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 people in Naval Group I had the chance to work with. I, of course, thank my PhD advisor, Navid Nikaein, first for accepting 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 taking 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: Laurent Gallo, Konstantinos Alexandris, Jingjing Zhang, Chia-Yu Chang, Irfan Khan, Paolo Viotti, Pierre-Antoine Vervier, Xiwen Jiang, Qianrui 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 supporting me in my life, and in that maybe not so crazy idea this was! Overview of military and naval communications Figure 2 Network topologies -scenarios 1, 2 and 3. . . . Figure 3 Network topologies -scenarios 4, 5 and 6. . . . Figure 4 Network topologies -scenarios 7 and 8. . . . . Figure 5 Network topologies -scenarios 9, 10, 11 and 12. Figure 6 Evolution of cellular system standards. . . . . Figure 7 LTE nominal architecture (Release 8). . . . . . Figure 8 3GPP PS oriented work items. . . . . . . . . . . Figure 9 Topologies based on standard LTE BTS (1,2,3) and the envisioned LTE network (4). . . . . . . Figure 10 e2NB stack. . . . . . . . . . . . . . . . . . . . . . Figure 11 Main e2NB states. . . . . . . . . . . . . . . . . . Figure 12 Example of different network topologies based on e2NBs. . . . . . . . . . . . . . . . . . . . . . . Figure 13 LTE resource grid for a 1.4MHz (6 PRBs) channel width. . . . . . . . . . . . . . . . . . . . . . . Figure 14 Symbol allocation in a SF for Uu and Un interfaces. . . . . . . . . . . . . . . . . . . . . . . . . Figure 15 Resource allocation example of DL at DeNB/RN. Figure 16 Non-synchronized e2NB transportation. . . . . Figure 17 Connection procedure. . . . . . . . . . . . . . . Figure 18 Startup phase operation flow. . . . . . . . . . . Figure 19 Isolated state operation flow. . . . . . . . . . . Figure 20 Meshed state operation flow. . . . . . . . . . . Figure 21 vUE relay state operation flow. . . . . . . . . . Figure 22 Coordination and Orchestration Entity architecture. . . . . . . . . . . . . . . . . . . . . . . . Figure 23 R-PDCCH and PDCCH computational time. . Figure 24 TX/RX time for PDCCH/PDSCH and R-PDCCH/R-PDSCH. . . . . . . . . . . . . . . . . . . . . . . . Figure 25 Minimum SNR level to decode 75% of the TBs. Figure 26 Minimum SNR level for several aggregation levels. . . . . . . . . . . . . . . . . . . . . . . . . Figure 27 Considered network topologies. . . . . . . . . . Figure 28 Hexagonal topology with 7 e2NBs and 70 UEs using 10MHz in FDD mode. . . . . . . . . . . . Figure 29 Hexagonal topology with 7 e2NBs and 70 UEs using 10MHz in TDD mode. . . . . . . . . . . . Figure 30 Hexagonal topology with 7 e2NBs and 70 UEs using 10MHz in TDD mode or 5MHz in FDD mode. . . . . . . . . . . . . . . . . . . . . . . . .

Line topology with 7 e2NBs and 70 UEs using 5MHz in FDD mode. . . . . . . . . . . . . . . . Figure 32 Line topology with 7 e2NBs and 70 UEs using 10MHz in TDD mode. . . . . . . . . . . . . . . Figure 33 Line topology with 7 e2NBs and 70 UEs using 10MHz in TDD mode or 5MHz in FDD mode. Figure 34 Hexagonal topology with 19 e2NBs and 190 UEs using 5MHz in FDD mode. . . . . . . . . . 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. . . . . . . . . . . . . . . . . . . . . . Figure 36 Hexagonal topology with 19 e2NBs and 190 UEs using 10MHz in FDD mode. . . . . . . . . Figure 37 Hexagonal topology with 19 e2NBs and 190 UEs using 10MHz in TDD mode. . . . . . . . . Figure 38 Network topology for in/out-band comparison. Figure 39 Data rate of traffic flow of in/out-band deployments. . . . . . . . . . . . . . . . . . . . . . . . . Figure 40 Cumulated data rate of two traffic flows. . . . Figure 41 Hexagonal topology with 7 e2NBs and 70 UEs using a 10MHz FDD configuration. . . . . . . . Figure 42 Hexagonal topology with 7 e2NBs and 70 UEs using a 10MHz TDD configuration. . . . . . . . Figure 43 Hexagonal topology with 7 e2NBs and 70 UEs using a 10MHz TDD and a 5MHz FDD configuration. . . . . . . . . . . . . . . . . . . . . . . . Figure 44 Line topology with 7 e2NBs and 70 UEs using a 5MHz FDD configuration. . . . . . . . . . . . Figure 45 Line topology with 7 e2NBs and 70 UEs using a 10MHz TDD configuration. . . . . . . . . . . Figure 46 Line topology with 7 e2NBs and 70 UEs using a 10MHz TDD or a 5MHz FDD configuration. Figure 47 Aperçu des communications sans fil militaires et navales . . . . . . . . . . . . . . . . . . . . . . Figure 48 Architecture nominale du LTE (Release 8). . . Figure 49 Travaux du 3GPP orientés sécurité publique. . Figure 50 Topologies réseaux réalisables à parti des spécifications LTE (1,2,3) et réseau LTE visé (4). . . Figure 51 Architecture de l'e2NB. . . . . . . . . . . . . . . Figure 52 États principaux de l'e2NB. . . . . . . . . . . . Figure 53 Exemples de topologies réseaux obtenues grâce aux e2NBs. . . . . . . . . . . . . . . . . . . . . . Figure 54 Architecture du COE (Coordination and Orchestration Entity). . . . . . . . . . . . . . . . .

L I S T O F TA B L E S

I N T R O D U C T I O N
Wireless communications have never been so widely used by humans. 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 expectations of end users.

In such a crowded landscape, Long Term Evolution (LTE) is becoming the technology reference for 4G cellular networks, as it is increasingly adopted by all major operators all over the world. Currently, 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, diversespectrum 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 Intelligent 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.

motivations

In the United States of America (USA), LTE has been chosen up as the next appropriate communication technology to support PS communications and it is likely to be the same in Europe. Moreover, several vendors (e.g. Ericsson, Nokia, Huawei, Cisco) are now starting 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 missioncritical voice communications, their designs cannot meet the new requirements and the shift to higher bandwidth applications. In addition, 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 reliability, confidentiality, security, group and Device-to-Device (D2D) communications. Therefore, the raising question is whether LTE suffices to be an appropriate solution for PS networks. To address those issues, 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-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 availability 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 connectivity (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 communication landscape. However, this has changed. Indeed, the digital revolution has been relying on communication systems and has greatly increase the involvement of private companies to provide reliable 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 communication 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.

contributions

To the best of our knowledge, there have not been extensive research and contributions to extend the LTE connectivity to more than two wireless hops from a base station that has access to the CN without 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 requirements 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 targeting in our study by reviewing the operational situations encountered by military, navy and PS entities. We show the limitations of their current wireless communication systems. Then, we present the network topologies common to PS, military and other entities that arise in their respective use cases. In light of the previously mentioned limitations, 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 environments. We conclude this first chapter by drawing the functional requirements of a potential solution based on this target. Three contributions have enlighten these problems:

-R. Favraud In the second chapter, we start from these requirements that we extend with the external constraints applying to communication systems for PS and military use, such as limitations in available frequency resources. We then select LTE as the Radio Access Technology (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 Vehicular 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 enhanced evolved Node B (e2NB). We present the e2NB building blocks, such as the eNB and CN components as well as the newly defined virtual UEs (vUEs) enabling the self-backhauling. We then present the 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 procedures 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 before 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 orchestration functionality within the proposed architecture. As we are targeting an applicable solution with constrained resources suitable for both Frequency Division Duplexing (FDD) and Time Division Duplexing (TDD) operation, we propose a cross layer hierarchical resource 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 contributions:

-R. Favraud, N. Nikaein 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 airinterface on both computing requirements and spectral efficiency. We then evaluate the efficiency and adaptability of our proposed hierarchical 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 concerning real-field deployments and we conclude this study drawing the required steps to push the proposed solution forward to a functional Radio Frequency (RF) wireless communication system.

In this chapter, we introduce the specific use cases that we are targeting 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 systems. We present the common network topologies that can arise for both military and PS communication systems depending on the operational 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 considered use cases and we review the associated external constraints.

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.

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, Military authorities rely on Command, Control, Communications, Computers, and Intelligence (C4I) to effectively address their missions. Communications for the military forces are very strategic for controlling and information sharing in real time among different forces to enable fast reaction to an event, as General Dempsey explains: "Information 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 marine forces have to communicate to several entities that can be close or very far away: civil surface ships; military surface ships and submarines; airplanes; UAVs and Unmanned Surface Vehicles (USVs); operational centers at land, etc. Figure 1 provides an overview of some communication needs of military and Naval Forces. 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 communications from close to far entities. However, communication systems for military and navies are not evolving as fast as civilian communication 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 visibility are currently not able to meet the increasing needs of navies regarding data-rate and latency. Indeed, currently deployed communication 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 system [START_REF]Rifan 2 : un nouveau système de transmission pour les forces aéronavales. État-major des armées[END_REF] while North Atlantic Treaty Organization (NATO) navies can cooperate using the UHF SubNetwork Relay (SNR) system [START_REF]SubNet Relay (SNR) brochure[END_REF]. Performance 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 maintenance is highly appreciated by the sailors. However, there is a need 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 flexible 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 various needs: dedicated radios with limited interoperability are often used and WiFi is being experimented for opportunistic links [START_REF]DCNS expérimente au large de Toulon un drone de surface[END_REF].

Last but not least, there is currently no wireless high data rate communication 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 -Easy or ideally automatic set-up, use and maintenance -Low Capital expenditure (CAPEX) and Operating expense (OPEX)

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" [START_REF]Public Safety Statement of Requirements for Communications and Interoperability[END_REF]. 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 communication -Inter-agency interoperability -Security -Support to new data applications

The second volume of the U.S. department of Homeland Security PS statement of requirements "provides specific performance requirements and metrics to ensure a quality of service level that is satisfactory or higher for the applications and services identified in [the first] volume" [START_REF]Public Safety Statement of Requirements for Communications and Interoperability[END_REF]. Specifically, it defines technical requirements for:

- The survey from Baldini et Al. [START_REF] Baldini | Survey of Wireless Communication Technologies for Public Safety[END_REF] provides a complete overview of the PS environment by surveying the use cases, the current state of wireless communication technologies and the current regulatory, standardization and research activities related to PS communications. Contrary to military communications, most PS communications relies on fixed infrastructures and cellular networks as they operate on friendly territory and on short to medium ranges. However, PS missions can take place in several different environments which affect network availability and network topologies: in urban or suburban areas 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 obstacles 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 [START_REF] Baldini | Survey of Wireless Communication Technologies for Public Safety[END_REF] 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) [START_REF] Tia | Project 25 System and Standards Definition[END_REF], TETRA [START_REF]Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 1: General network design[END_REF] or TETRAPOL (Europe) for the wireless access. 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 highbandwidth applications like real-time video streaming or exchanges of large amounts of data [START_REF] Gomez | Enabling disaster-resilient 4G mobile communication networks[END_REF]. 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 [START_REF] Baldini | Survey of Wireless Communication Technologies for Public Safety[END_REF]. Moreover, there fixed deployment designs cannot sustain major outage such as large natural disaster in a rural area due to the centralized architecture.

network topologies

In this section, we present the scenarios and common network topologies that can arise for both military and PS communication systems depending on the operational situation. Moreover, this topologies also correspond to some moving cell scenarios that can appear for instance in ITS and UAV use cases [START_REF] Settapong | Ad Hoc Lte Networks For Small-Scale Uav Applications[END_REF].

Scenarios

Normally, a nation-wide wireless PS network relies on a wired network supporting fixed BTSs providing planned coverage and bringing services to mobile entities (e.g., hand-held UEs or vehicle inte- grated devices) that requires a seamless access to the CN. Such a deployed network can support a variety of use cases; however, stringent requirements shall be considered when utilizing it for PS communications, namely robustness, reliability, and non-prone to malfunctions and outages [START_REF] Câmara | Wireless Public Safety Networks 2: A Systematic Approach[END_REF]. 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 responders still need efficient PS communications in all circumstances even in harsh environments that require some large area opportunistic 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 [START_REF] Câmara | Wireless Public Safety Networks 2: A Systematic Approach[END_REF]. 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 CN that allows to provide services with no intermissions to incoverage UEs (e.g., continuous link connectivity with operation center, monitoring, billing) [START_REF] Balachandran | Mobile responder communication networks for public safety[END_REF]. 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 [START_REF]Study on LTE device to device proximity services; Radio aspects[END_REF] with nearby users.

-BTS-to-CN connectivity: When the backhaul link (i.e., links between BTS and CN) disruption or failure happens, the CN may not be fully accessible from BTSs. If it can only provide some control plane functionalities, i.e., BTSs can still accept PS UEs connections but need additional mechanisms to provide data transportations (e.g., local routing [START_REF]Feasibility study for Proximity Services (ProSe)[END_REF]), it is referred as limited BTS-to-CN connectivity (scenarios 2 and 3). Otherwise, it is referred as unavailable 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 connectivity. For instance, a full connectivity between BTSs (scenarios 2 and 4) can allow to form a large network even with limited BTSto-CN connectivity.1 Note that the limited BTS-to-BTS connectivity (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 being on land or at sea [START_REF] Yutao Sui | Moving cells: a promising solution to boost performance for vehicular users[END_REF][START_REF] Favraud | Wireless mesh backhauling for LTE/LTE-A networks[END_REF]). In such cases, it is difficult to maintain 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 dynamically and it shall be maintained properly to provide the widest service area to covered UEs. Furthermore, the interference between 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 nonidealities of classical cellular networks.

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 usually 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 directly between ships to maintain the necessary operational awareness which may require large data file transfers. There are usually not many mobile UEs around ships but some may require high bandwidth 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 communications 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 characteristics in Table 3.

Scenario

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 underlined in Baldini et Al. [START_REF] Baldini | Survey of Wireless Communication Technologies for Public Safety[END_REF] study and in section 2.1.2, most PS communication 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 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 system to cover the network centric scenarios (ranging from 1 to 11 in Table 2) that would provide better performance than current systems presented in section 2.1.1 and 2.1.2. Such a system would allow 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 autonomous 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 vehicular, ITS, drone networks, UAV communications, etc. [START_REF] Settapong | Ad Hoc Lte Networks For Small-Scale Uav Applications[END_REF][START_REF] Yutao Sui | Moving cells: a promising solution to boost performance for vehicular users[END_REF].

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: (c) A set of services/applications to allow for the minimum required 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 situations regardless of the mobility of nodes. Moreover, it should not rely on any entity external of the network to provide its services. Creation of an autonomous network is an enabler of several use cases in military communications such as ship-to-ship communications presented in section 2.1.1. Thus, some additional elements and functions are listed on top of the autonomous node requirements: (d) A wireless communication interface to establish inter-BTS connections;

(e) Neighboring BTSs detection and connection mechanisms to enable 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 traffic 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 operate the envisioned autonomous network that provides the required services with sufficient quality for PS and military users.

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 discuss 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.

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 constraints when deploying the solution. These constraints are external to the aforementioned scenarios but are essential to enable the solution 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 [START_REF] Fantacci | Public safety networks evolution toward broadband: sharing infrastructures and spectrum with commercial systems[END_REF]. 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 narrow 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 utilized freely but suffer from power limitation and high interference. Furthermore, in some use cases such as military operations, new wireless 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 surface 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 requirement in section 2.3.1. Moreover, its cost shall be minimized in terms of required hardware resource. Lastly, it shall be capable of dealing 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.

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 [START_REF] Baldini | Survey of Wireless Communication Technologies for Public Safety[END_REF] compares the following communication 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) / General Packet Radio Service (GPRS)/ Universal Mobile Telecommunication System (UMTS) / 3G; LTE; Satellite Networks; WiFi / Worldwide Interoperability for Microwave Access (WiMAX); Ad-hoc Networks; Marine Communications; Avionics Communications. In their conclusion, 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. [START_REF] Ferrus | LTE: the technology driver for future public safety communications[END_REF] come to the same conclusion, noting that LTE has reached the required maturity level and wide adoption to replace the previous PS communication systems. 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 [START_REF] Favraud | Toward moving public safety networks[END_REF]. 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 military mobile users.

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 Network (RAN) part of the EPS, called the E-UTRAN that corresponds to the deployed BTSs [START_REF] Nohrborg | LTE. 3GPP[END_REF]. The EPS, that we will call LTE hereinafter, is the new terrestrial cellular network specificied by the 3GPP to replace 2G and 3G cellular systems as shown on Figure 6. 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 [START_REF] Nohrborg | LTE. 3GPP[END_REF]:

IS-95A CDMA IS-95C cdma2000 E-GPRS EDGE W-
-Provide higher data rates and better quality of service than previous 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

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 interface. 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 interfaces 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 wireless technology that would provide an IP connectivity given some minimum latency and/or data rate requirements. The eNBs are connected 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 existing IP connectivity through Stream Control Transmission Protocol (SCTP) and GPRS Tunneling Protocol (GTP) tunnels established between 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 manage the control and user planes of UEs to provide end-to-end com- in 3GPP Release 11 along with the introduction of high power devices 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 provided to the covered UEs. However, this feature prevents UEs from a seamless communication service when an eNB is getting disconnected of the EPC. Thus, eNB service to the UEs is interrupted even for local communications which is essentially required by first responders. To tackle the aforementioned shortcoming, 3GPP has launched two series of work items: the first one refers to device-to-device communications for enabling ProSe, and the second one refers to the continuity 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, Isolated E-UTRAN aims at the restoration of the service of one eNB or a set of connected eNBs without addressing their backhaul connectivity. 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, "limited bandwidth signalling only backhaul" case and "limited bandwidth signalling and user data backhaul" case (TS 22.346). Additionally, 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 communications, MCPTT, ProSe and group communications for PS UEs under 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 availability 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 reject UE connection attempts. PS UEs should use a dedicated Uni-versal Subscriber Identity Module (USIM) application for authentication 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, requirements 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 broadband 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 Figure 9.(3) [START_REF]Isolated Evolved Universal Terrestrial Radio Access Network operation for public safety; Stage 1[END_REF]. Hence, such topology can be mapped to the scenarios with no common CN connectivity, i.e., scenario 1 to 6 in Table 2. Nevertheless, it can solely serve local UEs and can not establish any con- 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.

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 directional antennas. Taipale T. studies the feasibility of a wireless mesh for LTE small-cell backhauling [START_REF] Taipale | Feasibility of wireless mesh for LTE-Advanced small cell access backhaul[END_REF] and details a new wireless mesh solution developed by Nokia Networks (NN) and VTT Technical Research 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 [START_REF] Abusch-Magder | 911-NOW: A network on wheels for emergency response and disaster recovery operations[END_REF] details a PS architecture that relies on meshing of moving BTS and investigates 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 Absolute 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 [START_REF] Al-Hourani | Cognitive Relay Nodes for airborne LTE emergency networks[END_REF][START_REF] Gomez | Aerial base stations with opportunistic links for next generation emergency communications[END_REF].

While some of these solutions might cover the use cases we identified, 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 requirements and have already selected LTE as the access RAT. Even if some hardware resources can be shared (such as antennas), isolation 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 backhaul will put high requirements on filters and amplifiers at each node to avoid self-interference or will require split in smaller subbands. 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 performance. Use of ISM bands to avoid regulatory constraints may limit the coverage due to the power limitations and interference, especially 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 [START_REF] Pitaval | Full-duplex self-backhauling for small-cell 5G networks[END_REF].. To briefly sum up, Table 4 compares all aforementioned backhaul link candidates in several aspects. 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 allowing to cope with the limited frequency bands availability case. We first present the challenges this BTS is confronted to, then its architecture 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.

challenges

Realizing an autonomous network based on meshing of enhanced LTE eNB with in-band backhauling rises several challenges.

Support of Legacy UEs

Maintaining an in-band mesh network with shared access and backhaul 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 interface 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.

Autonomous operation

While legacy LTE system is designed to deploy fixed BTSs with proper planning and Self Organizing Network (SON) capability [START_REF]Telecommunication management; Self-Organizing Networks (SON); Concepts and requirements[END_REF], the LTE BTSs are moving in the considered scenarios and are required to be autonomous.

Self-configuration and self-organization extensions

Moving e2NBs can affect the behavior of other neighboring e2NBs due to significant variations in perceived interference. Moreover, network topology changes such as split and merge of nodes and networks 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 interference between e2NBs and to manage state changes as network nodes are moving.

Coordinated scheduling

Because the radio resources are shared between access and backhaul links, scheduling shall guarantee end-to-end QoS, in particular for real-time traffics [START_REF] Nokia | LTE networks for public safety services[END_REF]. However, due to network mobility, wireless 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 characteristic 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 authentication and ciphering, some adaptations are needed to maintain 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 different 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 different components including topology management, routing, and applications. Service discover, registry and automatic reconfiguration are required in the deployed services and applications as well as reactive routing and dedicated CN procedures to handle the network expansion and UE handover.

architecture

Figure 10 presents the proposed e2NB stack, designed to fully satisfy the requirements delineated in section 2.3.1 to enable an autonomous LTE mesh network. In corresponding to the requirements (a), (b) and (c) of section 2. 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 handover and on an embedded routing module for packet marking and forwarding). In addition, some remaining LTE entities like PCRF1 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 entities based on the policy rules enforced by the COE. The COE agent acts as a local controller in charge of managing routes, network topology 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 [START_REF] Sesia | LTE -The UMTS Long Term Evolution[END_REF].

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 control 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 internetworking 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 approaches. They are cleverly utilized to establish the inter-e2NB communications. Each single vUE is managed and instructed by the COE and can report real-time radio information (e.g., received sig-nal power, newly detected eNB information) to the COE. Furthermore, each vUE will include the entire protocol stack of a legacy UE required to detect and establish communication with an eNB. Additionally, 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 including the worst case with a single frequency band, the e2NB shall operate 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. Nevertheless, such constraints can be relaxed for certain type of deployment 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 directly 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 network.

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 cooperation 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;

-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 management 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.

e2nb states

Under the proposed e2NB architecture, a node can transit between states as shown in Figure 11. The transition between states are managed 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 provides 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 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.

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 between Meshed state e2NBs have both Downlink (DL) and Uplink (UL) directions relying on two corresponding vUEs, while connections between 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.

D E S I G N E L E M E N T S A N

D P R O C E D U R E S O F E 2 N B
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 connectivity. Then, we present the connection related procedures of the e2NB, the associated specific LTE parameters that enable the autonomy, 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 efficiently provide services over the network.

physical layer interfaces

As mentioned before, the in-band deployment comes with highlyanticipated 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.

Background LTE information

Originally, an eNB is composed of TX and RX chain to communicate with UEs using Uu interface in DL and UL directions, respectively. 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 Access (OFDMA), the UL uses Single Carrier Frequency division Multiple 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 comprises 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 aspect, there are two slots in each SF and each slot contains several 35 symbols, namely there are fourteen symbols in a SF numbering from symbol 0 to symbol 14 in the normal cyclic prefix and twelve symbols in the extended cyclic prefix case. In frequency aspect, each SF is made up of several subcarriers depending on the frequency bandwidth. 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 subcarriers 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 Physical 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 carrier arrangement is different and depends on the RB allocation due to the use of SC-FDMA.

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 Synchronization Signal (SSS) must be transmitted in the SF 0 and SF 5 (in FDD) to allow the initial synchronization of UEs. Then, the Master Information Block (MIB) and a number of SIBs will then be utilized 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, namely Physical Downlink Control Channel (PDCCH), Physical Control 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 information of DL and UL resource allocation for each UE. Finally, UEs will use Cell-Specific Reference Signalss (CRSs) for synchronization and channel estimation1 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 division manner (i.e HD) hence prohibits the possibility of in-band Uu HD deployment as we mentioned in section 4. Indeed, it would require 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 [START_REF] Bharadia | Full Duplex Radios[END_REF].

Several works have been carried out to study the influence of FD radios on cellular systems. In [START_REF] Goyal | Improving small cell capacity with common-carrier full duplex radios[END_REF] and [START_REF] Goyal | Analyzing a fullduplex cellular system[END_REF], 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 [START_REF] Pitaval | Full-duplex self-backhauling for small-cell 5G networks[END_REF], performance 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 limitations still exist at the moment keeping FD solutions to be suitable only for small cells in cellular networks [START_REF] Goyal | Full duplex cellular systems: will doubling interference prevent doubling capacity?[END_REF]. 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 [START_REF] Bharadia | Full Duplex Radios[END_REF] and [START_REF] Bharadia | FastForward: Fast and Constructive Full Duplex Relays[END_REF], are realized with relatively low transmit power (23-24dBm). There is two reasons for that. First, the current analog RF cancellation techniques 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 requirement for a 10MHz channel [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); Base Station (BS) radio transmission and reception[END_REF] 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 acceptable 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 radius 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 [START_REF] Yun | Intra and Inter-Cell Resource Management in Full-Duplex Heterogeneous Cellular Networks[END_REF], showing when FD is beneficial over HD depending on the transmitting power as [START_REF] Sharma | Joint Backhaul-Access Analysis of Full Duplex Self-Backhauling Heterogeneous Networks[END_REF] 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.

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 capacity 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 [START_REF] Teyeb | Dynamic Relaying in 3GPP LTE-Advanced Networks[END_REF], through the Un interface and then relay to the legacy UEs through the Uu interface using the same frequency 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 [START_REF] Pitaval | Full-duplex self-backhauling for small-cell 5G networks[END_REF][START_REF] Kela | Flexible Backhauling With Massive MIMO for Ultra-Dense Networks[END_REF] 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) contrary 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 specification 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 transportation [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer for relaying operation[END_REF]. Such R-PDCCH can deliver downlink scheduling information (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 starting 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 depends on the higher-layer parameters Downlink StartSymbol (DLSS) and End Symbol Index (ESI) in order to cope with the transmission of the legacy control channels of UEs (PCFICH, PHICH, PDCCH), TX/RX switching time or some non-idealities (e.g., propagation delay, synchronization offset, etc.). In following, we elaborate on more details about the differences between Un and Uu interface.

PDSCH PDCCH R-PDSCH R-PDCCH R-PDCCH 1,
relay downlink Both R-PDCCH and PDCCH format the DCI in the same way, but they are mapped to different time-domain symbols (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 mapping 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 redundancy 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 maximum 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 maximum 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 available 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 simplicity). 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 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 [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2[END_REF]. 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 transmissions between the DeNB and the RN [START_REF]Study on LTE device to device proximity services; Radio aspects[END_REF]. 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 configuration 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 interface. 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)).

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.

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.

Synchronization

Within the backhaul links, synchronization issue has already been studied to minimize disturbance between BTSs and to be compliance with the frequency accuracy requirements [START_REF] Bladsjö | Synchronization aspects in LTE small cells[END_REF]. 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 Orthogonal Frequency Division Multiplexing (OFDM) symbol duration (around 66.67 micro-seconds) that corresponds to around 20km physical distance (which can be realistic for high powered maritime and PS use cases). Last but not least, 3GPP specified the minimum requirement for TDD time synchronization to be up to 10 (large cell) or 3 (small cell) micro-seconds [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); Requirements for support of radio resource management[END_REF].

In the case of FDD network, UL timing synchronization also matters. 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 [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); Base Station (BS) radio transmission and reception[END_REF].

To address both synchronization issues, a Global Positioning System Disciplined Oscillator (GPSDO) can be utilized as a clock reference for the local oscillator at each e2NB to guarantee extremely high frequency (sub-parts-per-billion (ppb) level) and time (<20 ns) synchronization [START_REF] Michael | Time and frequency measurements using the global positioning system[END_REF]. However, when the Global Positioning System (GPS) signal is not available (e.g., tunnel), the Rubidium oscillators can provide holdover capability to steer synchronization [START_REF] Michael | The use of GPS disciplined oscillators as primary frequency standards for calibration and metrology laboratories[END_REF].

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 transition 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 using 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 receiving 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 reachable 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 [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures[END_REF] do not depend on the number of available 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 single antenna Transmission Mode (TM) 1 as an example, the maximum value of TBS is 18336 bits shown in [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures[END_REF] when using the largest Modulation and Coding Scheme (MCS) 28 with 25 PRBs (i.e., N P RB = 25). On the other hand, the number of bits that can be carried by available REs can be formulated as:

N bits = Q m * (N subcarriers * N symbols -N CRS ) * N P RB (1)
where N subcarriers is the number of subcarriers in a PRB which is equal to 12, Q m is the modulation order, i.e., the number of bits per RE, which equals to 6 when MCS is 28, N CRS is the number of RE used by CRS in the data region within a PRB which equals to 6 in TM 1, N symbols is the number of symbols for PDSCH/R-PDSCH transmission. With N symbols = 11, N bits = 18900 > 18336 in the considered case (MCS 28, 25 PRBs), the coding rate will be 0.97. However, when N symbols becomes 10, then N bits = 17100 < 18336, and the coding rate will be 1.07.

To this end, reducing the number of symbols of R-PDSCH (i.e., N symbols ) will further prohibit some more combinations of MCS/PRB 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 [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer for relaying operation[END_REF]. 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 [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer for relaying operation[END_REF]. 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 different 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 different e2NBs will overlap. To avoid such overlapping, some allocation strategies can be utilized by the COE controller and will be discussed in chapter 6.

HARQ modifications for Un interface

As the adoption of Un interface for the multi-hop in-band backhauling, 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 approach. 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 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 allocation 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 ACKs/NACKs can be multiplexed if several DL transmissions have been received from the specific e2NB since the last DL transmission opportunity. Unfortunately, such method requires large buffers at the e2NB DL queues and might increase latency of transmissions depending 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 reduce 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.

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. Finally, we present the e2NB operation flows that comprises the startup phase, and the three aforementioned major states in Figure 11.

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 different groups: (a) parameters that can be configured depending on configuration of adjacent eNBs, and (b) parameters that require specific 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 configuration and MBSFN information in SIB2 with the related prerequisite 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 scheduling 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 CI 1 and P CI 2 such that P CI 1 ≡ P CI 2 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.

vUE attach procedure

As introduced beforehand, we utilize both Uu and Un interfaces for the inter-e2NB backhaul link. Hence, the attach procedure is provided in Figure 17 and we detail the overall procedure in this subsection. To enable such procedure, we rely on some specific parameter configuration that allows e2NB to connect to new e2NB using its vUEs without disconnecting locally served UEs.

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 implies that the vUE cannot naturally receive and detect the PSS/SSS broadcasted by neighboring eNB.

Thanks to the time and frequency synchronization previously described, it is simple for a vUE to detect PSS and SSS from adjacent 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 failure 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 configured 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 SIBs2 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 [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2[END_REF][START_REF]Telecommunication management; Automatic Neighbour Relation (ANR) management; Concepts and requirements[END_REF]. 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 detect other nodes faster or it can detect nodes that are not in its detection 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 transport the Physical Random Access Channel (PRACH) preamble. Note 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 transmit 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 [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC)[END_REF] 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 configured 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 connection 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. However, 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.

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 instantiated 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 connectivity 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-col stack with the operation flow in Figure 18. In the legacy LTE system, the initial configuration phase includes choosing the PCI value through the self-configuration processes relying on the common CN [START_REF]Telecommunication management; Self-Organizing Networks (SON); Concepts and requirements[END_REF][START_REF]Telecommunication management; Automatic Neighbour Relation (ANR) management; Concepts and requirements[END_REF][START_REF]Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Self-configuring and self-optimizing network (SON) use cases and solutions[END_REF].

However, in our case, the newly startup e2NB do not have the access to a common CN. Hence, following the e2NB architecture, a specific 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 [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) procedures in idle mode[END_REF]. When detecting the neighboring 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. Finally, 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 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 selfconfigured 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 [START_REF] Baliosian | Distributed auto-configuration of neighboring cell graphs in radio access networks[END_REF].

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 depict how it works. Firstly, the conflicting e2NBs must realize that there is a conflict. Such realization is not a problem when the conflicting e2NBs are meshed due to the maintenance of topology at COE Controller. However, it will become a problem when the conflicting e2NBs are isolated or in different meshes. In that case, conflicting 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 report directly such a situation, the monitoring on the inconsistencies between the DL and UL directions can potentially disclose such hidden 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

Such e2NB state is with one instantiated eNB and several vUEs to serve local UEs, connect to neighboring e2NBs, and detect neighboring 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 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 reduce 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.

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.

MME

As legacy LTE access network, MME is a key controlling entity that supports various functionalities to enable logical connectivity and service continuity. Firstly, each MME shall maintain its own TAI, do 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.

HSS provisioning and cooperation

To allow inter-connection between e2NBs, the vUE and the embedded 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/synchronize 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.

S/P-GW

These two entities may be utilized to allow the IP-based communication 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.

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 [START_REF] Akyildiz | Wireless Mesh Networks: A Survey[END_REF]. Our proposal does not rely on any hypothesis of a specific routing algorithm but the routes should be updated at each topology change and propagated over the network. Note that network split and merge operation will impact the routing decision, and can potentially trigger the handover and gateway change for UEs.

Application and services

Such high-layer applications and services is used to retain the minimal user services regardless of e2NB states and can be used for following 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 control (e.g., Flow control policies of real-time traffic flow, load balancing within the meshed network, access to the shared content).

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 approach to deal with these problems in the next chapter.

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 proposed hierarchical approach that comprises a centralized scheduler, a distributed scheduler and the way to utilize the COE architecture. Finally, we detail on the algorithms for both centralized and distributed schedulers.

problem overview

Using the Un interface to realize the backhaul links of a LTE network in a mesh fashion is similar to the Time Division Multiple Access (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 becomes a potential interferer which limits the achievable rate. Furthermore, there exist more related issues that need to be considered in the meantime as summarized in [START_REF] Pathak | A Survey of Network Design Problems and Joint Design Approaches in Wireless Mesh Networks[END_REF], 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 [START_REF] Benmimoune | Dynamic joint resource allocation and relay selection for 5G multi-hop relay systems[END_REF], 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 wireless mesh networks [START_REF] Pathak | A Survey of Network Design Problems and Joint Design Approaches in Wireless Mesh Networks[END_REF]. 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 [START_REF] Zhou | TRITON: high-speed maritime wireless mesh network[END_REF]. A summary of algorithms for scheduling and routing for WiMax mesh networks can be find in He et Al. study [START_REF] Hey | Routing and Scheduling for WiMAX Mesh Networks[END_REF]. 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 routing, thus there is no a priori preferred route to a specific gateway for flow going through each BTS. Similar limitations can be drawn from 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 [START_REF] Sapountzis | Network layer optimization for next generation heterogeneous networks[END_REF]. 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 unleash the performance barriers when meshing e2NBs in order to guarantee the QoS in per-flow basis of the self-backhauling LTE mesh network. As distributed scheduling is generally inefficient in QoS guarantee, 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 implementation. Last but not least, such approach will rely on the coordination between COEs of meshed e2NBs that will be described in next section.

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 [START_REF] Foukas | FlexRAN: A Flexible and Programmable Platform for Software-Defined Radio Access Networks[END_REF], one per e2NB in a typical case (refer to Figure 10). The COE controller manages and orchestrates the mesh network through policy enforcement over the COE agents [START_REF] Favraud | Wireless mesh backhauling for LTE/LTE-A networks[END_REF][START_REF] Favraud | Toward moving public safety networks[END_REF]. The COE agent can either act as a local controller delegated by the centralized controller, or in coordination with other agents and cen- tralized COE controller. The communication protocol between the centralized 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 centralized 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.

Coordination & Orchestration Entity Controller

COE Controller Scheduling Algorithm

Coordination & Orchestration Entity Agent

Then, all related cross-layer parameters shall be scheduled by the centralized COE controller that include (a) next e2NB hop for backhaul relaying, (b) MBSFN SFs for backhaul transportation, (c) relaying transportation direction (DL/UL), and (d) low-layer transportation 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 notation G = (V e2N B , E link ). The vertex set V e2N B comprises e2NBs in the mesh, and the edge set E link 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 N u 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 significantly 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 [START_REF] Akyildiz | Wireless Mesh Networks: A Survey[END_REF]. After routing, we furthermore compute the link load for real-time traffic over edge (u, v) as load u,v in terms of the number of real-time traffic bits to be transported within a SF. It is based on the flow information available at the flow controller entity at COE controller provided by COE agents. A set L = {load u,v : ∀ (u, v) ∈ E link } is defined to comprise all link load of edges in the mesh that will be used for resource scheduling of realtime 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 resources (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 controlplane 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 several aspects (detail later). To sum up, the hierarchical approach not only shows its practical usage and implementation but also is compliant with legacy SF-based schedulers.

Traffic prioritization

Prioritize real-time traffic over elastic traffic

coe controller scheduling algorithm

Firstly, we present the CSA at the centralized COE controller in Algorithm 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 duration), we introduce the SuperFrame (SuF) concept. The duration of a SuF is denoted as L SuF as computed in Algorithm 1; however, such duration value is not fixed and can be updated after a period of time P SuF or triggered via some events like a newly-added real-time traffic

Superframe duration computation (L SuF )

As its centralized manner, the CSA can retrieve following information 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).

-M hops : The expected maximum number of hops of all active realtime traffic flows.

of f set: A stretch factor of M hops to deal with the mobility pattern (i.e., vehicular speed) and network topology.

Based on aforementioned information, the CSA computes the SuF duration (L SuF ) 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.

SF allocation for inter-e2NB self-backhauling

After getting the duration of SuF, we then use Algorithm 2 to compute the number of DL SFs required by each e2NB to transport realtime flows within this duration as

SF D rt [u] , ∀u ∈ V e2N B .
Note the main operation to get the SF D rt [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., N D P RB ). In the computation of the number of required PRBs, we firstly multiply the link load within a SF (i.e., LL u,v ) by the duration of a SuF (i.e., L SuF ) to get the number of real-time bits to be transported in the SuF duration. Then, we introduce P RB D/U u,v (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., LL v,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 SF D rt [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 "saturated" concept to know the bottleneck links of elastic traffics over the

Algorithm 2: SF D rt = f (L SuF , V e2N B , L) Input : V e2N B is
foreach u ∈ V e2N B do rP RB D [u] = v∈Nu P RB D u,v (LL u,v • L SuF ) ; SF D rt [u] = rP RB D [u] N D P RB ; nP RB U [u] = SF D rt [u] • N U P RB ; foreach v ∈ N u do LL u,v = 0 ; /* allocated over DL in SF D rt [u] */ rP RB U = P RB U v,u (LL v,u • L SuF ) ; if rP RB U = 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 -tP RB U rP RB U ) ; LL v,u = LL v,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 aggregated 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 allocated 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).

S D u {v : v ∈ N u , DL (u, v) is saturated} (2a) S U u {v : v ∈ N u , U L (v, u) is saturated} (2b)
Based on aforementioned definitions, we compute two values, i.e., SF U e [u] and SF D e [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 S D u and S U u as detailed in Eq. ( 3). As the first step, we estimate the Average Frequency Reuse (AFR) factor from the previous scheduling results (i.e., L N -1 SuF , SF N -1 T X [u] in Algorithm 1) where N mbsf n (L SuF ) returns the set of MBSFN SF during the SuF duration L SuF . 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 SF f ree via excluding SFs that are already reserved for real-time traffic from all MBSFN SFs. Thirdly, we compute B D e [u] and B U e [u] as the sum of average TBS per PRB of all saturated DL and UL directions 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 CS D u,v represents the applied MCS index on DL direction DL (u, v) whereas M CS U u,v 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 SF U e [u] and

SF D e [u]. AF R = u∈V e2N B SF N -1 T X [u] N mbsf n (L N -1 SuF ) (3a) SF f ree =   N mbsf n (L N SuF ) - u∈V e2N B SF D rt [u]   • AF R (3b) B D e [u] = v∈S D u T BS M CS D u,v , 1 (3c)
SF D e [u] = B D e [u] • SF f ree v∈V e2N B B D e [v] (3d)
B U e [u] = v∈S U u T BS M CS U v,u , 1 (3e)
SF U e [u] = B U e [u] • SF f ree v∈V e2N B B U e [v] (3f)
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. SF T X [u] [v] and SF RX [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 principle 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, SF T 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 I u,v comprises the e2NBs which shall be blocked due to the transmission on edge (u, v)

u ∈ V e2N B do if SF D rt [u] + SF D e [u] + SF U e [u] ≥ 1 then if SF ∈ SF T X [u][ * ] then T ransmit = 0 ; /* Initialize transmit indicator */ foreach v ∈ V e2N B ∧ (u, v) ∈ E link do if SF ∈ SF RX [v][u] then I u,v = genIntf (u, v, A e2N B ) ; (cf. Alg. 4) if ∃ w ∈ A e2N B I u,v then /* Cannot transmit to vUE v that would receive too much interference from e2NBs already activated in A e2N B */ remove(SF, SF RX [v][u]) ; remove(SF, SF T X [u][v]) ; else T ransmit = 1 ; T x(u, v) = T x(u, v) + 1 ; remove(SF, SF RX [u][ * ]) ; remove(SF, SF T X [v][ * ]) ; foreach w = u ∈ V e2N B and (v, w) ∈ E link do remove(SF, SF RX [v][w]) ; foreach w ∈ I u,v do remove(SF, SF T X [w][ * ]) ; else remove(SF, SF T X [u][v]) ; if T ransmit == 1 then A e2N B = u A e2N B ; if min(T x(u, * )) ≥ 1 then foreach v ∈ V e2NB ∧ (u, v) ∈ E link do T x(u, v) = T x(u, v) -1 ; if SF D rt [u] ≥ 1 then SF D rt [u] = SF D rt [u] -1 ; else if SF D e [u] ≥ 1 then SF D e [u] = SF D e [u] -1 ; else if SF U e [u] ≥ 1 then SF U e [u] = SF U e [u] -1 ; foreach u ∈ V e2N B do if SF D rt [u] = 0 then rtDisSat = 1 ;
as shown in Algorithm 4. Note the decision is made based on the received signal power (i.e., P u,v and P w,v ) and a pre-specified blocking 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 handover), 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, A e2N B ))

Input : (u, v) is the edge of the graph from u to v P x,w is received signal power at w from x criteria (a, b) is blocking criteria with input a, b Output :

I u,v begin I u,v = ∅ ; foreach w ∈ A e2N B ∧ w = u do if criteria(P u,v , P w,v
) then /* Add interferer when meet blocking criteria */ I u,v = w I u,v ;

Distributed link scheduling

The results of CSA (i.e., SF T X ) are transported to each COE agent for a distributed link scheduling. Such DLS aims to allocate the frequency 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., V vU E ) and UE set (i.e., V U 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 prioritizing real-time traffics over elastic ones. Among vUEs/UEs in the same set (i.e., V vU E /V U E ), we firstly sort them based on the number of queued real-time traffic bits and then provide P RM min PRBs in a round-robin way. Furthermore, in the PRB provisioning, the number of requested bit (i.e. ReqBit) within the corresponding queues is used to derive the allocated PRBs, and thus prevent resource overprovisioning. It has to be noted that Algorithm 5 can be adapt to apply priorities among UEs/vUEs. the selection of direction highly depends on the traffic QoS requirement, 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.

extensions to tdd system

All aforementioned algorithms are designed for FDD system; however, a joint operation of heterogeneous FDD/TDD network is envisioned as an efficient deployment to utilize available spectrum resources [START_REF] Huawei | The second phase of LTE-Advanced[END_REF]. Moreover, the e2NB solution targets worst case scenarios 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 purpose in TDD mode. Furthermore, the FDD characteristic cannot be leveraged to allocate resource also for reverse link when computing SF rt in Algorithm 2. As fewer MBSFN SFs can be used for backhaul link but with more required SF rt for real-time traffic transportation, we can anticipate a smaller number of free SFs can be used for elastic traffic (i.e., SF f 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 configurations, 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 connectivity 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 heterogeneous DL SF allocations between e2NBs. The second solution is to enable the COE controller to allocate the UL SFs just after the allocation 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 direction. 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 directly possible using legacy UL SFs; however, some MBSFN SFs can 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 previous 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 SF rt for FDD mode.

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 [START_REF] Kela | Flexible Backhauling With Massive MIMO for Ultra-Dense Networks[END_REF] 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 proposed approach without any drastic changes, the multi-sector BTS can also be supported but with some necessary changes. As all sectors 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 highpower 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 (Algorithm 3) is still valid as it is. However, different values of SF D,i rt can be further computed for antenna i based on the value of SF D rt as the maximum value for all antennas of such BTS. The same approach can be applied in the computation of SF D,i e and SF U,i e at antenna i with the value of SF D e and SF U e reflecting the maximum value among all antennas at this BTS. Such approach would allow for a better satisfaction 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 transmission and reception. Ideally, each sector can be considered equivalently as an e2NB with independent SF D rt , SF U e , SF D e in Algorithm 4 and 3 but with one additional constraint to block adjacent sectors when it is being allocated. Such constraint can lead to a better frequency re-use; however, it will require each BTS to know for all its sectors the interference contributed from other sectors of adjacent BTSs. Such information shall be reported to the COE controller but may be complicated to be measured.

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 SF D rt , SF D e , SF U e and executes the CNS.

SF D rt computation in Algorithm 2 loops on the e2NB u within e2NB set V e2N B (containing N e2NBs), where each e2NB u further loops on the number of its adjacent e2NBs (i.e., N u ) in FDD mode. While the set V e2N B can contain a large number of e2NBs, the set of adjacent 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 comparable to the number of adjacent neighbors, the complexity of SF D rt 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 SF D e and SF U e are equivalent to O (N ) due to the summation over the set V e2N B .

The CNS in Algorithm 3 loops firstly on the number of MBSFN SFs which depends on the lowest latency requirements of the realtime flows but is staked in all cases. Inside this first loop, it loops on the e2NBs u in the set V e2N B (equivalent to O (N )). Inside the second loop, it loops on the edge set of connected neighbors to e2NB u: v ∈ V e2N B ∧ (u, v) ∈ E link which is equivalent to N u . 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 (A e2N B ) is a subset of V e2N B . However, the set A e2N 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 N u can be considered equivalent to N , the set A e2N B will most probably be very small compared to V e2N B as most links will interfere each other (i.e., low frequency re-use factor). In a larger network, each N u will be an order of magnitude smaller than N and will most probably be bounded by a constant value c which is not proportional to N , while A e2N 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.

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 interference.

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 directly managed and taken into account by the proposed approach. Access-backhaul interference on UL can happen if e2NBs are scheduling 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 coverage of adjacent e2NBs are severely overlapping, the COE controller 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.

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 [START_REF] Mavoungou | Survey on threats and attacks on mobile networks[END_REF], several attacks in LTE networks are categorized: (a) security and confidentiality attacks, (b) IP-based attacks, (c) signaling attacks, and (d) jamming attacks. Unfortunately, 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 [START_REF] Bhattarai | On Simulation Studies of Jamming Threats Against LTE Networks[END_REF] 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 remedy such attack, there are several manners that can be applied. Firstly, we can dynamically change the SuF update periodicity (i.e., P SuF ) to avoid the illegal jamming device easily perceiving the exact transporting SuF duration. We can also randomly allocate SFs within a SuF between 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 communications.

Nevertheless, more resilience performance analyses shall be taken when dealing with other attacking threats in several threat spaces [START_REF] Bhattarai | On Simulation Studies of Cyber Attacks against LTE Networks[END_REF], e.g., attack venue, plane of attack, and security services.

E X P E R I M E N TAT I O N S

In this chapter, we evaluate the proposed approach at different levels. 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 computing requirements to ensure its usefulness. Then, we evaluate the cross-layer approach proposed in chapter 6 over several mesh topologies to understand its behavior and to evaluate its efficiency.

physical channel performance evaluation

Even with several aforementioned merits when adopting Un interface for self-backhauling purpose in chapter 5, there is still no previous work endeavored to compare its performance with the legacy Uu interface. In this sense, we evaluate if the Un interface is performing sufficiently good compared to the legacy Uu interface in terms of spectral efficiency, maximum throughput and computing requirements to ensure its usefulness in this section.

We implement a subset of the R-PDCCH and R-PDSCH of the Un interface in OAI [START_REF]The OpenAirInterface Platform[END_REF], 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 [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures[END_REF] for explanations on resource allocation types). It also includes R-PDSCH encoding and decoding with resource allocation type 0. Both support all DLSS and ESI configurations (see section 5.1.3). However, one unimplemented feature defined in 3GPP specification [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer for relaying operation[END_REF] 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 [START_REF] Favraud | Analysis of LTE Relay Interface for Self-backhauling in LTE Mesh Networks[END_REF]. 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.

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 aggregation 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 generated and the full process from Cyclic Redundancy Check (CRC) attachment 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 generate 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 computation 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 aggregation 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 (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 decoding processing time.

Then, we vary the MCS value and compare the total processing time of the transmission procedure or reception procedure when using either PDCCH/PDSCH or R-PDCCH/R-PDSCH. Such comparisons 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 channel) and 96 PRBs (20MHz) for the relay channel with a R-PDCCH VRB set containing only one (5MHz) or four (20MHz) PRBs. It can 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 interface. 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 [START_REF] Nikaein | Processing Radio Access Network Functions in the Cloud: Critical Issues and Modeling[END_REF].

To conclude this section, we see that at equivalent bandwidth usage, the required processing capability for the Un interface is equivalent 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 expenditures.

Link-level performance

As a link-level performance metric, we examine the minimum Signal to Noise Ratio (SNR) level to successfully decode 75% of Transport Blocks (TBs) for both PDSCH/R-PDSCH in Figure 25 using ag-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 [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) radio transmission and reception[END_REF]). Such experiment is taken under different radio bandwidth [START_REF] Syracuse | Direction Générale de l'armement[END_REF][START_REF] Tia | Project 25 System and Standards Definition[END_REF]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, [START_REF] Baldini | Survey of Wireless Communication Technologies for Public Safety[END_REF][START_REF] Tia | Project 25 System and Standards Definition[END_REF][START_REF]Study on LTE device to device proximity services; Radio aspects[END_REF][START_REF]Feasibility study for Proximity Services (ProSe)[END_REF][START_REF] Favraud | Toward moving public safety networks[END_REF][START_REF] Al-Hourani | Cognitive Relay Nodes for airborne LTE emergency networks[END_REF][START_REF] Gomez | Aerial base stations with opportunistic links for next generation emergency communications[END_REF].

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 interface 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 linearly 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, lowering 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 achievable TBS of R-PDCCH/R-PDSCH and PDCCH/PDSCH increases when 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.

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 several resource scheduling approaches on different network topologies experiencing various traffic flows.

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 ( [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); Further advancements for E-UTRA physical layer aspects[END_REF][START_REF]Radio Frequency (RF) system scenarios[END_REF][START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Frequency (RF) system scenarios[END_REF]) with each e2NB operating in TM 1 (Single Input Single Output (SISO)) using a single omnidirectional antenna. To characterize the in-band characteristic, we use the same carrier frequency (2.1GHz, band 4) through the network with either 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 cancellation 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 communications would reduce the maximum distance between e2NBs. Between e2NBs and UEs, a rural (from [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Frequency (RF) system scenarios[END_REF]) path loss model is used with Claussen shadow fading and EPA channel type. The above channel model is selected to limit the interference effects between UEs served by adjacent e2NBs as no interference mitigation or coordination method is assumed for the access links (i.e., eICIC) are considered 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 to allow for MCS 22 without any interferer, w is considered an interferer 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). Moreover, the of f set parameter for L SuF computation is set to 1 and P SuF 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 patterns simulates to what is presented in Table 3. For real-time traffic flows, we randomly pair all UEs to establish bi-directional VoIP calls. Each call generates 20 bytes payload packets with a 20ms arrival 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 [START_REF] Ribadeneira | An analysis of the MOS under conditions of delay, jitter and packet loss and an analysis of the impact of introducing piggybacking and reed solomon FEC for VoIP[END_REF]. Whereas the elastic traffic is set between BTSs to represent the inter-site data transfers 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.

Considered Algorithms

In our previous work [START_REF] Favraud | QoS guarantee in self-backhauled LTE mesh networks[END_REF], we compared a first version of the hierarchical 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:

2.

A simplified algorithm which does not leverage the FDD characteristic when computing the required SFs for real-time traffic in Algorithm 2, denoted as DL Alg. (or DL.).

3.

The full algorithm proposed in this work that exploits the UL direction 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 Algorithm 1), we increase the SuF duration (i.e. L SuF ) 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 Table 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 pairing for real-time flows. Here, as there is no elastic flows, we forcedly set their SuF duration (i.e., L SuF ) 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 algorithms 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., N hop . 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).

Simulation Results

Based on the aforementioned three network topologies in Figure 27, we compare the following two performance metrics belonging to different 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 evaluated for elastic traffic: (i) from e2N B 4 to e2N B 6 (4 → 6), (ii) from e2N B 1 to e2N B 2 (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 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 Figure 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 SF D rt ; 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 SF D rt 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 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 B 1 (or either e2N B 5 ), e2N B 1 can do the transmission over DL direction to e2N B 6 at SF n and can also transmit to e2N B 4 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 twohop elastic flow and can achieve a close throughput as the one-hop one. To sum up, e2N B 1 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.

B . V B . D L . V U L . V D L . / U L . B . V B . D L . V U L . V D L . / U L . B . V B . D L . V U L . V D L . / U L .
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 scheduler. 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 baseline 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 periodicity of transmissions of other e2NBs, thus the average latency and 95-percentile point is increased. tdd mode We then evaluate the behavior of the different algorithms over a 10MHz TDD mode using the TDD UL/DL configuration 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 current TDD approach, even though such TDD configuration 4 allows for one UL SF to be used for Un interface [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer for relaying operation[END_REF].

We can observe in Figure 29.(a) that both full and simplified algorithms 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 twohop 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 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 onehop 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 onehop 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. 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 B 2 to e2N B 6 (2 → 6), (ii) from e2N B 7 to e2N B 5 (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- sion since it exploits the full FDD capability and is able to save some SFs for elastic traffic. However, the difference between the full algorithm 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 topology. Firstly, as the maximum number of hops over the network as increased from 2 to 6, the SuF duration (i.e., L SuF ) 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 duration 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 traffics 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 (L SuF ) will become smaller to ensure the end-to-end latency of such flows (see M hops 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 L SuF (as explained in previous FDD paragraph). To quantitatively evaluate such impact, we restrain the maximum number of hops between UEs during the pair-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 algorithms provide a higher throughput of elastic flows than the baseline 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 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).

B . V B . 1 V B . D L . V / U L . V D L . 1 V / U L . 1 V D L . / U L . B . V B . 1 V B . D L . V / U L . V D L . 1 V / U L . 1 V D L . / U L . B . V B . 1 V B . D L . V / U L . V D L . 1 V / U L . 1 V D L . / U L .
In Figure 32.(b), without any restrictions on the maximum number 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 latency. Last but not least, all algorithms can provide 100% satisfaction for all VoIP flows among each case, but both simplified and full algorithms 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 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.

U L . V ( T D D ) U L . V ( F D D ) U L . V ( T D D ) U L . V ( F D D ) U L . V ( T D D ) U L . V ( F

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 B 12 to e2N B 11 (12 → 11 with two hops), one flow from e2N B 15 to e2N B 13 (15 → 13 with three hops), and one from e2N B 2 to e2N B 16 (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 algorithm; 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 unable 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 section 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., N hop = 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-proach can provide 100% satisfaction, with around 5% of dissatisfaction 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 transmissions from some vUEs are subject to a higher failure rate. In DL direction, 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 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 adaptation scheme. To tackle this problem, the DL direction should be more privileged for the real-time traffic even when both DL and UL directions 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 performs 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., SF D rt ) over the MBSFN SFs in the SuF duration L SuF . As there is no flow control in the simulation, it leads these two algorithms to increase the duration of SuF; otherwise 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 SF D rt while the full one does and hence reduces the expected total number of required DL SFs for real-time traffic. Once again, the full algorithm shows the best tradeoff between throughput and meeting latency requirements.

tdd mode Finally, we examine the TDD mode over the same topology 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 constraint (i.e., N hop = 2 or N hop = 3) are shown in Figure 37. We can observe in Figure 37.(a) that both simplified and full algorithms outperform 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 performance; 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)) 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).

B . 3 V D L . 3 V / U L . 3 V B . 2 V D L . 2 V / U L . 2 V B .

Summary

To summarize our findings in every scenario, Table 8 provides several important results in this section. We can observe that the full algorithm 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 TDD mode can provide the best trade-off in two specific scenarios: (a) a unique one hop elastic flow over the 7 e2NBs hexagonal topology, and (b) two hops restriction on VoIP flows over the 19 e2NBs hexagonal topology. In the later case, the runner-up is the same algorithm in FDD mode since it does not perform as expected due to a higher interference along the UL directions. Using a more conservative scheduler for UL transmissions will potentially further improve its results and allows the FDD to outperform the TDD mode. Moreover, 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 traffic, i.e., SF D rt . Last but not least, the simplified algorithm can be 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 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 proposed approach achieves the trade-off between guaranteeing the latency 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., SF D rt . 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 allowing 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.

performance comparison of in-band and out-band deployment

Apart from aforementioned in-band deployment, the out-band deployment is another possible approach for self-backhauling network. We discussed in section 3.2.2 that the out-band backhaul was not complying 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 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 B 1 to e2N B 2 , (ii) From e2N B 1 to e2N B 3 , and (iii) From U E 1 to e2N B 1 . 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 dividing 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 5MHz channel bandwidth as done by the Uu backhaul. With a traffic flow transmitted from e2N B 1 to e2N B 3 over two backhaul hops, the data rate over Uu backhaul does not change from the e2N B 1 to e2N B 2 case, as it is limited by the UL direction from e2N B 1 to e2N B 2 (PRBs reserved for PUCCH makes it slightly slower than DL). On the other hand, Un backhaul links perform slightly worse in e2N B 1 to e2N B 3 case than in e2N B 1 to e2N B 2 because it has to rely on UL SFs for half of its transmissions while it mainly use DL SFs in the latter case. When transmitting only a single flow from U E 1 to e2N B 1 , the Un backhaul architecture performs much better as almost all the 10MHz bandwidth can be used by the U E 1 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 E 2 to e2N B 2 and from e2N B 2 to e2N B 1 , and (ii) from U E 2 to e2N B 2 and from e2N B 1 to e2N B 2 . 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 B 2 . As there is no traffic coming from other e2NBs, U E 2 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 B 2 can properly transmit (i.e., to e2N B 1 ) and receive (i.e., from U E 2 ) 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 due to the concurrent reception at e2N B 2 from both e2N B 1 and U E 2 . 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 B 1 for backhauling in DL direction, the e2N B 2 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 efficiently 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 inband self-backhauling network.

summary

In this chapter, we have seen that the Un interface is performing similarly to the Uu interface on computation requirements and requires 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 increasing 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.

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 different 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 channels. 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-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 delivery 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.

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 estimation for the vUE along the backhaul links can degrade the performance 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 currently proposed computation of SF D e and SF U e 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 SF D e and SF U e , the COE controller will think the saturation condition is resolved immediately. Hence, it will not allocate anymore resources until such link is saturated again; nevertheless, such oscillations behavior has been observed using other types of elastic flows. We can propose for instance two solutions to overcome this issue. Firstly, SF D e and SF U e 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 SF D e and SF U e 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 better 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 negatively on every traffic flows in the mesh. The flow control algorithm can take such condition into account with other metrics to preserve the expected network behavior. Otherwise, we can include such condition when doing the handover process to make the source UE closer in the number of hops toward its destination.

C O N C L U S I O N

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 inappropriate to sufficiently deliver seamless and continuous backhaul connectivity in moving cell scenarios, thus making first responders and tactical forces be deprived of critical communications. Understanding 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 selected LTE as the RAT for both access and backhaul connectivity of the envisioned mesh network based on the current status of PS communications and on the limitations of other state-of-the-art solutions given the previously defined constraints. Then, we expose the challenges 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 functional 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 associated flow charts governing the e2NB behavior. To specifically answer the dynamic resource allocation problem, we explored and proposed an interference aware cross-layer hierarchical resource scheduling algorithm to efficiently meet QoS requirements for real-time traf-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 performance of the proposed solution. Firstly, we evaluated the proposed 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 requirements and spectral efficiency using the OAI emulations. We also demonstrated the effectiveness of the proposed hierarchical scheduling approach to ensure QoS requirements while maximizing throughput of elastic flows.

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 covered by current PS and military wireless communication systems. Particularly, we have detailed many design points and procedures that are required at the e2NB to realize the self-backhauled LTE mesh network 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 architecture 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 implemented and experimented. Regarding the physical layer, synchronization 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 thoroughly. On higher layers, we over-viewed the content of messages that should be exchanged between e2NB to enable the COE communications 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 defined. Moreover, as we have seen in chapter 7, flow control algorithms matter to ensure an efficient behavior and the high performance of 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 effective gain. Similarly, beam forming techniques are known to severely improve performance in mesh network. However, integrating it efficiently in the proposed scheduling algorithms is not straight forward and would require more studies. While we targeted a solution working with minimal available radio resources, the procedures could be evolved to support CA if accessible. Particularly, the use of Multefire [START_REF]MulteFire Alliance[END_REF] could also be considered to improve the performance of the solution. Taking a look at the progression of cellular network architectures, we can observe that the e2NB aligns quite well with the softwarization (use of Virtual Network Function (VNF) and of Network 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 approach. 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 communication systems, compatibility with 5G New Radio (5G NR) and flexible numerology should be evaluated to determine what are the necessary modification if any.

B R É S U M É E N F R A N Ç A I S

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 consulter 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 électromagnétique soit fixe et que les fréquences disponibles se fassent de plus en plus rares, de nouvelles technologies émergent continuellement, 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 connexions, 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 couverture 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érimentations 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. Cependant, leur conception ne leur permet pas de répondre aux nouvelles 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 cellulaire 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 proximité, ainsi qu'aux exigences de sécurité, de confidentialité et de fiabilité 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 évoqué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 coeur de réseau commun.

Du côté des instances militaires, celles-ci ont longtemps été précurseurs des avancées techniques dans le domaine des télécommunications. 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 technologiques 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 communications 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 inté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 mobilité 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 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 fonctionnelles auquel un système de communication fournissant un tel service doit répondre.

Dans le second chapitre, nous étendons ces exigences aux contraintes externes qui s'appliquent sur les systèmes de communications militaires ou pour la sécurité publique, en particulier la disponibilité 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 Equipments) ainsi que les communications entre les stations de base autonomes.

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 introduisons 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 limites 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 fonctionnalité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 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 coordination et d'orchestration nécessaire au fonctionnement du réseau maillé. Afin d'assurer le fonctionnement à la fois en LTE mode Frequency 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 faisabilité 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 montrer 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 système sans fil réel et totalement fonctionnel. Dans la plupart des environnements, les forces militaires ont fortement 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 embarqué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. Cependant, les systèmes de communications militaires n'évoluent pas aussi rapidement que les systèmes de communications civils. Contrairement aux communications militaires, les communications de sécurité publique s'appuient sur des infrastructures fixes. Cependant, 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. [START_REF] Baldini | Survey of Wireless Communication Technologies for Public Safety[END_REF] présente une vue complète des environnements de sécurité publique et des systèmes de communications associés.

Systèmes de communications navals

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 opportunistes.

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 systèmes actuels ne peuvent couvrir les cas où l'accès de toutes les stations de base à un coeur 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épondre à l'évolution des besoins. En particulier, ils ne peuvent s'adapter à différentes topologies et ne fournissent pas des performances satisfaisantes.

Ainsi, l'objectif de cette étude est de concevoir un système de communication 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écessaires à 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 coeur de réseau externe ou à un autre équipement, ceci afin d'être une station de base autonome. 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 [START_REF] Favraud | Toward moving public safety networks[END_REF].

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 Internationale 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 coeur de réseau (CN) pour fournir l'accès au service aux UEs. Ce coeur 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écifications du LTE spécifie complètement l'interface radio entre les stations de base (eNBs) et les UEs depuis la couche physique jusqu'à la fourniture du service IP utilisateur. Cependant, les communications au sein du coeur 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 coeur de réseau tant que celle-ci fournit une connexion IP entre ces éléments. Ainsi la liaison X2 entre eNBs est 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 "Release 11". La Figure 49 regroupe les principaux travaux.

Cependant, malgré tous ces travaux, un certain nombre de fonctionnalité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- 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 considé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 principale 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 noeud à proximité, etc.). Chaque vUE comprend la pile protocolaire complète d'un UE classique qui lui permet de détecter et d'établir des communications avec un eNB. De plus, il comprend la pile protocole du relai LTE (RN) qui permet le maillage sur une seule bande radio. Le service 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 configuration 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 coordonne avec les autres agents d'e2NBs auxquels il est connecté pour permettre la gestion de ressource inter-couche sur tout le réseau.

b.4.1 États de l'e2NB

Nous avons défini trois états principaux pour l'e2NB. Ceux-ci correspondent aux différents états d'interconnexion possibles. Les transitions 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. 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 classique 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.

Les différents états et les transitions possibles sont présentés

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 différentes. La Figure 53 présente différents exemples.

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éristiques 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 contrô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 relais LTE. Nous montrons alors que cette interface peut être modifiée légèrement pour être utilisée par les e2NBs afin de réaliser les liaisons inter-noeuds. 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", 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 modifications 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 efficacement 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 noeuds 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 soustrame (Subframe (SF) de 1ms). Nous expliquons ainsi que nous pouvons exploiter certains paramétrages des UEs classiques pour fournir une fenêtre d'écoute plus longue aux vUEs de détection. Nous abordons 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 diagrammes 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 coeur 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'ordonnancement 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é basée sur une interface Time Division Multiple Access (TDMA), de façon intelligente afin de réduire les interférences subies. De nombreuses é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 Division 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. 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 particulier 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 indicateurs de qualité de canal et d'interférence avec les noeuds 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 Algorithm (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 réception. Ces algorithmes tiennent compte de l'état des canaux radio 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ériodique 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.

Coordination & Orchestration Entity Controller

COE Controller Scheduling Algorithm

Coordination & Orchestration Entity Agent

Chaque e2NB, par le biais de son ordonnanceur interne, le Distributed Link Scheduler (DLS) (Algorithme 5), peut alors décider pour chaque sous-trame qui lui est attribuée à quels e2NBs il transmettra, 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 étendre 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 proposé, 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 soustrame. 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érarchique dans un simulateur développé sur MatLab et nous simulons plusieurs topologies de réseaux maillés avec 7 ou 19 e2NBs qui chacun 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 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 importance, 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 section 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 équivalente 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éveloppement.

b.8 conclusion

Dans cette thèse, nous proposons une nouvelle architecture de station 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 identifié les lacunes des solutions techniques actuelles, montrant qu'elles ne sont pas adaptées à des scénarios de cellules en mouvement. Constatant 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 solution, 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é entre 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.

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égration de fonctions de coeur 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écifiques 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èrement, nous avons évalué la couche physique proposée pour le maillage 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 approche 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 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 proposé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èrement, alors que nous avons conçu la plupart des fonctionnalités requises par l'e2NB, seulement une partie d'entre elles ont été mises en oeuvre et expérimentées. Concernant la couche physique, la synchronisation 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. Concernant les couches supérieures, nous avons défini le contenu des messages qui devrait être échangés entre e2NBs pour permettre les communications 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 processus 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 noeuds ou un nombre é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 coeur 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 coeur 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 fonctionnement avec les stations de base multi-sectorielles ont été proposé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. Cependant, 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 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 [START_REF]MulteFire Alliance[END_REF] pourrait également être envisagé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 Functions Virtualization (NFV)) du Radio Access Network (RAN) car il repose sur l'utilisation des vUEs orchestrés par le COE de

vii b. 2 . 2

 22 Figure 1Overview of military and naval communications Figure2Network topologies -scenarios 1, 2 and 3. . . . Figure3Network topologies -scenarios 4, 5 and 6. . . . Figure4Network topologies -scenarios 7 and 8. . . . . Figure5Network topologies -scenarios 9, 10, 11 and 12. Figure6Evolution of cellular system standards. . . . . Figure7LTE nominal architecture (Release 8). . . . . . Figure83GPP PS oriented work items. . . . . . . . . . . Figure9Topologies based on standard LTE BTS (1,2,3) and the envisioned LTE network (4). . . . . . . Figure10e2NB stack. . . . . . . . . . . . . . . . . . . . . . Figure11Main e2NB states. . . . . . . . . . . . . . . . . . Figure12Example of different network topologies based on e2NBs. . . . . . . . . . . . . . . . . . . . . . . Figure13LTE resource grid for a 1.4MHz (6 PRBs) channel width. . . . . . . . . . . . . . . . . . . . . . . Figure14Symbol allocation in a SF for Uu and Un interfaces. . . . . . . . . . . . . . . . . . . . . . . . . Figure15Resource allocation example of DL at DeNB/RN. Figure16Non-synchronized e2NB transportation. . . . . Figure17Connection procedure. . . . . . . . . . . . . . . Figure18Startup phase operation flow. . . . . . . . . . . Figure19Isolated state operation flow. . . . . . . . . . . Figure20Meshed state operation flow. . . . . . . . . . . Figure21vUE relay state operation flow. . . . . . . . . . Figure22Coordination and Orchestration Entity architecture. . . . . . . . . . . . . . . . . . . . . . . . Figure23R-PDCCH and PDCCH computational time. . Figure24

Figure 1 -

 1 Figure 1 -Overview of military and naval communications

  Speech transmission performance -Video transmission performance -QoS (packet loss, jitter, latency)

Figure 2 -Figure 3 -Figure 4 -Figure 5 -

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

  (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;

Figure 6 -

 6 Figure 6 -Evolution of cellular system standards.

Figure 7 -

 7 Figure 7 -LTE nominal architecture (Release 8).

Figure 9 -

 9 Figure 9 -Topologies based on standard LTE BTS (1,2,3) and the envisioned LTE network (4).

-

  Figure 10 presents the proposed e2NB stack, designed to fully satisfy the requirements delineated in section 2.3.1 to enable an autonomous 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.).

Figure 10 -

 10 Figure 10 -e2NB stack.

Figure 11 -

 11 Figure 11 -Main e2NB states.

Figure 12 -

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

Figure 13 -

 13 Figure13-LTE resource grid for a 1.4MHz (6 PRBs) channel width.

  (a). Whereas both transmission (to UEs) and reception (from DeNBs) are required at RN2 as depicted in Figure15(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 Sounding Reference Signal (SRS). Moreover, there is no Acknowledgment (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) information 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. Resource allocation example at RN2 (TX/RX).

Figure 15 -

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

  offset between e2NB1 and e2NB2 R-PDCCH/R-PDSCH (From e2NB1 to e2NB2) OK TX→RX switching time RX→TX switching time (a) From early e2NB to late e2NB. /R-PDSCH ( From e2NB2 to e2NB1) Fail TX→RX switching time RX→TX switching time (b) From late e2NB to early e2NB.

Figure 16 -

 16 Figure 16 -Non-synchronized e2NB transportation.

Figure 18 -

 18 Figure 18 -Startup phase operation flow.

Figure 19 -

 19 Figure 19 -Isolated state operation flow.

Figure 20 -

 20 Figure 20 -Meshed state operation flow.

Figure 22 -

 22 Figure 22 -Coordination and Orchestration Entity architecture.

Figure 23 -Figure 24 -

 2324 Figure 23 -R-PDCCH and PDCCH computational time.

Figure 25 -

 25 Figure 25 -Minimum SNR level to decode 75% of the TBs.

Figure 26 -

 26 Figure 26 -Minimum SNR level for several aggregation levels.

  (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 -

 27 Figure 27 -Considered network topologies.

  1. A baseline algorithm which is unaware of the required SF of both real-time and elastic traffics, i.e. SF D rt [u] = 1 and SF D e [u] = k > 1, SF U e [u] = k > 1, ∀u ∈ V e2N B . It only aims to allocate the same number of backhaul SFs to each e2NB, and is denoted as Basic (or B.).

  Throughput of elastic flows over three elastic traffic scenarios.

  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 -

 28 Figure 28 -Hexagonal topology with 7 e2NBs and 70 UEs using 10MHz in FDD mode.

  .(b) shows the CDF of the 95-percentile point of perflow 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 Throughput of elastic flows over three elastic traffic scenarios.

  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 -

 29 Figure 29 -Hexagonal topology with 7 e2NBs and 70 UEs using 10MHz in TDD mode.

  Throughput of elastic flows over three elastic traffic scenarios.

  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 -

 30 Figure 30 -Hexagonal topology with 7 e2NBs and 70 UEs using 10MHz in TDD mode or 5MHz in FDD mode.

  B. V DL. V UL. V B. V DL. V UL. V B. V DL. V UL.Throughput of elastic flows over three elastic traffic scenarios.

  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 -

 31 Figure 31 -Line topology with 7 e2NBs and 70 UEs using 5MHz in FDD mode.

  Throughput of elastic flows over three elastic traffic scenarios.

  CDF plot of the 95-th percentile of packet latency among real-time flows with two elastic flows: 2 → 6 and 7 → 5.

  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 -

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

  Throughput of elastic flows over three elastic traffic scenarios.

  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 -

 33 Figure 33 -Line topology with 7 e2NBs and 70 UEs using 10MHz in TDD mode or 5MHz in FDD mode.

  Throughput of elastic flows over three concurrent elastic flows. region have less than 95% of their packets arriving in less than 150ms (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. region have less than 95% of their packets arriving in less than 150ms (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 -

 34 Figure 34 -Hexagonal topology with 19 e2NBs and 190 UEs using 5MHz in FDD mode.

Figure 35 -

 35 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.

  Throughput of elastic flows over three concurrent elastic flows. 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 -

 36 Figure 36 -Hexagonal topology with 19 e2NBs and 190 UEs using 10MHz in FDD mode.

  Throughput of elastic flows over three concurrent elastic flows. 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.

  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 -

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

( b )Figure 38 -

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

Figure 39 -

 39 Figure 39 -Data rate of traffic flow of in/out-band deployments.

Figure 40 -

 40 Figure 40 -Cumulated data rate of two traffic flows.

ALatency

  A D D I T I O N A L F I G U R E SThis appendix gathers figures that were not displayed in section 7.2 to improve readability. Hexagonal topology with 7 e2NBs CDF plot of the 95-th percentile of packet latency among real-time flows. 1 → 2 elastic flow scenario. CDF plot of the 95-th percentile of packet latency among real-time flows. 4 → 6 elastic flow scenario.

Figure 41 -

 41 Figure 41 -Hexagonal topology with 7 e2NBs and 70 UEs using a 10MHz FDD configuration.

Figure 42 -

 42 Figure 42 -Hexagonal topology with 7 e2NBs and 70 UEs using a 10MHz TDD configuration.

  CDF plot of the 95-th percentile of packet latency among real-time flows. 1 → 2 elastic flow scenario. (b) CDF plot of the 95-th percentile of packet latency among real-time flows. 4 → 6 elastic flow scenario.

Figure 43 -

 43 Figure 43 -Hexagonal topology with 7 e2NBs and 70 UEs using a 10MHzTDD and a 5MHz FDD configuration.

Figure 44 -

 44 Figure 44 -Line topology with 7 e2NBs and 70 UEs using a 5MHz FDD configuration.

Figure 46 -

 46 Figure 46 -Line topology with 7 e2NBs and 70 UEs using a 10MHz TDD or a 5MHz FDD configuration.

b. 2

 2 état de l'art et définition de la problématique b.2.1 Cas d'utilisation militaires

  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 -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 systèmes actuellement déployés -Configuration, utilisation et maintenance simple ou automatique -Faible Capital expenditure (CAPEX) et Operating expense (OPEX) b.2.2 Communications pour la sécurité publique

Figure 48 -

 48 Figure 48 -Architecture nominale du LTE (Release 8).

Figure 50 -

 50 Figure 50 -Topologies réseaux réalisables à parti des spécifications LTE (1,2,3) et réseau LTE visé (4).

Figure 51 -

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

  Figure 52.

Figure 52 -

 52 Figure 52 -États principaux de l'e2NB.

Figure 53 -

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

Figure 54 -

 54 Figure 54 -Architecture du COE (Coordination and Orchestration Entity).

Table

  Medium range ship-to-ship communication systems vs military satellite . . . . . . . . . . . . . 7 Table Possible network scenarios . . . . . . . . . . . . 10 Table Considered scenarios . . . . . . . . . . . . . . . 13 Table Comparison of different LTE meshing solutions 25 Table Comparison of LTE meshing solutions . . . . . 42 Table Comparison of centralized and distributed schedulers . . . . . . . . . . . . . . . . . . . . . . . . . 62 Table Compared algorithms with corresponding notations . . . . . . . . . . . . . . . . . . . . . . . . 84 Table Summary of the evaluation results . . . . . . . 98 Table Systèmes de communication navals à moyenne portée et système de communication par satellite127

xv 1

  and N. Nikaein, "Wireless mesh backhauling for LTE/LTE-A networks," MILCOM 2015 -2015 IEEE Military Communications Conference, Tampa, FL, 2015, pp. 695-700. -R. Favraud, A. Apostolaras, N. Nikaein and T. Korakis, "Toward moving public safety networks," in IEEE Communications Magazine, vol. 54, no. 3, pp. 14-20, March 2016.

-R.

Favraud

, A. Apostolaras, N. Nikaein and T. Korakis, "Public safety networks: Enabling mobility for critical communications," in Wireless Public Safety Networks 2 : A systemic approach, Wiley-ISTE, 2016.

Table 1 -

 1 Medium range ship-to-ship communication systems vs military satellite

	System	UHF SNR [4] / RIFAN 2 Satellite (Syracuse [5])
	Frequency band	UHF	SHF, EHF
		(500 KHz wide channel)
	Maximum data-rate	< 2 Mbps	5 Mbps unprotected
			2 Mbps protected
	Minimum latency	> 100 ms	240 ms on spot
			480 ms otherwise
	Range	Radio visibility (UHF)	Satellite coverage

Table 2 -

 2 Possible network scenarios

	Scenario	UE-to-BTS	BTS-to-CN	BTS mobility	BTS-to-BTS
		connectivity	connectivity		connectivity
	1	In BTS coverage

Table 3 -

 3 Considered scenarios

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

 4

		Low	Medium
	flexibility
	Scheduling	Medium	Medium to High
	complexity
	Self-backhauling	+ to +++	+++
	coverage	(depends on RAT)
	Hardware	+ to +++	+
	cost	(depends on RAT and bands)

Table 5 -

 5 Comparison of LTE meshing solutions

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

Isolated state (vUE, eNB)

	No new e(2)NB	e(2)NB detection	New eNB detected
	detected		procedure
	Remote vUEs		New e2NB detected
	supervision No change	New Remote vUE	e2NB connection procedure	Fail	Update embedded eNB parameters
	connection	Initialize new vUE
			To

meshed state Success To isolated state To isolated state

		Conflict eNB
		parameters
	No	Yes	Update topology
		Update embedded	and routes
		eNB parameters
			Merge procedures

Table 6 -

 6 Comparison of centralized and distributed schedulers

	Characteristic	CNS	DLS
	Network view	Central view of mesh e2NBs	Local view of neighboring vUE/UE
	Periodicity	Large time-scale (e.g., frame, superframe)	Small time-scale (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
	Node prioritization	Prioritize e2NB with high real-time demand	Prioritize vUE over UE

  the set of e2NBs L SuF is the superframe duration L is the set of link load with load u,v of edge u → v N u is the neighboring e2NB set of u from V e2N B Output : SF D rt is the set of the number of SFs required by each e2NB for real-time traffic transportation begin foreach u ∈ V e2N B do nP RB U [u] = 0 ; /* Initialize allocated UL PRBs of u */ foreach v ∈ N u do LL u,v = load u,v ; /* Initialize each link load */

Table 7 -

 7 Compared algorithms with corresponding notations

	Algorithm	Traffic	Possible UE pairing	Notation
		Only elastic	-	B.
	Baseline	Real-time	Pair users with N hop ≤ 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 N and elastic No restriction on pairing	DL. V
		Only elastic	-	UL.
	Full	Real-time	Pair users with N hop ≤ 1/2/3 UL. 1V, UL. 2V, UL. 3V
		and elastic	No restriction on pairing	UL. V

hop ≤ 1/2/3 DL. 1V, DL. 2V, DL. 3V

Table 8 -

 8 Summary of the evaluation results

	Scenario	Best VoIP latency	Best elastic data rate	Best 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

  Un ensemble de services et applications pour permettre la fourniture minimale de services aux UEs connectés, tels des services voix, de localisation, etc. Ensuite, nous souhaitons concevoir un système qui permette l'interconnexion 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 noeuds, 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éation 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 : Des mécanismes de coopération entre services et applications fournies par différents noeuds 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.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 communication 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. 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 notent que le LTE a émergé comme la technologie de choix pour les futures 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 radio grâce à des puissances maximales d'émission élevées et support natif des flux Internet Protocol (IP). Ferrus et Al.[START_REF] Ferrus | LTE: the technology driver for future public safety communications[END_REF] 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 évolutions pour répondre aux exigences des réseaux de communication de sécurité publique.

	Radio Service (GPRS)/ Universal Mobile Telecommunication System (j) b.3 contraintes de conception et choix de la technolo-(UMTS) /
		gie d'accès radio
	Nous exposons les contraintes externes qui s'appliquent sur le sys-Il tème et procédons au choix des technologies de transmission sans fil doit ainsi disposer de : (Radio Access Technologies (RATs)).
	(a) Une couche radio pour servir les UEs locaux comme une station
	de base classique; b.3.1 Contraintes externes
	(b) Un ensemble minimal de fonction de coeur de réseau pour as-
	surer la gestion des UEs locaux, les fonctions d'authentifications, En plus des exigences fonctionnelles précédemment déterminées,
	etc.;	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 (c) (d) Une interface de communication sans fil pour établir des li-de spectre n'est pas assurée.
	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; b.3.2 Choix de la technologie d'accès radio
	(h) Des mécanismes de connexion entre les coeurs de réseau des L'étude de Baldiny de 2013 [9] nous renseigne sur les systèmes de différentes stations de base pour permettre la mobilité transpar-communication mis en oeuvre pour les communications de sécurité ente des UEs sur le réseau créé; publique : Analog Professional Mobile Radio (PMR) ; Digital Mo-
	(i) Des mécanismes de routage efficaces pour transporter le trafic bile Radio (DMR) ; P25 ; TETRA V.1 ; TETRA V.2 ; TETRAPOL ;
	sur le réseau à travers plusieurs bonds sans fil; Global System for Mobile communications (GSM) / General Packet

  Figure 49 -Travaux du 3GPP orientés sécurité publique. 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 possibilités pour réaliser ces liaisons sans fil en l'absence d'accès à un coeur 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 supplé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 objectifs 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 spectrales entre le réseau d'accès (eNB -UE) et le réseau backhaul (eNB -eNB).

	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 Push To Talk 22.179 23.179 23.379 24.379 24.380 24.980	Mission Critical Data 22.282 22.880 23.282 24.282 24.582
			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

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

  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 permettant 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 nommons e2NB, s'appuie sur le LTE pour fournir un service d'accès radio 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 mobilité 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
	vUE	NAS	Local EPC	MME HSS	S-GW P-GW	eNB
	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

  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 intercouches. Enfin, bien que nous soyons confiants sur la possibilité d'adapter la solution proposée pour une utilisation avec les futurs systèmes de communication cellulaire, la compatibilité avec la nouvelle radio 5G (5G New Radio (5G NR)) et la numérologie multiple associée devrait être évaluée afin de déterminer les modifications nécessaires.

	Acronyms
	A C R O N Y M S IMS IMSI IOPS RN ROHC R-PDCCH IP R-PDSCH	DeNB DL DLS IP Multimedia Subsystem. Donor evolved Node B. Downlink. Distributed Link Scheduler. International Mobile Subscriber Identity. Isolated E-UTRAN Operation for Public Safety. P25 Project 25. PAPR Peak to Average Power Ratio. Relay Node. Robust Header Compression. Relay Physical Downlink Control Channel. DLSS Downlink StartSymbol. Internet Protocol. PCFICH Physical Control Format Indicator Channel. C Relay Physical Downlink Shared Channel.
	ISM RRC	DMR Industrial, Scientific, and Medical. Digital Mobile Radio. PCI Physical Cell Identity. Radio Resource Control.
	ITS RSRP	DMRS Intelligent Transportation System. Demodulation Reference Signal. PCRF Policy and Charging Rules Function. Reference Signal Received Power.
	3GPP ITU RX	3rd Generation Partnership Project. International Telecommunication Union. PDCCH Physical Downlink Control Channel. Receiver.
	5G NR	5G New Radio. e2NB enhanced evolved Node B. PDSCH Physical Downlink Shared Channel.
	kbps SC-FDMA	ECGI kilobit per second. E-UTRAN Cell Global Identifier. PEP Performance-Enhancing Proxy. Single Carrier Frequency division Multiple Access.
	ACK SCTP	Acknowledgment. ECI E-UTRAN Cell Identifier. P-GW Packet Data Network Gateway. Stream Control Transmission Protocol.
	ADC LAA SDN	Analog-to-Digital Converter. EHF Extremely High Frequency. Licensed Assisted Access. PHICH Physical Hybrid-ARQ Indicator Channel. Software-Define Networking.
	AFR LOS SF	Average Frequency Reuse. eICIC enhanced Inter Cell Interference Coordination. Line of Sight. PHY Physical. Subframe.
	AMC LTE S-GW	Adaptive Modulation and Coding. eMBMS evolved Multimedia Broadcast Multicast Service. Long Term Evolution. PLMN Public Land Mobile Network. Serving Gateway.
	ANR LTE-A SIB	Automatic Neighbour Relation. EMHS Emergency Medical and Health Services. LTE Advanced. PMR Professional Mobile Radio. System Information Block.
	ARQ SINR	Automatic Repeat reQuest. eNB evolved Node B. ppb parts-per-billion. Signal to Interference and Noise Ratio.
	MAC SISO	EPA Medium Access Control. Extended Pedestrian model A. ppm parts-per-million. Single Input Single Output.
	BS MBSFN SNR	Base Station. EPC Multicast Broadcast Single Frequency Network. Evolved Packet Core. PRACH Physical Random Access Channel. SubNetwork Relay.
	BTS MCPTT SON	Base Transceiver Station. EPS Evolved Packet System. Mission Critical Push-To-Talk. PRB Physical Resource Block. Self Organizing Network.
	MCS SRS	ESI Modulation and Coding Scheme. End Symbol Index. ProSe Proximity Services. Sounding Reference Signal.
	C4I MIB SS CA MIMO SSS CAPEX MME SuF CDF MOS CFI MSISDN TAI CFO TAU CN TB CNS NACK TBS COE NATO TDD COTS NDI TDM CQI NeNodeB TDMA CRC NFV TETRA CRS NN TM CSA nrt TR TS CSMA/CA Carrier Sense Multiple Access with Collision Command, Control, Communications, Computers, E-UTRAN Evolved Universal Terrestrial Radio Access Net-Master Information Block. PS Public Safety. Subscriber Station. and Intelligence. work. Multi Input Multi Output. PSS Primary Synchronization Signal. Secondary Synchronization Signal. Carrier Aggregation. Mobility Management Entity. PTMP Point To Multi-Point. SuperFrame. Capital expenditure. FD Full Duplex. Mean Opinion Score. PTP Point To Point. Cumulative Distribution Function. FDD Frequency Division Duplexing. Mobile Subscriber Integrated Services Digital Net-PTT Push-To-Talk. Tracking Area Identity. Control Format Indicator. FeICIC Further enhanced Inter Cell Interference Coordina-work Number. PUCCH Physical Uplink Control Channel. Tracking Area Update. Carrier Frequency Offset. tion. PUSCH Physical Uplink Shared Channel. Transport Block. Core Network. FirstNet First Responder Network Authority. Non-acknowledgment. Transport Block Size. Centralized Node Scheduler. North Atlantic Treaty Organization. QoS Quality of Service. Time Division Duplexing. Coordination and Orchestration Entity. GPRS General Packet Radio Service. New Data Indicator. Time Division Multiplexing. Commercial Off-The-Shelf. GPS Global Positioning System. Nomadic eNodeB. RA Random Access. Time Division Multiple Access. Channel Quality Indicator. GPSDO Global Positioning System Disciplined Oscillator. Network Functions Virtualization. RACH Random Access Channel. Terrestrial Trunked Radio. Cyclic Redundancy Check. GSM Global System for Mobile communications. Nokia Networks. RAN Radio Access Network. Transmission Mode. Cell-Specific Reference Signals. GTP GPRS Tunneling Protocol. Neighbour Relation Table. RAT Radio Access Technology. Technical Report. Controller Scheduling Algorithm. RB Resource Block. Technical Specification. HARQ Hybrid Automatic Repeat reQuest. OAI Open Air Interface. RBP Resource Block Pair. TTI Transmission Time Interval. Avoidance. HD Half Duplex. OFDM Orthogonal Frequency Division Multiplexing. RE Resource Element. TX Transmitter.
	D2D OFDMA DCI OPEX UAV	HSS Orthogonal Frequency Division Multiple Access. Home Subscriber Server. RF Radio Frequency. Device-to-Device. IMEI International Mobile Equipment Identity. Downlink Control Information. Operating expense. RIFAN 2 Réseau Intranet des Forces Aéro-Navales 2. Unmanned Aerial Vehicle.
		147

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

Some related services and application can also be included such as IP Multimedia Subsystem (IMS).

Based on the transmission mode, the Demodulation Reference Signal (DMRS) will be used.

Based on the schedulingInfoList in SIB1.

sort_descend (V, a, b, • • • ) is to sort V in descending order following the metric ordering from a, b and so on.

/*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 (SF T X in Algorithm 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., SF T X ) to distributively allocate the transportation resources at each SF (DLS as presented in section 6.3.3 and Algorithm 5).

In the following, we detail on the CSA operation.

Algorithm 5: Distributed Link scheduler (DLS)

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

relaying direction selection

As mentioned beforehand, both DL and UL directions can be selected during relaying in backhaul links. It means that each packet can go over the DL or UL direction to reach the next hop. However, 9.

Appendices