Keywords: API Application Programming Interface. 46, 90 ARP Address Resolution Protocol. 78 AWG Arrayed Waveguide Grating. 70, 77 B2B Back to Back. 75 BAA Broadband Access Abstraction. 31

Philippe Chanclou

Ingénieur d'études, Orange Labs (FR)

vi La troisième partie, composée du Chapitre 6, montre deux approches d'abstraction d'éléments de réseau dans le réseau d'accès. Dans la première approche on présente un scénario qui met en évidence des fonctionnalités clés dans le réseau d'accès du futur comme la convergence fixe mobile et le Mobile Edge Computing (MEC). Cette solution consiste à transporter un signal mobile dans une architecture fixe/mobile, rendu possible à travers un serveur standard qui comporte un lien point à multipoint mise en place à travers un OLT miniature avec un plan de contrôle déporté dans une machine distante. La deuxième approche consiste à démontrer le concept de multi-tenancy et multi-service à travers l'abstraction des paramètres physiques du réseau. On a réussi à travers cette abstraction de créer des network slices consistant en une découpe virtuelle du réseau, chaque «slice» peut être déployé de manière ininterrompue à travers une interface centralisé. Cet exemple vient servir un cas d'usage spécifique qui consiste à fournir de différentes classes de services à différents utilisateurs, en l'occurrence des opérateurs mobiles, pour pouvoir déployer leurs services dans un réseau d'accès qui contient une partie en fibre et une autre en sans fil. Le manuscrit se termine par un résumé général des travaux réalisés au cours de cette thèse, ainsi qu'une ouverture sur d'éventuels travaux futurs et perspectives pour le réseau d'accès de demain. Ma thèse était entourée d'un riche écosystème de projets. Le premier est un projet de recherche interne d'Orange (Réseaux Optiques). Ce projet est transversal entre les équipes du réseau d'accès optique et du segment optique longhaul. Le second est 5G-PHOS (H2020-ICT-2016-2) un projet européen axé sur la création d'une solution de réseau d'accès hybride pour la 5G. Cette solution est composée d'un segment fibre relié à un segment sans fil. Cette thèse a commencé juste après la fin du projet 5GCrosshaul et même si les travaux décrits ici n'ont pas été réalisés dans son cadre, nous avons eu la chance de bénéficier d'un de ses éléments clés : la solution virtuelle RAN et EPC. Ceux-ci sont au coeur même de cette thèse.

Tout au long de ce travail, nous avons tenté de répondre à une question importante concernant les aspects définissant une convergence fixe/mobile. Nous avons tenté aussi de répondre au défis futurs du réseau d'accès en essayant de répondre à deux questions, la première concerne l'augmentation de la capacité des interfaces du réseau d'accès optique en terme de débit. La seconde se porte sur la potentielle amélioration du contrôle de ce réseau de façon a mieux accommoder les cas d'usages mobile et pousser encore plus la convergence fixe/mobile dans le réseau d'accès optique.

Resumé

Le réseau d'accès est le dernier segment du réseau télécom, il connecte les utilisateurs finaux (les abonnées fixe et mobile) à leur fournisseur de service. Il est défini comme l'ensemble de connections entre un central office (CO) et les équipements qui servent l'utilisateur final. Il établit cette connexion à travers différents supports de transmission comme le cuivre, la fibre optique ou l'air (avec une transmission radio). Le réseau d'accès peut servir différent types de points. Ces points varient entre des utilisateurs résidentiels communément désigné par le terme Fiber To The Home (FTTH) et les sites antennaires qui, à leur tour, servent les clients mobile, ce dernier connu sous le nom de Radio Access Network (RAN).

L'apparition de la fibre comme solution durable à faible coût pour le transport de hauts débits à travers les différent segments du réseau télécom a permis la démocratisation du haut débit que ce soit pour les résidences, les entreprises ou les sites antennaires. Cela a poussé l'adoption graduelle de la fibre au lieu du cuivre ou des liens radio à tous les niveaux du réseau, y compris le réseau d'accès en ce qui est nommé par conséquent le réseau d'accès optique.

Le réseau d'accès optique actuel connecte les clients fixes généralement à travers des interfaces fournis par la technologie PON et pour les sites antennaires à travers des interfaces comme l'Ethernet et CPRI. Les réseaux d'accès fixe et mobile ont leurs propres générations de technologies qui réussissent à chaque itération à offrir plus de bande passante à l'utilisateur final.

Dans le cas des clients fixes, les solutions 10 Gbit/s telles que le XGS-PON sont actuellement déployés offrant plus de bande passante que la précédente solution GPON avec du 2.5 Gbit/s. Pour les clients mobiles, nous nous apprêtons à déployer la 5G, la nouvelle génération de communication mobile succédant à la 4G.

La 5G se veut disruptive par nature. En poussant au delà de l'évolution traditionnelle de la bande passante entre générations qui, d'ailleurs promet d'être 10 fois plus grande que celle de la 4G. La 5G promet d'exploiter de nouvelles technologies de l'industrie des télécommunications telles que le cloud computing ainsi que l'utilisation d'une nouvelle gamme de fréquences radio qui n'était pas envisagée auparavant.

Le réseau d'accès optique du futur doit pouvoir s'adapter à ce caractère disruptif de la 5G et devrait être équipé d'un arsenal fiable d'outils, de protocoles et de règles d'ingénierie pour pouvoir faire face aux défis de la 5G et tenir ses promesses.

Cette thèse vise à mettre en évidence l'impact et les défis apportés par l'avènement de la 5G sur le réseau d'accès. Ce dernier étant parmi les segments les plus délicats du réseau télécom.

A travers les contributions de cette thèse, nous proposons des solutions s'inscrivant dans ce contexte de la nouvelle génération de transmission mobile. Ce sujet est traité à travers deux paradigmes: le premier étant la virtualisation et le second la proposition et l'évaluation de nouvelles solutions de transmission optique pour le RAN. Le manuscrit est structuré en trois parties principales. La première partie est composée de trois chapitres détaillant le contexte et la motivation de la thèse. Dans iv le premier chapitre le contexte de la thèse est détaillé, en commençant par une définition de l'écosystème 5G à travers les différentes technologies, services et concepts qui y seront utilisés. Par exemple, en termes de nouvelles technologies, la 5G s'aventure dans le spectre des ondes millimétriques et l'utilisation du massive MIMO pour mener des opérations de beamforming et beam steering. Côté services, la 5G promet une bande passante 10 fois supérieure à la 4G et promet une faible latence pour les applications critiques ainsi qu'une densité de connexion plus élevée pour un nombre massif de machines communicantes. La 5G va introduire également de nouveaux concepts dans le réseau mobile, tels que le Mobile Edge Computing, la prise en charge de plusieurs technologies d'accès, le découpage de bout en bout du réseau connu sous le nom de slicing et l'utilisation de la virtualisation à travers le concept de SDN et NFV ainsi que la redistribution des fonctionnalités de la machine RAN dans le réseau d'accès connu sous le nom de découpes fonctionnelles (functional splits). Ces concepts ont été définis comme des éléments clés pour des nouveaux cas d'usage de la 5G, par exemple le NFV offrant une flexibilité de déploiement et le SDN comme support pour le slicing permettant de réaliser de la multi-tenancy et la création de différents classes de services. Le chapitre se termine en présentant les principales initiatives de virtualisation dans le RAN avec un objectif principal d'avoir un déploiement flexible du RAN qui peut bénéficier de l'ouverture des interfaces.

Le deuxième chapitre présente le réseau d'accès optique sous-jacent qui est utilisé pour transporter les diverses connexions en fibre jusqu'à l'utilisateur final, FTTA et FTTH pour les clients mobiles et fixes respectivement. L'objectif de ce chapitre est de présenter l'infrastructure physique sur laquelle la 5G sera transportée pour expliquer comment certains des concepts 5G tels que les découpes fonctionnelles se concrétisent dans cette infrastructure et comment la nouvelle bande passante 5G affectera le système optique du réseau d'accès. Dans ce chapitre, nous avons présenté les principales initiatives de virtualisation dans l'accès fixe qui se concentrent principalement sur la virtualisation des fonctionnalités PON en termes de VNF et le concept de multi-service/multi-location classique pour le SDN.

Le troisième chapitre présente à travers le contexte de la virtualisation, les progrès des initiatives de recherche industrielle et universitaire. Dans ce chapitre, nous avons essayé de concilier les mondes fixe et mobile en présentant un état de l'art des travaux de recherche visant à faire évoluer le réseau d'accès. Nous nous sommes concentrés sur des travaux de recherche utilisant les technologies de virtualisation comme acteurs dans divers scénarios fixes et mobiles dans le réseau d'accès, y compris leur éventuelle convergence. Ce troisième chapitre a servi de référence afin de pouvoir mettre en perspective ce travail de thèse et le positionner dans le cadre de l'état de l'art. Ce chapitre conclut la première partie du manuscrit en présentant le contexte de cette thèse et l'état de l'art qui l'entoure.

La deuxième partie présente le bilan de transport de notre mise en oeuvre d'une solution mobile industrielle dans le réseau d'accès. Cette solution repose sur une infrastructure virtuelle gérée par un gestionnaire d'infrastructure virtuelle mettant à l'épreuve le concept NFV dans le monde mobile : La deuxième partie est composée de deux chapitres, le premier (Chapitre 4) est dédié à la présentation de nos travaux expérimentaux en termes de mise en oeuvre d'une solution mobile comprenant des éléments du coeur mobile et du RAN virtuel (vRAN). Ce chapitre s'est concentré sur la description de l'infrastructure virtuelle ainsi que sur le positionnement de ses divers éléments dans le cadre ETSI NFV. Nous avons ensuite évalué la solution mobile composée du coeur mobile LTE (Evolved Packet Core (EPC)) et du Radio Access Network (RAN) dans une découpe fonctionnelle PDCP-RLC. L'évaluation v a été réalisée en ce qui concerne les performances globales des différents blocs VNF et la manière dont les ressources virtuelles en termes de RAM et de nombre de processeurs ont affecté les performances de la solution, mesurées par le taux de perte de trames, la latence et la gigue des paquets. Cela nous a permis de choisir son point de fonctionnement optimal afin d'évaluer les solutions optiques présentées dans le chapitre suivant.

Le chapitre 5 s'est concentré sur l'évaluation du transport du trafic de la plateforme mobile virtuelle ainsi que d'autres options de découpe fonctionnelles mobile en utilisant différents solutions de transmission optique. Afin de répondre aux questions sur la façon dont une plate-forme virtualisée réagit au transport physique sous-jacent, dans cette évaluation, nous avons réussi à tester différentes configurations :

• Le NRZ classique point à point : cette configuration a servi de référence aux autres configurations puisque c'est l'approche traditionnelle pour transporter des interfaces mobiles.

• PAM4 point à point : construction sur un prototype qui était un sujet de recherche ayant lieu en même temps que cette thèse [START_REF] Barthomeuf | Real-time Downstream 25 Gbps PAM4 for High Speed TDM-PONs with both 25 and 12[END_REF]. Nous avons réussi à transporter le trafic mobile sur une solution telle que pour le même débit en bauds qu'une solution NRZ, nous avons doublé le débit en codant des bits sur quatre niveaux d'amplitude. Nous avons réussi à transporter avec succès nos données mobiles sur du PAM4 (Pulse Amplitude Modulation). Nous avons évalué les effets de cette modulation en la comparant à la modulation NRZ (Non Return to Zero) classique en termes de perte de paquets, de latence et de gigue de paquet.

• WDM PON point à point : un prototype allant jusqu'à 25Gbit/s/λ a été testé, montrant la flexibilité qui peut être atteinte dans le réseau d'accès du futur grâce à la convergence de différentes interfaces (Ethernet et eCPRI) au niveau de l'équipement d'accès (OLT) rendu possible grâce à l'accordement automatique en longueur d'onde et poussant le débit binaire autorisé dans l'accès par la biais du multiplexage en longueur d'onde. Cette solution repose sur un prototype d'un fabricant tiers qui utilise le multiplexage en longueur d'onde basé sur la technologie PON. Le trafic a testé est généré avec une interface fronthaul eCPRI. Grâce à cette étude, nous avons réussi à évaluer la capacité de cette solution à accueillir le transport du fronthaul avec les différentes classes de latence.

• XGS-PON point à multipoint : utilisant une solution d'accès fixe pour transporter un signal mobile, ce signal mobile a été transporté dans le même arbre PON à côté d'un signal fixe pour évaluer les effets de ce dernier dans un scénario où il y a une convergence entre clients fixe et mobile sur le même support fibre. La solution a été utilisé pour transporter le trafic de la plate-forme virtuelle agrégé avec un trafic fixe émulé. Le but est d'évaluer un scénario de convergence fixe/mobile où le trafic mobile peut être déchargé dans une solution d'accès fixe de type PON dans une architecture point à multipoint.

• Présentation d'un cas d'utilisation spécifique de la 5G qui a suscité notre intérêt, à savoir un scénario de communication mobile haut débit pour la 5G. Nous avons utilisé la technologie XGS-PON pour montrer une preuve de concept de cette transmission appuyée par des considérations théoriques pour un déploiement sur le terrain.

• Implementation of a virtual infrastructure to host a mobile solution with a high layer PDCP-RLC split. This solution comprises of core network and virtual RAN (vRAN) elements.

• Testing optical solutions in the transport of various split options through a lab implemented optical access network. Our tests have been mainly focusing on the high layer vRAN split while exploring potential key network features of the future such as fixed mobile convergence and Mobile Edge Computing (MEC). Conventional point to point have been evaluated but also, in a less conventional way, point to multipoint approaches. The latter approaches have been proposed in the context of fixed mobile convergence as well as to meet the service requirements of 5G.

• Explicitly showcase an instance of abstraction in the network thanks to software defined networking. We work on a case that simplifies the configuration of radio signal generation/analyse equipment in order to set up classes of services and slicing through the optical access network.

Introduction

The access network is the last segment of the telecommunication network, connecting the end user (fixed and mobile subscribers) to their respective service provider. The access network is defined as the set of connections between a central office and the equipment serving the end users. It brings connectivity to the end user through various physical media such as copper, fiber and wireless. The access network can serve various types of endpoints ranging from home users in what's known as Fiber To The Home (FTTH) to antenna sites which in turn serve mobile clients in what's known as Radio Access Network (RAN).

The apparition of fiber as a sustainable, low cost solution for high bandwidth transport on various segments of the telecom network has allowed the democratization of high speed access for all end users be it homes, businesses as well as antenna sites. This prompted the gradual adoption of fiber instead of copper or microwave links at all the levels of the network including the access in what is referred to as the optical access network.

The current optical access is the provider of fiber to fixed clients mainly through interfaces provided by the PON technology, and to the antenna sites through interfaces such as Ethernet and CPRI. Both the fixed and mobile access networks have their own generations of technologies that succeed with each iteration to offer more bandwidth to the end user. In the case of fixed clients, 10Gbit/s solutions such as XGS-PON are currently being deployed offering more bandwidth than the previous 2.5Gbit/s GPON solution. For the mobile clients, they are in the process of deploying 5G, the new generation of mobile communication succeeding 4G.

5G is seeking to be disruptive by nature. Going beyond a traditional evolution of bandwidth which promises to be 10 times that of 4G. 5G promises to harness new technologies of the telecom industry such as virtualization and cloud computing as well as the venture into a new range of radio frequencies previously not considered.

The optical access of the future should be able to adapt to this disruptive nature of 5G and should be equipped with a reliable arsenal of tools, protocols and engineering rules to be able to face the 5G wave head-on and deliver its promises.

This thesis comes to shed a light on the impact and challenges brought by the advent of 5G on the access network. The latter being one of the most delicate segments of the telecom network. In our contributions, we propose solutions to accommodate it by investigating the issue through two main paradigms, virtualization and the proposition and evaluation of new optical transmission solutions for the RAN.

The manuscript is structured through three main parts. The first part is composed of three chapters detailing the context and motivation of the thesis. Chapter 1 and 2 present the 5G ecosystem through its services and requirements and the underlying optical access network. Chapter 3 presents through the context of virtualization, the actual advancements in industrial and academic research initiatives.

The second part is composed of two chapters, the first one (Chapter 4) is dedicated to presenting our experimental work in terms of the implementation of a virtual mobile solution comprising of core network and virtual RAN (vRAN) elements. The solution is created with a high layer option 2 functional split. First, we conduct an initial protocol study of the solution by analysing data encapsulation as well as basic mobile procedures (attach and detach of a user equipment), then, we assess the performance (in terms of frame loss ratio, latency and packet jitter) of this virtual platform and the effects of the availability of virtual resources (number of CPUs and size of RAM) on the mobile signal.

The second chapter in this part (Chapter 5) presents the optical solutions that we tested in the transport of mobile traffic in our experimental optical access. We managed to successfully transport our mobile data on a Pulse Amplitude Modulation (PAM4) solution that doubles the transmitted bitrate on fiber. We assessed the effects of this modulation, as opposed to the classical Non Return to Zero (NRZ), on the transmission in terms of frame loss ratio, latency and packet jitter. The second transport solution we tested, is a 25 Gbit/s/λ wavelength multiplexing third party prototype, based on Passive Optical Network (PON) technology. This solution utilizes a wavelength tunability mechanism enabling easy Dense Wavelength Division Multiplexing (DWDM) transceivers matching. The traffic tested is generated with an eCPRI fronthaul interface. Through this study we managed to assess the solution's readiness at accommodating fronthaul transport with its different latency classes. The third solution, is a commercial 10Gigabit Symmetrical XGS-PON solution. The solution has been used to transport the virtual mobile platform traffic alongside with an emulated fixed traffic. The aim is to assess a convergent fixed mobile scenario, where a mobile traffic can be offloaded into a fixed access PON solution in a point to multipoint architecture.

The third part (Chapter 6) showcases two approaches of network elements abstraction in the access network. The first approach we present a scenario that highlights potential key features of the access network of the future such as fixed mobile convergence and Mobile Edge Computing (MEC). This solution consisted at transporting a mobile signal in a fixed/mobile architecture, enabled by a commodity server that features a point to multipoint link enabled by a miniature OLT with an abstracted control plane. The second approach consisted of showcasing the concept of multi-tenancy and multi-service through the abstraction of physical network parameters. We managed through this abstraction to create network slices that can be deployed seamlessly through an intent based interface. This example comes to serve a specific use case which is to provide different classes of services to different tenants, in this case, mobile operators, to be able to deploy their services in an access network that contains a fiber and a wireless segment.

The manuscript concludes on a general summary of the work realised during this thesis, as well as opening up on possible future work and perspectives for the access network of tomorrow.

My thesis was surrounded with a rich ecosystem of projects. The first one is an internal research project of Orange (Optical Networks). This project is transversal between the teams of the optical access network and the optical longhaul segment. The second one is 5G-PHOS (H2020-ICT-2016-2) a European project focusing on the creation of a hybrid access network solution for 5G. This solution is composed of a fiber segment linked to a wireless one. This thesis has started right after the end of the 5G Crosshaul project and even if the works here described have not been done in its framework, we were lucky enough to benefit from one of its key components: the virtual RAN and EPC solution. Those are on the very core of this thesis.

Part I

State of the art of 5G and the current mobile/fixed access ecosystem

Chapter 1

The Next Generation Mobile Network "5G"

The main motivation behind 5G is to propose a new set of services in an effort to keep up with the explosion of data usage everywhere. One of the key elements that drove the technology so far is the desire to innovate, not only to answer existent needs but also to push forward in uncharted territories and propose new services.

Throughout this chapter we are going to present this next generation of mobile services, its capabilities as well as the services it promises to deliver. We are going to highlight the technological differences that separate it from the 4G while laying out the challenges that faces its deployment and how virtualization can be used as a key enabler for it.

The announced specifications for the 5G network

With the announcement of each new mobile network generation, gears start moving towards the standardization of this new technology. In the case of 5G, the official kickoff has been in early 2016 with two main telecom standardization bodies, the 3rd Generation Partnership Project (3GPP) and the International Telecommunication Union (ITU), studying and laying out its requirements. On one hand, the ITU is an intergovernmental organisation that regulates the telecommunication field worldwide. Its job is to find a consensus between all the nations involved to define what Key Performance Indicators (KPIs) each telecom generation or technology should have. On the other hand, the 3GPP regroups actors in the telecom such as corporations, hardware manufacturers, telco operators and generally actors who have a stake in the making of new telecom technologies. The two standard bodies collaborate with each other intricately. The ITU defines the requirements and the KPIs of each mobile generation and the 3GPP defines the requirements through technical studies. Studies would then be submitted to the ITU to verify if they are in concordance with the ITU's KPIs and requirements, the ITU then delivers guidelines back to the 3GPP to asses practical and technical solutions to meet these KPIs. This cyclical back and forth between the two standard bodies assures that each technology is up to the original requirements and delivers the services it promises. In Figure 1.1, we have simplified the timeline of the standardization of 5G showing the evolution of both standards and the interaction between the two standardisation bodies. If we follow the 3GPP standard timeline, 5G study has started in the release 14 (R14) to define its requirements, then release 15 and 16 (R15, R16) specified the 1st phase and 2nd phase of 5G respectively. The phase 1 comes to lay out the foundation of 5G services while phase 2 comes to extend the first phase by introducing new features and capabilities. In this section, we are going to take a look at the requirements, the services and features this new technology promises.

The three services of 5G

When the 5G was conceived, it was decided that it will be a disruptive technology, not only in matters of technical novelty, but also in matter of proposed services. The 5G was thus defined through three major services (Figure 1.2):

• enhanced Mobile Broad Band (eMBB): Promising high bandwidth for 5G applications in the order of magnitude of Gbit/s per user. Motivated mainly by the constant need for more bandwidth with the increase of the number of users everywhere as well as their internet usage trends. The eMBB applications consist mainly of bitrate hungry applications such as streaming services, gaming, and peer to peer downloads. This service seems like a natural evolution of the 4G in terms of bitrate. Through the proposed high bandwidth, it can enhance connectivity solutions such as Fixed Wireless Access (FWA) [2] which consists of providing "FTTH like" experience through a mobile connection.

• Ultra-Reliable Low-Latency Communication (URLLC): This service enables a new set of applications that rely on low latency communications sometimes with an end to end round trip time of less than 1 ms. This is a new service that has been defined especially for the 5G to enable out of the box services that require a low amount of latency, such as self driving cars and industry automation. The URLLC aims at defining the requirements of a new class of services, namely in terms of low latency and reliability. 3GPP release 15 introduced lowlatency and ultra-reliability and in release 16 the full technical specification, namely the processes of scheduling and managing radio resources were introduced.

• massive Machine Type Connectivity (mMTC): This service concerns the communication between a big number of connected devices. Same as the URLLC, this is a new proper 5G specification that has as ambition to enable small as well as large scale connected entities. This service requires a lot of coordination at a low bandwidth in the orders of kbit/s. The mMTC concerns applications that require a great amount of interconnectivity and is mainly defined through the density of its connections. Applications for this service include Internet of Things (IoT), where connectivity is ubiquitous and the different nodes are connected with each other.

An overview of these services proposed by the 3GPP can be seen in [3]. The technical specifications of these services is reported in [4]. Table 1.1 summarizes the main technical requirements for each 5G service and their target value. For example, the peak data rate for eMBB services can reach up 20 Gbit/s and 10 Gbit/s for downlink and uplink respectively. The URLLC is required to have a 1 ms one way latency and a transmission reliability, with a probability of 1 -10 -5 at transmitting a layer 2 Protocol Data Unit (PDU) of 32 bytes within a 1 ms window. Finally, the mMTC must support a density of connections that amounts to 1 million devices per km

The new technologies used for the 5G

In order to have a 5G capable network, adjustments have to be made for the different segments of the mobile network, mainly the access and the core network.

The air interface: 5G NR

The major breakthrough in the radio access network lies in the air interface, called 5G New Radio (NR). New technologies for the air interface have been specified for the 5G. The first one being the venture into a new segment of the spectrum called the millimeter Wave (mmWave). This segment consists of radio signals with wavelengths in the millimeter range (with frequencies in the tens of GHz). This part of the spectrum was previously un-appealing due to the high attenuation the signal can receive but could be interesting in the case of small cell antennas deployment and for FWA as it has been reported in [5]. As a result of that, spectrum allocation for the 5G has been divided into two categories: Frequency Range 1 (FR1), that specifies the sub 6 GHz frequencies, where all the previous mobile generations are operating, and FR 2 that specifies the mmWave usage ranging from 24GHz to 52 GHz (Table 1.2). The Multiple-Input, Multiple Output (MIMO) is another technology that will be seen in the 5G air interface, previously standardized for 4G up to 8 antennas in the emission and 8 in the reception in the downlink. In the 5G, the number has increased up to 64 antennas in the emission and 64 in the reception, now known under the name of massive MIMO (mMIMO). The antennas are arranged in order to allow for spatial multiplexing, spatial diversity as well as beamforming capabilities.

The spatial multiplexing allows the transmission of multiple signals on each antenna. As a result, we increase the peak throughput by sending multiple data streams over multiple antennas at the same time.

The spatial diversity is taking advantage of the spatial separation of MIMO antennas in such a way as to capitalize on the signal's multipath while sending or receiving the same radio signal. By having the same radio signal with different paths, we transmit less throughput as in the spatial multiplexing case but we create signal redundancy, therefore increasing the reliability of the received signal.

Beamforming is performed by changing the phase and amplitude of the signal transmitted from each individual antenna composing the mMIMO therefore creating a strong localised radio beam, targeting only a selected group of users. This multiplexing can be enhanced by coupling it with the capacity of steering the beam by dynamically changing the phase shift of each antenna element. This process is called beam steering.

The 5G NR will introduce a signal in the dowlink, like 4G LTE, based on Orthogonal Frequency Division Multiplexing (OFDM). The radio frame structure remains the same as well, with a duration of 10ms and a certain particularity of having a new additional parameter called numerology, identified by the variable µ. This parameter is put to allow for flexibility in radio resource allocation to address efficiently different spectrum ranges, with the main values of µ being 0, 1, 2, 3. These numbers define multiple spacing options between each OFDM sub-carrier (See Table 1.3) previously fixed at 15 kHz in the 4G, as well as defining the number of elementary slots (each containing 14 OFDM symbols) per 5G NR sub frame (See Figure 1.3). This flexibility comes to accommodate the carrier frequency, with some values of Carrier Aggregation (CA) is a technology previously introduced in the 4G. It consisted of aggregating up to five 4G Component Carrier (CC) totalling up to 100 MHz in aggregated bandwidth to allow for a maximum throughput for users [START_REF] Wannstrom For 3gpp | Carrier Aggregation explained[END_REF]. This technology is going to be present in the 5G as well, allowing up to 16 carriers to be aggregated. Moreover, 5G in its dual connectivity configuration can have its carriers aggregated with 4G carriers. The coexistence between the two access technologies goes even further by allowing the sharing of the same carrier in what is known as Dynamic Spectrum Sharing (DSS). DSS shown in Figure 1.5, allows for more flexibility when providing both services in a dual connectivity scenario or in the case of the unavailability of an exclusive 5G band in the FR1.

The 5G Core network (5GC)

The 5G Core network, which is the backbone of the mobile network, will have new functionalities :

• Enabling hosting of Mobile Edge Computing (MEC): The ability to push functions closer to the end user to allow for latency sensitive applications, and overall, services that will benefit from being closer to the end user. In order to support this use case, 5G uses "Service Hosting Environment", a service that can be implemented by the network's operator. It allows for hosted services closer to the end user.

• End to End Network slicing: The ability to create multiple virtual networks logically separated. Each one of them have their own services and engineering rules on top of the same physical network. Having the 5G core network capable of slicing in the latest stages of the network deployment will allow for an end to end (from the core to the air interface) network slicing completely enabled by 5G.

• Support for multiple access technologies: when accessing a 5G service, the access technology should be transparent to the User Equipment (UE). For instance, a client can connect to the 5G Core and access its services through other access networks such as the 4G LTE or through FTTH.

5G deployement options

In order to ensure a smooth transition from one mobile technology to the other, 5G has specified two major sets of deployment options. The first one being the Non-Standalone (NSA), which indicates that the radio access is provided simultaneously both by the 5G NR and the 4G LTE. The second one is the Standalone (SA) where only one radio access technology is used. The NSA presents three main options:

• Option 3: EN-DC (E-UTRA -New Radio Dual Connectivity), the 4G base station, the Evolved Node B (eNB) is working as a Master eNB (MeNB) and the 5G base station, the gNodeB (gNB) working as the Secondary eNB (SgNB), both connected to the 4G Core, the Evolved Packet Core (EPC) now called 5G EPC. This scenario is going to be one of the first to be deployed.

• Option 4: NE-DC (Next Generation -E-UTRA Dual Connectivity), gNB is working as Master (MgNB) and eNB is working as Secondary (SeNB), and they are both connected to a 5GC.

• Option 7: NGEN-DC (Next Generation E-UTRA -New Radio Dual Connectivity), eNB is working as MeNB and gNB as a SgNB, both connected to 5GC.

The SA comes in three options as well:

• Option 1 : eNB is working with EPC.

• Option 2 : Standalone (SA) NR, gNB is working with 5GC (2nd stage of 5G).

• Option 5 : eNB is working with 5GC.

The early deployment of 5G is likely to be in NSA mode, since it allows for the reuse of the existing 4G Core network. For instance the option 3 has been fully specified in the 3GPP release 15. For more details on each option see document [START_REF]Operator Requirements for 5G Core Connectivity Options[END_REF].

The Radio Access Network (RAN)

The access network is the last network segment before reaching the end users, be it internet broadband or mobile users, industry or home endpoints. The specificity of this segment is its high capillarity due to the vast amount of users served. In a nutshell, it takes connections coming from the core network and fans them out into different clients in the last miles. A subset of this network is the RAN. It describes specifically the access network segment that serves the mobile clients. Its definition is somewhat malleable, some define it as all the mobile equipment located closer to the end user responsible of generating the radio mobile signal including the air interface, some define it as the combination of the fiber infrastructure and the mobile equipment.

The vision we chose to go by into defining the RAN is the location of its equipment known as the RAN machine. The reason why we went with such vision, is that the RAN machine can describe exhaustively what a mobile access is, regardless of the underlying transport technology that links it with the core network from one side, and the mobile users from the other. Another reason why we chose to go by this decomposition is that as we will explain further in this chapter, the RAN machine can be implemented and deployed following various functional and geographical schemes making the definition of the RAN otherwise inconvenient.

Centralised vs distributed and the advent of functional splits

The implementation of the RAN machine in the access network has known various changes going from 2G to 4G. Namely, the geographical entities that host the RAN functionalities. The last generation, the 4G, had typically all of the RAN machine hosted in the antenna site and was referred to as the eNB which in turn can be viewed as two distinct entities: the Base Band Unit (BBU) also know as the Digital Unit (DU) and the Remote Radio Unit (RRU) also known as the Radio Unit (RU). The signal coming from the core network will be transformed into a baseband mobile signal in the BBU and then upconverted to the carrier frequency in the RRU to be transmitted through the antenna. Each antenna site has its own RAN machine, and is connected to a Central Office (CO) that aggregates all the other antennas' links to be transmitted to the core network. This type of RAN topology is known under the name of Distributed Radio Access Network (D-RAN) (see Figure 1.8).

Telecom operators have noticed that the resources of the BBU in the RAN machine at the level of each antenna site aren't always fully utilised. As a result, they sought to centralise theses machines at the level of the CO. This entails that the baseband mobile signal will be fully generated at the level of a CO and hauled to the antenna site. This revealed to be interesting in terms of the availability of Commercial Off The Shelf (COTS) optical transceivers that are capable of transmitting over that distance as well as the reduction of energy consumption [START_REF]The Benefits of Cloud-RAN Architecture in Mobile Network Expansion[END_REF]: by centralising these equipment one of the possibilities is to dynamically allocate BBU resources to serve mobile clients in what's known as BBU pooling. Other configurations for the centralisation of the BBUs exist such as the BBU stacking which consists of one BBU in the CO handling all RRUs located at the same antenna site [START_REF] Chanclou | Optical fiber solution for mobile fronthaul to achieve cloud radio access network[END_REF]. This type of RAN topology is known under the name of Centralised RAN (C-RAN) (see Figure 1.9). F 1.9: Centralised RAN architecture.

C-RAN has a downside. By centralizing all mobile functionalities, there was the need to extend the communication interface between the RAN machine and the Chapter 1. The Next Generation Mobile Network "5G" antenna through multiple kilometers, prompting the use of specific interfaces that have considerable latency constraints such as ORI [START_REF] Etsi | Open Radio equipment Interface (ORI);Requirements for Open Radio equipment Interface (ORI) (Release 3)[END_REF], OBSAI [START_REF] Lanzani | OBSAI RP 301 6.144 Gbps Interface Implementation[END_REF] and Common Public Radio Interface (CPRI), the latter being implemented the most. The CPRI interface for instance can cause in some antenna configurations a bitrate increase 12 times higher than the bitrate of the air interface [START_REF] De La Oliva | An overview of the CPRI specification and its application to C-RAN-based LTE scenarios[END_REF]. This bitrate increase is due to the method used into transporting the mobile signal: CPRI interface takes the complex mobile baseband signal and quantifies the I (In phase) and Q (Quadrature) samples with a 15 bits resolution (Figure 1.10). CPRI interface comes into different options numbered 1 through 9 (Table 1.4). The maximum capacity the CPRI interface can support is around 12 Gbit/s. 4G bitrate in this case will remain unaffected by the limitations of the fiber interface. However for 5G, with promises of bitrates in the Gigabit/s in the air interface, the fronthaul link will be challenged. The requirements needed from the RAN to accommodate the 5G must take into account its services and their technical requirements (Table 1.1). Being aware of the trade-off between a fully distributed and a fully centralized RAN, various standard bodies, for instance the 3GPP in [START_REF] Gpp | Technical Specification Group Radio Access Network; Study on new radio access technology: Radio access architecture and interfaces[END_REF], and the Institute of Electrical and Electronics Engineers (IEEE) in [START_REF]1-2019 -IEEE Standard for Packet-based Fronthaul Transport Networks[END_REF] through its Next Generation Fronthaul Interface (NGFI) standard have specified split options inside the RAN functionalities to allow for a more flexible architecture. Their objective is to allow for the possibility to rearrange the RAN functionalities throughout the access network from the CO to the antenna site in a bid to find a compromise of mobile resource sharing and transported bitrate between C-RAN and D-RAN. These options are called functional splits. The 3GPP in [START_REF] Gpp | Technical Specification Group Radio Access Network; Study on new radio access technology: Radio access architecture and interfaces[END_REF] has also specified the different possible divisions of these functionalities onto different equipment. These equipment are the Central Unit (CU), Digital Unit (DU) and Radio Unit (RU). An example of where these blocks might be located are shown in Figure 1.11. Currently, the main 4G RAN deployed topology is D-RAN. A number of telecom operators have been surveyed in [START_REF] Perrin | 5G transport: Operators focus on fronthaul[END_REF] concerning their plan for the adoption of functional split in 5G networks. Based on their estimations, 21% of sites will have CU, DU and RU in separate locations. 25% CU, DU together and RU in a separate place. 27% DU and RU together and the CU in a separate place. 27% CU, RU and DU all together (no split). The idea of functional splits is thus gaining momentum and we can expect various split configurations deployment in the future.

High layer and low layer functional splits

There are two major groups of functional splits. The first one is the high layer splits, concerning layer 2 in the Long Term Evolution (LTE) stack. The split can occur after functionalities such as the Packet Data Convergence Protocol (PDCP) and Radio Link Control (RLC). The second one is the low layer splits, occurring inside functionalities of the physical layer (Layer 1) in the LTE stack.

The high layer split occurs between the CU and DU while the low layer split occurs between the DU and RU. The high layer splits have less latency constraints compared to the low layer splits whereas the low layer splits can offer the possibility to pool resources. For the remainder of this section we are going to align our functional split vision with the definitions and nomenclature of the 3GPP.

To showcase how much a split can affect the optical access network we are going to see some few examples. Figure 1.12 shows in detail the various split options that have been defined. Taking the example of downlink data going through all the processing functionalities we are going to analyse the output of each split. From option 1 to option 7-3 the output of the split (in this case packets or bit stream) scales with the size of the user's data.

Chapter 1. The Next Generation Mobile Network "5G" From option 7-2 to option 7-2a the split output (transmission layers and modulation symbols respectively), varies with the number of antenna ports as well as the transmission mode (transmission diversity or spatial multiplexing). And finally, option 7-1 and option 8 the split output scales with the channel bandwidth and the number of antennas (the number of antennas can be a considerable factor in case of mMIMO). Scaling our access network in term of throughput capacity should take into account the various possible splits and assess the best split option(s) for each 5G service. Efforts from industrials have been initiated to enable these kind of splits. The O-RAN alliance initiative for instance, has chosen the open platform/virtualisation route to enable the different possible splits with more details given in the virtualisation section of this chapter 1.3. The evolution beyond a binary vision of the RAN, i.e., going from distributed and centralised architectures to the adoption of functional splits, promises benefits for the 5G. In addition, starting to use virtualization as a tool for future networks produced a new type of RAN called virtual RAN (vRAN).

Virtualisation in the RAN and the concept of SDN and NFV

Virtualisation is now one of the current defining technologies of the IT industry. Through this mechanism, various technological leaps are happening, especially in terms of agility and efficiency at deploying IT services with reduced deployment time and cost relative to hardware deployment. Virtualisation has many definitions. The definition we chose to use is the following: a process that creates a virtual instance of an equipment based on the separation of the software and the hardware. In our definition, we want to make the distinction between two aspects of this decoupling. The first one is Network Functions Virtualisation (NFV): the separation of the software from the underlying hardware in which it is implemented, meaning that instead of having a physical machine with a unique role, providing a unique function, we have a function that can be implemented on any COTS machine such as all purpose servers. The second one is Software Defined Networking (SDN), which is the separation of the control plane from the data plane, meaning that the control of the equipment isn't achieved through a local (often proprietary) interface that needs direct communication with the equipment. This process can allow us to have a centralized control plane of multiple equipment, manageable through a centralized entity, giving us an abstract global view of the network and allowing us to enact policies in a more scalable and programmable fashion.

Current NFV and SDN proposed solutions for the RAN

The NFV solutions in the RAN can achieve hardware independence. It would be easier to imagine a scenario where RAN functionalities supplied from different vendors can be seamlessly integrated. Another scenario would be where a single physical RAN machine hosts different telcos' software with each their own services and engineering rules. Functional splits for instance can benefit from the flexibility of deployment and can be easier to test and implement.

The SDN solutions can enable certain 5G capabilities, for instance for slicing or being hardware agnostic when it comes to configuring network equipment. SDN will allow for the centralisation of the network intelligence by abstracting the control plane allowing easier interfacing between the various components with the ability to have an end to end vision of the mobile network (for instance the RAN with the core network) as well as a global vision of all types of networks (for example a unified vision of fixed and mobile networks).

In this section we show the actual ecosystem of virtualization applied to the mobile network and depict its main actors in term of initiatives and relevant milestones.

Open RAN based on NFV

The efforts toward making the RAN open, based on NFV, was pushed forward by three main initiatives. The first one is the O-RAN alliance [START_REF]O-RAN Use Cases and Deployment Scenarios[END_REF] that comes mainly through its work groups (WG) to define the requirements necessary to have open, interoperable RAN blocks that can be supplied from different vendors, in particular, the Work Group 6 (WG6) "the Cloudification and Orchestration Group" [START_REF]Cloud Architecture and Deployment Scenarios for O-RAN Virtualized RAN[END_REF].

The second one is Open RAN, its goal is to set the environment for the development of hardware agnostic RAN solutions. Open RAN, through its work in the Telecom Infra Project (TIP), sets up the requirements of the openness of the vRAN interfaces. In particular, in the "vRAN fronthaul" project group [START_REF]Toward Disaggregated Mobile Networking[END_REF], the main goal is to develop a framework for vendors to be able to come up with new RRU/BBU models that can be adapted to different deployment scenarios in terms of where the RAN functionalities are located in the RRU and BBU blocks.

In the same effort as Open RAN, the third main virtualization initiative is Open vRAN backed by Cisco [START_REF]Open vRAN Ecosystem : Overview and Current Activities[END_REF], working towards the same openness of interfaces and using virtualisation in the RAN to promote vendors interoperability.

With many initiatives in the market, the issue of having overlapping project interests might arise. According to Sachin Katti, the technical steering board Co-chair of the O-RAN Alliance [START_REF] Marek | How Many vRAN Initiatives Does it Take to Open the Radio Network?[END_REF], the O-RAN alliance focuses on the defining of the global architecture of vRAN. Whereas Open RAN and Open vRAN focus more on the interoperability issues and how to implement the virtual blocks of vRAN. These initiatives laid the ground for solutions to be developed. For instance one of the biggest known projects related to virtualizing the RAN would be Open Air Interface (OAI). OAI is a product of open AirInterface Software Alliance [START_REF]OpenAirInterface[END_REF] where they introduce the notion of RAN as a Service (RANaaS). Various works used OAI as the basis of their vRAN implementation. For instance in [START_REF] Huang | Design and Integration of Fiber Fronthaul with Soft PHY for OAI-BASED RAN[END_REF], they designed and integrated a fronthaul for a C-RAN based on OAI and in [START_REF] Costanzo | DEMO: SDN-based network slicing in C-RAN[END_REF], they implement a slicing on top of an OAI based C-RAN. The flexibilty of implementation of an OAI C-RAN made it possible to be deployed on top of different virtualization platforms such as Openstack as demonstrated in [START_REF]C-RAN Demo -OPENAIRINTERFACE deployment on top of OpenStack[END_REF]. Instances of running OAI on containers as well as on top of kvm hypervisor have been demonstrated in [START_REF]HUAWEI-EURECOM Meeting[END_REF].

Industrials have been working into putting in place real life demos based on their own RAN Virtualized Network Functions (VNFs), where a vRAN platform would be fully integrated in an operator's network. Telecom equipment vendor Ericsson for instance, is teaming up with NVIDIA to build virtualized 5G access networks using NVIDIA's GPUs and software. The aim of this collaboration is to create an open source O-RAN compliant solution [START_REF] Begley | Virtualized radio access networks in a nutshell[END_REF]. Another example is the telecom operator Orange in collaboration with Nokia. They tested Nokia's solution consisting of both a VNF Manager (VNFM) and virtualized 4G vRAN implemented with a Packet Data Convergence Protocol-Radio Link Control (PDCP-RLC) split. The test concluded that the vRAN platform had minimal effect on the exisiting RAN and that the solution wasn't cloud native.

Traditionally, the main actors for mobile solutions were companies that created the entirety of the solution (mobile and hardware). With the shift into software components, new actors have emerged, for instance Core Network Dynamics (CND) with their mobile software solution that features a virtual EPC and RAN. As of february 27 2020, Altiostar, an open virtual RAN technology provider, announced the first cloud native container based 5G vRAN solution. The solution was developed with the collaboration of intel and will be deployed by the operator Rakuten mobile in Japan [START_REF] Altiostar | Rakuten Mobile and Altiostar To Launch World's First Cloud-Native, Container-Based 5G Radio Access Network Solution[END_REF].

SDN initiatives

The SDN approach in the RAN is similar to that in other types of network (For instance IP based network equipment). The approach should concentrate into defining the interfaces that the equipment will use to communicate with the controller and creating a model to abstract the network equipment. For instance, if a controller is configured with the right protocols and interfaces, it will be able to interface with routers as well as mobile network nodes, creating an abstract model that gives a global view of the network.

In the previous section, we talked about the open RAN initiatives in terms of their NFV contribution. In this section we are going to discuss how their efforts into providing open interfaces for the RAN can pave the way for more RAN oriented SDN controllers based on the separation of the Control Plane (CP) and the User Plane The defined entities in Figure 1.13 are the following :

• The RAN Intelligent Controller (RIC) is the enabler of RAN functionalities as applications that can be managed and orchestrated through its northbound interface A1 in favor of the orchestration and automation block. The use cases of the RIC and its deployment scenarios can be seen in [START_REF]O-RAN Use Cases and Deployment Scenarios[END_REF].

• The A1 intent based control interface provides enough abstraction for users and operators not to be concerned with device configuration and other low level applications is given in [START_REF]A1 interface: Application Protocol[END_REF].

• The O1 interface as a general operation and maintenance interface in [START_REF]O-RAN Operations and Maintenance Interface Specification[END_REF].

• The E2 interface that serves as a signaling protocol between the RIC and the RAN defined in WG3 [START_REF]Near-Real-time RAN Intelligent Controller, E2 Application Protocol (E2AP)[END_REF].

• The E1 interface between the CU-UP and the CU-CP addressed in [START_REF]O-RAN Open F1/W1/E1/X2/Xn Interfaces Working Group; NR Cplane profile for EN-DC[END_REF].

• The User plane interface F1 is used to transport user data between the CU and DU and the interface ORAN NGF-I between DU and RU.

Research projects have aligned themselves with the O-RAN vision. For instance the Open Networking Foundation (ONF) initiative is working on an O-RAN compliant SD-RAN with an ONOS based RIC developed on top of Aether, a hardware platform providing 5G/LTE Edge as service [START_REF]Aether: Enterprise-5G/LTE-Edge-Cloud-as-a-Service[END_REF]. Another instance of O-RAN based controller would be the one developped by IS-Wireless, which is a proprietary SD-RAN controller to enable 4G and 5G applications [START_REF]5G Network Software and Hardware to enable networking revolution[END_REF]. Other initiatives chose to align themselves with Open RAN [START_REF]Parallel Wireless Real-Time OpenRAN Controller Data Sheet[END_REF] and the overall objective is to come up with a controllable RAN through the abstraction of its blocks. In terms of readily available and tested platforms, FlexRAN is one of the first open source implementation of a flexible and programmable platform for SD-RAN [START_REF] Flexran | First Open-source Implementation of a Flexible and Programmable Platform for Software-Defined Radio Access Networks[END_REF]. Through its RAN runtime environment, it provides abstraction of RAN modules. These abstraction elements are controlled through its Real Time Controller (RTC). Various SDN RAN demos have been implemented using the FlexRAN environment such as [START_REF] Costanzo | DEMO: SDN-based network slicing in C-RAN[END_REF] that showcases an SDN based network slicing and in [START_REF] Foukas | Demo: Flexran: A software-defined ran platform[END_REF] shows a Mobile Edge Cloud scenario. The authors in [START_REF] Foukas | Flexran: A flexible and programmable platform for software-defined radio access networks[END_REF] present an implementation on top of an OAI setup. The paper aim is to evaluate the deployment of FlexRAN considering the existence of time critical operations in the RAN functionalities.

Virtualisation in the mobile world in general, and its radio access network in particular are still in the beginning of their progress, harnessing the recent advancement in this technology. With the 5G in its way, the virtualisation efforts in the RAN are expected to increase to accommodate the disruptive nature of this technology.

Chapter conclusion

This chapter presented the 5G ecosystem as a whole, defining the services it promises as well as the strict requirements it needs. The takeaway from this chapter is the disruptive character of this technology and how its effects will be felt in all the segments of the mobile network, from the core network all the way down to the access network and to the end user. The emphasis in this chapter was to present the effect of this technology in the access network, being one of the most fast changing segments of the network and the most delicate given the multiplicity of technologies coexisting in the same segment.

The chapter's vocation was also to shed a brighter light on the recent advances in softwarization and how we can use virtualization to enable the RAN of the future. The main take away of this is that virtualization can benefit greatly the implementation of the various functional splits and overall contribute to the dynamicity, coexistence and openness of RAN interfaces long sought in the access network in particular, and in the whole network in general.

So far, the discussion on this chapter covered the RAN network, defined through the RAN machine without much thought on the underlying transport infrastructure. Mostly fiber, known under the name of optical access network, this infrastructure will be in the front line facing the requirements of the 5G. This network will be presented in the next chapter.

Chapter 2

A vision of the current optical access network

Before the fiber, the prevalent method of wireline transportation in the telecom network was copper due to its high connectivity and to this day, copper media are still used to transport data and voice for millions of users. However, the commercial introduction of optical fiber in the late 70s revolutionized how data is being transmitted. First of all, the marginal price of fiber compared to copper as well as the reduced latency and increased bandwidth put quickly the fiber in the telecoms' adoption fast lane. This once emergent technology quickly made a name for itself. For instance, in 2016 it is estimated that more than 274 millions homes and businesses have been connected around the world [START_REF]FTTH Global perspective[END_REF]. Figure 2.1 presents an overview of the telecom network. The fiber has been used to connect long distances through intercontinental cables, then goes through the aggregation network to finally reach the access network. This last segment is known for its high connections density and used to connect different endpoints. In this chapter we are going to specifically discuss the optical access network and its different fiber connections. The focus will then shift to describe the fiber link to the antenna, in a bid to explain how the mobile access network is constructed.

The Optical Access Network

Telecom operators generally take an approach where they gradually replace legacy equipment such as copper to lay out fiber. As such, the particularity of the last mile of the network is that it contains different types of endpoints, connected to the network through new as well as legacy equipment. As a result, to take account of these different termination points, many fiber layouts have been coined, namely, FTTH, Fiber To The Cabinet (FTTC), Fiber To The Building (FTTB) and eventually Fiber To The Antenna (FTTA) known under the umbrella term of Fiber To The X (FTTX).

Fiber To The X

Fiber to the X (FTTX) defines the delivery of the optical fiber infrastructure to different building entities. It is a general term that defines all types of fiber connections. A simple view of the optical access network would be to present it as containing the CO, marking the beginning of the access network, then the fiber, going from the CO and eventually connected to its final endpoint in a point to point fashion or through splitters in point to multipoint.

The four main deployment options are shown in Figure 2.2 and described as follows: • FTTB: defines a fiber connection from the central office to the level of the building, the legacy connections inside the building such as coaxial cables are leveraged to deliver the last meters of the connection.

• FTTH: the most commonly known service connecting homes. Each home has its own dedicated fiber up to a splitter, then multiple homes share the same fiber all the way to the CO.

• FTTC: defines a fiber connection up to a roadside cabinet next to the building to be served, from there the connection becomes copper, this allow the reuse of the copper infrastructure.

• FTTA: defines the fiber connection up to the antenna site. Depending on the architecture of the antennas site, the connections inside the site can be copper or fiber.

Figure 2.2 depicts succinctly the different fiber connections coming from the same splitter. This configuration (different FTTX scenarios from the same splitter) is not indicative of a real life scenario and shown here for the sake of conciseness. Another way to classify the different FTTX options, would be in terms of connection topology, i.e., the geometric properties of each fiber connection. For instance, in FTTB, FTTH and FTTC there is only one fiber coming from the CO that through optical splitters fans out to multiple users. Here we talk about a Point to Multi-Point (PtMP) topology. Conversely, in the case of FTTA the fiber connection from the CO goes directly to the antenna site, here we talk about a Point to Point (PtP) connection. Other use cases can necessitate PtP connections such as businesses. In general, the majority of fiber customers in the optical access network are FTTH users. Indeed with the huge number of connected homes that doesn't cease to increase, the choice of having one fiber from the CO connecting multiples users through splitters revealed to be optimal. To do so, telecom operators rely on a technology called PON.

The Passive Optical Network

The passive optical network is a widely adopted solution to share the fiber resource between the different endpoints of the optical access network. This solution is composed of two main components, the Optical Line Terminal (OLT) typically located in the CO and the Optical Network Unit (ONU) located at the end user.

It is said to be passive because the components between the OLT and the ONU do not necessitate power supply. For example, in an FTTH scenario, we will have one OLT for multiple ONUs. The sharing of the fiber infrastructure is done using a Time Division Multiple Access (TDMA) scheme in the uplink, and a broadcast in the downlink. Figure 2.3 shows how the multiplexing scheme works.

Nowadays, this technology is ubiquitous and almost every fiber linked home uses it. This technology is also used for business purposes. In this case a PtP connection coming from the CO can be considered. The OLT features multiple line cards. The cards feature multiple ports. In the case of PtMP link, each port correspond to a PON tree with multiple clients. Users in the same PON tree can request more or less bandwidth depending on the nature of the offer they subscribed to, their • Fixed: the bandwidth is permanently allocated to the ONU and cannot be repurposed for other users if the bandwidth is not in use.

• Assured: the bandwidth is guaranteed to be allocated to the ONU if it needs it, but if it is not in use, can be re-purposed for other clients.

• Non-Assured: the bandwith is granted if the fixed and the assured bandwidth constraints are not present.

• Best effort: has a lower priority than the non-assured, can be assigned if the bandwidth available can permit it. This type as well as the non-assured one allow for proposing internet offers to clients that amount to more than the capacity of the PON tree itself, relying on the non concurrent usage of the full capacity of the PON tree. In the best effort mode, the bandwidth is allocated up to a certain maximum level.

• Maximum: the upper limit in terms of bandwidth that can be allocated.

Table 2.1 shows T-CONT profiles, numbered 1 through 5. They act as enablers for different bandwidth parameters. For instance, T-CONT 1 can only be configured to allow the ONU to transmit in a fixed, permanently allocated bandwidth. T-CONT 2 however, can assure a certain bandwidth but will only provision the bandwidth for the ONU if needed. Through these T-CONTs, network architects can provision the optical access network for fixed clients according to their needs.

Fixed X X Assured X X X Non-Assured X X Best Effort X X Max. X X X
The main use case of PON is to implement PtMP architecture in service of home users. However, there are other implementations of this technology. For instance, some PON solutions uses Wavelenght Division Multiplexing (WDM) or both Time Division Multiplexing (TDM) and WDM in what's known as Time Wavelength Division Multiplexing (TWDM). There are two main standardisation bodies that are currently working on the specification of different PON technologies, the ITU and the IEEE. Each one of them is laying out specifications that telecom operators need to follow in order to deploy their own PON network. The two standards specify differently the physical layer requirements necessary to manufacture a PON system. As a result, an ONU based Chapter 2. A vision of the current optical access network on the IEEE standard would not be able to communicate with an OLT based on the ITU standard.

Figure 2.4 shows the different standards released by both the ITU and the IEEE. As we can see, the main drive from one generation to the other is to increase the bandwidth going through the network. The motivation behind it is partly attributed to the telecom operators competition and the desire to constantly offer more bandwidth to customers. For instance, in the ITU standard, the G-PON offers 2.5 Gbit/s in downlink and 1.25 Gbit/s in the uplink. The next generation XGS-PON on the other hand, offers 10 Gbit/s both in the downlink and the uplink. Both these generations operate through TDM. After the push for 10 Gbit/s, there was a push for 40Gbit/s through multiplexing different wavelenghts in the same channel, it was standardized under the name of Next-Generation Passive Optical Network 2 (NG-PON2). Finally, the last evolution is referenced under the name of High Speed PON (HS-PON), intended to specify the technologies in term of physical layer parameters necessary for PON systems operating at more than 50 Gbit/s. The standard is known under the name of G.hsp.x and is currently under work with the first document being released [START_REF] Itu-T | Higher speed passive optical networks -Requirements[END_REF].

Vision of the FTTH on the field

In practice, the optical access for FTTH is laid out following engineering rules that take into consideration various real life parameters, such as the clients geographical disposition (density for instance), urban planning or the integration with legacy last mile infrastructure. As a result, the FTTH park is deployed differently according to the country and operator. We took a look at an example of an FTTH deployment laid out by one major European telecom operator (Orange). Figure 2.5 are screenshots from their software that shows an example of PON deployment in three different city sizes. The top figures show a much zoomed out view of the city, in those figures we can see the disposition of optical connection nodes, these nodes aggregate the subscribers lines of a neighbourhood or a city into a single point. In this node, we find the OLT and in our representation of the access network would correspond to the CO. The bottom figures represent a small zoomed in portion of the city, the small red/pink/blue wedges represent a closer step to the final client. In those locations the fiber coming from the CO would be split for the clients of the same building or neighborhood.

Fiber To The Antenna

Traditionally, the antenna sites were linked to the CO with copper, however due to the increasing demand for bandwidth, fiber links start to be adopted instead. In this section we are going to reiterate some key elements of the RAN from the first chapter while putting them into the the context of their underlying physical infrastructure.

Initially, the eNB comprised one entity, one machine performing both radio and baseband signal processing. This entity was then linked to the antenna at the top of the antenna site through coaxial cables. The radio signal will then be transmitted as it is to the antenna to be upconverted to the carrier frequency. This process revealed to introduce signal losses due to cable attenuation which prompted telecom operators to substitute this copper link with a fiber one. This substitution decoupled the RU from the DU and the mobile baseband signal generated in the DU transformed into an Non Return to Zero (NRZ) signal through standardized interfaces, the most common of which is CPRI. Still, both these architectures are called distributed, albeit having the mobile processing machine separated into two blocks, the processing remains local at the antenna site. These architectures fall under the D-RAN term.

The flexibility added by separating the two blocks allowed telecom operators to experience with the idea of pushing the DU even further down the access network. The reason behind it was to pool DU equipment into the CO and have an intelligent resource management. The term C-RAN was coined for this type of distribution.

D-RAN and C-RAN, previously explained in Chapter 1 in terms of the location of the RAN machine, are to be seen in this chapter through the type of transport links that constitute them. In C-RAN, the link between the CO and the antenna site is called the fronthaul and for the D-RAN is called the backhaul. Figure 2.6, represents the evolution of fiber to the antenna. Subset (a) presents the early 4G RAN topology using copper between the DU and the RU. In (b) we see the substitution of the copper link with an optical one with the relocation of the RU in the top of the antenna site and finally (c) C-RAN with the DU centralized even further.

In Chapter 1, we also mentioned the trade-off between having a fully centralized and a fully distributed RAN. The discussion mainly focused on the effect this two types of topologies have on the RAN interfaces and the optimal usage of the DU blocks. We mentioned that in the case of a fully centralized topology while using a CPRI interface, the bitrate coming from the backhaul can be multiplied 12 times depending on the antennas configuration. The maximum capacity the CPRI interface can support is around 12 Gbit/s (see Table 1.4). 4G bitrate in this case will remain unaffected by the limitations of the fiber interface, however for 5G, with a promise of an air interface capacity in the Gbit/s, the fronthaul link will not be able to withstand such bitrates. To remedy to this issue which was reported in Chapter 1, functional splits were proposed along with one of their possible key enabler, the virtualization in the mobile access network.

It has become clear that virtualization in the mobile access network is going to offer various advantages for the RAN. The optical access domain in its turn has been 2.6: fiber to the antenna infrastructure evolution.

introduced to virtualization as well. In the next section we are going to present its ecosystem.

Virtualization in the Optical Access Network

When virtualization has been made possible through the advances of softwarisation, the operators soon sought to find use cases that can relate to the optical access. It is known that one of the defining technologies of the optical access is the PON technology. For that effect, two main initiatives have been working towards making the access network more flexible with the abstraction of the control plane and the virtualization of the functionalities of the PON equipment. The first initiative is Central Office Re-architected as a Datacenter (CORD) [START_REF]Central Office Re-architected as Datacenter (CORD)[END_REF], backed by ONF, and the second one is Cloud Central Office (CloudCO) [START_REF]Broadband Forum CloudCO Projects Transform Traditional Access and Aggregation Architectures[END_REF] backed by Broad Band Forum (BBF). Their work revolves primarily on the PON network as a the centerpiece of their activities. CORD project focuses on the desegregation of functions that lie in the edge network equipment leveraging the recent breakthroughs in SDN and NFV. In particular, they present Virtual OLT Hardware Abstraction (VOLTHA) [START_REF]VOLTHA[END_REF], a project aiming at decoupling the control and data plane of the OLT while enabling a modular approach for the implementation of various PON functionalities. The VOLTHA initiative specifies interfaces where the solutions would be compatible with different vendors' OLTs. Finally the possibility to have different vendors' OLT / ONU inter-operability is also preconized. VOLTHA focuses on the abstraction of PON elements, whereas another CORD initiative called SEBA [START_REF]SEBA[END_REF] was launched to extend this abstraction to different access network technologies including PON, as well as copper based technologies such as G.Fast and DOCSIS. CloudCO is an initiative of BBF. They present their solution named cloud Central Office with its main objective to define a cloud based CO utilizing SDN and NFV approach. This solution consists of implementing a cloud like infrastructure in the CO buildings. In [START_REF] Bbf | Cloud Central Office Reference Architectural Framework[END_REF], the authors define its architectural framework as well as the abstraction layer named Broadband Access Abstraction (BAA) that will provide the interface between the devices located in CO such as whitebox and vendor specific equipment through an SDN controller.

The NFV aspect in optical access virtualization lies in the fact that some major OLT functions have been virtualized and put into software, namely, the DBA and the ONU Control Management Interface (OMCI) traditionally located at the OLT. The DBA, introduced earlier in this chapter, is the algorithm that takes care of granting the bandwidth to the ONUs. By having the DBA virtualized, we can have multiple tenants on the same PON tree with each tenant their own DBA algorithm responsible for allocating the bandwidth for its virtual segment. However, one of the challenges of virtualizing the DBA is to respect its strict latency requirements. The authors in [START_REF] Elrasad | Virtual dynamic bandwidth allocation enabling true PON multi-tenancy[END_REF], showcase a virtual DBA in a scenario where multiple Virtual Network Operators (VNOs) share the same physical PON tree but are virtually separated by having each their own distinct DBA algorithm. This work highlighted the flexibility that vDBA can allow in order to share physical resources. The OMCI which is the control interface used to configure and monitor ONUs was proposed as a VNF. The aim is to have interoperability between vendors. For instance, having a virtual OMCI running in a server separated from the OLT will grant the OLT the possibility to fetch the appropriate OMCI that will enable it to discuss with the ONUs. Efforts have been initiated for the specification of this interface and are underway by the BBF in their WT-451 specification [START_REF][END_REF].

Chapter conclusion

The main idea to retain from this chapter is that the optical access delivers fiber connectivity to all premises, with FTTH being one of its main use cases. FTTH relies on PON technology that allow the reach of multiple users efficiently due to its PtMP topology. We illustrated this with a glimpse into a real-life geographical disposition of the PON network elements. The focus then shifted to the fiber connectivity regarding antennas' sites. Our goal was to shed a light on the underlying fiber infrastructure that serves the RAN and put it into the context of the issues relative to the transport of a 5G signal. We then presented the virtualisation paradigm applied to the optical access through launched initiatives. The virtualisation in the optical access presented here, as well as the virtualisation in the mobile access presented in the first chapter, opened a wide door to researcher to innovate and propose ideas that leverages this technology in both the fixed (mainly FTTH) and mobile segments. This prompted the development of research interests that revolves around the convergence of both networks. In the next chapter, we are going to present the state of the art of the research work conducted in the access network through the lens of virtualisation and network convergence.

Chapter 3

State of the art of research works in the access network

After presenting the 5G through its services and requirements in the first chapter, we talked in the second chapter about the optical infrastructure that delivers all types of connections to the end user, mainly to the antenna and through the RAN machine depending on the split options. Often, the mobile community takes for granted the fiber infrastructure, as it appears as a seamless tunnel used to transport the mobile signal to the user, while in reality, the optical access network segment is subject to its own physical limitations concerning bandwidth, latency and resource sharing. It goes without saying that mobile network planners need to take into account these limitations, previously minimal with the 4G but more and more present with the 5G and its requirements. The objective of this chapter is to study this symbiotic relationship between the optical access, specifically the access for fixed clients (FTTH) and the mobile access with the aim of bridging the gap between the two worlds. This relationship will be realised through a review of the state of the art. Then, in a second time, we position our work with respect to this state of the art and present the novelty of our contribution through three main axis:

• Optical fixed access infrastructure accommodating the upcoming 5G network through work realised in terms of functional splits study and their implementation.

• Raise awareness of the virtualization paradigm through research work realised around the access domains.

• Finally, bridging the gap between the two worlds, by presenting the works aiming towards fixed-mobile convergent networks.

Functional splits

Splitting RAN functionalities has been proven to have an effect on the transportation of the mobile signal in terms of operational costs and bitrate. For that matter, studies for RAN interface transportation have been proposed, especially in the case of C-RAN through its CPRI interface. As a consequence, we notice a considerable amount of research going into that direction, focusing mainly on the strong and weak points of different split options in terms of throughput, latency, centralization benefits etc. Figure 3.1, gives a chronological list of some of the most relevant works in that domain. Due to the fact that CPRI has already been used in C-RAN deployment, it 2012 • One of the earliest studies around CPRI in the access network describing "CPRI backhauling" as a new paradigm while listing its key advantages as well as its potential. [START_REF] Lometti | Network architectures for CPRI backhauling[END_REF] • Proposing WDM solution for CPRI based mobile fronthaul. [START_REF] Lee | CPRI transceiver for mobile front-haul based on wavelength division multiplexing[END_REF] 2013 • Compression method for the LTE signal transported in CPRI interface based on the removal of redundancy in the spectral domain as well as quantization that takes into consideration the amplitude distribution of the signal. [START_REF] Guo | LTE/LTE-A signal compression on the CPRI interface[END_REF] 2015 • A new specification (eCPRI 1.0) was released, its aim is to enhance the fronthaul interface in order to support 5G. [START_REF]Common Public Radio Interface:eCPRI Interface Specification[END_REF] 2018 • CPRI signal compression using a non uniform quantization of the LTE signal. [START_REF] Darweesh | CPRI Data Compression Using Non-Uniform Quantized Huffman Technique in C-RAN[END_REF] • General study to put the fronthaul in the context of 5G citing the main actors in the fronthaul and contrasting the 5G requirements with the fronthaul capacity. [START_REF] Sehier | Bandwidth Efficient and Flexible 5G Fronthaul[END_REF] • Proposing silicon photonics as a cost efficient enabler for 5G/Optical fronthaul while highlighting the challenge of transporting massive MIMO signal. Describes the optical network solutions for 5G. [START_REF] Mikroulis | CPRI for 5G Cloud RAN? -Efficient Implementations Enabling Massive MIMO Deployment -Challenges and Perspectives[END_REF] F 3.1 Fronthaul Timeline.

has been under scrutiny a bit more than the other split options. Initially, research revolving around the CPRI interface ranged from studying its economical and ecological impact to the bitrate's impact on the fronthaul and solutions to reduce this bitrate through compression algorithms. As research evolved, the attention has shifted into focusing on how to accommodate the somewhat rigid by design CPRI interface as the 5G specifications started to come out and to be compatible with other transmission protocols such as Ethernet. Notably, one of the major breakthroughs regarding this interface was the specification of enhanced CPRI (eCPRI) with the aim of enhancing the fronthaul interface and accommodate 5G [START_REF]Common Public Radio Interface:eCPRI Interface Specification[END_REF]. It differs from the CPRI for supporting natively Ethernet, allowing PtMP connections and enabling low layer functional splits. Functional split options have been investigated following their standardization and different specifications and have been the subject of various studies as well as implementations. Figure 3.2 lists the main contributions of the literature regarding real practical implementations of these options while highlighting their relevance. Generally speaking, the most researched split in term of experimental evaluation is the MAC/PHY split (Option 6) as well as intra-PHY (Option7x) options. Concerning High layer splits, there are fewer experimental implementations and those are generally focused on the PDCP-RLC split (Option2). With our choice of testing the transport of an option 2 PDCP-RLC split, we contribute to the practical experimentation regarding High-Layer Split (HLS) in the state of the art (Chapter 4). 2017 • Experimental evaluation of the capacity and the latency requirements of the fronthaul when an intra-PHY (Option 7) functional split is implemented in a vRAN/OAI setting. [START_REF] Valcarenghi | Virtualized eNB latency limits[END_REF] • Experimental evaluation of the MAC-PHY split (Option 6) in terms of latency, jitter and throughput. The implementation is based on the OAI solution. [START_REF] Mountaser | On the Feasibility of MAC and PHY Split in Cloud RAN[END_REF], [START_REF] Birring | An Ethernet-Based Fronthaul Implementation with MAC/PHY Split LTE Processing[END_REF] • Experimental evaluation of an intra-PHY implemented using an FPGA (Option 7.3 between channel coding and modulation blocks) demonstrating a 90% decrease in the optical bandwidth compared to a traditional C-RAN architecture. [START_REF] Miyamoto | Performance evaluation of ethernet-based mobile fronthaul and wireless comp in split-PHY processing[END_REF] 2018 • Proposing milimeter wave as an alternative backup for fiber.

The authors used a MAC-PHY as well as a PDCP-RLC (Option 2) split solution previously presented under the framework of the 5G Crosshaul project. Their contribution comes in the implementation of a mmWave (70 GHz) solution that will link the BBU to the RRU . [START_REF] Roldan | Experiments and results of a mmW transport platform to enable 5G cloud RAN lower layer splits[END_REF] • Provisioning of network resources for the RAN network through an SDN orchestrator, the RAN topology in question implements a PDCP-RLC split. [START_REF] Baranda | Orchestration of End-to-End Network Services in the 5G-Crosshaul Multi-Domain Multi-Technology Transport Network[END_REF] F 3.2 Functional splits timeline.

NFV and network abstraction for the access network

Following the advances in software technology, virtualizing network functions became easier. NFV for RAN has gone though massive breakthroughs and, as a consequence, various research works, namely through the OAI solution have seen the light. In addition to that, 5G sought to be disruptive and there has always been a will by the technical community to make various aspects of it cloud native and even present 5G as a service [START_REF] Imadali | Cloud Native 5G Virtual Network Functions: Design Principles and Use Cases[END_REF]. In the timeline of relevant works (Figure 3.3), we can see that the adoption of a VNF approach in the RAN follows broadly the shift in the trends in the virtualisation world. Starting with research work relying on hypervisors as a virtualization layer, then onto Virtual Machines (VMs) enabled by a Virtual Infrastructure Manager (VIM) such as Openstack and finally NFV deployment using containers, the virtualization technology that is currently in vogue. Our contribution to the state of the art for that matter is the implementation of mobile VNFs relying on a third party mobile software that recreates the entirety of the mobile network through the VIM Openstack, featuring a PDCP-RLC split (Chapter 4).

2016 • Implementation of an OAI based vRAN platform on top of a KVM hypervisor. [START_REF]HUAWEI-EURECOM Meeting[END_REF] 2017 • Proposition and implementation of slicing on top of a vRAN network realised in a modular approach, where each protocol layer is integrated into a software module. [START_REF] Zeng | 5G virtualized radio access network approach based on NO Stack framework[END_REF] • Demonstration in real time of an Ethernet based fronthaul solution based on a vRAN implementation of Altiostar on top of the virtual infrastracture manager Openstack. [START_REF] Tayq | Real time demonstration of the transport of ethernet fronthaul based on vRAN in optical access networks[END_REF] • An experimental evaluation in terms of latency and jitter of three RAN deployement scenarios: the first with a one to one DU/UE relationship, the second with multiple DU muliple UEs and finally a scenario where the CU and the EPC are virtualized.

The experimentation was conducted at the ARNO-5G testbed. [START_REF] Giannone | Impact of RAN Virtualization on Fronthaul Latency Budget: An Experimental Evaluation[END_REF].

2018 • Real time demonstration of an LTE connection to a C-RAN architecture enabled by an OAI implementation. [START_REF] Huang | Design and Integration of Fiber Fronthaul with Soft PHY for OAI-BASED RAN[END_REF], [START_REF] Costanzo | DEMO: SDN-based network slicing in C-RAN[END_REF] • The authors demonstrate a wireless fronthaul based on an OAI enabled vRAN [START_REF] Ramantas | A C-RAN Based 5G Platform with a Fully Virtualized, SDN Controlled Optical/Wireless Fronthaul[END_REF] • Automated deployement of vRAN using a OpenEPC mobile NFV solution. The study examined the deployement aspect of VNFs such as VM deployement and configuration time as well as recovery time in case of a link failure. [START_REF] Salvat | WizHaul: An Automated Solution for vRAN Deployments Optimization[END_REF] • OAI deployement on top of Openstack. [START_REF]C-RAN Demo -OPENAIRINTERFACE deployment on top of OpenStack[END_REF] • The authors deploy a virtual mobile solution to demonstrate their SDN orchestrator, the mobile solution is based on the OpenEPC platform [START_REF] Baranda | Orchestration of End-to-End Network Services in the 5G-Crosshaul Multi-Domain Multi-Technology Transport Network[END_REF] 2020 • Altiostar announced the first cloud native container based 5G vRAN solution, developed with the collaboration of Intel and which will be deployed by the operator Rakuten mobile in Japan. [START_REF] Altiostar | Rakuten Mobile and Altiostar To Launch World's First Cloud-Native, Container-Based 5G Radio Access Network Solution[END_REF] F 3.3 Mobile VNF timeline.

NFV for the Fixed Access Network (FAN) focuses mainly onto simplifying the implementation of the PON infrastructure by reducing the processing done localy at the level of the OLT. For instance, by applying the NFV process to the Operations Administration and Management (OAM) functions in the OLT we can deport these functions to generic servers. However, the real challenge is to apply this process to the DBA, a process that is sensitive to latency and which manages critical configurations on the bandwidth allocation of ONUs in the uplink. For that matter, most research work revolving around NFV for the fixed access try to come up with a virtual DBA that can be deported while respecting the time-critical operations. Recently, another trend that saw the light was the miniaturization of the OLT, holding into a Small Form-factor Pluggable transceiver (SFP). This miniaturization allows for a flexibility of PON deployment. We contribute to this aspect of NFV and flexibility through our work in 6.1 where we showcase a hybrid convergent PtP PtMP topology for mobile and fixed users enabled by a third party mini OLT. The main motivation behind SDN for the access network has already been reported in the previous chapters. In this chapter, we are trying to isolate the most relevant research work focusing on the abstraction of access network and not list all SDN initiatives in the field. The main use cases that have been highlighted pertain to slicing, easy deployment of a RAN network and multi-tenancy. Our contribution to the state of the art comes mainly in the form of an abstraction of various network parameters to create service slices in the access network (part III).

Fixed mobile convergence

Bridging the gap between the fixed and mobile worlds might be one of the characteristics of the access network of the future. The opening of mobile interfaces as well as the standardization of various split options in one hand and the abstraction of the control layer for the fixed access equipment following standardisation efforts on the other hand, are shrinking, day by day the separation between the two networks. To that effect, various research works (Figure 3.6) have been investigating how to marry the two worlds. One of the most promising leads is the cooperative DBA (CO-DBA) 2016 • FlexRAN implementation on top of an OAI setup, the paper aim was to evaluate the deployment of FlexRAN considering the existence of time critical operations in the RAN functionalities. [START_REF] Foukas | Flexran: A flexible and programmable platform for software-defined radio access networks[END_REF] 2018 • The authors provide abstraction models for links and nodes of the 5G-Crosshaul network to be leveraged by their end to end transport orchestrator. [START_REF] Baranda | Orchestration of End-to-End Network Services in the 5G-Crosshaul Multi-Domain Multi-Technology Transport Network[END_REF] • FlexRAN implementation on top of an OAI setup, the setup allowed for a real time demonstration of a mobile connection to stream videos and file download. FlexRAN allowed the creation of service slices for the mobile users. [START_REF] Costanzo | DEMO: SDN-based network slicing in C-RAN[END_REF] • Experimental demonstration using an SDN controller to dynamically configure the mobile fronthaul bandwidth in a Fixed/Mobile converged PON architecture. [START_REF] Alvarez | Experimental Demonstration of SDN-controlled Variable-rate Fronthaul for Converged LTE-over-PON[END_REF] 2020 • The ONF initiative is working on an O-RAN compliant SD-RAN with an ONOS based RIC developed using Aether, a hardware platform providing 5G/LTE Edge as service. [START_REF]Aether: Enterprise-5G/LTE-Edge-Cloud-as-a-Service[END_REF]. which aims at creating a DBA algorithm that adapts the transport according to the mobile signal requirements to be transported in the PON network. The idea behind this approach is that the OLT receives the mobile scheduling information from the CU through a cooperative interface in advance. From the received information it estimates the mobile data arrival period and allocates the bandwidth to cover the estimated arrival period. Another promising lead is to use virtualisation for creating a convergent fixed/mobile network through VNFs and a virtually implemented DBA algorithm to create a multi-tenancy that can be of service of fixed as well as mobile tenants [START_REF] Elrasad | Virtual dynamic bandwidth allocation enabling true PON multi-tenancy[END_REF]. These research works tackled the idea of convergence mainly through algorithmic and software solutions on top of physical PtMP topologies to showcase scenarios where convergence is allowed on the same PON tree. There are various theoretical works and studies that tackle the 5G connectivity and propose flexible scenarios such as [START_REF] Sehier | Transport evolution for the RAN of the future [Invited[END_REF] and [START_REF] Sehier | Transport Network Design for FrontHaul[END_REF] that also highlight the different infrastructure challenges for the 5G. In particular, [82] focuses on the optical infrastructure challenges. We must also mention that the fixed mobile convergence has been tackled in terms of service convergence such as in [START_REF] Savi | Energyefficient caching for Video-on-Demand in Fixed-Mobile Convergent networks[END_REF] or in terms of optimisation algorithms such as in [START_REF] Buttaboni | Virtual PON assignment for fixed-mobile convergent access-aggregation networks[END_REF] leveraging in their scenario a TWDM virtual PON and the assignment of its resources for the different network tenants.

Our contribution to this fixed mobile convergence comes into play through different sections of this manuscript (Sections 6.1, 5.2.2, 5.2.1 and in general, chapter 5), where we investigate, in a wider sense, different levels of convergence. Those which are at the level of the access equipment (one equipment serving both PtP and PtMP topologies), at the level of the fiber infrastructure (on the same PON tree) as well as the adoption of fixed access transport solutions in service of a mobile traffic (fixed and mobile traffic served by the same ONU). 2015 • Energy efficient video content caching archicteture that leverages the usage of a convergent Fixed/Mobile network by allowing the access to content caches on both of these network, previously mutually exclusive. [START_REF] Savi | Energyefficient caching for Video-on-Demand in Fixed-Mobile Convergent networks[END_REF] 2017 • The authors use virtualisation to create a convergent fixed/mobile network with a virtually implemented DBA algorithm to create multi-tenancy servicing fixed and mobile tenants. [START_REF] Elrasad | Virtual dynamic bandwidth allocation enabling true PON multi-tenancy[END_REF] 2018 • The authors experimentally demonstrate the execution of their vDBA algorithm implemented inside the fixed and mobile tenant's VNF, with an optimisation in place through a DPDK module to reduce the transaction time between the virtual entities and their underlying virtualization layer. [START_REF] Slyne | Experimental demonstration of DPDK optimised vnf implementation of virtual dba in a multi-tenant pon[END_REF] 2019 • Proposing the use of a novel DBA scheme relying on combining the Self reporting DBA, traditionally used in PON systems as well as the CO-DBA, the mechanism that was put in place to allow for the PON technology to be used in the RAN. In that way HLS, LLS as well as Fixed access users can all use the same Physical PON network. [START_REF] Nomura | Novel DBA scheme integrated with SR-and CO-DBA for multi-service accommodation toward 5G beyond[END_REF] • Proposing the use of a DBA scheme that accomodates mobile fronthaul traffic for IoT services as well as traditional FTTH traffic in the same PON network. The idea was to efficiently place the discovery window mechanism in the uplink transmission so to minimise the uplink latency for mobile services. The author's experimental setup shows an uplink latency of 150µs, 100µs lower than a traditional PON system. [START_REF] Uzawa | First Demonstration of Bandwidth-Allocation Scheme for Network-Slicing-Based TDM-PON toward 5G and IoT Era[END_REF] 2020 • Providing an algorithm that describes how multiple virtual tenants (fixed as well as mobile) with each their own vDBA algorithm can coexist in the same physical PON infrastructure. This coexistence is enabled by a "Merging engine" that causes two algorithms to schedule the access to the physical PON resources. The authors propose the creation of traffic classes that account for the fronthaul traffic and its specificities as well as the more traditional Fixed Access PON traffic [START_REF] Ahmad | Capacity Sharing Approaches in Multi-Tenant, Multi-Service PONs for Low-Latency Fronthaul Applications based on Cooperative-DBA[END_REF] F 3.6 Fixed Mobile Convergence.

Chapter conclusion

We presented the major state of the art research revolving around the main themes of this thesis, while putting our contributions into this context. This chapter serves as a projection of the previous two chapters into the world of research and academic innovations. Our main idea here was to provide a complement to the previous chapters, whose aim was to present the access network ecosystem and 5G through a broader lense of technology used, standardization efforts and telecom innovation initiatives. This chapter concludes the first part, and in the following one we are going to start presenting our experimental work, beginning with the building of our virtual infrastructure.

Part II

Transport of mobile interfaces using different optical access solutions

Chapter 4

Building the virtual mobile platform

Setting up the virtual platform to host the mobile solution required various building blocks. In this chapter we are going to present this platform, by first positioning it in the context of the ETSI NFV framework then presenting its blocks. We also present the implementation choices we made and the technical settings that allowed us to assemble the different blocks of the platform. Finally, we assess the performance of the mobile solution and the effect of the virtual resources (CPU and RAM) on it.

Context and implementation choices

This section presents the context surrounding the implementation of the virtual mobile platform, the challenges, the ETSI considerations and the description of the functional split that we implemented.

The challenges of enabling mobile functionalities by the NFV approach

Every mobile function can be virtualised, but the requirements of such task depends on the nature of this function. According to the European Telecommunications Standards Institute (ETSI), EPC functionalities such as the Mobility Management Entity (MME), Home Subscriber Server (HSS) and the Service/Packet Gate-Way (SPGW) are all good candidates. For the RAN, they suggest an approach where the computational resources are pooled and shared between various RAN virtual instances [START_REF]White paper; Network Functions Virtualisation (NFV); Network Operator Perspectives on Industry Progress[END_REF].

Previously in section 1.3.1, we discussed the current technological ecosystem that gave us the possibility to softwarize some of the RAN functionalities that can bring flexible deployment of RAN architectures. These architectures fit into a CU, DU, RU model. By deconstructing the RAN as such, the operators gain multiple degrees of freedom when deploying their access network by using non dedicated hardware such as COTS servers to implement different mobile functionalities. However, not all functions can be virtualised in the same fashion. For instance, time sensitive processing hungry functions typically found in the DU such as radio signals generation can always be better executed in dedicated hardware. The O-RAN alliance has estimated the features necessary for each of the vRAN blocks in their Open-CU Control Plane and User Plane (O-CU-CP and O-CU-UP) / O-DU / O-RU definition (see Table 4.1) with more details in [START_REF]Cloud Architecture and Deployment Scenarios for O-RAN Virtualized RAN[END_REF]. Taking Table 4.1 as reference, we can see for example that the CU functions can be separated into control plane and data plane functions. The latter are potential candidates for virtualization on non dedicated servers (typical cloud infrastructure). The DU on the other hand can host time sensitive functions that demand a lot of processing power. Virtualizing the DU functions can require hardware acceleration depending on the split, and finally if we wish to push for a full virtualization of the RAN stack, the RU being composed of entirely physical layer functionalities, need hardware acceleration to implement PHYsical (PHY) functions. Recently, an industrial (xilinx) has taken as reference the O-RAN Cloud/Hardware features and managed to propose a solution to transport the 5G fronthaul and accommodate the different time and computational sensitive functions [START_REF] Gibbons | Xilinx Hardware Accelerators Link Up With O-RAN to Push 5G Server Performance[END_REF].

Positioning our virtual infrastructure with respect to the ETSI NFV framework

The ETSI standard developed an architectural framework [START_REF] Etsi | Network Functions Virtualisation (NFV);Architectural Framework[END_REF] to come as reference for the building of NFV compatible products. The overall NFV architecture has been exhaustively defined with all its key elements as well as the interfaces and how they interact with each other. These elements can be seen in Figure 4.1. In a nutshell, we can define three main categories:

• The NFV Management and Orchestration (in cyan) of physical and software resources. It interacts with the NFV, NFVI (shown in the third bullet point) and with the Operations Support System (OSS) / Business Support System (BSS) blocks that pertain to the network management and business operations respectively.

• The Virtualised Network Function (VNF) (in green), consists of the functions being implemented as a software as well as the Element Management System (EMS) that manages its corresponding VNF instance.

• The Network Functions Virtualisation Infrastructure (NFVI) (in orange), details the hardware and software components an NFV infrastructure should contain.

To put our virtual mobile infrastructure in terms of the ETSI NFV paradigm, we represent our virtualization environment (Figure 4.2) with its elements listed below: • Our Openstack software, that manages the abstraction of hardware resources and exposes them for the use of our NFV elements.

• The physical host which is a rack server with an x86 architecture running CentOS Linux distribution (Figure 4.3).

• The VNF elements, each one of them representing one of the mobile network elements running on a Ubuntu Linux distribution VM. Our implementation doesn't include all the NFV blocks specified in the ETSI. For instance, we don't have distinct orchestration blocks, a VNF manager or an EMS block. Our setup relies on one physical node (a DELL POWEREDGE R630 x86 Linux server) that features 40 Intel Xeon E5-2630 v4 processors with a frequency of 2.5

GHz and 62 Gigabits of RAM as well as a 1.1 terabyte of disk storage. The node and its physical resources are managed by an Openstack software that instantiates VMs and manages them through a toolset that we are going to detail a bit further in the chapter. Our single node implementation through the management of Openstack exposes virtual resources such as memory, CPU and network interfaces for the VMs to use. Openstack is a VIM and can be described as a platform for providing Infrastructure as a Service (IaaS) through network functions as well as server resources provisioning. To be able to provision these resources, Openstack typically relies on the virtualisation layer to expose the physical server resources through corresponding virtual ones. In our case, the Openstack implementation used (Ocata version) doesn't go through a typical virtualization layer such as hypervisors but uses a set of Openstack Application Programming Interfaces (APIs) in what is known as a bare metal implementation. This bare metal implementation relies on the Ironic virtualization driver for nova compute, one of the main nodes of Openstack (that we develop further in section 4.2.1.2) to provision the physical resources for the virtual machines created.

Why a PDCP-RLC split?

In our experimental setup, we chose to go with a PDCP-RLC split. It is one of the reoccurring functional split in the literature (see section 3.1). It gained traction with various operators and is one of the most likely splits to be implemented. We are going to further develop the specificity of this split and how it is an interesting candidate for 5G.

The PDCP protocol layer serves as the link between the radio access network world with its protocols and the rest of the IP based network. It has many functionalities with more details in [START_REF] Etsi | Packet Data Convergence Protocol (PDCP) specification[END_REF] such as:

• Transferring user and control data between RLC and the higher layers user plane interface, as well as multiplexing multiple RLC links.

• RObust Header Compression (ROHC) which serves at reducing the protocols overhead and thus maximizing the useful data going through our network.

• Encryption and decryption of user and control data.

• Ensuring the Integrity of control plane data.

The RLC links connect to the PDCP layer and serve mainly as a concatenation and segmentation of IP packets that are being forwarded through the PDCP header. However, the main particularity of this layer is that it provides three distinct transmission modes given in detail in [START_REF] Etsi | 5G;NR; Radio Link Control (RLC) protocol specification[END_REF]:

• Transparent Mode (TM): Transmits the data to and from the Media Access Control (MAC) and the PDCP layers without any further processing. Instead, it works as a buffer for the incoming packets before transmitting them.

• Unacknowledged Mode (UM): Adds/removes the RLC header to/from the data before forwarding it to its designated layer, as well as segmenting, concatenating or reordering IP packets that are encapsulated in PDCP frames. The packets' transmission to the MAC layer is not assured as it is an unacknowledged mode.

• Acknowledged Mode (AM): The main difference of this mode compared to the UM mode is that it allows re-transmissions. Each RLC packet is sent to the MAC layer with another copy of it sent to a re-transmission buffer. If the RLC does not receive a confirmation from the MAC for the packets, the retransmission buffer will send the packet to the main transmission block to be sent again.

The PDCP-RLC split can be a good candidate for 5G. It can be transmitted in a D-RAN architecture and the interface bandwidth would be closer to that of the backhaul S1 interface, thus minimising its impact in terms of bit-rate and latency constraints. With regards to standardization, this split is recommended as a solution for the dual connectivity scenario in the 3C configuration (Figure 4.4) between a master eNB and a secondary gNB as described in [START_REF] Gpp | Technical Specification Group Radio Access Network; Study on new radio access technology: Radio access architecture and interfaces[END_REF], with more details in the next section (4.1.4).

In the next two sections we will explain how the PDCP-RLC split is a good candidate. First, for 5G NSA scenarios and second, as a high layer split option for a (CU, DU, RU) in a SA RAN architecture.

The PDCP-RLC split role in the 3C configuration for 5G NSA

For the sake of conciseness and since our goal in this section is to highlight a scenario where a separation occurs after the PDCP layer, we will focus only on option 3 of 5G deployment (see Figure 1

.7).

A radio bearer is a link provided by layer 2 to higher layers for the transfer of data, it defines user packets that have the same quality of service treatment and is used to transport them from the UE to the RAN. An abstraction of this process would be to represent it as a data tunnel that can go from the UE to the radio equipment. In a standard LTE network the radio bearer would go directly from the eNB to the UE (Figure 4.4). However, in 5G NSA, a new concept will be seen, known as the split bearer.

The split bearer comes to serve the dual connectivity scenarios. One of these scenarios is as follows: a MeNB will be connected to a SgNB and a user equipment will be connected to both the master and secondary antennas. The control information relative to the UE will be transported in the MeNB whereas the user data will be transmitted first to the MeNB and then it will continue its course both in the MeNB and to the SgNB designated by the number "3" of the option, under the same bearer, hence the name split bearer. One of the split bearers scenarios would be one where the PDCP sublayer of the MeNB will serve RLC packets destined for both MeNB and SgNB. The process of having one PDCP sublayer being served by multiple RLC sublayers is designated by the letter "C" in "3C" [START_REF] Antonioli | Dual Connectivity for LTE-NR Cellular Networks: Challenges and Open Issues[END_REF] (see

The PDCP-RLC split adoption as the CU-DU split in 5G SA

The PDCP is the link between the UE from one side and the eNB from the other side. While keeping in mind the minimal impact of said split on our D-RAN topology and the fact that we can multiplex multiple RLC sublayers serving different paths and users, it would be an interesting choice to use the PDCP as an aggregation point in the CU, while serving multiple DUs through their respective RLC sublayers. In the 3GPP standard given in [START_REF] Gpp | Technical Specification Group Radio Access Network; Study on eNB(s) Architecture Evolution for E-UTRAN and NG-RAN", 3rd Generation Partnership Project (3GPP)[END_REF], the authors study the architecture evolution of the eNB in E-EUTRAN (4G RAN) and in general for the NG-RAN (Both 5G NR and E-UTRAN available). The authors define the eNB Central Unit (eNB-CU) as the logical node hosting RRC and PDCP layers, and the eNB Distributed Unit (eNB-DU) as the logical node holding RLC, MAC and PHY layers.

The implementation of the mobile platform

In this section we are going to describe the building blocks of the platform and the technical considerations that allowed us to generate and transport the mobile traffic on the network.

The platform building blocks

The platform in which we have implemented our vRAN infrastructure is going to be described from the bottom up with the foundation of it all relying on a CentOS Linux distribution.

The CentOS Linux distribution

We decided to use CentOS, the free equivalent of the RedHat Linux (RHEL) distribution as our server's OS. Table 4.2 presents it characteristics compared to other known Linux distributions. CentOS offers more stability (thoroughly tested with fewer bugs) than the Ubuntu and fedora ones. Although it has less frequent updates and relatively less software packages, it is mainly used in IT platforms and its stability make it suitable as a host for the mobile platform.

VIM Openstack

Openstack exposes the physical resources of the server and abstracts them into virtual resources, it manages them through virtual resources using several key elements listed below as well as shown in Figure 4.6:

• Nova : is the Openstack component that creates virtual machines and provisions them with the appropriate resources to function.

• Keystone: provides identity and authentication for all Openstack services.

• Glance: provides the OS images that the virtual machines will use to boot. • Neutron: responsible for creating and managing virtual as well as physical networks to which the VMs will connect to upon boot.

• Horizon: the graphical user interface of Openstack, through this interface we have an overview of all Openstack services.

• Cinder: the Openstack service that provides storage volumes to virtual machines. This storage volume is persistent and can be attached to a virtual machine similar to an external storage disk in the case of a physical machine.

• Openstack Object Storage (swift): used for redundant and scalable data storage. In other terms, it offers a cloud storage software that enables the storage and the retrieval of large amounts of data.

Virtual Network Functions

The virtual network functions that we implemented on top of Openstack consist of the entirety of the mobile functions from the core network elements in the EPC to the RAN functionalities down to the LTE MAC layer. The solution's name is OpenEPC and is provided by the company Core Network Dynamics (CND). Figure 4.7 shows the logical mobile architecture with the different mobile interfaces that link each block with the other (an overview of these interfaces can be seen in [START_REF] Cablefree | LTE Interfaces: Explaining the Interfaces in LTE[END_REF]). This logical architecture is compared to the screenshot of the Openstack implementation as viewed through the horizon dashboard, a view that gives the network links between each virtual machine. We are going to describe the VM roles going from the EPC towards the vRAN: Our first virtual machine called epc_enablers regroups some of the major core functionalities such as the HSS, the IP Multimedia Subsystem (IMS) functionalities [START_REF] Gpp | Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS)[END_REF] such as Proxy-CSCF (PCSCF), Diameter Routing Agent (DRA), Interrogating-CSCF (ICSCF) and the Serving-CSCF (SCSCF) (Figure 4.8).

Then we have a virtual machine for the SPGW. The SPGW is a node that is composed of two main functions, the Serving Gateway (SGW), the gateway that represent the ingress/egress point of user data from and to the core network, and the Packet Gateway (PGW) which is the ingress/egress point between the core network and the Packet Data Network (PDN), an umbrella term that designs the outer network relative to the mobile network (typically internet network). The next VM is the MME. It manages the signaling between the UEs and the core network and communicate with the HSS in order to search and stock UEs profiles and security information.

For the vRAN, the high layer split that we implemented is comprised of two main blocks: the CU VM which holds all the CU's functionalities up to the PDCP layer and the DU+RU VM1 that holds functionalities from the RLC up to the MAC layer. Since we don't study the radio transmission, we don't have a physical transmission layer (radio layer). Finally, we have an emulated UE at the reception, which is put in a separate virtual machine, and which holds all the aforementioned mobile protocol layer functions so that it can deal with the signals sent to/received from the DU+RU.

Assembly of the building blocks

In this section we present the approach we followed to put in place the mobile platform. To do so, we used Openstack services as well as specific Linux kernel configurations inside the host server. These configurations allow the server to perform as two separated blocks hosting the mobile services. The separation occurs between the CU and the DU+RU blocks at the level of the PDCP-RLC split. The entirety of Openstack services in our platform are hosted in a single server which is a sufficient configuration for testing. In case of a real life deployment scenario, an Openstack implementation relying on multiple nodes is common. In the multiple nodes configuration, the Openstack services are located on different physical nodes. The most common approach in multi node configuration is to have the compute nodes (running with the nova compute service and hosting the VMs) separated from the controller node (containing the other Openstack services), the latter controls the compute nodes and supplies them with the necessary services. In our single node configuration, we mainly relied on the following Openstack services:

• Nova: Through this service we created the VMs for the "EPC enablers", the SPGW, the CU, the DU+RU and the UE.

• Neutron: After creating the VMs, we use neutron to create an IP network to interconnect them. We configured the IP network with the appropriate subnetworks (subnets) and security rules that provides them with connection as well as isolation.

• Glance: Used to install the Linux Ubuntu Operating System (OS) in the VMs.

In addition, glance offers the possibility-once the necessary software prerequisites are installed in a VM-to take a snapshot image of the machine and use it to boot up the other created machines. As a result, the installation process is reduced considerably and is less prone to human error.

Once the virtual infrastructure (virtual machines, subnets, security rules) is put in place, the mobile blocks are connected with each other. Each block is virtually connected according to the mobile architecture in Figure 4.7. In order to test the optical transmission solutions at the level of the PDCP-RLC split, we need to break the virtual connection between the CU and DU+RU machines and expose their interfaces outside the server through the NICs. In the case of such exposition, and in a downlink scenario, the data will be transmitted from the EPC to the CU, then goes out the server and through the optical solution and loop back to the server to be received by the DU+RU blocks. In Figure 4.9 we explain the process we applied in order to expose the mobile interfaces outside of the server. Figure 4.9 (a) shows the initial implemented mobile platform and (b) shows the platform after exposing the interfaces. In the closed mobile platform, Openstack uses a type of network called self service that creates private networks that links the VMs with each other. In the exposed mobile platform, we break the private network between the CU and the DU+RU and link each one to a distinct provider network. A provider network is an external network that has the ability to connect to the physical infrastructure (in our case to the NICs) via layer2 bridging and switching. Now that both the mobile interfaces are exposed outside of the server, another issue is to make the traffic go outside. The traffic goes from one interface to the other from within the server because both interfaces are located in the same Host OS domain.

In order to make the traffic go outside the server, we created two separate domains for each NIC. These newly created domains are called namespaces, they are a feature of the Linux kernel that creates partitions of kernel resources. The processes inside of each namespace have access only to the partition of resources inside it. In our case, namespaces allowed us to create domains isolating the NICs. As a result the NICs are isolated from the provider networks located in the Openstack namespace. In order to link the different domains while maintaining their isolation, we are going to use pairs of virtual Ethernet (VETH) devices. A VETH pair is a local Ethernet tunnel, when established between two namespaces, all traffic transmitted on one device of the pair is immediately received on the other device, when either device is down, the link state of the pair is down. The NIC1 and NIC2 namespaces are connected to the DU+RU and CU blocks respectively. In the namespace of NIC2 we created a virtual router that allow us to route packets to and from the CU and on the other side, in the NIC1 namespace, we created a simple bridge to forward traffic to and from the DU+RU blocks.

Assessment of the mobile solution in the virtual platform

Given the mobile solution is proprietary with no access to the source code, it is important to verify that the solution is working in concordance with the 3GPP specifications and to study the behaviour of the mobile solution with the virtual platform. The assessment of the mobile solution is conducted following three main parts:

• Analysing the encapsulation of transmitted data by the solution.

• Verifying that the solution is conforming to the 3GPP standard.

• Studying the effects of virtual resources on the performance of the solution.

Analysis of data encapsulation in the mobile platform

In this section we are going to detail the functioning of the virtualized mobile platform and we start with an understanding of how the mobile protocol stack affects the IP packet transported in the platform. First, we are going to analyse the different headers added at each node of the platform (represented in Figure 4.12). The encapsulation will be explained in detail by analysing a UDP/IP packet containing a 1000 bytes payload transmitted from the EPC_enablers machine to the UE. The analysis will address the various encapsulations performed at the level of each node. The EPC_enablers: First we start by studying the packet coming out of the EPC_enabler machine and reaching the SPGW. In the first row of Figure 4.13, we can see the 1000 bytes of data encapsulated in a UDP header of 8 bytes then an IP header of 20 bytes with the source address of the EPC_enablers' machine and the destination address of the UE. The 1028 bytes represent the mobile payload that is generated by this machine and transported to the SPGW. At the level of the EPC_enablers machine a 14 bytes MAC header is added to be able to create a Layer 2 communication link with the different mobile nodes. If we were to draw a parallel with the real world, this encapsulation would represent in general the physical medium in the access network that would allow the transport of mobile data. The SPGW: The SPGW in the virtual setup creates a GPRS Tunneling Protocol (GTP) tunnel (shown in the wireshark screenshot in Figure 4.14) that transports the data from the core network to the vRAN. The second row of Figure 4.13 shows the additional packet encapsulations that happened at the level of the SPGW machine. An additional 8 bytes of the GTP header for the user plane has been added. The wireshark screenshot in Figure 4.14 details the various fields of this header in our transmission namely, the GTP version, its type, and the message type. In our case it is signaling a G-PDU (GPRS tunneling protocol PDU) and its payload the T-PDU (indicating that the mobile payload is an IP packet). The GTP tunnel is encapsulated in a UDP then an IP packet with the source IP address of the emitting node (in this case the SPGW) and the destination IP address of the next node (in this case the CU). The addition of the UDP and IP headers, 8 and 20 bytes respectively, are performed by the mobile solution in what's called "LTE over UDP" which has been purposefully defined for wireshark to be able to dissect LTE packets' fields [START_REF] Wireshark | Medium Access Control (MAC) for LTE[END_REF].

The CU:

At the CU, there was an increase of 2 bytes compared to the received packet from the SPGW. Wireshark wasn't able to decode beyond the network access Ethernet and mobile internet/transport headers. Therefore, we based our analysis (illustrated in the third row of Figure 4.13) on the premise that the GTP tunnel is still maintained at the level of the CU and that the PDCP header is encapsulated in the GTP tunnel.

The DU+RU:

At the level of the transmission of the DU+RU and the reception of the UE, various encapsulations occur (illustrated in the fourth row of Figure 4.13). Based on the previous assumptions of encapsulations at the CU, we assume that there is no longer a GTP tunnel. We also assume that an RLC header of 2 bytes has been added after the PDCP header to be in accordance of the MAC SDU length of 1032 bytes, advertised by the MAC-LTE header. This header of 20 bytes was perfectly decoded by wireshark and we assume that it encapsulates the RLC packet.

The MAC-LTE header is added in the scope of the LTE over UDP framing discussed earlier in this section. This header contains the "layer 2 of the LTE interface" according to the wireshark Wiki [START_REF] Wireshark | Medium Access Control (MAC) for LTE[END_REF]. In the case of our transmission these are the fields contained in this header viewed in the wireshark capture in Figure 4.15:

• Radio type : Frequency Division Duplex (FDD)

• Transmission direction : downlink • Frame and subframe number : 0 and 6 respectively • Radio Network Temporary Identifier (RNTI) and its type: in our case it's a Cell RNTI (C-RNTI) which is a unique identification used to identify the connection and scheduling of a particular UE.

• The MAC PDU: representing the real mobile MAC header. In our case it contains one subheader composed of 3 flag bits and a 5 bit Logical Channel ID (LCID) field (Figure 4.15). A mobile MAC header size is variable depending on the channels transported within it and the number of subheaders transported. More details of its fields are given in [START_REF] Gpp | Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification[END_REF].

The study of the encapsulation allowed us to calculate the overhead added by the mobile solution. By applying the findings we can estimate the overhead added at each mobile interface. Table 4.3 shows the results for each interface. We based our calculations on the same previous example of the 1000 Bytes data transmission and these percentages will change based on the size of the payload. With the addition of the User Datagram Protocol (UDP) and Internet Protocol (IP) headers, we had a mobile payload of 1028 bytes to be transported. To this mobile payload were added various headers by the mobile solution. The overhead percentage is calculated based on how many bytes were added on top of the 1028 bytes of the mobile payload. In our calculation we didn't include the MAC header (Blue in Figure 4. [START_REF] Lanzani | OBSAI RP 301 6.144 Gbps Interface Implementation[END_REF] because it pertains to the transport of the physical medium and is not added by the mobile solution. From the analysis of the mobile payload we can have an idea about the additional bandwidth necessary at the level of each mobile interface which can be beneficial for network dimensioning. The analysis remains limited to this particular mobile solution but can give us an overall idea of how the mobile payload is encapsulated in the network.

Mobile interface

Basic mobile procedures in the vRAN

The analysis of the control plane was conducted through the control messages exchanged between the different RAN entities namely for the attach and the detach of a user equipment while contrasting them with the 3GPP standard. The aim here is to verify if the two main mobile procedures that allow for the UE to connect and disconnect from the network are operational. Figure 4.16 and 4.17 show the attach and detach procedures respectively. They also show the different type of messages that have been exchanged between the UE and the rest of the network.

Attachment procedure

The attach procedure shown in Figure 4.16, corresponds to the LTE 3GPP standard.

The first notable exchange of information corresponds to the Radio Resource Control (RRC) connection (presented in [START_REF] Gpp | Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification[END_REF]), this procedure is composed of three main messages :

• RRC Connection Request: the RRC layer of the LTE stack sends a connection request from the UE.

• RRC Connection setup: the DU+RU machine replies with an RRC connection setup message that configures the MAC layer of the LTE protocol.

• RRC connection setup complete: the UE sends a confirmation message notifying of the setup of the RRC connection.

After the establishment of the RRC procedure, the UE sends a messages to establish a connection to the PDN and to attach to the network. Following this, the DU+RU initiates an authentication, security and identification procedures. Once these procedures are successful, an exchange of information between the three nodes indicate the acceptation of the attach (3GPP spec [START_REF] Gpp | 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access[END_REF]).

Detachment procedure

The detachment procedure (Figure 4.17) contains two parts, the first exchange of messages that detach the UE from the network ((3GPP spec [START_REF] Gpp | 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access[END_REF]), and the second one is the release of the RRC connection that was previously setup in the attach procedure (3GPP spec [START_REF] Gpp | Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification[END_REF]) .

Studying the effect of virtual resources on the performance of the mobile solution

Through Openstack we can manage the resources of each virtual machine. It will be interesting to see the effect of allocating certain virtual resources (RAM, CPU, disk space) to a certain VNF and assess the overall performance of the system. We chose to assess this performance in terms of latency, packet jitter and frame loss rate and Table A.2 in Annex A, shows some of those results. We found out that there is no correlation between the virtual resources allocated for the virtual machines F 4.17: UE detach procedure.

and their performance. However we found out that there is a minimal requirement setting (1 CPU and 1 GB of RAM) for all machines and (1 CPU and 2 GB of RAM for the "epc_enabler") that allows the vRAN to function. Table 4.4 shows some of the configurations that we tested inside the EPC VM, the "OK" means that the three oprations of attach, ping and iperf were succesful whereas the "NOK" means that those same operations were not possible. 4.18 shows the limitations. The dark blue zone corresponds to a low frame loss ratio. The Frame Loss Ratio (FLR) increases with the increase of bitrate and the decrease of packet size. This is due to the fact that the process that enables the mobile functions inside each virtual machine is executed on a single thread. Therefore, adding multiple virtual CPUs won't increase the capacity of the transmission. This is further supported by our results in Table A.2 about the non correlation between the resources and the performance of the platform.

As a consequence of this execution on a single processor for each VM, the number of packets being processed each second is linked to the CPU frequency (more details about this in section 6.1.2.1). This creates an upper limit on the number of packets that can be transmitted. This translates to a packet loss increase after a configuration of packet size and bandwidth that exceeds this limit. This upper limit have been tested on standard VMs not containing the mobile VNFs and it showed that this limit is much higher (Table A.1 in the Annex). This leads us to conclude that this particular mobile solution itself has an effect on the limitation of the transmission, an example of a potential parameter that should be taken into consideration by operators when deciding to implement a virtual mobile solution. In the remainder of our vRAN experiments we will position ourselves in an optimal transmission zone (dark blue in Figure 4.18) so that we only to assess the effect on the mobile signal transmission caused by the various optical transport solutions.

Chapter conclusion

In this chapter we presented the context and the implementation choices we made when putting in place the virtual mobile platform. We chose to set up a commercial mobile solution (OpenEPC) that comes with a PDCP-RLC split configuration in a virtual platform managed by Openstack. The implementation of the mobile platform consisted of installing the mobile software on top of created VMs and interconnecting them using virtual networks. Through additional configuration on the host server, we managed to expose the virtual interfaces of the CU and the DU+RU VMs outside the server through the physical NICs. The mobile traffic generated will, as a result, be transported virtually inside the server, goes outside through electrical Ethernet interfaces and then transported on an optical transmission solution. We analysed the mobile header encapsulation of the mobile payload that occurs at the level of each mobile interface and with that information we can estimate the additional bandwidth required on top of the mobile payload at the level of each interface allowing proper dimensioning of the network. The paradigm shift of using virtual infrastructure in the network adds new parameters to the implementation of mobile nodes compared to the traditional approach relying on dedicated equipment, these parameters range from the correct dimensioning of the virtual infrastructure at the level of datacenters as well as the provisioning of the virtual resources (RAM, CPU, Disk space) and the different approaches of scaling the network. This chapter serves as a premise for the following one where we present the transmission of the virtual mobile traffic through various optical transmission technologies and topologies. In the next chapter we will test the transport of mobile data generated by the virtual platform and putting different optical transmission solutions between the CU and the DU+RU blocks to assess their impact on the transport of mobile traffic.

The study in the next chapter will not focus only on this split but it will also concern a Low Layer Split (LLS) interface.

Chapter 5

Assessing the transport of mobile interfaces over various optical media

The last segment of the RAN is predominately based on PtP links capable of transporting different Radio Access Technologies (RATs) interfaces (2G, 3G, 4G). With the advent of 5G and the later evolution of the 4G network, new topologies have been proposed for the RAN to answer future service demands [START_REF]5G wireless fronthaul requirements in a passive optical network context[END_REF]. The alternative topologies that have been proposed instead of the classic PtP are the PtMP, a setup primarily used to connect FTTH users in the access network (see sections 2.1.1 and 2.1.2) and a hybrid architecture merging both PtP and PtMP elements [START_REF]5G wireless fronthaul requirements in a passive optical network context[END_REF]. In this chapter, we are going to investigate and study the impact of the virtual mobile platform on architectures that we propose. These architectures consists of two PtP architectures enabled by two different optical transmission solutions then finally a PtMP one enabled by a 10 Gbit/s solution.

Transmission of mobile interfaces through optical pointto-point architectures

The optical modules used traditionally for RAN are black and white NRZ transceivers, meaning that they should be appropriately matched so they can both transmit and receive in their designated wavelengths. In this section of the chapter, we are going to assess the transport of our vRAN PDCP-RLC interface through two different PtP architectures. Each one of them with the potential to increase the RAN throughput. In the first one we propose, implement and test the transmission of the mobile signal using a modulation format called Pulse Amplitude Modulation (PAM4). In PAM4, the same baud rate as an NRZ transceiver codes the bits into 4 levels of optical power. The second one consisted on proposing, implementing and testing a Low Layer Splits (LLS) split mobile transmission on a PtP WDM PON prototype relying on tunable DWDM transceivers.

PAM4 modulation scheme in service of the virtual RAN

In this section we test the PAM4 modulation to assess its performance at transporting our vRAN interface while comparing it with a traditional NRZ transmission.

Motivation behind using PAM4

PAM4 is a modulation format that codes bits onto 4 levels of amplitude compared to the NRZ which uses only 2 levels. For instance, a sequence of "01" will be transmitted using one PAM4 symbol whereas an NRZ signal will need two symbols. So for the same baud rate, a PAM4 doubles the bitrate.

Our lab generation of a PAM4 signal relies on encoding it as Most Significant Bit (MSB) and Least Significant Bit (LSB) NRZ streams. The MSB is aligned with the LSB, the latter is then attenuated and added to the MSB to form our PAM4 signal. The decoding relies on three Limiting Amplifiers (LAs) in addition to Exculsif OR (XOR) gates to detect both the MSB and the LSB (Figure 5.1).

Our motivation behind this solution is that the optical access infrastructure is extremely cost sensitive so any technology that will allow the reuse of already available COTS optical components will be interesting. For instance, using available lasers with a large bandwidth allowing us to double the bitrate of access links would be interesting to investigate in the context of eMBB services. There is however, a sensibility penalty going from NRZ to PAM4, for example going from 25 Gbit/s NRZ to 50 Gbit/s PAM4 incurs a sensitivity penalty of 8-9 dB [START_REF] Van Veen | Strategies for economical next-generation 50G and 100G passive optical networks[END_REF]. This is due to the fact that the Peak to Peak Voltage (VPP) permitted is divided into four levels instead of two for the NRZ, making the decision threshold smaller.

Mobile traffic over PAM4 experimental setup

Studies have been conducted to show the feasibility of such transmissions by transmitting a Pseudo Random Binary Sequence (PRBS) signal in optical access solutions such as PON, using PAM4 to enable a 25Gbit/s PON downstream transmission over 20 km, with a 29 dB Optical Distribution Network (ODN) budget [START_REF] Barthomeuf | Real-time Downstream 25 Gbps PAM4 for High Speed TDM-PONs with both 25 and 12[END_REF]. In our contribution, we are demonstrating the transmission of our real-time PDCP-RLC interface over an experimental bench using a PAM4 generator (the PAM4 solution is taken from [START_REF] Barthomeuf | Real-time Downstream 25 Gbps PAM4 for High Speed TDM-PONs with both 25 and 12[END_REF]) in a PtP architecture. The remainder of the setup is given in details in chapter 4.2.1. In the access segment, between the switch and the antenna site, we are going to perform a physical layer transmission using a real-time traffic at 20 Gbit/s PAM4 over 20 km of fibre. Figure 5.2 shows our experimental setup: In the extremities (in blue) we have the virtual mobile platform (see 4.2.1). The second part of the setup refers to the emulation of the aggregation network. This emulation is realised with a network impairment engine introducing latency, packet jitter and Bit Error Rate (BER) to the mobile interface. The mobile interface then goes to a 10 Gb Ethernet (10 GbE) switch that would also be connected to other cell sites in the case of an actual deployed network. The traffic of those additional sites for both uplink and downlink (UL/DL) is created with an Ethernet traffic generator, allowing us to reach a symmetric throughput of 10.3125 Gbit/s. The overloading and mobile payload interface under evaluation are distinguished with different Virtual LAN (VLAN) tags.

Finally, the fixed access plane is represented essentially by the real-time PAM4 encoder and decoder, the optical transceivers and a point-to-point transmission through 20 km of Standard Single-mode optical fiber (SSMF). We use 10G Small Form-factor Pluggable transceiver (SFP+) modules and evaluation boards to provide connectivity adaptation between the 10 GbE switches and the SMA coaxial connectors inputs/outputs of our PAM4 bench. Without loss of generality, here we focus only on the downlink transmission. The uplink does not go through the PAM4 bench and is short circuited between the evaluation boards. We generate a 10GbE stream containing the mobile payload and the overloading traffic. This single stream is copied and phase shifted to provide two decorrelated streams to the PAM4 generator. We then inject both streams as MSB and LSB inputs of our PAM4 encoder. The PAM4 signal is amplified with an electrical driver before modulating a 10 GHz Directly Modulated Laser (DML) emitting at 1311 nm. An attenuator adjusts the power at the input of an 8 GHz Avalanche Photo Diode (APD), with embedded Transimpedance Amplifier (TIA) after the propagation through a standard single mode fiber. The received electrical signal then attacks the PAM4 decoder, which separates the LSB and MSB flows of the PAM4 signal as shown in the previous section. More details on the procedure are given in [START_REF] Barthomeuf | Real-time Downstream 25 Gbps PAM4 for High Speed TDM-PONs with both 25 and 12[END_REF].

Results and discussions

In order to assess the effects of the PAM4 modulation in the mobile transmission, we take an Optical Back to Back (OB2B) NRZ Ethernet transmission as reference and we compare it with the MSB flow of our PAM4 transmission after 20 km SSMF without forward error correction. In our studies we focused only on the MSB because we couldn't decode the LSB and retrieve from it our initial data due to issues relative to the performance of the PAM4 module. The eye diagram corresponding to our transmission is shown in Figure 5.3 where we can see the eyes corresponding to the LSB bit much smaller than those of the MSB bit.

To evaluate the access transmission and emulate different possible degradation phenomena coming from the aggregation network, we purposefully degrade the mobile interface BER and we introduce a normally distributed latency variation in order to insert some packet jitter in our system. Figure 5.4 shows UDP FLR variation between the EPC and the UE for different bitrates and introduced BER values for a packet size of 1200 bytes. We can see that the FLR of our reference scenario is below 0.3% but increases for bit-rates beyond 150 Mb/s. The reason behind this is the limitation of the mobile solution, explained in section 4.3. We can also see that the PAM4 MSB optical access degrades the FLR by 0.8pp (percentage points) compared to the reference scenario. The introduction of a BER of 10 -6 degrades both NRZ (Ethernet) and PAM4 transmissions by about 0.5pp compared to their respective transmissions without degradation. The BER value of 10 -6 is supposed to deliver a near error-free Ethernet transmission with an FLR of less than 1% as been demonstrated in [START_REF] Brand-Rex | White paper: The Impact of Bit Error Rate on LAN Throughput[END_REF]. This confirms that the PAM4 solution doesn't react differently to a BER degradation. In all cases, the FLR remains below 5% for bit-rates up to 150 Mb/s. Figure 5.5 depicts the impact of the emulated packet jitter in the FLR for different bit-rates. We fixed the mean introduced one-way latency to 2 ms and considered two values of packet jitter, namely 0.66 ms and 0.10 ms. The effect of the jitter is particularly noticeable and stronger for higher bit-rates. Whereas an introduced jitter of 0.1 ms imposes a linear FLR degradation with respect to the bit-rate, a jitter of 0.66 ms imposes a more abrupt signal degradation. For instance, we could measure 4pp higher FLR for an introduced packet jitter of 0.66 ms at 20 Mb/s and 6pp for 50 Mb/s. Finally, the degradation introduced by the PAM4 modulation is relatively low compared to an ordinary Ethernet transmission. The measured packet jitter is 0.5pp and 0.3pp higher with the PAM4 for induced jitters of respectively 0.66 ms and 0.10 ms and bit-rates up to 150 Mb/s.

Summary of the PAM4 section

We experimentally demonstrated the feasibility of transporting the mobile interface configured with a PDCP-RLC split over an Ethernet aggregation network and 20 km optical access network using real-time PAM4 modulation. We have also investigated the impact of different impairments that could come from the aggregation network namely the BER and packet jitter. Using iperf in UDP mode allowed us to test the true capacity of our system. UDP mode doesn't allow for retransmissions so it mirrors with accuracy the packet drops and errors as well as packet jitter phenomena occuring in the network [START_REF]Tuning a UDP connection[END_REF]. We found that in terms of packet loss and packet jitter over the PAM4, the MSB is similar to that of the NRZ in the OB2B scenario. The PAM4 limitations in regards of decoding the LSB is tightly related to the middle eye, as well as the upper and lower eyes (The MSB is only affected by the middle eye) thus configuring the decoder for the LSB is more challenging. Their shape influence the BER of MSB and LSB as reported in the second chapter of [START_REF] Barthomeuf | Real-time Downstream 25 Gbps PAM4 for High Speed TDM-PONs with both 25 and 12[END_REF].

In conclusion, we can see that the introduction of the PAM4 encoding and decoding equipment had minimum impact on the MSB performance. PAM4 in the access network can be an interesting solution to transporting higher bitrates while using the already available COTS optical components.

High Speed PON WDM solution for different functional splits

We investigated in the previous section the possibility of using a different modulation format to increase the throughput of a RAN interface, in this section, we are going to test a 25 Gbit/s/λ wavelength multiplexing prototype based on PON WDM technology.

Introduction and motivation

Efforts are currently being made to improve the capacity of the optical access for fixed clients (mainly FTTH) by implementing 10 Gigabit PON solutions to answer the near future market demands. Efforts are also made to standardize the future evolution of these solutions. Referred to as High Speed PON (HSP-PON) in the ITU standard and currently under work in the project G.sup.HSP (see 2.1.2), the requirements of such technologies are under specification [START_REF] Itu-T | Higher speed passive optical networks -Requirements[END_REF]. There are other standards that have started working on next generation PON systems such as the IEEE 802.3ca for the 25G and 50G Ethernet PON (EPON) based on black and white transceivers. Bidirectional PtP single fiber transceivers have proven to be an ideal and costeffective candidate to transport such bitrates while meeting the latency requirements of different RAN interfaces and services. We propose in this case, to assess a PtP WDM candidate that can be considered to connect the next generation RAN. In addition of having multiple wavelengths to increase the overall capacity of the PtP link while sharing the same fiber resource, the capacity of the link can also be extended by increasing the bit-rate transported in each of its wavelengths.

WDM solutions come mainly in two main configurations. The first one is Coarse Wavelength Division Multiplexing (CWDM), where the wavelengths' channels are widely spaced, allowing the use of low-cost lasers. The second one is DWDM, costing more, but still leaving enough wavelength spectral resources available for future evolution. The DWDM transceivers respect the spectral grids given by the ITU-T [START_REF] Itu-T | Spectral grids for WDM applications: DWDM frequency grid[END_REF] offering a wide range of possible wavelenghts to be used. As a result, a pair of DWDM transceivers that are operating at a fixed wavelength can be cumbersome to set or remove when you have dozens of other DWDM transceivers set on the same PtP link. For the time being, there isn't an OMCI for the PtP WDM PON ONU as it exists for other technologies based on PtMP as Gigabit PON (G-PON)/10 Gigabit Symmetrical PON (XGS-PON) [START_REF]ONU management and control interface (OMCI) specification[END_REF]. But its development could enable ONU wavelength management and enable easier setup of DWDM transceivers. We propose in this section another way of managing the setup of these transceivers, by using an industrial prototype of auto-tunable modules.

Wavelength tunable, manageable and interoperable PtP DWDM system could then meet the RAN high throughput requirements especially when we take into account the possible redistribution of the RAN functionalities in the network and how they can influence the overall bitrate transmitted in the last mile (see 1.2.2). In this section we study a real-time 25 Gbit/s/λ tunable DWDM PON industrial prototype and experimentally assess its capacity at transporting a fronthaul eCPRI interface as well as an emulated F1 Ethernet backhaul interface (full scenario presented in Figure 5.6). The transceivers tunability is performed with an in-frame OLT-ONU communication, which is a first step for a pseudo-OMCI standard that performs wavelength management control. The tested solution is able to provide up to 3 x 25 Gbit/s PtP connectivity and targets macro cell deployments with 3 sectors. Besides physical layer metrics, we also examine layer 2 eCPRI/Ethernet performance indicators of the system such as latency, packet jitter and frame loss and we finally extend this analysis to the IP layer (L3).

Experimental setup

Fig. 5.7 shows our experimental setup. The tested 25Gbit/s/λ DWDM PON PtP OLT is connected to an Arrayed Waveguide Grating (AWG) with an embedded Erbium Doped Fibre Amplifier (EDFA). The cyclic AWG has 100 GHz channel spacing grid with downstream wavelength λ from 1529 to 1544 nm and upstream wavelength λ from 1550 to 1565 nm. It is implemented as a typical card of a commercial OLT chassis. The optical transceivers used to connect the OLT to the tunable ONUs are wavelength managed SFP28 prototypes capable of automatically tuning themselves into one of the available wavelengths of the fibre channel. The tuning operation is initiated by the SFP28 at the OLT side, which informs the SFP28 on the ONU side of the targeted wavelength. The wavelength management information is transmitted using available bytes of the Forward Error Correcting (FEC) header of the interface and the operation is carried automatically when the SFP28s on both ends are plugged to the AWG channels. The wavelength manageable SFP28 devices are composed by a >20GHz bandwidth Mach-Zehnder intensity modulator with embedded Continuous Time Linear Equalizer (CTLE) acting in all SFP28's at both ONU and OLT sides, as well as a 10 GHz APD. At the ONU side, a passive AWG block is used to separate the wavelengths associated to each client after propagation through a SSMF, eCPRI traffic is then created using a 25GbE eCPRI generator connected to both OLT's backhaul card and ONUs by means of commercial black and white 25GbE SFP28 transceivers. The generator is capable of creating L1 streams, eCPRI and standard L2 Ethernet frames as well as L3 IP packets.

Results and discussion

Single Wavelenght Transmission Assessement

The first set of measurements, shown in Figure 5.8, has been conducted by transmitting one single wavelength. We assessed layer 1 BER as well as layers 2 and 3 FLR for different optical budgets and with three fixed transmission lengths, namely OB2B, 10 km and 15 km. For layer 2 measurements, we have tested both eCPRI and conventional Ethernet signals with fixed 512 bytes frames. The output power per wavelength at the central-side (AWG + EDFA) is +6.4 dBm. [START_REF]40-Gigabit-capable passive optical networks 2 (NG-PON2): Physical media dependent (PMD) layer specification[END_REF], while ensuring High Class of Service (CoS) in terms of frame loss compatibility for eCPRI splits E, ID, IID and IU [START_REF]Common Public Radio Interface: Requirements for the eCPRI Transport Network[END_REF]. IP layer assessments (Fig. 5.8 (right)) show similar performances to those of layer 2. Figure 5.9 (right) shows the single wavelength layer 3 performances of the system precisely when submitted to different frame sizes, at 10 km, where negligible degradations are observed when compared to the 512 bytes case. The latency added by the WDM PON system under test was measured at 7.8 µs with a peak packet jitter of 0.06 µs for different frame sizes from 64 bytes to 1512 bytes. The same packet jitter performances were observed with a random frame size configuration. Performances are thus compliant with eCPRI High100/200/500 (100µs, 200µs, 500µs one way latency) latency classes for propagation up to 15 km. This would allow, for instance, approximately 19µs of switching time margin for a High100 class and a 15 km fronthaul link2 [START_REF]Common Public Radio Interface: Requirements for the eCPRI Transport Network[END_REF]. Wavelength stability assessment over a period of 16 hours showed good performances with ±0.1 dB variation of the peak optical power and under 0.01 nm variation of the center wavelength.

Crosstalk evaluation

The last evaluation test consisted in a crosstalk assessment at full ONU capacity, with 3 wavelengths at 25 Gb/s each. We assume a worst-case scenario where the neighboring wavelengths have 4 dB higher powers than the channel under test. The channel under test transmits eCPRI or Ethernet data whereas the neighboring channels are simply modulated with idle frames. Figure 5.9 (left) shows layer 2 frame loss performances with respect to the received optical power at the ONU. It can be seen that the degrading effects of crosstalk are negligible, with the same performances for the channel under test as in the single wavelength case.

Summary of the PON WDM section

We successfully demonstrate the transmission of an eCPRI signal through a 25 Gb/s/λ tunable DWDM PON system up to 15 km of fiber. The wavelength tunability is performed with an in-frame communication between both sides of the link, acting as the first step to a wavelength management standard. This tunability avoids complex wavelength management that we find in commercially available DWDM transceivers involving onsite technician intervention. The transmission evaluation managed to fulfill all the transport requirements of eCPRI (High, Medium and Low) Class of Services in terms of latency and frame loss ratio, while maintaining an ODN compatible with L1 NG-PON2 PtP class. We evaluated, as well, the wavelength crosstalk and we found negligible impact on our transmission. In conclusion, the 25Gb/s/λ tunable DWDM PON might be a very interesting solution to address most of the requirements of the second phase of 5G while conserving a traditional PtP architecture.

Transmission of mobile traffic through an optical PtMP architecture

In the previous sections, we investigated how can we increase the throughput of the RAN, by means of a different optical modulation format as well as wavelength multiplexing using a PON prototype while still maintaining a PtP topology. We studied their impact on the vRAN interface and how they can accommodate future 5G services. In this section, we are going to test a PtMP architecture based on PON technology. While the WDM PON system that we previously tested was a prototype, the PON solution we used for this study is an XGS-PON commercial solution, currently being deployed, providing a symmetrical 10 Gbit/s througput and being standardised under [START_REF]10-Gigabit-capable symmetric passive optical network (XGS-PON) Amendment 1[END_REF].

10Gigabit Symmetrical XGS-PON

The PON technology was originally conceived for residential areas and business use cases. In dense and ultra-dense areas this resource is widely available. Conversely, for the next generation RAN it would be challenging to provide all the needed resources, since eMBB services are one of the key elements for the upcoming 5G, with greedy bandwidth requirements (see 1.1).

To address the limitations in the optical access for the RAN, we propose the scenario shown in Figure 5.10. It consists of offloading part of the mobile traffic onto the already available PON infrastructure. This would allow leveraging the already deployed PON infrastructure to alleviate the throughput in the RAN optical access.

In this section we propose and implement an architecture depicting our proposed scenario. Concretely, we set up a lab experiment testing the performance of transporting the vRAN mobile interface using a commercial XGS-PON equipment. This experiment leverages an OLT and an ONU with two ports, the aim is to assess the behavior of mobile traffic when transported in a PON infrastructure, with a fixed mobile convergence at the level of the ONU equipment.

General overview of our experimental setup

The XGS-PON solution we used is composed of an OLT, an ONU (Figure 5.12), a fixed attenuation emulating a splitter and 10 km of SSMF. We have one port of the ONU to serve the UE and the other to serve our fixed traffic emulation. A T-CONT of type 3 is associated to each ONU port. This type of T-CONT gives us the possibility to configure the available bandwidth through certain configurations necessary to our test procedure. Mainly configuring a part of the bandwidth in assured mode. In this mode, the bandwidth allocated will always be granted to the ONU in the upstream by the DBA. The remainder of the PON bandwidth will be configured in non-assured mode: the bandwidth will be granted to the ONU in the uplink if the resource is available. For more details of how the DBA operates refer to section 2.1.2. The aggregation network (presented in Chapter2), is the network segment between the core network and the access network and is emulated with the Ethernet degradation engine. It allows us to add packet latency and jitter to the incoming mobile interface. The mobile interface is then transported through a 10Gigabit Ethernet switch and mixed with a 10 Gb/s-capable overloading Ethernet signal which emulates fixed clients traffic. The two streams are tagged with different VLAN tags by the switch and then transported together in the same port towards the optical access in the downlink. An equivalent scenario is set up for the uplink but with different ports of the switch associated to the different tags so that the DBA procedures can be individually applied to mobile and overloading traffic in both ports of the ONU.

We configured the two ONU ports with 150 Mbit/s in assured mode and the remainder in non-assured mode. The goal here is to overload the PON link with the Ethernet traffic corresponding to the fixed clients to put it in direct competition with the traffic coming from our mobile infrastructure in the uplink, which is limited at 150 Mbit/s (see 4.3) and assess any potential changes in the mobile link.

Results and discussion

We start the experimental assessment by investigating the impact of eventual degradation coming from the aggregation network in the uplink. Figure 5.13 shows the effect of the induced packet jitter to the downlink mobile interface, with UDP packets 1200 bytes long. The packet jitter values correspond to the standard deviation of a normally distributed latency, with a 2 ms mean value. Three sets of measures are shown, namely, without packet jitter, with 0.1 ms jitter and with 0.66 ms jitter. The 0.66 ms corresponds to the maximum packet jitter value that can be introduced by our impairement engine. We can see that for a transmission without added jitter, the FLR is relatively low from 20 to 100 Mbit/s. After that, we have a steep ascent up to 150 Mbit/s, which is due to the limitations of the virtual mobile solution (see section 4.3). When adding packet jitter, the overall FLR is higher and we observe a steep ascent that begins earlier with respect to the bitrate, with much stronger impact with 0.66 ms. The second set of measurements consisted on investigating the impacts of DBA in the uplink. By assessing the needed response time to provide full assignment of a specific bit-rate to the mobile stream at the level of a layer 4 OSI protocol, namely UDP. UDP packets are transmitted via iperf from the UE to the EPC while the overloading traffic is always set to a maximum useful bit-rate of 8.5 Gb/s. We then measured the time needed for the bitrate in the mobile interface of the CU to be reached, which is shown in Figure 5.14. Two bit-rates are considered, one below the maximum assigned bit-rate (100 Mb/s) and another at the limited assigned capacity (150 Mb/s). Figure 5.14 compares the evolution of the bit-rate in the XGS-PON with an optical Back to Back (B2B) PtP scenario, where the server is looping back directly in itself and thus without TDMA (Figure 5.14 a and b). Figure 5.14 c and d show the upstream bit-rate evolution profile for our XGS-PON system. Comparing the two setups, we can see that the bandwidth is more rapidly allocated in the B2B case compared to the XGS-PON. For 150 Mbit/s, the B2B setup allocates the required bandwidth in 60 ms to the CU, whereas in the XGS-PON setup, a two-fold increase in the system response is observed, with 120 ms. We can also observe that without congestion (100 Mb/s bit-rates), the XGS-PON and point-to-point set-ups behave similarly. Finally, Table 5.1 shows the Round Trip Time (RTT) latencies added by the XGS-PON system over 10 km compared to the PtP B2B uplink transmission scenario. It can be observed that the XGS-PON not only increases the mean latency but also increases the packet jitter by a factor of 3, from 0.047 ms to 0.154 ms. Round Trip Time (ms) B2B PON min 0,405 0,675 average 0,516 0,942 max 0,678 1,556 std deviation 0,047 0,154

Summary of the XGS-PON section

In this section, we assessed the behavior of transporting the mobile interface through a commercial XGS-PON equipment, as an answer for a bandwidth resources issue that will affect the next generation RAN elements following the heavy bandwidth requirements of the 5G. The answer was to offload some of the RAN traffic into PON links which are extensively available in dense urban areas. Firstly, we took a look at how an induced packet jitter affect the performance of the packet transmission in terms of frame loss ratio. Secondly, we assessed the necessary time for the PON to allocate the necessary bandwidth to the mobile interface and its repercussions in milliseconds on the transmission. And thirdly, we evaluated how the insertion of a PON equipment affects the packet jitter as well as latency in the uplink transmission. The added latency in RTT by the PON is of 0.5 ms which can be negligible for the majority of mobile services but can be critical for ultra low latency services. The FLR was not impacted by the introduction of the PON transmission in a scenario where the mobile solution is operating within the optimal transmission interval and with no induced packet jitter. The PON solution reaction to packet jitter was considerable. With 0.66 ms of added packet jitter, the FLR received a steep ascent (up to 6pp higher than the OB2B scenario), so the usage of this PON solution must factor in the effects of packet jitter. In conclusion, the XGS-PON solution reveal to be an interesting solution for accommodating the offload of non time critical mobile traffic.

The scenario that we tested in this section pertains to a possible convergence of fixed and mobile clients at the level of the same ONU equipment, by means of offloading non critical mobile traffic onto a PON link. In section 2.2 we talked about the reality of PON deployment in the terrain. In practice, the antenna site density is considerably lower than a PON network. As a result, using TDM PON technology solely for antenna site deployment might not utilize the full potential of the PON network. However, using PON as a traffic offloading solution might be interesting. The remaining issue would be to dimension the PON network accordingly to allow for the convergence of fixed and mobile clients, a convergence that can go potentially to the level of the same ONU, with two ports, one connected to a fixed client and the other to a small cell antenna servicing mobile clients. In the next section we are going to present a scenario relying on this same XGS-PON technology, this time to enable a 5G vehicular transportation use-case.

A 5G Use case: High-Speed Train Cell-less Network

The main interest of this part of the chapter is is to propose a scenario where an XGS-PON network is used to transport a mobile interface for a vehicular transportation use-case.The following study details the research done to answer this use case for high speed trains, the various experiments and the proofs of concept that have been achieved. Then, we present our proposed solution using XGS-PON and finally a case study of PON deployment is assessed taking into account real life transmission factors.

Context and motivation

In this section we put into place a small proof of concept that consists of implementing a specific use case that can be among 5G objectives. One of these objectives is providing higher bitrates as well as making mobile services available as much as possible in order to have a seamless connectivity wherever we go. Examples of making the mobile network ubiquitous ranges from reaching rural area users with FWA offers, or densifying areas with macro-cell antennas for urban uses cases such as residences, offices or stadiums. With this in mind, one of the areas where the 5G should be made available is vehicular transportation with studies already being conducted by the 3GPP [START_REF] Gpp | NR; Study on NR Vehicle-to-Everything (V2X)", 3rd Generation Partnership Project (3GPP)[END_REF] on Vehicle-to-Everything (V2X) .

As far as rail transportation is concerned, the GSM-R [START_REF] He | High-speed railway communications: From gsm-r to lter[END_REF] standard is available. It relies entirely on circuit switching and can only be used for voice communication and signaling operations for trains and railways. For the coming mobile generation, the requirements for a successor railway communication technology beyond 3GPP's Future Railway Mobile Communication System (FRMCS) are given in TS 22.289 [START_REF] Gpp | Technical Specification Group Services and System Aspects; Mobile Communication System for Railways; Stage 1 (Release 17[END_REF]. In this context, efforts focusing on extending the mobile coverage in rural areas are currently being intensified to improve mobile services in High Speed Train (HST) environments. However, guaranteeing high data rates can be challenging in HST due to the speeds at which users are moving, generally beyond 300 km/h. Indeed, with fast mobility comes great complexity. The management of the mobile handover as well as the propagation limitations imposed by the Doppler frequency shift [START_REF] Sarkar | Wireless cellular network for high speed (up to 500 km/h) vehicles[END_REF] need thus to be taken into consideration. A way to overcome the challenges of high-speed handover has been recently proposed where a mobile "cell-less" configuration is obtained thanks to an optical transmission system. A successful transmission was demonstrated in [START_REF] Dat | High-Speed and Handover-Free Communications for High-Speed Trains Using Switched WDM Fiber-Wireless System[END_REF], [START_REF] Dat | Cell-Less Network for Handover-Free Communications to High-Speed Trains Using a Switched WDM Fiber-Wireless Backhaul[END_REF] using Analog Radio-over-Fiber (A-RoF) and per-antenna wavelength allocation. WDM handover-free operation was enabled by a fast tunable laser with service interruption times in the order of some µs. A more recent work has demonstrated the feasibility of an A-RoF WDM switching via AWG as well as optical switching via TDMA based routers, with a field trial using 90-GHz bands and a train traveling at 240km/h [START_REF] Kanno | High-Speed Railway Communication System Using Linear-Cell-Based Radio-Over-Fiber Network and Its Field Trial in 90-GHz Bands[END_REF].

In this section, we propose an equivalent cell-less network which is enabled, differently, by a commercially available XGS-PON system. Each Trackside Remote Unit (TRU) is connected to an ONU, the latter being connected to the OLT through a classical PtMP topology as shown in Figure 5.15. The PON will actually behave most the time as a PtP system, being only temporarily switched to a 1:2 PtMP transmission during the transitions between an ONU and its neighbor as the HST moves along the rail. First, we experimentally demonstrate the principle of the proposed solution and the switching between two ONUs with an Ethernet interface emulating a RAN functional split interface. Then, we evaluate the impacts of the transmission of the real-time PDCP-RLC vRAN interface as seen in the previous sections. Finally, we address the XGS-PON parameters that would allow transmission at different RF frequencies.

Building blocks of the experimental setup

The experimental setup of the XGS-PON capable of enabling fast switching between ONUs is depicted in Figure 5.16. The blocks in each end represent the emulation of a generic Ethernet based functional split as well as the bi-directional transmission of the virtual mobile platform. This traffic is fed to an XGS-PON OLT connected to two ONUs through an optical coupler. The ONUs are connected to a probe device that allows us to visualize the bit-rate evolution and switching in real time for the PON system. The high speed train transition from one TRU to the other is emulated by a 10GbE switch. The switching method relies on the aging time of its MAC address table which is configured to 20 seconds, meaning that the Address Resolution Protocol (ARP) table is updated each 20 seconds and will take a different route to forward packets to and from the ONUs. Connected simultaneously to both of our ONUs, after 20 seconds, the switch transmits the flow from one ONU to the other, similarly to what would happen on an actual transition of a train from one TRU to the next one. Finally, an Ethernet packet analyzer is used to evaluate the transmission of the generic GbE interfaces. Our DU+RU and the emulated UE are used to complete the downlink transmission for the PDCP-RLC split scenario. The setup also supports upstream traffic with standard TDMA operation. It should be noted that the main advantage of a virtualized CU in our approach is that it could facilitate the implementation of longer reach railways. Indeed, the handover of the mobile backhaul interface between zones covered by different PON trees could be easily implemented by simple transfer of virtual Central Unit (vCU) virtual machines between regional nodes (see Figure 5.15).

Results and discussions

In order to demonstrate the feasibility of the cell-less network with an XGS-PON system, the degradation during the transitions from one ONU TRU to its neighbour should be minimized. To do so, we explicitly disable anti MAC flapping rules (A MAC Flap is caused when a switch receives packets from two different interfaces with the same source MAC address) of the PON during a short period of time in which the two ONUs will be transmitting at the same time in the uplink with the same source MAC address (the address of the UE) towards the OLT. In a real implementation, some sort of white list policy would have to be implemented for groups of three consecutive ONUs (previous/current/next) to allow for localized MAC flapping (see Algorithm 1). The first set of results correspond to the PDCP-RLC real-time mobile transmission. We transmitted a stream of 1200 Bytes UDP packets at a 100 Mbit/s. We assigned to the mobile traffic a DBA profile using a type 2 T-CONT with 150 Mbit/s fixed bandwidth to assure that our system could handle eventual bandwidth bursts higher than 100 Mbit/s without having to discard packets. In Figure 5.17, at the 17:10:28 time mark and at the level of the links between the switch and the ONUs, the switch allows for a transition from ONU 1 to ONU 2. The transition period lasted for three seconds in which the communication wasn't interrupted and the system didn't suffer any additional FLR at the reception of the mobile data. We should note that this time limitation is exclusively due to the railway emulation.

On an actual implementation, switching times could possibly be as small as 125µs, which corresponds to the minimum duty cycle and frame duration on a PON system [START_REF] Itu-T | Gigabit-capable passive optical networks (G-PON): Transmission convergence layer specification[END_REF]. In Figure 5.18 we can see two cycles of the upstream transmission with a higher power burst corresponding to ONU 1. Figure 5.19 shows the results for the generic GbE interface. In Figure 5.19, we can see that at 15:09:16, for both uplink and downlink transmissions, the transition from ONU 1 to ONU 2 is done under less than 1 second. During this time interval, both ONUs are transmitting at the same time. The DBA profile in this case was configured to transmit a maximum bandwidth up to 9 Gbit/s with an assured bandwidth of 1 Gbit/s. We didn't stress F 5.17: ONUs bitrate and FLR evaluations. F 5.18: OLT bursts corresponding to the two ONUs in the uplink.

our system to the limit due to a bandwidth limitation of our probe device, incapable of providing throughput visualization beyond 1 Gbit/s. Figure 5.20 shows the two optical bursts of the ONUs.

Practical considerations for field deployment of the solution

In order to open up the possibilities of such solution, Table 5.2 shows three possible deployment use-cases. For instance, for a 700 MHz carrier, a 1:4 PON compatible with optical budget class N2 could be considered. By setting the distance between adjacent ONUs in the railway to 40 km, we would allow compatibility with the maximum differential distance between ONUs and between an ONU and the OLT [START_REF]10-Gigabit-capable symmetric passive optical network (XGS-PON) Amendment 1[END_REF], while guaranteeing a cell radius below 6.5 km. Those values are obtained from the Friis equation, which depicts transmission in free space [START_REF] Friis | A Note on a Simple Transmission Formula[END_REF]:

P r x (d B ) = P t x +G t x +G r x + 20l og 10 (λ/4πD r )

• P r x = Reception power

• P t x = Transmission power • G t x = Transmission gain • G r x =Reception gain • λ = Radio wavelenght • D r = Propagation distance
This would allow for an uninterrupted communication time of approximately 26 minutes per PON tree considering a speed of 360 km/h. For the 3.5 GHz Carrier frequency which is one of the candidate frequencies for 5G [START_REF] Gsma | 5G Spectrum: GSMA Public Policy Position[END_REF], the Friis model was put into comparison with another model by Okumura that takes into consideration terrain variables (the cyan line in Table 5 For the Okumura model, we considered a transmission in a rural area, since trains typically transit through open terrains. The height of the mast where the TRU will be located is 15 meters long. We should note that the Okumura model is typically valid up to 3 GHz, however it gives us an initial idea for our 3,5 GHz transmission on how the cell radius is affected by real world parameters.

The mobility of the mobile user at high speeds can become problematic for the reception of the radio signal due to the Doppler shift effect which alters the received frequency of a radio wave depending on the position and speed of the radio wave emitter. In table 5.2, we calculated the maximum shift in frequency that can happen at the reception of the mobile user for each carrier frequency. The biggest value we got is estimated at around 9 KHz. This value is relatively low and can be corrected using already available control systems such as Phase Locked Loop (PLL) at the reception as well as many other advanced solutions described in the literature.

Chapter conclusion

In this chapter and through its different sections we studied the transport of the virtual mobile traffic through different optical solutions in the access network, concluding with a proposition of a 5G use case relying on fixed access technology to enable a HST scenario. We managed to explore different architectures summarized in Table 5.3 by investigating outside of the traditional PtP NRZ topology (cyan line in the table). First, we tested the PAM4 optical modulation in a PtP topology using packet switching with L2 Ethernet protocol, then a WDM PON solution transmitting Ethernet as well as eCPRI traffic and finally using XGS-PON, a technology originally used for PtMP topologies in service of fixed clients.

With each new transmission approach, we tried to see the effect on the virtual mobile packet transmission (in terms of latency, packet jitter and FLR) and proposed what type of standardized 5G class of services that can be transported on each one of them. The major takeaway from this chapter is that the access network presents potential as well as challenges for the arrival of 5G. For instance, the challenge of the additional optical budget penalty brought by PAM4 and its potential of doubling the bitrate in the optical fibre. The challenge of managing transmission wavelengths in WDM solutions and its potential of increasing the throughput in the RAN through wavelength multiplexing schemes. The challenge of adapting PON technologies for the mobile use cases (in term of network dimensioning and the definition of the candidate mobile services) and the potential of harnessing the power of broadband technologies originally used for fixed access clients.

Chapter 6

Showcasing two approaches of Software Defined Networking (SDN) in the RAN

In chapter 1 and 2, we discussed how the current access network is still serving conventional services. However, with the advent of the 5G and the proposal of its new services, the requirements for the access network of the future is to be flexible and capable of handling these services. The SDN approach revealed to be interesting for this flexibility. In this chapter, we will be discussing how the abstraction of network parameters in the access network can act as an enabler for this flexibility through two main use cases, the first one is the use of smart SFP+/OLT modules, PON abstraction and the virtual mobile platform connected to a generic server containing an Open vSwitch (OVS) virtual switch. We consider a scenario where the server would host multi-access edge computing (MEC) functionalities. Simultaneous PtP and PtMP connectivities are considered to showcase a fixed mobile convergence scenario and the server interfaces are bound to data plane development kit (DPDK) which enables fast packet processing and forwarding by circumventing the operating system kernel. The second one where we address the concept of multi-tenancy and multi-service by investigating a novel SDN approach in the optical access. A RESTCONF/YANG solution is used for the creation of different slices based on physical layer parameters.

Transmission of mobile traffic on a hybrid PtP/PtMP architecture

After studying the PtP architecture as well as the PtMP architecture in the previous chapter. In this section, we are going to test one of the many possible hybrid PtP/PtMP architectures. Motivated by a scenario of convergence between the fixed and mobile access technologies which we propose as follows:

• Convergence of PtP(Ethernet)/PtMP(PON) architecture at the level of a RAN equipment, to propose an offloading scenario where traffic can be dynamically switched from one topology (for example from PtMP to PtP) depending on the the network usage.

• Proposing as convergence equipment a server acting as a Customer Premises Equipment (CPE), allowing with its geographical proximity to the end user for low latency Mobile Edge Cloud (MEC) applications [START_REF] Etsi | Mobile-Edge Computing (MEC); Service Scenarios[END_REF], such as hosting 5G Core (5GC) user plane [START_REF]Aether: Enterprise-5G/LTE-Edge-Cloud-as-a-Service[END_REF], or enabling RAN functional splits. Chapter 6. Showcasing two approaches of Software Defined Networking (SDN) in the RAN

Motivation behind low latency applications and the concept of Mobile Edge Computing

As it has been shown in section 1.1, URLLC services compose one of the three main pillars in 5G. After addressing how mobile services would be affected by various optical transmission technologies in the PtP and PtMP in the previous chapter. In this section of this chapter, we propose an access network architecture that will enable the implementation of Mobile Edge Computing (MEC) functionalities closer to the end user as well as mobile services, either by relocating 5G core elements closer to the end user to enable strict latency applications, or setting up a CU to enable a functional split.

Building blocks for the MEC server

The set up of our MEC server is composed of three main elements:

• A software tool (DPDK) that will allow us to fast process packets transiting through the server by reducing the processing overhead of the OS.

• A virtual switch inside the server to connect the various Data Plane Development Kit (DPDK) enabled ports.

• A mini OLT mounted on an SFP+ module to enable the PtMP topology.

In the following sections, we will explain how these elements work and how they interact with each other to allow for the proposed convergence scenario.

DPDK

Linux distribution based machines have a certain way of dealing with incoming packets from the network and onto their NIC. First upon reception, the packet is sent to the RX (reception) queue. After that, the packet is copied to the system's memory in a special buffer called "sk_buffer" and an interrupt is raised from the NIC onto the CPU notifying the kernel to transmit the packet into the user space so that they can be processed by the user application. The user application executes a system call "syscall()" which is how a program enters the kernel space to perform a variety of operations. For more details on system calls, please refer to the Linux manual page [122]. In this case the message "RECVFROM" will be sent to receive the packet from the sk_buffer and onto the user space. This, in addition to other multiple mechanisms relative to the indexation of "sk_buffer" memory addresses and how the NIC Direct Memory Access (DMA) engine operates to send and receive from the "sk_buffer" as explained in [START_REF] Sosnowski | How can DPDK access devices from user space?[END_REF], can consume a lot of CPU cycles. For instance, a user application sending UDP packets trough the kernel space will use the syscall() SENDTO and the ensuing operations invoked are shown in Figure 6.1 and Table 6.1.

In order to have a network interface working at 10 Gbit/s in a Linux system, it should be capable to handle every Ethernet packet size possible at that bitrate. The most challenging case would be to only process the smallest Ethernet packets possible with a size of 64 bytes, meaning that the Linux system will have to increase its processing overhead to accommodate every small packet sent and received. The 10 GbE interface will have to receive 14.8 million packets per second while taking into consideration the Ethernet Inter Frame Gap (IFG) and its preamble, giving each packet a processing time of approximately 67.2 ns. To put these values into perspective, with a 2.4 GHz CPU, each packet should be processed in less than 93 CPU cycles. Therefore, if we can manage to reduce the kernel's processing overhead (system calls and the potential context switching, number of interrupts, copying operations of packet data from the kernel to the user space instead of receiving directly from the NIC TX/RX queues), it will allow us to have more relaxed transmission constraints. In this context, the DPDK module helps to mitigate the effects Chapter 6. Showcasing two approaches of Software Defined Networking (SDN) in the RAN of going through the Linux kernel by having all its modules and necessary libraries for packet processing in the user space. Figure 6.2 depicts the user space interaction with the NICs through the Peripheral Component Interconnect (PCI) with and without DPDK. First of all with DPDK, the communication between the NIC and the kernel space is limited. To allow a network interface to use DPDK, first we must unbind it from its default kernel driver (for example driver e1000 for the 8254x NIC family) and bind the interface into a compatible DPDK User space Input/Output (UIO) driver, for instance "uio_pci_generic" . The binding of the NIC to this driver gives the user space a direct access to the NIC to communicate with it and thus circumventing the kernel space and its subsequent system calls. In addition to that, DPDK comes with a Poll Mode Driver (PMD) that configures TX/RX queues in the NIC. One particular advantage given by PMD is that it checks the RX queue for incoming packets continuously, therefore no interrupt is raised to the CPU. PMD also allows sending and receiving packets in batch and transmit them immediately to their corresponding destination with minimum time overhead.

The use of DPDK module has been tested in various works, such as a enhancing 5G multimedia communications in a virtualised media gateway [START_REF] Chen | Performance Enhancement of Virtualized Media Gateway with DPDK for 5G Multimedia Communications[END_REF] and as a high performance software router [START_REF] Li | Hpsrouter: A high performance software router based on dpdk[END_REF].

Open vSwitch

Open vSwitch (OVS) is a virtual switch that can give advanced L2 switching capabilities to virtual machines inside servers. It's lightweight and easily deployed and comes with a set of APIs enabling its configuration just as much as a physical switch. Its northbound interface supports the communication protocol openflow and its southbound interface can communicate with DPDK enabled interfaces. Our goal is to create a virtual switch using OVS and connect it to our DPDK enabled interfaces. Doing so will enable us to add intelligence and configurability to these interfaces while benefiting from the fast forwarding that DPDK enables. For example, the merging of these two technologies been implemented as a solution to optimize the slicing of a VNF PON system presented in [START_REF] Slyne | Experimental demonstration of DPDK optimised vnf implementation of virtual dba in a multi-tenant pon[END_REF]. To contrast it with our motivation, the merging of these two solutions in our setup comes to provide an easily configurable server node enabling us to switch from one transport topology to another while ensuring a suitable environment for potential VNF to be implemented.

Miniaturised OLT port and PON control plane abstraction

The concept of a mini OLT comes to add more flexibility to the deployment of future access network equipment. The concept is to have all functionalities of a single port OLT held inside an SFP whereas in conventional scenarios, several ports are implemented in line cards plugged into an OLT chassis (Figure 6.3). The mini OLT is capable of being plugged into a generic hardware for example, a switch or a server (Figure 6.4). By doing so, we can have convergence of different link Chapter 6. Showcasing two approaches of Software Defined Networking (SDN) in the RAN types (PtP with PtMP) in the same equipment with the capability of serving different types of services. The component we chose to use in our experimental setup is an XGS-PON mounted on an SFP+ port.

Real-time Assessment of PtP/PtmP Fixed Access Serving RAN with MEC Capabilities

In our experimental bench we propose a setup that would be a potential host for strict latency 5G applications, MEC services, as well as a convergence equipment for both PtP and PtMP topologies.

As stated in 1.2.1, RAN is mostly deployed following a D-RAN approach, where the mobile processing functionalities are all located at the antenna site (Figure 6.5).

In order to partly centralize some RAN functions without stressing the underlying optical network in terms of bit-rate or latency (see 1.2.1), some of the higher layer functions of the RAN (CU block) can also be virtualized and placed inside generic servers at the central office site, giving birth to the new vRAN topology (see 1.2.2).

Adopting this new RAN topology gives us the opportunity to use generic servers in order to enable MEC applications co-hosting with mobile functions at the same physical equipment. MEC introduces new service scenarios such as connected vehicles or video stream analysis. Those are discussed in particular within the Industry Specification Group (ISG) of the ETSI on MEC [START_REF] Etsi | Mobile-Edge Computing (MEC); Service Scenarios[END_REF]. MEC services require that computing resources are located close to the user. This setup will also be beneficial for the implementation of strict latency 5G applications. By having computing resources as close as possible to the end user, we can consider a complete move of 5G core components into the access network. This will not only benefit us in term of latency but also in term of reliability of these services by reducing the time of their un-availability [START_REF] Philippe | The place of optical access to meet the challenges of 5G latency and reliability, OFC20 Workshop , Converged 5G and Heterogeneous Services Access Networks: How to Achieve Ultra-low Latency and High Reliability?[END_REF].

In this section we propose an architecture where a server simultaneously hosts MEC applications and an aggregation equipment for both fixed and mobile architectures, as shown in Figure 6.5(c). We propose to use intelligent 10Gb/s SFP+ devices to support all the functions of an OLT (see 6.1.2.3). As a result, generic server ports can be adapted to support PtMP usages. This is done thanks to an abstraction of the PON control layer and proper forwarding of the OMCI in what is currently referred to as part of the virtual OLT (vOLT) trend [START_REF] Simon | Ftth and optical lan synergy enabled by virtual olt for home, office and campus[END_REF]. This solution is particularly interesting in the sense that scalability can be obtained in a pay-as-you-grow fashion by simply adding new OLT PON ports, i.e. new SFP+/OLTs, to a generic switch (or server) port. Potential enabling coexistence between PtP and PtMP topologies.

In our proposed solution, the server and the IT infrastructure are shared to host MEC and the vCU, while supporting SFP-OLT interfaces. Each port of the server supports a specific topology, for example one port connects the PtP link dedicated to the mobile antenna macro site, another one connects a PON PtMP linking multiple small cell antennas. The multiplexing of the PON link used by small cell antennas with the PtP Ethernet macro cell antenna link in the same equipment, will allow the offloading of traffic from one link to the other depending on current link occupation and service requirements. For instance when the load supported by a small cell is low, we can offload its traffic through the macro cell antenna link and put the small cell in sleep mode in order to save energy. Or inversely, when the macro site antenna link is overloaded, we can offload part of it onto the set of small cells. As offloading may increase latency since it is transmitted through a PtMP link in the proposed scenario, only services that present non-stringent latency requirements are suitable for a PtMP offloading. These are for example identified by the Metro Ethernet Forum (MEF) that defines CoSs for Ethernet applications. For example, the "medium" CoS relating to streaming media is a good candidate to be offloaded [START_REF] Mef | Transport Services for Mobile Networks[END_REF]. Through our experimentation, we are going to validate which CoS can be offloaded.

Experimental setup

In order to assess how offloading can be performed on our proposed solution, an experimental setup has been designed and is illustrated in Fig. 6.6. Our experiments rely on four main parts: traffic emulation, vRAN implementation, multiplexing scheme, and optical transmission links.

Traffic Emulation and vRAN implementation

We have experimented with two different types of emulated Ethernet traffic represented by the green components from Fig 6 .6. The first type is the overloading traffic to emulate a PtMP load coming from multiple small cells. The second one is to emulate a PtP macro-cell antenna traffic, both produced by the Ethernet traffic generator. The vRAN interface role in this setup is to be used as the offloaded traffic from one topology to the other, while assessing the effect the offload may have on it. Aggregation DPDK Server The central block in Fig. 6.6 represents the server we used. It is a general purpose workstation that runs Linux and whose 10GbE SFP+ network interfaces have been bound to DPDK. DPDK as described in 6.1.2.1, enables fast packet processing and forwarding between the four ports of the machine, by circumventing the Linux kernel to avoid overhead of interrupt management and other kernel related mechanisms. Then, to link the ports together and being able to specify switching rules we created a virtual bridge using OVS (described in 6.1.2.2). It has allowed us to switch the traffic as well as to control the maximum outgoing bitrate from each port of the server.

Optical Transmission Links

The PtMP is implemented using the smart XGS-PON SFP+ with the OMCI control plane deported and located in a machine connected to our DPDK server. The optical PtMP link serves two ONUs. The PtP link is an optical link served by a COTS 10G SFP+. Both the PtP link and the branch serving the mobile platform server in the PtMP link are aggregated through a 10G switch that enabled us to emulate the handover from a macro site to a small cell and offload the vRAN traffic from one link to the other. The offload of the traffic is done using VLAN tags, so each type of traffic is tagged differently making it possible to differentiate them in the switch as well as the DPDK server. To assess this offloading, we put a probe measuring the bitrate in both of the links in the (A) and (B) positions.

Results and discussions

For the experiment, we have created an uplink transmission by generating UDP traffic at 100 Mbit/s going from the UE to our virtual EPC (vEPC). This traffic is the one representing the user's data that initially will be served by the PtP link then that will be switched to the PtMP link and inversely. The traffic emulation for the macrosite as well as the other small cells is set at 7,88 Gbit/s each in both the uplink and downlink directions.

First, we are going to take a look at the backhaul offloading that occurs when the vRAN uplink traffic is initially transported on the PtP link, with a bitrate of 100 Mbit/s along with the traffic coming from the macrosite, totalling up to 7,98 Gbit/s. At a certain time mark "TM1", we shift the small cell load from the PtP link to the PtMP PON by instructing the OVS bridge to allow the VLAN tagged small cell traffic to go through the server port serving the PtMP link. Now, the PtP link is having a traffic of 7,88 Gbit/s and the PtMP link a traffic of 100 Mbit/s. At a second time mark "TM2" we offload the traffic going through the PtMP link back to the PtP link. Fig. 6.7 (a), shows the variation of bitrate inside the PtP link, Fig. 6.7 (b) the variation inside the PtMP link, and Fig. 6.8 the FLR at the reception of the vEPC.

We should note here that the FLR is stable in both PtP and PtMP at less than 2,5%. At the moment of switching the traffic from one link to the other, a big surge in FLR occurs at around 50%, this could be due to the limitation in our 10G switch that plays the role of a handover emulator or a limitation in the DPDK server which blocks the traffic at the moment of the offloading. Moreover, the nature of the UDP traffic doesn't allow for re-transmissions, so momentarily when we go from one link to the other, the packets are lost. In a real-life scenario where the offloading will occur using handover, there are mechanisms in place to ensure the reliability of the communication such as Hybrid Automatic Repeat reQuest (HARQ) [START_REF] Ryu | LTE Basic Procedure: HARQ Entity/Process[END_REF].

Afterwards we did a latency assessment for both the PtP and the PtMP link. Fig. 6.9 shows the packet jitter and RTT latency differences between the two links. The fiber length of the transmission is less than 1 km for both PtP and PtMP. The results are valid without loss of generality for up to 10km, since our COTS SFPs are capable of transmitting over this distance. In average, the RTT of the PtP is µ = 2,22 ms and has a packet jitter value of σ = 0,11 ms. For the PtMP the values were respectively µ = 3,21 ms for RTT and σ = 0,29 ms for packet jitter. We should also mention that we only had two ONUs in our PtMP link, the packet jitter value could increase if we add more ONUs to our link. F 6.9: Variation of RTT and packet jitter at the reception in the vEPC.

Summary of the section

We proposed in this section a scenario of convergence between a PtP link and a PtMP PON link. The convergence of the two links comes at the level of a server that enables the PtP link through 10GbE SFP interfaces and the PtMP link through a mini Chapter 6. Showcasing two approaches of Software Defined Networking (SDN) in the RAN OLT from one side and two ONUs in the other. The server is running a fast packet processing software to show the potential of hosting MEC applications as well as potential 5G core elements which use cases requires hardware resources closer to the end user. We demonstrated the transmission and the offloading of the real time PDCP-RLC functional split traffic from the PtP to the PtMP and inversely, giving performance results indicating the feasibility of this transmission for the mobile services with relaxed latency constraints. However for time sensitive 5G URLLC applications where the allowed round trip latency should be less than 1 ms, the offload will not be applicable since the PtMP link enabled by the XGS-PON SFP+ OLT adds 1 ms in the round trip time as shown in Table 6.2. Examples of such applications are defined for instance by the MEF in [START_REF] Mef | Transport Services for Mobile Networks[END_REF] where the transport latency requirements in the backhaul have been defined through four distinct CoS. For the mobile PtP backhaul services with "tight radio coordination constrained (PT0.3)", the "very high" as well as the "high" CoS would be unlikely to be transmitted as they require a mean one way latency of less than 0.7 ms. An example of these services would be synchronization and network signaling. More 5G URLLC applications that may or may not be compatible with the PtMP topology are detailed in the ETSI standard, with more use cases related to industries in [START_REF] Etsi | 5G;Service requirements for next generation new services and markets[END_REF]

Controller for physical parameters to enable a Fi-Wi link

In this section we showcase an SDN controller that can be enabled by the abstraction of physical equipment in the access network. This will allow us to create network slices supporting multi-tenancy/multiple CoS in a fiber/wireless access network.

Service description

Fiber connectivity in the access network isn't always available. In the state of the art chapters, we assumed fiber as the main medium serving fixed and mobile clients through the optical access network. We also presented the FWA as one of the enablers of 5G, providing FTTH-like service to rural clients and, generally speaking, regions with no fiber deployment.

In the spirit of flexibility that will come with the 5G, a flexible access network relying on both the concept of the traditional optical access (a fiber segment) as well as the FWA (a wireless segment) is not far fetched. This flexible, hybrid access network has been proposed and is called Fiber-Wireless (Fi-Wi). Fi-Wi is composed of a fiber segment linked to a wireless one, serving as an extension of this fiber in regions where the last mile area isn't suitable for fiber deployment for economical or geographical reasons. The European project 5G PHOS [START_REF]5G-PHOS Home page[END_REF] was created to tackle this issue through the creation of a testbed that utilizes a Fi-Wi link. Through this 6.2. Controller for physical parameters to enable a Fi-Wi link 97 project we had the opportunity to work on the abstraction of the physical parameters aspect of it.

We propose a scenario where this last mile connectivity is proposed to clients (telcos operators) on top of which they can in turn, provide their services to their own clients. This service will be granted through a service manager that will be available on top of multiple layers of abstraction with an end goal of having an intent based interface defined as "an abstract, high-level policy used to operate a network" according to the Internet Research Task Force (IRTF) [START_REF] Irtf | Autonomic Networking: Definitions and Design Goals[END_REF].

Figure 6.10 shows the proposed Fi-Wi architecture. On the left and right side of the figure we show different access network scenarios with different split configurations that can coexist on the same Fi-Wi link. The main idea is that in the different access network configurations we can utilise this Fi-Wi link. At the beginning of this link, an A-RoF signal is generated to be then transmitted through a wireless segment and back to a fiber segment for reception.

In our scenario, the Fi-Wi link can present a transparent connectivity for the packet based segments and also through control of its physical transmission parameters, be able to create classes of service.

The scope of our work and therefore the experimental setup consists of the bricks in green, namely the master flexbox and the slave flexbox. The role of these blocks is the generation and analysis of an OFDM signal containing all the elements of an LTE data signal. On top of these blocks we implemented our abstraction model that allowed us to have an intent base interface. The mmWave segment implementation is out of the scope of this work with further details in [START_REF] Ruggeri | Multi-User V-Band Uplink Using a Massive MIMO Antenna and a Fiber-Wireless IFoF Fronthaul for 5G mmWave Small-Cells[END_REF].

The experimental setup

Overview of our abstraction layers

.12 represents the different abstraction layers of our software stack. These layers can be seen as three major blocks. From the bottom up, the first one defines the SDN controller. The second one the service manager responsible for creating the connectivity services and the third one is an the intent based interface to seamlessly manage the network, create or optimize the deployment of services. We are going to describe the abstraction layers of these three blocks from the bottom up:

• The first brick is the SCPI functions: SCPI commands follow a a standardized format to communicate with lab devices. Each equipment has its own set of commands.

• The YANG model: used to abstract our lab equipment. Figure 6.13 shows the YANG model that we created to abstract our equipment. A YANG model contains "leafs" that represent the parameters of the equipment (more details on the YANG models can be checked in this RFC [START_REF] Ietf | YANG -A Data Modeling Language for the Network Configuration Protocol (NETCONF)[END_REF]). In this figure we can see the various leafs representing the physical parameters that we managed to represent in the model, namely the identity of the equipment itself under the "equipment-type" leaf. This leaf can either be the master or the slave F 6.12: The different abstraction layers of our software stack.

flexbox. The YANG model is used to abstract equipment into configuration as well as state data. Example of leafs that are configurable are the carrier frequency "ifreq" and its power "rf power". An example of a state leaf is the "evm_PDSCH_max" which is used to get the Error Vector Magnitude (EVM) value of the received mobile traffic at the level of the slave flexbox. A YANG/SCPI adapter was put in place between the YANG module and the SCPI functions in order to translate the abstract model into commands understandable by the equipment. • The REST API and REST client: defines the interaction between our SDN controller and the service aspect of our abstraction model. The REST API brick creates the REST server that communicates through the RESTCONF protocol with the REST client through its operations: POST to create the equipment with its parameters, GET to fetch values from the equipment, PUT to change the value of the equipment's parameters and DELETE to delete the equipment. [START_REF] Liew | Understanding And Using REST APIs[END_REF] gives more details on the REST API. • The web frontend: a graphical interface (Figure 6.14) to illustrate the intent based principle. Through this interface, the network manager can deploy the service. The interface hides the technical details of how the service is deployed and only shows high level information. F 6.14: The intent based interface of our service.

Creating service slices based on physical parameters

In order to create our CoS, a classification of the physical parameters is to be made. Figure 6.15 shows EVM (%) measurement over all subcarriers at the reception after propagation through 1km SSMF. The transmission was performed by varying the carrier frequency and the input power at the photodiode. After mapping out the different EVM regions, we had a detailed cartography that we can use to position our OFDM transmission on the best conditions. Our engineering rules were set to reserve the best frequency of 2.06 GHz to the high quality slice and the second best of 1.95 GHz to the best effort one. Our two generators are capable of creating multiple LTE bands, with different bandwidths and amplitudes. We set the first generator with one LTE band with a bandwidth of 10MHz and a power density of 0.2 mW/MHz. The second generator was set with 5 LTE bands component carriers with each one a bandwidth of 20MHz and a power density of 0.9 mW/MHz. The power density difference between the two slices is put to give one slice more importance in terms of energy at the level of the signal modulating the laser.

With the creation of these different physical parameters values and through the abstraction layers of our software stack we created the two CoSs with Through the abstraction of these parameters we managed through a simple interface to select a slice, create it or destroy it (Figure 6.14). As a result of that, we managed to create one instance of each CoS. Figure 6.16 represents the spectrum received at the level of the analyser. On the right, the 5 LTE component carriers of the high quality CoS, in the middle, the single band of the best effort CoS and in the left the spectrum of the control channel. Figure 6.17 shows the received constellations with the 64 QAM destined to the high quality and the 16 QAM for the best effort, with all EVM values below 3.2%. These EVM measurements are below the required values for 64 and 16 QAM which are 12.5% and 8% respectively.

Summary of the section

The present work comes to showcase a practical use case of network elements abstraction in service of slicing to create multi-tenancy and multi-service. We showed the abstraction of physical transmission parameters of OFDM generators and analysers and we used them to create slices that can be deployed seamlessly through Chapter 6. Showcasing two approaches of Software Defined Networking (SDN) in the RAN an intent based interface. This work showcases and demonstrates an important aspect of network elements abstraction and the use of an SDN controller for physical access network elements, demonstrating the feasibility of such process in network elements other than the conventional ones such as switches and routers. F 6.17: The QAM constellations for each class of service.

Chapter conclusion

In this chapter, we have shown two examples of how SDN applied to the access network can provide abstraction to the underlying physical infrastructure. The first example to showcase a fixed mobile convergence enabled by the abstraction of the PON control plane and the usage of virtual switches and the second one to showcase a scenario of multi-service and multi-tenancy based on the creation of network slices. These slices are based on the abstraction of physical layer parameters of a mobile transmission.

Conclusion

The research work conducted throughout this thesis focused on the access network and the various challenges that it faces to accommodate the arrival of the new 5G technology. This new mobile generation is technologically disruptive and promises new services with a wide range of needs in terms of bit-rate, strict in latency or requiring a high number of simultaneously connected devices.

We have seen that the optical access network can accommodate multiple technologies and that it has historically evolved with fixed and mobile connectivity topologies taking separate ways. Nameley, with the former majoritarily based on PtMP topologies and highly interoperable standardized PON systems and the latter counting more on PtP links with commodity network equipment such as switches and routers.

The first chapter detailed the context of the thesis, starting by a definition of the 5G ecosystem through the various technologies, services and concepts that will be used in it. For instance, in terms of new technologies, 5G ventures into the millimeter wave spectrum and the usage of massive MIMO to conduct beam forming/steering operations. In terms of services, 5G promises a bandwidth 10 times that of the 4G and promises low latency for critical applications and higher density of connection for a massive number of communicating machines. The 5G will also bring new concepts in the mobile network, such as the mobile edge cloud, the support of multiple access technologies, end to end slicing and the usage of virtualisation through the concept of SDN and NFV as well as the redistribution of the RAN machine functionalities in the access network in what's known as functional splits. These concepts have been defined as enablers of new use cases for the 5G, for instance the NFV granting flexibility of deployment and the SDN as the key support for slicing to achieve multi-tenancy and the creation of classes of services. We ended the chapter by presenting the main virtualisation initiatives in the RAN with a main goal of having flexible deployment of the RAN that can benefit from open interfaces .

The second chapter presented the underlying optical access network that is used to transport various fiber connections to the end user, FTTA and FTTH for mobile and fixed clients respectively. The aim of this chapter was to present the physical infrastructure in which 5G will be transported to explain how some of the 5G concepts such as functional splits come into fruition in this infrastructure and how the providing of the promised 5G high bandwidth will heavily affect the optical access network. In this chapter we presented the main virtualisation initiatives in the fixed access, with such initiatives focusing mainly on the virtualization of PON functionalities in term of VNF and the classical multi-service/multi-tenancy for SDN.

The third chapter tried to reconcile the fixed and mobile worlds by presenting a state of the art of the research works aiming at evolving the access network. We focused on research work that used virtualisation technologies as enablers for various fixed and mobile scenarios in the access network including their eventual convergence. This third chapter served as the reference in which we have put into perspective this thesis work and position it in the scope of the state of the art. The third chapter concludes the first part of the manuscript presenting the context of this thesis and the state of the art surrounding it.

The second part presents the transport assessment of our implementation of an industrial mobile solution in the access network. This solutions sits on top of a virtual infrastructure managed by a virtual infrastructure manager putting the NFV concept in the mobile world into the test:

Chapter 4 focused on describing the virtual infrastructure as well as position its various elements through the ETSI NFV framework. We then evaluated the mobile solution consisting of the LTE mobile core (EPC) and the RAN in a PDCP-RLC functional split composition. The evaluation was performed with respect to the overall performance of the different VNF blocks and how the virtual resources in terms of RAM and number of CPUs affected the performance of the solution, measured through frame loss rate, latency and packet jitter. This allowed us to choose the optimal working point for it in order to asses the optical solutions presented in chapter 5.

Chapter 5 focused on the assessment of the transport of the virtual mobile platform traffic as well as other mobile split options through multiple optical transmission solutions. In order to answer the questions of how a virtualised platform reacts to the underlying physical transport, in this assessment we managed to test various setups:

• The classical NRZ point to point: this setup served as the reference of the other setups since it's the traditional approach to haul mobile interfaces.

• PAM4 point to point: building on a prototype that was a research subject that took place at the same time as this thesis [START_REF] Barthomeuf | Real-time Downstream 25 Gbps PAM4 for High Speed TDM-PONs with both 25 and 12[END_REF]. We managed to transport the mobile traffic on a solution such that for the same baud rate as an NRZ solution, we doubled the bitrate by coding bits on four levels of amplitude.

• WDM PON point to point: a prototype going up to 25Gbit/s/λ was tested, showcasing the flexibility that can be attained in the access network of the future through the convergence of different interfaces (Ethernet and eCPRI) at the level of the access equipment (OLT) enabled by automatic wavelength tunability and pushing the bit-rate allowed in the access by means of wavelength multiplexing.

• XGS-PON point to multi-point: using a fixed access solution to transport a mobile signal, this mobile signal was transported in the same PON tree beside a fixed signal to assess the effects of the latter in a scenario where there is a convergence between fixed and mobile clients on the same fiber medium.

• Presenting a specific 5G use case that sparked our interest which is a high speed mobile communication scenario for 5G. We used XGS-PON technology to show a proof of concept of this transmission backed up by theoretical considerations for a field deployment.

The assessment of these optical transmission solutions allowed us to draw conclusions on the feasibility of the transport of mobile interfaces on these setups and more importantly, define the 5G class of services that can be transported by each of them.

The last part of the manuscript (Chapter 6) presented two examples of the abstraction of network parameters in the access network. The first one, to enable fixed mobile convergence using a commodity server that features a PtMP link enabled by a miniature OLT with an abstracted control plane and a PtP link enabled by an classical SFP. The server can serve as a potential host for mobile edge cloud applications. The second one we used this abstraction to create network slices that can be deployed seamlessly through an intent based interface. This example comes to serve a specific use case which is to provide different classes of services to different tenants, in this case, mobile operators, to be able to deploy their services in an access network that contains a fiber and a wireless segment.

Throughout this work we tried to answer an important question concerning the defining aspects of a fixed/mobile convergence. We demonstrated that latency is added in the uplink of a PON TDM PtMP architecture. Knowing that, the PON solutions cannot answer all possible 5G verticals in their current state. For instance it would be challenging for the solutions to be compatible with LLS architectures which are known for their strict latency or with 5G URLLC services. For HLS architectures, this solution will be feasible, but to what extent ? and at what level the fixed mobile convergence will be interesting ?

If we decide to share the same PON tree with fixed and mobile clients, one challenge would be to put in place sharing policies that take into consideration fixed (FTTH) and mobile clients needs.

Another alternative is to use a PON TDM infrastructure (or tree) solely for the HLS interface mobile traffic. The main challenge is that the current deployed PON technologies, mainly the XGS-PON, offer at best a 10Gbit/s throughput both in uplink and downlink. While this capacity may not be enough for a 5G phase 2 macro cell antenna, it can still be considered for small cell deployments.

PON TDM systems can offer a high density of connections, generally a ratio OLT port/clients of 1:64 and a deployment density dictated by a maximum differential distance of 40km between an OLT and an ONU (further details in [START_REF]10-Gigabit-capable symmetric passive optical network (XGS-PON) Amendment 1[END_REF]). This density was further shown in a real life PON deployment example given in section 2.2. However, small cell antenna density is much lower, so using PON technology would be difficult to justify given the mismatch between fixed and mobile deployment strategies.

Currently, the most realistic approach regarding fixed/mobile convergence would be to consider offloading scenarios where non priority mobile traffic is offloaded into a PON system. Finally, it is important again to stress the actual work and effort that is going into making a true converged fixed/mobile access network, either through research work around notions such as virtual DBA and CO-DBA or developing PON technologies such as the 25Gbit/s/λ WDM solution.

For the first time, the existence of a mobile generation will be in tandem with the deployment of high bandwidth FTTH solutions and one of the challenges for future mobile and fixed technologies generations would be to mutually benefit from each other.

Future work and perspectives

In this work we focused the study on the fixed and mobile access technologies' data plane. An evolution of our work would be to study in depth the control plane of these technologies and their impact on the data transmission. It will be interesting to consider scenarios where the control interface is heavily solicited and to come up with novel ways to transport those interfaces. This evolution can be further extended into studying the various synchronization mechanisms that keep the overall network especially the access network tightly coordinated.

This thesis tackled the access network ecosystem through the paradigm of virtualisation. This technology has existed long enough in other branches of the IT industry and was generally associated with high level notions of service. The democratization of this process and its permeation in the access network through various international initiatives will bring flexibility in the deployment of access functions. These same initiatives are calling for the openness of RAN interfaces prompting some security concerns in their implementation pointed out by industrials such as in [START_REF] Boswell | Making sure that Open RAN doesn't open the door for new risks in 5G[END_REF]. As a result, will the openness of mobile interfaces come at the expense of the security of the network?

The next generation of the access network will have to adapt to the different deployment options of 5G. Some of these deployment options are evolution of others but at a certain time, different deployment options will have to exist simultaneously, so how this plurality of interfaces will affect the performance of the mobile network?

The evolution of the access network of the future can reveal to be at times going in different technological directions. Be that as it may, one direction remains important, which is the study of the convergence of fixed and mobile infrastructures in order to leverage their diversity as their strength. We had the chance to witness firsthand the research initiatives surrounding 5G over time and had the opportunity to study it under our own light while witnessing its evolution. It has been a pleasure being a small part of this ecosystem and being able to look closely to the shift in trends through which we can see the innate desire for the 5G to push the boundaries of technology. From assuring the bare minimum needed in term of services, to dare conceiving a groundbreaking future. changed the characteristics of each VM separately while the remaining VMs were configured at a 1RAM and 1vCPU. The reason behind this is to assess the impact of each single VNF on the transmission, still, there was no correlation between the virtual resources allocated to the VNFs and their performance.

A.3 The underlying structure of the virtual mobile platform

1 . 1

 11 Timeline of 5G standardization. . . . . . . . . . . . . . . . . . . . . . . . . 1.2 5G services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 5G numerology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Numerology use cases in function of cell size, carrier frequency and latency [6]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 Dynamic spectrum sharing between 5G and 4G. . . . . . . . . . . . . . . 1.6 5G flexible resouce grid [8]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7 All 5G deployement options. . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8 Distributed RAN architecture. . . . . . . . . . . . . . . . . . . . . . . . . . 1.9 Centralised RAN architecture. . . . . . . . . . . . . . . . . . . . . . . . . . 1.10 CPRI quantization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.11 CU-DU-RU Architecture [17]. . . . . . . . . . . . . . . . . . . . . . . . . . 1.12 Detailed functional splits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.13 O-RAN Alliance proposed architecture for the vRAN. . . . . . . . . . . .

F 1 . 1 :

 11 Timeline of 5G standardization.

F 1 . 2 :

 12 5G services.

T 1 . 2 :

 12 Frequency Range designation for the 5G. FR designation Frequency range value FR1 410 MHz -7125 MHz FR2 24250 MHz -52600 MHz

F 1 . 3 :T 1 . 3 :F 1 . 4 :

 131314 5G numerology. the numerology better suited for certain radio configurations (cell size, latency, frequency) (Figure 1.4). It also comes to accommodate the aforementioned 5G services with each service demanding a special set of resources (latency, bandwidth, number of connections). Through the adoption of the numerology to each service by means of resources scheduling, the three services can coexist in the air interface (Figure 1.6). Numerology values and their corresponding parameters. Numerology Subcarrier spacing # slots per subframe Slot lenght 0 Numerology use cases in function of cell size, carrier frequency and latency [6].

F 1 . 5 :

 15 Dynamic spectrum sharing between 5G and 4G.

F 1 . 6 :

 16 5G flexible resouce grid[START_REF]Making 5G NR a reality[END_REF].

F 1 . 7 :

 17 All 5G deployement options.

F 1 . 8 :

 18 Distributed RAN architecture.

F 1 . 10 :

 110 CPRI quantization.

F 1 .

 1 11: CU-DU-RU Architecture[START_REF] Luiz | High-speed Optical Access Networks for Mobile "Fronthaul" Architectures[END_REF].

F 1 . 12 :

 112 Detailed functional splits.

1. 3 .

 3 Virtualisation in the RAN and the concept of SDN and NFV 21 (UP) in what we call Software Defined RAN (SD-RAN). The O-RAN alliance as well as the 3GPP have defined the open standardized CP interfaces for the RAN that are depicted in Figure 1.13.

F 1 .

 1 13: O-RAN Alliance proposed architecture for the vRAN.

F 2 . 1 :

 21 Overview of the telecom network.

F 2 . 2 :

 22 Main use cases of fiber To The X.

F 2 . 3 :

 23 Overview of a PON transmission in a point to multipoint architecture. daily bandwidth usage as well as the nature of traffic (Internet, VoIP ...), thus creating a dynamicity in the throughput of a PON tree. This dynamicity is managed by an algorithm embedded in the OLT called Dynamic Bandwidth Allocation (DBA). It controls the bandwidth by policing the time interval of communication for each ONU. The DBA algorithm is vendor specific and the details of its functioning are not provided to telecom operators. The algorithm exposes bandwidth parametrization through Transmission Container (T-CONT) profiles. T-CONT profiles configuration leverages 5 bandwidth types :

T 2 . 1 :

 21 Transmission containers and their bandwidth types. Bandwidth Type T-CONT types Type 1 Type 2 Type 3 Type 4 Type 5

F 2 . 4 :

 24 PON standardization timeline[START_REF] Effenberger | Pon standardisation status and future prospects[END_REF].

F 2 . 5 :

 25 PON network density.

F

F 2 . 7 :

 27 vOLT with control abstraction.

F 3 . 4

 34 Fixed VNF Timeline.

F 3 . 5

 35 Access network abstraction.

T 4 . 1 :

 41 Cloud/Hardware features for different RAN blocks. speed UP, acceleration for O-DU X CI + high speed UP, acceleration for O-RU X

F 4 . 1 :

 41 Global architecture of the NFV framework[START_REF] Etsi | Network Functions Virtualisation (NFV);Architectural Framework[END_REF].

F 4 . 2 :

 42 Our vRAN architecture through the NFV framework.

F 4 . 3 :

 43 Our vRAN server.

  Figure 4.4 (b) ).

F 4 . 4 :

 44 A typical radio bearer (a); Split bearer concept in a 3C configuration scenario (b).

Figure 4 . 5 ,

 45 shows a possible architectural evolution, where the different user and control plane interfaces are depicted of the eNB within the NG-RAN (based on the previous reference[START_REF] Gpp | Technical Specification Group Radio Access Network; Study on eNB(s) Architecture Evolution for E-UTRAN and NG-RAN", 3rd Generation Partnership Project (3GPP)[END_REF]). The figure represents a scenario where a CU/DU split is occurring within an eNB connected to the EPC in SA mode.

F 4 . 5 :

 45 Comparison between E-EUTRAN RAN (4G RAN) and NG-RAN basic CU/DU split.

T 4 . 2 : 1

 421 Overview of some major Linux distributions. Up to 10 years 2 5 years for LTS

F 4 . 6 :

 46 Openstack key elements.

F 4 . 7 :

 47 The mobile solution logical architecture and a screenshot showing the Openstack implementation.

F 4 . 8 :

 48 Screenshot of the epc_enablers Virtual Machine and its functionalities.

F 4 . 9 :

 49 Exposing the mobile platform PDCP and RLC interfaces

Figure 4 .

 4 10 (a) shows the path the mobile traffic takes in case of a direct connection of the provider networks with the NICs.

F 4 . 10 :

 410 Traffic path with and without the isolation of the NICs

F 4 .

 4 11: Technical overview

Figure 4 .

 4 Figure 4.11 shows a more technical view of the implementation, with the different technical configurations (Provider networks creation, isolation, namespaces connection with VETH pairs and the creation of the necessary IP routes) addressed.The NIC1 and NIC2 namespaces are connected to the DU+RU and CU blocks respectively. In the namespace of NIC2 we created a virtual router that allow us to route packets to and from the CU and on the other side, in the NIC1 namespace, we created a simple bridge to forward traffic to and from the DU+RU blocks.

F 4 . 12 :

 412 Mobile data encapsulation.

F 4 . 13 :

 413 Detailed overview of the mobile encapsulation.

F 4 . 14 :

 414 GTP header.

T 4 . 3 :

 43 Mobile solution's overhead in a data transmission for a 1000-byte payload.

F 4 .

 4 15: MAC-LTE header.

F 4 . 16 :

 416 UE attach procedure.

F 4 . 18 :

 418 Packet size vs bitrate.

F 5 . 1 :

 51 PAM4 functioning

F 5 . 2 :

 52 vRAN over PAM4 experimental setup.

F 5 . 3 :

 53 PAM4 eye diagram of our vRAN data + Ethernet overloading.

F 5 . 4 :

 54 FLR variation with bitrate.

F 5 . 5 :

 55 FLR vs bitrate for different induced packet jitter values.

F 5 . 7 :

 57 Experimental Setup.

Figure 5 . 8 (

 58 left) shows that ODN loss budgets of 20 dB, 22.6 dB and 21.8 dB can be respectively obtained for OB2B, 10 km and 15 km ssmf at BER = 10 -3 . Optical budgets of 19.9 dB, 21.4 dB and 22.4 dB are obtained at BER = 10 -12 , ensuring thus compatibility with budget class L1 and necessitates 5 dB to be compatible with L2 (optical budget classes of NG-PON2 WDM standard)[START_REF]40-Gigabit-capable passive optical networks 2 (NG-PON2): Physical media dependent (PMD) layer specification[END_REF]. The worst performances in OB2B are due to the CTLE parameters, which are optimized for 10 km operations. In the insets of Fig.5.8 (left) we can see the eye diagram after transmission through 0 and 10 km of optical fiber.

F 5 . 8 :

 58 Evaluations layers (left) L1 PHY, (middle) L2, with both Ethernet and eCPRI and (right) L3 with IP packets.

Figure 5 . 8 (

 58 Figure 5.8 (middle) shows similar performances between layer 2 Ethernet and eCPRI transmissions. It can be seen that up to 19.4 dB, 21.8 dB and 20.9 dB optical budgets can be ensured in OB2B, 10 km and 15 km respectively, matching L1 class NG-PON2 PtP WDM requirements[START_REF]40-Gigabit-capable passive optical networks 2 (NG-PON2): Physical media dependent (PMD) layer specification[END_REF], while ensuring High Class of Service (CoS) in terms of frame loss compatibility for eCPRI splits E, ID, IID and IU[START_REF]Common Public Radio Interface: Requirements for the eCPRI Transport Network[END_REF]. IP layer assessments (Fig.5.8 (right)) show similar performances to those of layer 2. Figure5.9 (right) shows the single wavelength layer 3 performances of the system precisely when submitted to different frame sizes, at 10 km, where negligible degradations are observed when compared to the 512 bytes case. The latency added by the WDM PON system under test was measured at 7.8 µs with a peak packet jitter of 0.06 µs for different frame sizes from 64 bytes to 1512 bytes. The same packet jitter performances were observed with a random frame size configuration. Performances are thus compliant with eCPRI High100/200/500 (100µs, 200µs, 500µs one way latency) latency classes for propagation up to 15 km. This would allow, for instance, approximately 19µs of switching time margin for a High100 class and a 15 km fronthaul link 2[START_REF]Common Public Radio Interface: Requirements for the eCPRI Transport Network[END_REF]. Wavelength stability assessment over a period of 16 hours showed good performances with ±0.1 dB variation of the peak optical power and under 0.01 nm variation of the center wavelength.

F 5 . 9 :

 59 Impact of optical budget on layer 3 frame loss rate. (left) Single wavelength, different frame sizes.(right) 3 wavelengths, 512B frame.

F 5 . 10 :

 510 Leveraging the PON infrastructure to offload mobile traffic.

F 5 .

 5 11: vRAN over XGS-PON experimental setup.

Figure 5 .

 5 Figure 5.11 shows the experimental setup composed of the virtual platform (explained in section 4.1.1), the aggregation and access networks. The mobile PDCP-RLC interface goes through the (emulated) aggregation segment, the access network and to the DU+RU block.

F 5 .

 5 12: XGS-PON OLT chassis (a), ONU (b).

F 5 . 13 :

 513 FLR variation with bit-rate for different induced packet jitter values in our PON transmission (a) compared to a Back to Back transmission (b).

T 5 . 1 :

 51 RTT comparison between B2B and 10 km XGS-PON.

F 5 . 14 :

 514 Upstream bitrate evolution for point-to-point B2B (a and b) and XGS-PON (c and d).

F 5 .

 5 15: HST XGS-PON "cell-less" network.

F 5 . 16 :

 516 HST experimental setup.

Algorithm 1 :

 1 White list policy for adjacent ONUs. while Frames received with the same MAC source do if Received from (ONU n and ONU n+1) or (ONU n-1 and ONU n) then Allow MAC flapping; else Deny MAC flapping; end end

F 5 . 19 :

 519 ONUs bit-rate variation for the down and uplinks. F 5.20: ONU uplink bursts.

T 5 . 2 : 1 .

 521 PON deployment scenarios. Carrier frequency Max. cell radius 1 #ONUs ∆L ONU | cell radius 2 ∆L D I F F ,M AX 3 For an RF link budget of 120 dB 2. ∆L ONU : distance between adjacent ONUs on a rail track 3. ∆L D I F F ,M AX : maximum differential distance between ONUs 4. L M AX : Maximum distance between ONU and OLT 5. Minimum needed optical budget/class 6. Uninterrupted communication time per PON (360 km/h)

F 6 . 1 : 6 . 1 :

 6161 Sending a UDP packet through the Linux kernel T Approximation of the cost of each operation for sending a UDP packet

F 6 . 2 :

 62 NIC/User space interaction with(w/) and without(w/o) DPDK

F 6 . 3 :

 63 XGS PON's OLT chassis (a), mini OLT mounted on an SFP+ (b) F 6.4: XGS PON's mini OLT plugged on a switch

F 6 . 5 :

 65 (a) D-RAN topology, (b) PON topology, (c) D-RAN/PON convergent topology

F 6 . 6 :

 66 Experimental setup. Chapter 6. Showcasing two approaches of Software Defined Networking (SDN) in the RAN

F 6 . 7 :

 67 vRAN offloading variation at the PtP (a), the PtMP (b).

F 6 . 8 :

 68 FLR at the reception in the vEPC.

F 6 . 10 :

 610 Fi-Wi architrecture.

Figure 6 .

 6 Figure 6.11 represents our experimental setup. Dark and light orange blocks in the left side represent the OFDM signal generator.It generates an LTE-like signal that goes through the fiber segment (Fi) and then the millimeter wave segment (Wi). In our scenario, each one of these generators is an enabler of a different CoS, one is for "High Quality" service and the other for "Best Effort". On the right side of the figure the two orange blocks are set to represent the signal analysers that will receive the

F 6 . 11 :

 611 Fi-Wi experimental setup.

F 6 . 13 :

 613 Our YANG model.

F 6 .

 6 15: EVM in % of the received data plane as a value of carrier frequency and power at the reception of the photodiode.

F 6 . 16 :

 616 The frequency bands of each CoS.

Figure A. 3 ,

 3 Figure A.3, shows a more detailed version accompanied with some relevant technical considerations of the exposition of the mobile interfaces of the CU (named bbu in the solution) and the DU+RU (named rru in the solution). Each dotted rectangle shows the various network informations of each block and we also show the IP addresses of the Openstack provider and self service networks. The elements of this figure has been kept with the original nomenclature of the platform elements.

of Optical Access Solutions in Line with Radio Access Network Interfaces

	ii		iii
	Author:	Supervisors:
	Anas EL ANKOURI	Dr. Annie G
		Dr. Isabel A
		Dr. Luiz A	N

D T

Study

  • A comprehensive study of CPRI detailing its requirement in terms of latency, data rate as well as other technical considerations such as jitter and monitoring. Ends with an open question about the adoption of CPRI for 5G and the usage of Ethernet to transport this interface.[START_REF] Pizzinat | Things you should know about fronthaul[END_REF]

	• Simulation work to test the performance of Ethernet when
	carying CPRI trafic. [55]
	2016 • Studying the CPRI specification through global end to end
	encapsulation and the different steps to go from an LTE signal
	to CPRI in addition of dimensioning of CPRI links to
	accomodate various antennas configurations. [14]

• Real time demonstration of a compressed CPRI signal based on filtering the LTE spectrum and reduction of the CPRI I/Q samples quantification resolution.

[START_REF] Tayq | Performance Demonstration of Real Time Compressed CPRI Transport[END_REF]

2017 • Dynamic Ethernet encapsulated CPRI bit rate configuration based on cell configuration change. It leverages on the configuration mechanism traditionally enabled at the startup of a frontahul link.

[START_REF] Valcarenghi | Time-versus size-based CPRI in ethernet encapsulation for next generation reconfigurable fronthaul[END_REF]

Added overhead (Bytes) Mobile overhead percentage

	SGi	0 Bytes	0%
	S1	36 Bytes	3.38%
	V1 (PDCP-RLC split)	38 Bytes	3.56%
	Uu	52 Bytes	4.81%

  .2). Correction parameters are plugged into the previous Friis equation to calculate the maximum propagation distance : P r x (d B ) = P t x +G t x +G r x + 20l og 10 (λ/4πD r ) + H t x + H r x +G ar ea -A( f , d ) mu

	• H t x = TX height correction	• A mu = Attenuation relative to free
		space
	• H t x = RX height correction	• G ar ea = Gain due to terrain

  .

	T	6.2: RTT comparison between B2B and 10 km XGS-PON.
			Avg RTT (ms) Jitter (ms) Max(ms)
	End to end 4G RAN only *	1,95	0,29	3,86
		DPDK PtP	2,225	0,17	2,6
		DPDK PtMP	3,21	0,36	4,13

* Virtual link between all the components of the EPC Mobile Core network and RAN

100

  Chapter 6. Showcasing two approaches of Software Defined Networking (SDN) in the RAN • The CoS Look Up Table (LUT): translates our CoS into the appropriate physical resources describing it.

Table 6 .

 6 3 giving a recap for the features of each CoS.

			T	6.3: Service classification.
		RF Carrier Frequency	# Component Carriers	Component Carrier Bandwidth	Power density	QAM Constellation
	High Quality	2.06 GHz	5		20 MHz	0.9 mW/MHz 64 QAM
	Best Effort	1.95 GHz	1		10 MHz	0.2 mW/MHz 16 QAM

  AcronymsCTLE Continuous Time Linear Equalizer. 70, 71 CU Central Unit. 17, 21, 43, 44, 48, 50-52, 54-56, 60, 61, 75, 79, 88, 92 CWDM Coarse Wavelength Division Multiplexing. 68 D-RAN Distributed Radio Access Network. 14, 17, 29, 92 DBA Dynamic Bandwidth Allocation. 26, 31, 36, 38, 39, 73-75, 79, 107 DMA Direct Memory Access. 88 DML Directly Modulated Laser. 65 DPDK Data Plane Development Kit. 88-91, 94 DRA Diameter Routing Agent. 50 DSS Dynamic Spectrum Sharing. 12 DU Digital Unit. 14, 17, 21, 28, 29, 43, 44, 48, 51, 52, 54, 60, 61, 73, 79 DWDM Dense Wavelength Division Multiplexing. 4, 63, 68, 70, 72 eCPRI enhanced CPRI. 34, 68, 70-72 EDFA Erbium Doped Fibre Amplifier. 70 eMBB enhanced Mobile Broad Band. 8, 9, 64, 72 EMS Element Management System. 44, 45 eNB Evolved Node B. 13, 14, 28, 47, 48 EPC Evolved Packet Core. iv, 13, 43, 48, 50, 52, 59, 66, 75, 106 EPON Ethernet PON. 68 ETSI European Telecommunications Standards Institute. 43-45, 92 EVM Error Vector Magnitude. 99 FAN Fixed Access Network. 36 FDD Frequency Division Duplex. 56 FEC Forward Error Correcting. 70 Fi-Wi Fiber-Wireless. 96, 97 FLR Frame Loss Ratio. 59, 66, 67, 70, 74, 76, 79, 82, 94 FTTA Fiber To The Antenna. 23-25 FTTB Fiber To The Building. 23, 24 FTTC Fiber To The Cabinet. 23, 24 FTTH Fiber To The Home. 3, 13, 23-25, 28, 32, 63 Acronyms 129 FTTX Fiber To The X. 23, 24 FWA Fixed Wireless Access. 8, 10, 77, 96 G-PON Gigabit PON. 68 gNB gNodeB. 13, 47 GTP GPRS Tunneling Protocol. 55, 56 HARQ Hybrid Automatic Repeat reQuest. 94 HLS High-Layer Split. 35, 107 HS-PON High Speed PON. 28 HSS Home Subscriber Server. 43, 50 HST High Speed Train. 77, 82 IaaS Infrastructure as a Service. 46 ICSCF Interrogating-CSCF. 50 IEEE Institute of Electrical and Electronics Engineers. 16, 27, 28, 68 IFG Inter Frame Gap. 88 IMS IP Multimedia Subsystem. 50 IoT Internet of Things. 9 IP Internet Protocol. 56, 68, 70, 71 IRTF Internet Research Task Force. 97 ISG Industry Specification Group. 92 ITU International Telecommunication Union. 7, 27, 28, 68 KPI Key Performance Indicator. 7 LA Limiting Amplifier. 64 LCID Logical Channel ID. 56 LLS Low Layer Splits. 63, 107 LSB Least Significant Bit. 64, 65, 67 LTE Long Term Evolution. 17, 47, 57 LUT Look Up Table. 100 MAC Media Access Control. 47, 50, 51, 78, 79 MEC Mobile Edge Cloud. 87, 88, 92, 93, 96 MEF Metro Ethernet Forum. 93 130 Acronyms MeNB Master eNB. 13, 47 MIMO Multiple-Input, Multiple Output. 10 MME Mobility Management Entity. 43, 50 mMIMO massive MIMO. 10, 18 mMTC massive Machine Type Connectivity. 8, 9 mmWave millimeter Wave. 10, 97 MSB Most Significant Bit. 64-67 NFV Network Functions Virtualisation. 19, 20, 30, 31, 35-37, 44, 45 NG-PON2 Next-Generation Passive Optical Network 2. 28, 70-72 NGFI Next Generation Fronthaul Interface. 16 NIC Network Interface Controller. xvi, 52, 53, 60, 88-90 NR New Radio. 10 NRZ Non Return to Zero. 28, 63-67, 82 NSA Non-Standalone. 13, 47 OAI Open Air Interface. 20, 22, 35 OAM Operations Administration and Management. 36 OB2B Optical Back to Back. 65, 67, 70, 71, 76 ODN Optical Distribution Network. 64, 70, 72 OFDM Orthogonal Frequency Division Multiplexing. 10 OLT Optical Line Terminal. 25, 26, 28, 30, 31, 36, 68, 70, 72, 73, 77-80, 88, 91-93, 96, 107 OMCI ONU Control Management Interface. 31, 68, 92, 94 ONF Open Networking Foundation. 21, 30 ONU Optical Network Unit. 25-27, 30, 31, 36, 38, 68, 70-74, 76-80, 94-96, 107

	OS Operating System. 52, 88
	OSS Operations Support System. 44
	OVS Open vSwitch. 90, 91, 94
	PAM4 Pulse Amplitude Modulation. 63-67, 82, 83

PCI Peripheral Component Interconnect. 90 PCSCF Proxy-CSCF. 50 PDCP Packet Data Convergence Protocol. 17, 46-48, 50-52, 55, 56, 60

in the mobile solution we chose, the CU and the DU+RU are called BBU and RRU respectively

F 5.6: The possible usages of a PtP WDM in serving different split options of RAN.

Latency of propagation in fiber is approximately 5µs/km

F A.2: Virtual resources assessment.

Acknowledgements

I would like to preface my acknowledgements by thanking my academic supervisors, Annie Gravey for her rigorous analysis and the opportunity that has been given to me to benefit from her lifelong expertise in both academic and telecom domains. Isabel Amigo for her continuous assistance, her pertinent remarks, her helpful feedback and her unique contributions to my research work.

Acknowledgements ix

General conclusion and perspectives

List of publications

As first author:

A.2 Virtual resources assessment

Abstract:

The advent of 5G is around the corner, with commercial deployment starting to be conducted all around the world. This new generation of mobile communication offers new services compared to the 4G. These new services require a considerable amount of bandwidth or strict latency constraints or even a massive number of connected objects. The Radio Access Network (RAN), which is the access network segment connecting the radio equipment to the rest of the network will be challenged with these new services, especially in the optical transport segment. Many solutions have been proposed to address this problem such as relying on functional splits. This thesis studies the impact and challenges brought by 5G on the access network and proposes solutions to accommodate it by investigating the issue through two main paradigms: virtualisation and the exploration of new optical transmission solutions for the RAN. This study will be composed as follows:

• Implementation of a virtual infrastructure to host a mobile solution with a high layer PDCP-RLC split. This solution comprises of core network and virtual RAN (vRAN) elements.

• Testing optical solutions in the transport of various split options through a lab implemented optical access network. Our tests have been mainly focusing on the high layer vRAN split while exploring potential key network features of the future such as fixed mobile convergence and Mobile Edge Computing (MEC). Conventional point to point have been evaluated but also, in a less conventional way, point to multipoint approaches. The latter approaches have been proposed in the context of fixed mobile convergence as well as to meet the service requirements of 5G.

• Explicitly showcase an instance of abstraction in the network thanks to software defined networking (SDN). We work on a case that simplifies the configuration of radio signal generation/analyse equipment in order to set up classes of services and slicing through the optical access network.