P Chanclou

G Simon

M Wang

" Procédé

Organisation du Manuscrit

Le manuscrit est structuré en deux grandes parties. Pour chaque partie, quatre chapitres sont inclus, en plus d'une introduction et un chapitre de conclusion.

La première partie présente un état des lieux sur les réseaux d'accès. Le Chapitre 1 introduit l'architecture du réseau d'accès fixe et mobile. Des chiffres clés de l'évolution et du déploiement FTTH sont donnés et une analyse de Key Performance Indicators (KPIs) pour réseaux mobiles 4G, 5G et 6G est effectuée pour comprendre des nouvelles demandes de la 5G/6G et surtout des solutions possibles pour réaliser les cas d'utilisations Ultra Reliability and Low Latency Communication (URLLC) de la 5G.

Dans le Chapitre 2, nous nous concentrons sur les aspects de management dans les réseaux d'accès. Nous discutons de la limitation des réseaux fixes actuels pour les services mobiles afin de prendre en charge les futures exigences de la 5G et au-delà.

Les technologies de virtualisation attirent de plus en plus l'attention des opérateurs confrontés au défis d'avenir. Dans le Chapitre 3, un panorama du SDN et NFV est donné: une explication technique est faite pour des différents projets de référence proposés par ONF et BBF (e.g. SEBA, VOLTHA, CloudCO, BAA).

Enfin, dans le Chapitre 4, nous analysons les efforts et défis de convergence fixe et mobile dans les réseaux d'accès.

Cette thèse couvre différents aspects, de la couche physique aux couches de contrôle et de gestion des éléments des réseaux fixes et mobiles. Nous décrivons précisément tous les éléments de notre banc de test au Chapitre 5 avant de rentrer dans les chapitres de contributions.

Au Chapitre 6, nous présentons deux nouvelles architectures d'OLT avec le contrôleur SDN associé avec chacun d'eux. La première contribution de ce chapitre révèle la capacité de contrôle dynamique des noeuds d'accès avec une architecture désagrégée et un contrôleur SDN.La deuxième contribution montre l'opportunité apportée par les serveurs génériques dans réseaux d'accès pour des fonctions du coeur mobiles. Au Chapitre 7, nous nous concentrons sur les exigences de disponibilité pour la 5G. Le réseau d'accès fixe transporte les services mobiles du CO aux sites d'antenne. Le problème des réseaux d'accès d'aujourd'hui est qu'il n'y a pas de liaison optique redondante pour les sites d'antennes donc une haute disponibilité de certains services mobiles ne peut être assurée. Nous proposons différentes architectures de protection en réutilisant ou non l'infrastructure de fibre déployée. Nous adaptons dynamiquement la QoS dans le cas de services résidentiels et mobiles partageant l'infrastructure fibre grâce à notre contrôleur SDN.

Nous continuons sur les demandes de la 5G au Chapitre 8, en particulier sur la réalisation du 5G slicing dans les réseaux d'accès optiques avec une infrastructure fixe-mobile convergée.

First of all, I would like to express my gratitude to Loutfi Nuaymi (professor at IMT Atlantique) and Philippe Chanclou (team manager at Orange Innovation) for giving me the opportunity to explore the telecommunication networks in the research area. I would like to express my appreciation to Loutfi for his patience, encouragement, and academic guidance as my doctoral advisor for this thesis. (...and he has a great passion for le pot de soutenance) I would also like to highlight Philippe for the sharing of his mastery knowledge in access networks, his advice and his firm leadership. (...and his 'unconscious' check about 'Combien de pages' ?) I extend my gratitude to my thesis jury members: Marco Ruffini, Paolo Monti, Djamal Zeghlache et Stefano Secci. I would like to express my special thanks to Marco Ruffini and Paolo Monti for accepting to review my thesis manuscript. I would like to express my sincere appreciation to my supervisors. Gaël Simon (research engineer at Orange Innovation), Luiz Anet Neto and Isabel Amigo (associate professors at IMT Atlantique). Gaël is always there to listen to me and help me out of all technical dilemmas. I am lucky to be accompanied carefully for three years. (...'J'ai entendu des rumeurs du confinement... faut que tout soit établi dans labo au plus vite!' ). Luiz influenced me both professionally and personally for his rigorous attitude and passion for work. (...'Minqi, pourquoi je ne peux plus ajouter des commentaires, Overleaf m'a blacklisté ?' ) Isabel's pertinent suggestions are always straight to the point in advancing our work more efficiently. (when we thought that we got an innovative idea...'this already exists no ?') All my supervisors have no hesitation in sharing the idea with me; without them, this thesis work cannot be carried out fluently. I would also like to thank all my colleagues in Orange and in the two campus of IMT Atlantique for the comfortable atmosphere during coffee breaks and dinner. The discussion with them about technical topics and other opinions about daily life expanded my horizons to understand the world. The list will start with Anas El Ankouri, André Bollore, Alain Le Blay, Christophe Billant, Daniel Abgrall, David Patient, David Minodier, Eric Pitard, Flávio André Nogueira Sampaio, Frédéric Miet, Fabienne Saliou, Fabien Scagnelli, Fabrice Bourgart, Géraldine Calvignac, Georges Gaillard,Jeremy Potet, Stéphane Le Huerou, Sophie Durel, Yann Denis, Zineb Belfqih, all intern students... This is an endless list, as some of you have not even left your name after encouraging, inspiring, and helping me during the conferences, the meetings, etc.

Abstract

Optical access networks provide both mobile and residential services for the last kilometers using typically Point-to-Point (PtP) and Point-to-Multi-Point (PtMP) fiber topologies. New services in 5G and 6G require not only higher bandwidth than 4G but also high reliability, ultra-low latency/jitter, massive connection capacity and low energy consumption. This requires telecommunication operators to rethink new access fiber infrastructure and improve the way management is implemented to provide better network performance and user experience with a cost and energy-efficient solution. With a massive fiber deployment of Fiber to the Home (FTTH), the reuse of Passive Optical Network (PON) infrastructure for mobile services becomes an interesting option for operators with minimum deployment effort. Meanwhile, virtualization technologies are key enablers for convergent fixed and mobile access networks: Software Defined Networking (SDN) decouples the data plane and control plane and allows global traffic path optimization and management coordination tasks; Network functions virtualization (NFV) provides the opportunity for flexible software implementation and resource sharing by running virtualized functionalities on generic servers.

This thesis studies the opportunities offered by Optical Line Terminal (OLT) virtualization in a new fixed-mobile convergence paradigm. Three topics are addressed as follows.

• Study of hardware-level convergence in fixed access networks with the help of virtualization technologies. Two disaggregated OLT topologies are proposed, each one corresponding to a fixed mobile convergence scenario. A dynamic fixed and mobile traffic management solution inside an OLT is proposed and reffered as extended-Cooperative Transport Interface (eCTI) using µOLT with a switch. A Multi-Access Edge Computing (MEC) and User Plane Function (UPF) compatible OLT using a generic server holding both µOLT and a virtualized switch is also proposed for time-critical mobile services.

• Study of mobile optical access protection solutions with FTTH infrastructure to increase availability/reliability of 5G/6G services. Comparison of PtP and PtMP using disaggregated OLT as protection for multiple antenna sites in terms of Capital Expenditures (CapEx) and energy consumption. The reuse of FTTH PON for mobile protection links with adapted Quality of Service (QoS) is also assessed to improve the availability and reliability of mobile networks.

• Study of 5G slicing application in access networks. A fixed-mobile management coordination interface is proposed to allow for End-to-End (E2E) slicing scenarios. A Proof-of-Concept (PoC) is shown with an emulated 5G core and Radio Access Network (RAN)/User Equipment (UE), disaggregated OLT and two SDN controllers for fixed access network and mobile network.

This thesis' contributions show that the SDN-based optical access nodes and converged PON provide novel and very promising architectures for time-critical and high-availability services. Finally, some interesting perspectives can be evaluated, such as advanced dynamic load balancing within OLT, or Virtual Machine (VM) resource optimization with a generic server in access networks.

Resumé en Français Motivation

Les réseaux d'accès distribuent à la fois des services mobiles, entreprises et résidentiels sur les derniers kilomètres de réseaux télécoms pour des utilisateurs. Les réseaux d'accès fixes sont traditionnellement déployés en ligne cuivre et progressivement remplacés par des fibres optiques. Deux différentes topologies optiques sont utilisées: Point-to-Multi-Point (PtMP) pour acheminer des services aux clients Fiber to the Home (FTTH) et Point-to-Point (PtP) aux sites antennaires.

Grâce aux différentes technologies du Passive Optical Network (PON), plus d'un milliard de maisons sont raccordables par la fibre optique en 2022 dans le monde. En France, Gigabit capable Passive Optical Network (GPON) est massivement deployé pour le réseau FTTH avec environ 37 millions d'abonnés fibre en 2021 [1]. Le 10 Gigabit Capable Symmetrical PON (XGS-PON), avec 10 Gbps de bande passante symétrique partagée jusqu'aux 128 clients, a démmaré son premier déploiement dans les réseaux FTTH d'Orange. Des futures générations du PON visent une capacité de 50 Gbps et des travaux de recherche sont actuellement concentrés au 100 Gbps.

Bien que les utilisateurs finaux du réseau mobile bénéficient d'une connectivité sans fil, les sites d'antennes qui émettent le signal radio pour couvrir le territoire sont généralement connectés au réseau télécom à l'aide de fibres optiques. Les réseaux d'accès fixes pour les services mobiles évoluent indépendamment des réseaux FTTH. Aujourd'hui, une fibre PtP fournie 10 Gbps de bande passante symétrique entre le site antennaire et le Central Office (CO) d'opérateur qui est 10 -20 km plus loin que les clients finaux.

Les nouveaux services de la 5G et de la 6G demandent non seulement une bande passante plus importante que les services de la 4G, mais aussi une très haute disponibilité, de très basses latence et gigue, une connectivité massive et une faible consommation d'énergie. Ces nouveaux besoins forcent des opérateurs à repenser l'infrastructure de la fibre optique et la manière de gérer l'ensemble du réseau pour fournir la meilleure performance aux clients tout en garantissant des solutions rentables en termes de coût et d'énergie.

Contexte

Avec 156 milliards d'euros investis en Europe pour les réseaux FTTH [2], le PON est déjà massivement déployé. En France, des fibres optiques sont souvent sur-dimensionnées. Par conséquent, une réutilisation du PON pour les services mobiles devient une option intéressante pour les opérateurs qui peuvent faire un minimum d'effort pour des nouveaux déploiements.

Orange, l'opérateur principal du deploiement de réseauxFTTH et le meilleur réseau mobile en France selon l'"Autorité de Régulation des Communications Electroniques, des Postes et de la distribution de la Presse" (ARCEP) en 2022, a décidé d'agréger du trafic résidentiel et du trafic mobile en utilisant le même équipment Optical Line Terminal (OLT) dans le CO. Aujourd'hui, un chassisOLT est composé par trois types de cartes: carte réseau, carte PtP et carte PtMP. Le choix d'utiliser un OLT pour différents services en réseau d'accès réalise une première convergence du réseau fixe et mobile.

Les opérateurs sont confrontés à de fortes contraintes financières non seulement à cause des infrastructures réseaux qui comptent des millions de terminaux (e.g. FTTH), mais aussi des outils de management qui sont dépendants de chaque fournisseur d'équipements (e.g. OLT). Les chercheurs et les opérateurs continuent à travailler sur l'utilisation ou la réutilisation de technologies PON et d'infrastructures de fibres résidentielles pour prendre en charge les services mobiles pour la 5G et au-delà afin de réduire les dépenses d'investissement (Capital Expenditures (CapEx)) et les dépenses opérationnelles (Operational Expenditures (OpEx)).

Parallèlement, la virtualisation, d'abord appliquée dans les datacenters, a été rapidement introduite dans les réseaux d'accès. En 2019, de nombreux opérateurs de télécommunications du monde entier ont exprimé leur considérations sur le Software Defined Networking (SDN)/Network functions virtualization (NFV), 51 opérateurs sont impliqués dans la transformation de la virtualisation [3].

Les techninologies de virtualisation qui utilisent les concepts de SDN et de NFV se sont développées rapidement ces dernières années. Ces techniques sont considérées comme des pistes intéressantes pour réaliser des scénarios pour la convergence de réseau fixe et mobile en réseau d'accès et éviter la dépendance des équipementiers. L'idée du SDN a été proposée à l'origine par l'Université de Standford pour réaliser un système de contrôle centralisé face au problème de sécurité. Depuis, l'approche de SDN représente un réseau révolutionnaire architecturale avec des éléments de réseau abstraits et une nouvelle façon de gérer le plan de contrôle et de management du réseau. Le developpement du NFV a officiellement commencé en 2012 avec le Whitepaper de l'European Telecommunications Standards Institute (ETSI) [4]. Le NFV fournit des opportunités pour des implémentations logicielles de manière plus flexibles et des partages de ressources dans des serveurs génériques. Les deux technologies sont souvent appliquées ensemble mais elles sont indépendantes l'une de l'autre.

Les deux organisations importantes qui ramènent la virtualisation dans les réseaux d'accès sont l'Open Networking Foundation (ONF) et le BroadBand Forum (BBF). L'ONF a été fondée par des opérateurs de télécommunications avec l'idée d' ≪ Open source, open hardware ≫ pour tous les segments de réseaux, y compris les réseaux d'accès. L'ONF a proposé une architecture SDN utilisant les protocoles Openflow. Les deux projets d'ONF nommés SDN Enabled Broadband Access (SEBA) et Virtual OLT hardware abstraction (VOLTHA) sont concentrés sur les réseaux d'accès optiques.

Contrairement à l'organisation open source ONF fondée ces dernières années, BBF est l'organisation qui développe traditionnellement des normes pour les réseaux d'accès et domestique depuis 25 ans. A partir de 2016, le BBF a entamé sa conversion d'une organisation de normalisation à une organisation plus agile et collaborative pour s'adapter à la tendance de la virtualisation portée par l'ONF. Le BBF se concentre désormais principalement sur les expériences industrielles pour les normes plutôt que sur les idées théoriques. De plus, BBF définit des modèles de données standards pour les éléments d'accès. Les deux projets open source de BBF nommés Cloud Central Office (CloudCO) et Broadband Access Abstraction (BAA) absorbent des avantages du SDN/NFV dans une architecture d'accès traditionnelle.

Avec les deux tendances de l'ONF et du BBF dans les couches d'infrastructure et de gestion des réseaux d'accès optiques dont nous avons parlé plus haut, une thèse Conventions Industrielles de Formation par la Recherche (CIFRE) a été proposée, entre l'opérateur français Orange (Lannion, France) et l'école d'ingénieur IMT Atlantique (Brest, France), cofinancée par l'Association Nationale de la Recherche et de la Technologie (ANRT) en 2019. Le sujet de cette thèse est d'étudier les opportunités menées par les technologies de virtualisation (SDN/NFV) dans les réseaux d'accès optiques et notamment les paradigmes de convergence fixe-mobile pour les futures générations mobiles.

Cette thèse a été réalisée dans le cadre des projets de recherche européens 5G-COMPLETE (appel H2020-ICT-2019) et MARSAL (appel H2020-ICT-52). 5G-COMPLETE a été lancé en 2019 avec l'objectif de révolutionner l'architecture 5G en combinant efficacement les fonctionnalités des ressources et de stockage sur un réseau d'accès radio à très haute capacité. A la fin du projet 5G-COMPLETE, une démonstration en laboratoire aura lieu à Orange Innovation, Lannion, fin 2022. MARSAL a été lancé en 2020 après le début de cette thèse dans le but d'analyser et optimiser des performances de réseau de bout en bout pour différents services de la 5G et 6G. Cette thèse est incluse dans MARSAL avec un accent sur les architectures désagrégées, le plan du contrôle SDN vers les cas d'utilisation de la convergence fixe-mobile et le paradigme de edge computing.

Objectifs et Contributions

L'étude des réseaux d'accès fixes et mobiles convergés chez Orange a commencée avant cette thèse. Des travaux [5] de la thèse intitulée Integration and Supervision de liens Fronthaul dans les réseaux 5G (2017) [6] ont évalué des solutions basées sur Ethernet avec GPON pour les liaisons fronthaul. Le dernier travail publié dans [7,8] inclus dans le manuscrit de thèse intitulé "Optical Access Solutions in Line with Radio Access Network Interfaces" (2021) [START_REF] Anas | Study of Optical Access Solutions in Line with Radio Access Network Interfaces[END_REF] a introduit XGS-PON pour les solutions de transport optique mobile et l'infrastructure PtMP de la fibre pour les cas d'utilisation de petites cellules 5G.

Trois objectifs sont fixés pour cette thèse et les études concernants ces objectifs sont adressées:

• Objectif 1: Réduire l'impact de la latence et de la gigue dans les réseaux d'accès optiques pour des services 5G qui sont sensibles au temps.

Nous avons réalisé des études sur la convergence du hardware dans les réseaux d'accès fixes avec l'aide de la technologie de virtualisation. Nous avons étudié également les options d'implémentation d'un OLT désaggrégé en deux formes et réalisé des scénarios de convergence pour chaque implémentation.

Une gestion dynamique du trafic fixe et mobile à l'intérieur de l'OLT est proposée, de même qu'une interface extended-Cooperative Transport Interface (eCTI) améliorée, avec un µOLT et un switch. Un OLT basé sur un serveur générique avec de l'informatique en périphérie (Multi-Access Edge Computing (MEC)) et des fonctions mobiles (User Plane Function (UPF)) pour des services mobiles de la faible latence sont implémentés.

Le µOLT et le switch virtualisé sont accueillis par le serveur générique.

• Objectif 2: Augmenter la fiabilité des réseaux d'accès mobiles à l'aide des technologies de virtualisation pour répondre aux exigences des services 5G. Proposer et comparer différentes approches fixe-mobile architecturales convergentes en termes de coût et de consommation d'énergie.

Nous avons réalisé des solutions de protection pour le réseau d'accès mobile en reutilisant le PON du FTTH déjà déployé pour satisfaire la disponibilité demandée par la 5G ou la 6G.

Nous avons utilisé un OLT désagrégé et comparé le CapEx et la consommation d'énergie avec les architectures PtP et PtMP pour plusieurs sites antennaires. Ensuite, nous avons réutilisé le PON du FTTH pour des liens de protections pour des sites antennaires puis adaptaté la qualité de service (Quality of Service (QoS)) lorsque le service mobile et le service FTTH utilisent le même arbre PON.

• Objectif 3: Identifier les éléments clés pour activer le 5G slicing dans les réseaux de transport d'accès optiques en utilisant les concepts de SDN et NFV.

Nous avons réalisé des applications du 5G slicing en réseaux d'accès. Une interface de coordination entre des entités de management pour réaliser le End-to-End (E2E) slicing est proposée et une preuve de concept est réalisée avec un coeur 5G, Radio Access Network (RAN)/User Equipment (UE) emulés, un OLT désagrégé et deux controleurs SDN pour réseaux d'accès fixe et mobile.

Le 5G slicing effectue une réservation de ressources de bout en bout pour différentes QoS des services mobiles. Nous analysons les activités de normalisation sur la couche de management entre le projet de partenariat de 3GPP et d'autres réseaux de transport. Il montre que dans une architecture basée sur le SDN, l'interface de management pour la coopération entre les réseaux d'accès mobile et fixe n'est pas clairement définie aujourd'hui, alors que cette interface est la clé pour réaliser le 5G slicing. Nous proposons et réalisons une solution avec une interface entre les contrôleurs SDN mobile et fixe pour une reconfiguration dynamique. Nous évaluons les performances de certains paramètres de QoS dans un réseau d'accès fixe pour des services sensibles à la latence.

Conclusions et Perspectives

Nos contributions montrent que la technologie SDN/NFV dans le réseau d'accès optique accélère des scénarios de convergeance entre services du fixe et du mobile, surtout pour le PON convergé pour fixe et mobile services. Le controleur SDN facilite l'implémentation de nouvelles propositions d'architecture pour les services mobiles à temps critique et à haute disponibilité.

Finalement, quelques perspectives intéressantes peuvent être évaluées à l'avenir, telles que la gestion dynamique de charge au sein de OLT, l'optimisation des ressources de Virtual Machine (VM) avec un serveur générique dans les réseaux d'accès, ou une étude de la consommation énergique avec une architecture SDN/NFV.

Introduction Motivation

Optical access networks for fixed and mobile services have been subject of significant evolution in both infrastructure and management aspects in recent years. The fixed access networks' traditional copper lines are gradually replaced by optical fibers, while the purpose remains similar: to provide the last 0 to 20 kilometers of wireline connection from operator technical locations to houses, buildings and mobile networks antenna sites. Today, Gigabit capable Passive Optical Network (GPON) has been massively deployed. In France, for example, fiber premises (fiber subscribers of houses and buildings) increased from 14.5 million in 2019 to 16.4 million in 2021, with approximately 37 million total premises (fiber and other subscribers) passed [1]. The Fiber to the Home (FTTH) infrastructure investment for the entire Europe is estimated as 156 billion euros [2]. The first deployments of 10 Gigabit Capable Symmetrical PON (XGS-PON), which has 10 Gbps symmetric bandwidth shared between 32 to 64 customers also started for residential services (e.g. FTTH). The next generations of Passive Optical Network (PON) studied by standardization organisms target 50 Gbps per wavelength, and research studies focus already on 100 Gbps and beyond. Slightly different technologies are used for companies and antenna sites. Today, a regular bidirectional fiber that provides the symmetric 10 Gbps bit rate is used for these connections.

With the ever-increasing fiber capacity demands for residential access networks and the massive deployment of FTTH, researchers and operators start to consider the use or reuse of residential fiber technologies and infrastructure to support mobile services for 5G and beyond in order to reduce Capital Expenditures (CapEx) and Operational Expenditures (OpEx).

Operators are facing strong financial challenges, particularly when the networks count millions of terminals. This requires operators to rethink the management of their networks while avoiding vendor lock-in. Moreover, the wide-scale deployment of both fixed and mobile networks enables different degrees of convergence with active or passive infrastructure. Adaptations are needed to the management layers so that convergence can be effectively enabled. In this context, virtualization technologies, which have been well developed in recent years, are considered as enabling solutions. These virtualization technologies, first applied in data centers, have been rapidly introduced in access networks. Two key concepts of virtualization technologies are studied in this manuscript: Software Defined Networking (SDN) and Network functions virtualization (NFV). SDN decouples the control plane from the data plane (both embedded in traditional network equipment). It centralizes all information from the control layer inside an application running within the SDN controller, which is usually deployed on a remote server. NFV deploys the network functions that were implemented in dedicated hardware on generic servers. Virtualized network functions can be both control plane or data plane functions. SDN and NFV are highly related but independent of each other. Standardization bodies such as Open Networking Foundation (ONF) and BroadBand Forum (BBF) adopt the concepts, and proposed different projects in the field of optical access network to build an agile, interoperable and easily automated network with SDN and NFV technologies. Typically, the SDN Enabled Broadband Access (SEBA) from ONF and the Cloud Central Office (CloudCO) from BBF.

Thesis Context and Objectives

With the two tendencies from ONF and BBF in infrastructure and management layers of optical access networks that we have discussed above, a Conventions Industrielles de Formation par la Recherche [fr] (CIFRE) thesis was proposed, between the French operator Orange (Lannion, France) and IMT Atlantique University (Brest, France), co-financed by Association Nationale de la Recherche et de la Technologie [fr] (ANRT) in 2019. The subject of this thesis is to study the opportunities offered by virtualization technologies (SDN/NFV) in optical access networks and especially the fixed-mobile convergence paradigms for future mobile generations.

The study of converged fixed and mobile access networks in Orange was begun before this thesis. Related work [5] from the thesis entitled Integration and Supervision of Fronthaul Links in 5G Networks (2017) [6] evaluated Ethernet-based solutions with GPON for fronthaul links. The last work published in [8,7] included in the thesis manuscript entitled Optical Access Solutions in Line with Radio Access Network Interfaces (2021) [START_REF] Anas | Study of Optical Access Solutions in Line with Radio Access Network Interfaces[END_REF] introduced XGS-PON for mobile optical transport solutions and the Point-to-Multi-Point (PtMP) fiber infrastructure for 5G small cell usecases.

In this thesis, several problems are specifically addressed including the increase of fixed access network availability, the decrease of latency and jitter impact for future mobile services and the implementation of 5G slicing in optical access transport networks. We assess the advantages of the replacement of legacy Optical Line Terminal (OLT) with disaggregated and virtualized OLT, and build prototype SDN solutions as experimental test beds for fixed and mobile convergence scenarios. Based on the problems mentioned above, our contributions are organized in this manuscript following the three objectives presented in the next list.

• Reduce the impact of optical access networks on latency and jitter for 5G time-sensitive services, using virtualization technologies.

• Increase the reliability of mobile access networks with the help of virtualization technologies to meet 5G services requirement. Propose and compare different fixed-mobile converged architectural approaches in terms of cost and energy consumption.

• Identify the key elements to enable 5G slicing in optical access transport networks using concepts from SDN and NFV.

This thesis was carried out in the context of the European research projects 5G-COMPLETE (call H2020-ICT-2019) and MARSAL (call H2020-ICT-52). 5G-COMPLETE was launched in 2019 with the objective of revolutionizing the 5G architecture by efficiently combining the functionality of compute and storage resources over ultrahigh capacity Radio Access Network (RAN). At the end of the 5G-COMPLETE project, a lab trial will take place in Orange Innovation, Lannion, at the end of 2022.

MARSAL was launched in 2020 after the beginning of this thesis with the aim of ensuring end-to-end performance analysis and optimization for varying 5G and 6G services. This thesis is included in MARSAL with a focus on disaggregated architectures, SDN control plane towards fixed-mobile convergence use cases and the edge computing paradigm.

Manuscript Organization

The manuscript is structured into two parts. For each part, four chapters are included, in addition to this introduction and the conclusion chapters. The first part presents a state-ofthe-art of access networks, both fixed and mobile. We also discuss the limitation of today's fixed networks for antenna sites to support future requirements of 5G and beyond. As virtualization technologies are attracting increasing attention from operators facing future challenges, a panorama of SDN and NFV is given. Finally, we analyze the fixed and mobile convergence efforts and challenges in access networks.

This thesis manuscript covers different aspects, from the physical layer to control and management layers of elements from fixed and mobile networks. Thus, we precisely describe all elements of our test bed in Chapter 5 before assessing the actual contributions of this thesis.

In Chapter 6, we present two new architectures of OLT with the associated SDN controller with each of them. The first contribution in this chapter reveals the capability of dynamic control for access nodes with a disaggregated architecture and SDN controller. The second contribution shows the opportunity brought about by generic servers in access networks for mobile edge functions.

In Chapter 7, we focus on 5G availability requirements. The fixed access network transports mobile services from Central Office (CO) to antenna sites. The problem in access networks today is that there is no redundant optical link for antenna sites and the high availability of some mobile services cannot be ensured. We propose different redundancy architectures reusing or not the deployed fiber infrastructure. We dynamically adapt Quality of Service (QoS) in the case of residential and mobile services sharing the fiber infrastructure thanks to our SDN controller.

We continue on 5G requirements in Chapter 8, specifically on 5G network slicing realization in optical access networks with a converged fixed-mobile infrastructure. The network slicing achieves an End-to-End (E2E) resource reservation for different mobile services' QoS requirements. We analyze the standardization activities on the management layer between 3rd Generation Partnership Project (3GPP) and other transport networks. It shows that in an SDN-based architecture, the cooperation management interface between mobile and fixed access networks is not clearly defined today, while this interface is the key enabler for 5G slicing. We propose and realize a solution with an interface between the mobile and fixed SDN controllers for dynamic reconfiguration. We evaluate the performance of some QoS parameters in a fixed access network for time-critical slices.

Part I Technological Context and Scientific

Challenges in Access Networks

7

Chapter 1

Access Network Architectures

Today, the Internet completely changes the daily life of everyone. Self-driving cars and automated industrial robots are going out of science fiction and reaching a new mile-stone in real life with 5G and 6G. All digital applications need a solid network infrastructure. From copper to fiber, from bit per second to giga-or tera-bits per second, telecommunication operators have experienced many evolution waves in this century and it will continue in the future. Access networks is the last segment of the network that provides high-density connections for all end users. In these last kilometers, both wireline and wireless connections are used. The complexity of the access network is to correctly distribute digital signals to each customer with cost-efficient solutions. Meanwhile, the charming part of access network studies is also finding these solutions. In this chapter, we start by describing the current infrastructure architecture of the optical access network of residential and mobile services, based on the current state of Orange in France.

The notion of access networks comes from the hierarchical inter-networking model that was first proposed by Cisco [START_REF]Campus Network for High Availability Design Guide -Cisco[END_REF] and is widely used to describe the architecture of today's telecommunication network [START_REF] Eido | How much LTE traffic can be offloaded?[END_REF]. Three network segments are given as core, metro and access networks shown in Figure 1.1).

• The core network (also called a backbone network) transfers numerous services (i.e. Internet content, telephone traffic, routing different packets from one sub-network to another, etc.) with high-speed and redundant connections for different metro networks. As indicated inside the blue-dashed square in Figure 1.1, the typical distance for the core networks is between 1500 km and 2500 km. This distance is between major cities and sometimes cross over two countries. To date, industrial core servers provide a switching capacity of 80 Tbps per chassis with 100 Gbps and 400 Gbps ports [START_REF] Ne | Series Converged Core Router[END_REF]. To achieve high redundancy, the mesh topology is applied to the core network, each network device being connected to other devices in such topology to dramatically reduce the take-down risk.

• Metro (transport) network distributes the traffic of the core networks to the access networks and aggregates the traffic of the access networks to the core network. This is also why the metro network is sometimes called the distribution network or the aggregation network. The typical distance for metro network connection is between 50 km and 1000 km. Ring topology is often used here to ensure some redundancy without large CapEx and OpEx compared to mesh solutions.

• Access network is also called the "last kilometer (mile)" to connect all mobile or fixed end-customers. As indicated within black-dashed square in Figure 1.1, access networks have various types of customers (e.g., individual and enterprise, private and public, residential and mobile). Depending on the density of clients and the service requirements, different fixed topologies are used in access networks. Due to the complexity mentioned above, adaptive technology to satisfy bitrate, latency, jitter etc. requirements from all customers and powerful management to configure the different QoS must be chosen carefully by operators. Moreover, for the massive fiber deployments in the last ten to twenty kilometers, a trade-off exists between the performance and cost from the operators' point of view.

This thesis focuses more generally on the development of fixed access networks and more particularly on the advantages brought about by the introduction of virtualization on both infrastructure and management layers.

Optical Access Network's Architecture

Copper lines were used in access networks before optical fibers. The term x Digital Subscriber Line (xDSL) describes different Digital Subscriber Line (DSL) technologies that use copper and coaxial networks such as Asymmetric Digital Subscriber Line (ADSL), Very-High-bitrate Digital Subscriber Line (VDSL) and so on. According to DSL technologies, the bit rate and the propagation distance are different. Generally, copper and coaxial material have higher cost and less performance compared to optical fiber [START_REF]From copper to fibre: the evolution of fixed networks[END_REF]. Consequently, optical fiber is gradually replacing copper lines in all segments of the network, including access networks. As indicated in Figure 1.2, optical access networks start with an OLT inside a CO (a technical facility for the operator) and end with Optical Network Units (ONUs) in houses, buildings or at antenna sites. Depending on the type of service, we separate RAN mobile wireless connections (green-colored zone) and Fixed Access Network (FAN) (blue-colored zone) for FTTH or building connections. We precise in Figure 1.2 downstream and upstream traffic according to end users: the traffic received by final users is downstream traffic and the traffic emit by final users is upstream traffic. We notice that different fiber topologies are used in fixed and radio access networks, so an explication of the Point-to-Point (PtP) / PtMP passive fiber topology will be given first. We explain technically the evolution of PON and OLT functions in the following sections together with the current deployment status of FTTH and to help readers have a global understanding of today's fixed access networks.

Point-to-Point and Point-to-Multipoint Topologies

As shown in Figure 1.2, two passive fiber topologies (PtP and PtMP) are used to provide fiber connection from OLT to different terminals (antenna sites, buildings, houses, etc.).

• PtP means that for each fiber from one port of OLT is connected to only one device on the other side. This final device could be a Cell Site Gateway (CSG) for mobile antenna sites or a PtP ONU for building/house.

• PtMP means that a fiber from one port of OLT is optically and passively separated into multiple fibers by optical splitting and each fiber after the optical splitter is connected to a terminal called an ONU. The Time Division Multiplexing (TDM)/Time Division Multiple Access (TDMA) from PON technologies are used for this specific PtMP architecture to ensure packet transmission without packet collision.

Independently of the type of client or service, the optical access network is a necessary segment to reach the end customers. The PtMP deployment is more CapEx profitable than PtP, but is less efficient for upstream performance due to the sharing of the dark fiber. The next sections concern PON technologies and OLT functionalities. We explain the operation mode of PON upstream / downstream and the role of OLT in PON.

Evolution and Standard of PONs

As presented in Figure 1.3, a PON is composed of an OLT, some ONUs and an Optical Distribution Network (ODN). The OLT is located in the CO, some technical details about the OLT chassis and its functional blocks will be explained in Section 1.1.4. ONU is the active equipment placed on the client side. The ODN is the passive fiber infrastructure with optical splitters (see PtMP in Section 1.1.1).

The PON technologies are based on widely used standards, proposed by two international organizations: the International Telecommunication Union (ITU) and the Institute of Electrical and Electronics Engineers (IEEE). York and today has more than 409,000 members. It is well known for its scientific publications, conferences and technology standards. As we know that Ethernet is standardized by IEEE, we are not surprised to learn that IEEE also provides PON standards based on Ethernet protocols from the Ethernet Working Group (802.3). The related standard documents are named "802.3XX".

The main PON standards from ITU and IEEE are summarized in Figure 1.4 on a timeline from the year 2000 to today. As listed in Figure 1.4, GPON, 10 Gigabit Capable PON (XG-PON), XGS-PON, Next-Generation PON 2 (NG-PON2) and Higher Speed PON (HS-PON) have been standardized by ITU for an average of five years between each end of each technology's standard drafting, while Ethernet Passive Optical Network (EPON), 10 Gigabit Ethernet PON (10G-EPON) and Next-Generation Ethernet PON (NG-EPON) have been standardized by IEEE for an average of ten years. In addition to the standardized PONs, a non-standardized 25 Gigabit Symmetric PON (25-GSPON) was defined by MSA with 17 members including AT&T, Nokia to provide a cost-effective and timely network upgrade path of PON [14]. However, according to the recent market forecast in [START_REF]lightcounting april 2022 market forecast[END_REF], 50G PON is a clear winner versus 25G starting from 2018.

Generally speaking, each generation of PON targets a higher bandwidth with a minimum multiple factor of 4 compared to the previous generation. When the bandwidth is greater than 10 Gbps, both ITU and IEEE start to introduce Time Wavelength Division Multiplexing (TWDM) technology in PON standard. In TWDM, wavelengths become an option in addition to time to achieve the desired bandwidth. The GPON and EPON families proposed by ITU and IEEE are not compatible with each other. Since Ethernet is standardized by IEEE, IEEE continues the usage of Ethernet in PON, however, GPON encapsulates Ethernet traffic into frame GPON Encapsulation Mode (GEM) to better adapt PtMP. GEM frame is the data frame used in GPON. The difference of the two types of frame forces operators to make their choice of technology before deploying the system. The reason for choosing the GPON or EPON family for each operator could be different and not limited to technology or income efficiency. In France, only the operator called Free has chosen EPON technology [START_REF]Fibre Free[END_REF], while other operators, such as Orange, have chosen GPON technology for the deployment of FTTH.

Key Numbers of Worldwide FTTH and the Current Deployment in France by Orange

Based on IDATE analysis [1] and Orange statistics [START_REF] Orange | [END_REF], we analyze some key numbers of FTTH networks' deployment in the world and particularly in France.

The number of worldwide subscribers and homes passed/households from 2014 to today and the forecast until 2025 are given in Figure 1.5. On a worldwide scale, there were 200 million FTTH subscribers in 2014, 700 million FTTH customers in 2022 and there will be more than 900 million by 2025 according to [1].

Other technologies exist for gigabit speeds. To date, VDSL and Data-Over-Cable Service Interface Specifications (DOCSIS) still have around 200 million subscribers. VDSL is mainly considered as a transition solution before the traditional copper infrastructure originally deployed for telephony services is converted to a fiber infrastructure. DOCSIS is mostly deployed in USA with the existing Hybrid Fiber-coaxial (HFC) infrastructure to reach gigabit speeds, but major operators are not considering keeping this option in the future, as it is less scalable and less common than the FTTH solution.

Orange is the first operator in terms of deployment of FTTH in Europe and the seventh in the world. Figure 1.5 shows the evolution of broadband Internet customers in France using xDSL and FTTH technologies, while the total number of broadband users increases by 1% per year. It is not difficult to find that FTTH is replacing xDSL in recent years more and more rapidly. With 13 million FTTH subscribers and more than 50% FTTH households in France in 2021 (see Figure 1.6 [START_REF]Ma connextion Internet -Arcep[END_REF]), the "Très Haut Débit" (THD) project driven by the French government aims to provide complete FTTH fiber coverage throughout France by 2025 [START_REF]Contre les fractures numériques, une France 100% fibre d'ici à 2025[END_REF].

Fiber deployment strategies are different from country to country. Historically, France Télécom (now Orange) was the national telecommunication operator and maintained all telecommunication infrastructure in France. In 2013, France Télécom became Orange after privatization. Today, four telecommunication operators are present in France: Orange, SFR, Bouygues Telecom and Free. According to the recommendation and decision of France's regulatory authority on telecommunications "Autorité de Régulation des Communications Electroniques, des Postes et de la distribution de la Presse" (ARCEP) [20], the last part of fiber networks should be shared by operators. Since Orange is historically the proprietary of the telecommunication infrastructure, it provides access to its network to other operators with co-financing plans. Due to the specificity of optical access networks in France compared to other countries, additional considerations are needed for infrastructure sharing and control/management sharing methods.

Figure 1.7 shows the deployment of FTTH fiber and, more generally, fixed access networks in France. The OLT chassis is placed inside a CO. We focus on the deployment of the FTTH fibers shown at the bottom of Figure 1.7, which is more complex than the PtP connections. The FTTH deployment plan is depicted from left to right: • Shared access Point (SAP), called "mutualized access point" as well, is the beginning of the shared infrastructure of FTTH by different operators. It is usually located at street level to enable connectivity to nearby neighbourhood. The SAP is accessible to all operators needing it; thus, operators can connect their own fibers coming from COs to the SAP. Optical splitters are available in SAP to provide PtMP FTTH connections.

The typical split ratio is 1:32 and 1:64 (meaning that one incoming fiber split into 32 outputs). However, 1:128 has started to be considered for future deployment in France according to the distance between OLT and ONUs and the density of customers.

• Starting from SAP, civil engineering infrastructures (e.g., fiber trenches, Optical Connection Point (OCP), etc.) are shared among telecommunication operators (i.e. Orange, Bouygues, Free, SFR in France) until OCPs. The OCP should be located near the final customers. There are two ways to deploy fibers between SAP and OCP: aerial and buried. OCPs for aerial deployment are on the top of the poles. An underground box is available for OCPs for buried deployment.

• Optical Termination Point (OTP) is the optical plug socket in houses, our ONU (e.g., Livebox for Orange) is connected to OTP with a small fiber segment.

OLT Chassis and Function Blocks

The OLT, as shown in Figure 1.2, is the last active equipment on the operator side with its chassis installed in CO. In the downlink direction, it forwards traffic from the metro network and distributes the traffic through fiber connections to antenna sites or residential/enterprise buildings and houses. In the uplink direction, it collects traffic from mobile and residential end-customers and forwards them to the metro network as well.

An OLT chassis is presented on the left of Figure 1.8 (a). It is assembled using three types of cards (sometimes we use boards or blades to designate the card in chassis as well): network card, PON line card and PtP line card. The switching capacity of several Tbps between network cards and line cards is provided by the master card on the backside of the chassis that interconnects all cards. The network cards and line cards are sometimes mentioned as Network Termination (NT) and Line Termination (LT).

• A Network card typically has 4 to 8 interfaces with 10 or 100 Gbps per interface.

Each interface connects directly to the routers of the metro networks with a PtP link.

• A PON line card typically has 8-16 interfaces per card. Each interface corresponds to a PON tree. With GPON technology, each interface supports 2,5 Gbps in downstream and 1,25 Gbps in upstream. PON line cards are installed for FTTH residential connections.

• A PtP line card typically has 8 to 16 interfaces per card. Today, the typical capacity of each PtP interface is 10 Gbps and it serves mobile and enterprise connections.

On the right side of Figure 1.8, the functional blocks of OLTs are presented according to ITU standard document [START_REF]Gigabit-capable passive optical networks (G-PON): Transmission convergence layer specification Amendment 1[END_REF]. We identify three entities:

• The Service shell includes service functions inside the network card in Figure 1.8.

A service shell provides translation between the Service Node Interface (SNI) and the PON core shell. Taking the Ethernet frame as an example of a data service for SNI, the data of the Ethernet packet in the downstream is mapped into the GEM payload.

The header information is automatically on the GEM payload to construct a GEM frame for PON.

• Cross-connect shell ensures the internal communication path between the service shell and the PON core shell. The links between these two shells are called backplane links.

• PON core shell (also called LT) includes different line cards as indicated in Figure 1.8. It includes PON Transmission Convergence (TC) functions and ODN interface functions. The three layers of PON protocol stacks that include PON TC and ODN interface functions will be introduced in the next part. Generally, TC layer of PON encapsulates Ethernet frames for transmission of the GPON segment. ITU-T precises the functions in PON TC as follows [START_REF]Gigabit-capable passive optical networks (G-PON): Transmission convergence layer specification Amendment 1[END_REF]: framing, Operations, Administration and Maintenance (OAM), Medium Access Control (MAC), Dynamic Bandwidth Allocation (DBA), the delineation of Protocol Data Unit (PDU) and ONU management functions.

On the other side of PON, the functional blocks inside ONUs are similar to those inside OLTs. However, ONU does not have a cross-connect function, since only one ODN interface is connected to the PON port of OLT.

PON protocol has its stack as shown in Figure 1.9. According to the ITU-T XGS-PON standard [START_REF]10-Gigabit-capable symmetric passive optical network (XGS-PON)[END_REF], the protocol reference model is divided into three layers: Service Data Unit (SDU) layer, TC layer and Physical Medium Dependent (PMD) layer.

The PMD layer takes care of a set of physical layer parameters to correctly emit and detect signals for different fiber distances. An electrical/optical adaptation is done at this level as well. The TC layer is placed between the Poll Mode Driver (PMD) layer and the SDU layer. Inside the TC layer, three sublayers are listed: physical adaptation layer, framing layer and service adaptation layer. Figure 1.9: PON protocol stacks in three layers: SDU layer, TC layer and PMD layer [START_REF]10-Gigabit-capable symmetric passive optical network (XGS-PON)[END_REF] • The physical adaptation sublayer modifies the bit stream modulation to optical transmitter and improves the detection/reception and other physical layer requirements by adding Forward Error Correction (FEC) data and synchronization headers.

• The framing sublayer takes care of the construction and parsing of the traffic headers and interfaces with the service layer. The frame/burst is composed of three fields: Physical Layer Operation, Administration and Maintenance (PLOAM) field, DBA field and GEM payload. The PLOAM field message is delivered by PLOAM processor for ONU activation and registration, encryption key information, power management etc. The DBA control is processed in this sublayer to program the upstream burst for every 125 µs. The GEM payload that includes user data comes from the GEM engine of the upper layer.

• The service adaptation sublayer receives/sends GEM frame encapsulation from/to framing sublayer. The GEM frame is built based on user data and ONU Management and Control Interface (OMCI) information from the upper layer. An XGSPON Encapsulation Mode (XGEM) port identity is assigned at this level for each frame to distinguish different services, GEM is the smallest connection entity of XGS-PON system.

SDU layer includes the user data client and the OMCI client. OMCI is the protocol inside a GEM connection. The OMCI messages discover ONUs, collect ONU statistics and detects alerts.

The OLT is responsible for traffic management of PON terminations, namely the ONUs (see Section 1.1.2), in the sense that it is the only network equipment having an overall view of the access network. Therefore, OLT has the role of a master, while ONUs behave as slaves. This manipulation is performed by OMCI which is mentioned above. The procedure is carried out by granting upstream traffic with different priority of access to the feeder fiber thanks to the DBA function. DBA is the time-critical function and impacts directly the uplink performance in a PON system. In Section 1.1.5, we explain the mechanism of TDM/TDMA PON downstream/upstream and how DBA with its related parameter Transmission Container (T-CONT) works.

DBA and T-CONT Scheduling parameters in PON

As mentioned in 1.1.2, the PON technologies deployed (or to be deployed) by Orange are GPON and XGS-PON. Shown in Figure 1.4, most of the deployed PON (i.e. EPON, GPON, 10G-EPON, XGS-PON) employ TDM, meaning that resources are shared between ONU only in time and the same wavelength is used for each transmission direction by all FTTH users. Thus, TDMA are applied in this passive PtMP topology in upstream to correctly share the transmission channel in time.

In Figure 1.10, the principles of TDM and TDMA (downlink and uplink, respectively) for the PON system are demonstrated with three ONUs connected to one PON port at the side of OLT. The following list explains the procedures of TDM and TDMA in PON, respectively.

• TDM solution is used for PON in downlink as shown in Figure 1.10 (a). Different downlink frames (colored blocks 1, 2 and 3) from metro networks are separated in time by OLT before being transmitted through ODN. Since the optical splitter is purely passive, the signal on each output "branch" of the splitter is a replica of all frames with a certain level of optical power decrease because of splitter ratio and fiber attenuation. In this way, the downlink messages for all ONUs are distributed to each branch of ONU. To ensure data security among ONUs from the same ODN, the content of each PON frame is encrypted but not the header. As shown in Figure 1.10(a), each ONU can only decipher the message that belongs to itself according to the header indication.

• TDMA is used for the uplink to avoid packet collision in PON. The packet collision occurs when the messages transmit by several ONUs arrive at splitter at the same time. A bandwidth allocation should be organized to avoid such a problem; moreover, since each ONU does not permanently transmit the message, a dynamic bandwidth allocation can be made for the uplink bandwidth to improve the bandwidth efficiency of PON.

DBA is a dynamic bandwidth control function within OLT for the PON optical access networks to avoid upstream data collision. There are two DBA working modes to allocate bandwidth to ONUs [START_REF]A broadband optical access system with increased service capability using dynamic bandwidth assignment[END_REF]. In Non Status Reporting (NSR) mode, OLT predicts the bandwidth needed according to the previous frames received [START_REF] Thangappan | Review of Dynamic Bandwidth Allocation in GPON[END_REF]. The NSR mode can possibly reduce the latency by eliminating the exchange message between OLT and ONU, however NSR hardly allocates the exact bandwidth needed. In Status Reporting (SR) mode, OLT takes knowledge of the bandwidth demand sent by ONU based on the waiting queue within ONU. Based on the QoS request for each frame, the DBA procedure draws a Bandwidth Map (BWmap) that includes all emission time slots for each ONU with a time-synchronization header in a downstream frame. According to this BWmap, ONUs emit their bursts only during the allocated time period. We can find different GEM frames that present different services from ONU in the bursts. Each PON upstream has a typical cycle of 125 µs, so that bursts are generally of a few microseconds, while the cycle duration can increase to a multiple. As shown in Figure 1.10 (b), yellow, purple and green colored bursts are received by OLT in order without packet collision thanks to the BWmap generated by DBA algorithm.

It is important to note that, since each ONU is located at different distances from OLT, a ranging procedure is needed to measure the round-trip delay between OLT and ONUs to align the upstream emission time of each ONU.

As mentioned above, DBA does not only care about the organization of emission time for ONUs, but also takes into consideration the priority level of services of ONUs before distributing BWmap. The T-CONT is an input QoS parameter of the DBA function. Each T-CONT may contain one or more XGEM entities by one ONU and different T-CONT support different QoS for attached services. Based on the T-CONT choice of each flow and the available bandwidth, the BWmap is generated for the ONUs. Five T-CONT types are defined for different QoS demands with bandwidth type configuration shown in Table 1.1.

Bandwidth Type Type 1 Type 2 Type 3 Type 4 Type 5

Fixed X X Assured X X X Non-assured X X Best effort X X Max X X X
Table 1.1: The five T-CONT types with associated bandwidth configuration [START_REF] Anas | Study of Optical Access Solutions in Line with Radio Access Network Interfaces[END_REF].

Each T-CONT is made of one or several bandwidth types. There are five bandwidth types:

• The "fixed" type permanently reserves a certain bandwidth per burst for ONU even if there is no transmission traffic (thus sending padding data). This type is the most bandwidth-hungry one, since the bandwidth resource cannot be released to other ONUs even if it is not used, meanwhile, the maximum bit rate cannot exceed the "fixed" value unless other bandwidth types are configured. However, it is useful for QoS sensitive services in terms of latency and jitter.

• The "assured" type can provide sufficient bandwidth when ONU requires it. Different from "fixed", "assured" bandwidth is released once there is no traffic sent.

• The "non-assured" and "best effort" have a similar principle, with the "non-assured" traffic having a higher priority than the "best effort" type. Both offer ONU the bandwidth requested if it is not used by "fixed" and "assured".

• The "max" is the upper bandwidth limit to distribute for the service.

If we order the priorities of bandwidth types from higest priority to lowest priority, the order is "fixed", "assured", "non-assured" and "best effort". Sometimes, we use "Guaranteed" to describe "fixed" and "assured" types, "additional" to mention "non-assured" and "best effort" types [START_REF] Wang | DBA (Dynamic Bandwidth Allocation) Overview[END_REF].

Mobile Network and Radio Access Network

As introduced in Section 1.1, in parallel to fixed access networks for residential or enterprise customers, RAN serves final mobile users. Although the final users of the mobile network benefit from wireless connectivity, antenna sites covering the territory are usually connected to the network with the help of optical fibers. Then, a segment of the optical access network is present in RANs, for transport purpose. The active equipment is usually deployed at the antenna site, while the recent evolutions of RAN starts to revisit the position of active units. As we will explain, the analog radio signal emitted by a user equipment (e.g. smartphone) and received by the antenna is deeply processed before being transmitted to the mobile core network. Business opportunities drive to split functions that operate analog-digital processing into different equipment. As a result, new optical network segments appeared to connect the different parts. Those optical network segments, referenced as x-haul (back/mid/fronthaul) have different requirements in terms of reach, latency, or throughput as we will show.

Here, we start by introducing the evolution of RAN in Section 1.2.1 to understand the different motivations of implementation of RAN. We then detail the current state of 4G and 5G deployment in Section 1.2.4. As we know, the 5G deployment today is still in an initial phase, to finally support time-sensitive services such as self-driving car, 5G slicing and edge computing are two important solutions to apply. Therefore, we explain the concepts of these two notions and discuss the impact on the optical access network segment in Section 1.2.3. We analyze some 6G Key Performance Indicator (KPI) at the end of this chapter for perspectives.

RAN Evolution: From D-RAN to C-RAN and v-RAN

Historically, RAN for mobile networks and PON for FTTH were deployed separately; OLT which includes PtP cards to transport the mobile access transport network has only been deployed very recently. However, PtP fiber is only the transport medium for the connectivity of mobile sites in access networks. The mobile network's signal goes through this fiber segment to reach the antenna sites. Once emited, it propagates in the air and eventually reaches the User Equipments (UEs) (e.g. our mobile phones).

Mobile data plane frames of the core network are based on Internet Protocol (IP) and encapsulated by General Packet Radio Service Tunnelling Protocol (GTP) (see Chapter 5). When traffic arrives at access networks, there is a translation between wireline signals and wireless signals. Taking downlink direction as an example (see in Figure 1.11), digital IPbased frames from the core network should be "re-encapsulated" with radio protocols and translated to analog radio signals before propagating to UEs.

Similarly to the protocol stack in PON, RAN also has its protocol stack to realize the "reencapsulation" procedure mentioned above. Without going into the details of each protocol layer, Figure 1.11 shows the simplified version of the RAN stack inside Evolved Node B (eNode B) for 4G mobile network. The mobile core used in 4G is called the Evolved Packet Core (EPC) and all core/metro/access transport networks are noted as Transport Networks (TNs) in Figure 1.11.

The basic RAN architecture is shown in Figure 1.11. In this case, the Layer-1, Layer-2 and Layer-3 (L1-L2-L3) protocols are processed in the so-called eNode B, also called the base station. The configuration where all functions are collocated at the antenna site is then called the single block Distributed Radio Access Network (D-RAN) [START_REF] Luiz | Optical networks for mobile connectivity[END_REF]. A coaxial link (typical 100 m) is used between the eNode B and the frequency multiplexer (to transform the analog baseband signal to radio frequency) on the top of the antenna sites. Starting from the unit that runs the RAN process (eNode B in Figure 1.11), the link to EPC is called the backhaul and the link to the antenna sites is called the fronthaul.

Due to the large attenuation of the coaxial cables in the fronthaul link, an electrical amplifier is often added to ensure the received signal power. With an optical fiber, less attenuation and more bandwidth can be realized compared to the coaxial cable. Therefore, the coaxial cable is usually replaced by an optical fiber. As optical fiber transmissions usually employ digital transmitters, the baseband analog signal emitted by (or received from) the antenna is digitized, usually using the Non Return to Zero (NRZ) modulation format (a type of binary signal coding). It also reduces the signal error introduced by physical transmission.

By doing so, it is possible to split the functionnality of the protocol layers. An option of functional split is applied between the L1 and other layers: a part of the L1 (physical layer) process that transforms the digital signal to an analog signal needs to be placed at the top of antenna sites. Functional splits were widely studied for 4G and 5G. A detailed description will be given in the following paragraphs. As indicated in Figure 1.12 (a), the dual-block D-RAN is created. In the dual-block D-RAN case, the eNode B is separated into two units, BaseBand Unit (BBU) and Remote Radio Head (RRH), with the RRH at the top of the antenna sites. Here, the interface between the BBU and the RRH is called the fronthaul. We explain the functionality of these two units in the following list.

• The BBU is the baseband signal processing unit. This unit goes through the radio protocol layers and makes signal transformation possible between the IP-based traffic coming from/to the core network and radio signals in the air to/from mobile terminals [START_REF] Chanclou | Optical fiber solution for mobile fronthaul to achieve cloud radio access network[END_REF]. It embbeds the high layers functions.

• The RRH is placed at the antenna sites. It contains electrical amplifiers, local oscillators for the transposition of baseband signals to the radio frequencies that are allocated to each operator and analog/digital converters. It embbeds the low layers functions.

The advantages in terms of high bandwidth and low attenuation of the optical fiber in fronthaul bring the possibility of centralizing several BBUs in a what is called a "BBU hotel", several kilometers away from the antenna sites. It created the concept of Centralized Radio Access Network (C-RAN), the "C" meaning in the first place "centralized", while the evolutions of RAN extended the meaning of the "C" to "cloud", as shown below. In Figure 1.12, the dual block D-RAN architecture (Figure 1.12 (a)) is changed to C-RAN (Figure 1.12 (b)) with BBU located some kilometers from the antenna site.

There are several advantages to centralizing BBUs [START_REF] Carapellese | An energy consumption comparison of different mobile backhaul and fronthaul optical access architectures[END_REF][START_REF] Pizzinat | Things You Should Know About Fronthaul[END_REF]:

• BBUs pool frees space at the antenna site and is very practical in very dense areas.

• The field intervention in the BBU pool is simpler than at each antenna sites since antenna sites can be deployed on the top of buildings that do not belongs to operators.

• Energy can be saved by using the BBU pool [START_REF] Zhu | Delay-Aware Energy-Saving Strategies for BBU Pool in C-RAN: Modeling and Optimization[END_REF].

• Furthermore, a centralized BBUs eases to manage interfaces between different sites.

• BBU pool makes it easier to secure BBU equipment.

Similarly to the principle given previously using eNode B as an example, the backhaul here is the interface between BBU and the Internet, and the fronthaul is the interface between BBU and RRH (see Figure 1.12). Different specifications are proposed to handle this digital radio over fiber in fronthaul. The most commonly used are Common Public Radio Interface (CPRI) [START_REF]Common Public Radio Interface (CPRI) Interface Specification[END_REF] and Open Base Station Architecture Initiative (OBSAI). CPRI and OBSAI simply extend the analog radio signal in digital form. They were developed by RAN providers with proprietary protocols in the first place. Thus very little interoperability exists (i.e., an RRH from a vendor cannot operate with a BBU from anothervendor, locking the operator with a limited number of vendors) [START_REF] Luiz | Optical networks for mobile connectivity[END_REF].

In addition to the limitation of CPRI, some other problem arises with fronthaul interface in the C-RAN architecture: since quantification is done in the time domain for an analog radio signal before it is transmitted in fronthaul, a very strict latency required. In other words, for each given time for an analog sample, the n bits used to digitize and this analog sample (the frame) should be sent into this time slot. This also brings strong requirements on the frame transmission: no frame can be lost (as it will cause a "hole" in the analog signal reconstructed) while the frame repetition (which may be employed if a frame is missing) must be received in time and in order.

Moreover, for CPRI, high-speed sampling frames with quantization of In-phase and Quadrature of the signal in the time domain are necessary to ensure the quality of the analog signal. According to [START_REF] Pizzinat | Things You Should Know About Fronthaul[END_REF], for 20 MHz carrier of analog radio content, the fronthaul link must provide 2,45 Gbps bandwidth from the digital signal (NRZ); the result is poor spectral efficiency. Taking the example given in [START_REF] Anas | Study of Optical Access Solutions in Line with Radio Access Network Interfaces[END_REF], different CPRI options, the maximum capacity of the CPRI interface will have to support is 12 Gbps. We can conclude that a tremendous baseband bit rate is needed for a limited payload and 5G needs even higher than the calculation done in 4G.

When operators decided to replace the coaxial cable by optical fiber, the main motivation was to benefit from the optical fiber low attenuation. However, with more services coming along with 5G (e.g. self-driving car, automated industry, VR etc.), a higher bit rate and a lower latency/jitter are needed. These requirements expose the traditional fronthaul interface with D-RAN or C-RAN, so a new architecture of RAN and new protocols for optical interfaces are studied. It should be noted that Next Generation NodeB (gNode B) in 5G is coarsely the equivalent appellation of eNode B in 4G, the base station. The functional splits that we mentioned above can also bring latency and bit rate problems. The basic idea behind functional splits is to divide the gNode B radio processes in different ways according to the latency and bit rate requirements. Eight main split options were proposed, as shown in Figure 1.13 [START_REF] Korhonen | Study on new radio access technology[END_REF]. To support functional split solutions, the RAN architecture can be separated into more than two units (BBU and RRH) as used in 4G. As shown in Figure 1.12 (c), the gNode B can be divided into three units called Centralized Unit (CU), Distributed Unit (DU) and Radio Unit (RU). An example is given with L3 and part of L2 in CU, the rest of L2 and a part of L1 in DU, and the rest of L1 in RU. Figure 1.13 details the functions for each layer and the 8 functional split options with an example of split choice for CU, DU and RU.

The specification enhanced CPRI (eCPRI) [START_REF]Common Public Radio Interface: eCPRI Interface Specification[END_REF] was worked out after CPRI (indicated in Figure 1.12 (c)) to enhance the fronthaul interface using standard protocol based on Ethernet that can better support 5G services. Unlike CPRI, RU and DU can be provided by two different vendors using standard eCPRI between them. One of the eCPRI options supports the given example with Option 7 for the fronthaul interface.The advantages of eCPRI compared to CPRI is that eCPRI makes the fronthaul a real network interface and ready for wholesale. Moreover, unlike CPRI that has a continuous bit rate regardless of traffic loading on the air interface, eCPRI can support a variable bit rate with split options before quantification of analog signals in time.

As we introduced a few pages earlier, the bit rate and latency constraints become more important as it approaches the low layer. In other words, the higher the stack of protocols RAN, the lower the latency criteria and bit rate. Meanwhile, with low-layer split, if quantification of the signal in the time domain (low PHY process) can be avoided in the fronthaul, the bit rate stress in the fronthaul link can be dramatically reduced. However, by implementing distributed low-layer functions at the antenna site, we lose some advantages of centralizing BBU or DU. Thus, there is a trade-off to find between the performance of the fronthaul and the advantages brought by centralizing RAN units, depending on the field and operators constraints (Element Management System (EMS) evolution, legacy sites, etc.).

The numerous options from functional splits affect the way of implementing the CU, DU and RU. That is, with different split options, CU, DU and RU could contain different processes depending on the vendor's choices. Dedicated CU, DU and RU units with a certain split option can be provided by different vendors; however, a flexible software implementation based on the same physical equipment can be more interesting than dedicated equipment.

With the development of virtualization technologies (NFV and SDN, through the cloud computing paradigm), virtualization became the key technology for operators to flexibly deploy different radio protocol layers as software on different generic servers (CU, DU and RU, the latter being more complex due to the low-layer protocol involved) according to service types. Virtualized Radio Access Network (v-RAN) is thus a C-RAN enabler, in the sense that it eases the deployment of splitted RAN functions. More information on virtualization technologies (especially for optical access networks) will be explained in Chapter 3.

The first effort to standardize v-RAN was made by Open-RAN Alliance (O-RAN Alliance) in 2019. In 2021, the most recent version of the document "O-RAN Cloud Architecture and Deployment Scenarios for O-RAN Virtualized RAN" was distributed [START_REF]O-RAN Cloud Architecture and Deployment Scenarios for O-RAN Virtualized RAN 2.02[END_REF]. The initiative of O-RAN Alliance is to provide recommendation for a standard cloud platform, O-RAN Cloud (O-Cloud), for virtualized and interoperable RAN. Other efforts (i.e. Open RAN [START_REF]OpenRAN-Telecom Infra Project[END_REF] by Telecom Infra Project and Open vRAN by Cisco [START_REF]vRAN -Cisco Blog[END_REF]) for an open v-RAN are detailed in [START_REF] Anas | Study of Optical Access Solutions in Line with Radio Access Network Interfaces[END_REF]. All these entities contribute to break the radio base stations into standardized modules (functional split) using virtualization technologies; however, there is a fine distinction of open RAN and v-RAN: a virtualized RAN is not necessarily an open RAN, vendors can provide its RAN components such as gNode B or CU, DU etc. without aligning with the O-RAN Alliance specification for the interfaces. This remains a major challenge for the next generation of RAN because traditional mobile vendors prefer to sell the entire RAN solution, similarly to the business model about generic and legacy OLTs equipment in fixed access networks (see Chapter 1.1).

To conclude, C-RAN consists in centralizing RAN functions closer to the core, to ease field interventions, management, or improve security. This can be benefit from the socalled fronthaul link, where the copper cable is replaced by an optical link and the analog signal is transformed into digital form. However, splitting the RAN functions has a cost in terms of latency, bit rate, and spectral efficiency of the involved transmission interfaces. Thus, the choice between the different split options, stating the amoung of distributed and centralized functions, are at the discretion of operators. In this opportunity, v-RAN is proposed to better adapt different functional splitting options by providing RAN functions to be deployed on generic hardware, easing deployment. Several entities also worked on standardizing the RAN interfaces created by the splits, providing "open" RAN interfaces, any many architectural specifications. As we can see, each evolution of the RAN architecture is driven by the requirements from end-users or operators. In the next section, we point out some KPI values and the deployment status of 4G, 5G.

From 4G to 5G, a Brief Analysis

3G achieved the first mobile Internet access with a very limited bandwidth from hundreds of kps to several Mbps [START_REF] Etsi | Universal Mobile Telecommunications System (UMTS);Requirements for the UMTS Terrestrial Radio Access system (UTRA)[END_REF]. 4G provides an enhanced bandwidth compared to 3G with an average user experience bit rate of 20 Mbps.

As shown in Figure 1.14, during this thesis (2019-2022), the total 4G subscriptions in the world have reached their ceiling of around 8 billion in 2021, and started to decrease in 2022. In the same figure, starting from 2019, the commercial deployment of 5G has started, until 2021, the number of subscribers is negligible; however, with the decrease in 4G subscribers from 2022, 5G subscribers are increasing rapidly and will reach 2.5 billion (29% of total) and 24-36 GBytes monthly traffic per smartphone by 2025. According to [START_REF]Wireless network data traffic: worldwide trends and forecasts[END_REF], 5G will represent 38% of subscribers in France and 51% of traffic in 2024.

5G has started its commercial deployment in 2020 by many operators around the world, including Orange in France. Ericsson released its mobile data forecast [START_REF]Ericsson Mobility Report[END_REF], it predicts that the total traffic will be multiplied by a factor 6 and worldwide mobile data traffic will increase by 5 between 2018 and 2025. However, these predictions were made in 2018 and did not take into account COVID19 [START_REF]COVID-19[END_REF]. According to [START_REF]Cisco Annual Internet Report[END_REF][START_REF]Wireless network data traffic: worldwide trends and forecasts[END_REF][START_REF]5G subscription growth to drive APAC mobile services market during 2021-2026, forecasts GlobalData[END_REF], the growth of cellular data traffic in western Europe will be between 4.2 and 4.9 times in the period 2018-2024.

Unlike 4G that enhanced the user bit rate experience for typically a data-centric usage. 5G enlarges many unprecedented usages with mobile networks compared to 4G. The new services are grouped into three axes and are usually presented in a 5G triangle, as shown in Figure 1.15. For each triangle end point, the service characteristic and its key KPIs are given with some examples.

• Enhanced Mobile Broadband (eMBB) feature ensures a large bandwidth for a highquality experience, such as Internet streaming, gamins or immersive augmented reality • massive Machine Type Communication (mMTC) feature allows services for a large number of connected devices. mMTC services are new services in 5G. The application services can be Internet of Things (IoT) which requires a large-scale connection at a low bandwidth on the order of kbit/s.

• Ultra Reliability and Low Latency Communication (URLLC) feature requires very high communications service availability and low latency. The E2E Round Trip Time (RTT) is expected to be less than 1 ms with a reliability of 99,9999%. The URLLC services are new 5G services as well; the typical example of the URLLC application is the self-driving car and industry automation [START_REF]ETSI. Digital cellular telecommunications system (Phase 2+) (GSM);Universal Mobile Telecommunications System (UMTS);LTE;5G[END_REF].

We can see that the new features proposed by 5G improve not only bit rate performance, but also massive connection with low energy consumption and high reliability with low latency services for industries. To meet these requirements, different innovative solutions along with 5G are proposed and will be introduced in the next section.

5G Solutions for URLLC Services

As mentioned above, 5G eMBB improves bandwidth to improve user-experienced data rate, mMTC allows massive connection for IoT and URLLC requires a high reliability and low latency/jitter network to support self-driving cars, industry automation services [START_REF] Gpp | Service requirements for the 5G system[END_REF]. Our focus in this thesis is especially on URLLC services. There are different approaches to enable URLLC services with high reliability and low latency. For RAN and the optical access architecture, different functional splits in the RAN architecture can achieve different bit rates and latency constraints (see Section 1.2.1). Our contribution in Chapter 7 focuses on improving the reliability of the optical access network by providing self-healing functionality with the protection link. Here, we present two other propositions for URLLC services that are related to the implementation of the 5G core.

5G Slicing

With various 5G services, network operators need to configure their network in a new way to adapt to new requirements. By creating virtual network slices, physical layer resources can be allocated in an efficient way. In fact, E2E 5G slicing is introduced by 3GPP in [START_REF]3GPP. System architecture for the 5G System (5GS)[END_REF] to enable a flexible and efficient network. Global System for Mobile Communications Association (GSMA) defined the 5G slicing in [START_REF]E2E Network Slicing Architecture[END_REF] as "E2E multiple logical networks running on a shared physical infrastructure, capable of providing an agreed service quality".

Concretely, the 5G slicing concept can contribute in different aspects and the reduction of latency is just one of its goals:

• Realize the functions of E2E priority, policy control, security, etc.

• Enhance the performance in terms of latency, mobility, availability, bit rate, etc.

• Enable multi-tenancy scenarios.

To realize the three points mentioned above, a widely used three-layer slicing concept is defined by Next Generation Mobile Networks Alliance (NMGN) in [START_REF] Thalanany | Description of Network Slicing Concept[END_REF]. Furthermore, SDN technologies (see Chapter 3) ease the dynamic configuration on the equipment.

• The service instance layer represents the services (end-user service or business services) which are to be supported. Each service is represented by a Service Instance and provided by the network operator or by third parties.

• The network slice instance layer provides the network characteristics required by a Service Instance Layer. A Network Slice Instance can be shared by several Service Instances.

• The resource layer has physical and logical resources for network functions. In Figure 1.16, an example of two logical network slice instances is given for two UEs. When the notion of E2E is perfectly applied, the configuration should be coordinated from core, metro, access transport networks to the final UE.

The Single Network Slice Selection Assistance Information (S-NSSAI) is introduced by 3GPP to help the application of an E2E slicing in [START_REF]3GPP. System architecture for the 5G System (5GS)[END_REF]. Two parameters are included in S-NSSAI, the first is Slice/Service types (SST) which describes the expected network behavior; the second is Slice Differentiator (SD), which is optional to realize further differentiation. There are three standard SST values to present eMBB, URLLC and mMTC traffic (1, 2 and 3) respectively [START_REF] Geng | Network Slicing Architecture[END_REF]. This value is used as an identifier for all network segments for the QoS configuration. More slice/service attributes for service profiles are defined by 3GPP in [START_REF]ETSI. 5G;Management and orchestration;5G Network Resource Model (NRM);Stage 2 and stage 3[END_REF].

The QoS for network equipment is a technical term in the network layer where infrastructure equipment can be OLTs, routers, switches, mobile core network servers, or RAN. Therefore, QoS is translated as Service Level Agreement (SLA) between a service provider and a client at the service layer. With 5G slicing, we can imagine that an E2E SLA or different SLAs that covers the whole core, metro and access networks will include new aspects like latency, jitter factors for URLLC traffic.

For public mobile customers' usage, the creation of network slice instance requires the seamless cooperation of different service providers/operators. Therefore, the operator's infrastructure and management system should be able to provide the corresponding SLA according to each requirement. In this case, a powerful management system becomes necessary to coordinate all network segments. In Chapter 4, the challenge of converged fixed and mobile networks, especially on access networks will be presented. Chapter 8 discusses the impact of 5G slicing on the access network and how to proceed with the optimized access transport configuration using the SDN architecture.

5G slicing enables an E2E logical tunnel from core to UE for mobile services with different priorities. Another way to reduce latency, jitter and increase reliability is to reduce the distance from UE to mobile services. In this case, some core functions of 5G need to be deployed on the edge to coordinate the data plane path of mobile traffic and we will explain this idea in the next part.

Cloud Computing, Edge Computing, MEC and UPF

Cloud computing, also called "on-demand computing", is the delivery of network services (including servers, storage, databases, networking, software etc.) in a flexible way over the Internet. With cloud computing, the data center is usually powered by virtualization technologies in order to have easy provisioning and automation management on generic servers. A cloud can be private or public. A public cloud provides Information Technology (IT) services to all people and the private cloud can only be used by a group of people. Whereas the private cloud is often associated with a private Data Network (DN) and this typical architecture is usually first deployed on the industry campus.

Edge computing is oriented for time-sensitive services. The DNs for edge computing are often situated very close to final customers in metro/access networks. European Telecommunications Standards Institute (ETSI) defines edge computing as an evolution of cloud computing that brings application hosting from centralized data centers down to the network edge, closer to consumers and the data generated by applications [START_REF] Sami | MEC in 5G networks[END_REF].

Mobile Edge Computing (MEC) was inspired by edge computing for time-sensitive mobile services. It was initiated and standardized by Industry Specification Group (ISG) within ETSI in 2015 to provide IT services and cloud computing capabilities at the edge of mobile networks [START_REF] Chao | Mobile Edge Computing A key technology towards 5G[END_REF].Eventually, the "M" inside MEC has evolved from "Mobile" to "Multiaccess" as the barrier between the fixed and mobile access networks is removing little by little (see Chapter 4). Multi-Access Edge Computing (MEC) enables different scenarios such as: intelligent video acceleration service, augmented reality service, connected vehicles, assistance for intensive computation, etc. [START_REF] Sami | Mobile-Edge Computing (MEC); Service Scenarios[END_REF]. These service scenarios are accompanied by Proof-of-Concept (PoC) organized by ETSI for further specification and implementation procedures.

Some research work is focused on the subject MEC. Based on the MEC architecture proposed by ETSI, a PoC of MEC and a 5G core in Virtual Machines (VMs) are shown in [START_REF] Kherani | Development of MEC system for indigenous 5G Test-Bed[END_REF]. The other paper [START_REF] Slamnik-Kriještorac | Multi-domain MEC orchestration platform for enhanced Back Situation Awareness[END_REF] focuses on MEC/NFV orchestration development. They realized an orchestrated MEC platform based on Docker and Kubernetes. A pre-commercial implementation of MEC is announced in [START_REF] Mu | The 5G MEC Applications in Smart Manufacturing[END_REF], the performance of application is measured in a real industrial environment. An average RTT of about 10 ms and a jitter of 2 ms are achieved. Optimization of the implementation and position of edge servers to support MEC services is important to reduce cost and energy consumption. A low-cost MEC server placement study with a proposed algorithm is given in [START_REF] Lee | Low Cost MEC Server Placement and Association in 5G Networks[END_REF].

To benefit from MEC in 5G, some core functions need to be implemented on the edge as well, otherwise, UEs cannot correctly select DNs on the edge. Therefore, it is necessary to explain User Plane Function (UPF) and other related core functions of 5G.

The 5G core architecture is given in [START_REF]3GPP. System architecture for the 5G System (5GS)[END_REF] by 3GPP. Here, we focus on some core functions to explain the 5G core system. The user plane and the control plane are separated in Figure 1.17 and the 5G core functions are highlighted in orange. To facilitate comprehension, only the functions that concern our work are listed with a comparison with 4G EPC related functions.

• UPF is the only 5G core data plane function. We could describe it as the data plane gateway to interconnect user traffic and DNs. Indeed, UPF is an evolution of Serving Figure 1.17: Simplified 5G user plane and control plane architecture based on 3GPP [START_REF]3GPP. System architecture for the 5G System (5GS)[END_REF] GateWay (S-GW) and Packet DataNetwork GateWay (P-GW) in the 4G core (EPC) [START_REF]Discover the 5G Core Network functions compared to 4G LTE[END_REF]. S-GW is the local mobility anchor in 4G, it is responsible for the routing of packets between RAN and P-GW where P-GW assigns IP to UE and performs the packet routing with QoS from S-GW to DNs. The 5G core reorganizes all functionalities from S-GW and P-GW into Session Management Function (SMF) and UPF by separating the control plane and data plane functions. This design that distinguishes the control and data planes makes it easier to adapt virtualization technologies (especially the SDN architecture. See Chapter 5) for the implementation of the 5G core in our test bed.

• Access and Mobility Management Function (AMF) is the control plane function that takes care of the UE registration and connection in 5G, the equivalent entity in 4G being the mobility management functions of the Mobility Management Entity (MME).

The AMF selects SMF for session management.

• SMF is mentioned above with UPF function that comes from 4G EPC S-GW and P-GW control plane functionalities and a part of 4G EPC MME session management. It is selected by AMF and is responsible for setting up a session for data plane transmission that is selecting UPF and creating/deleting PDU sessions. The SMF distributes IP to UEs.

• Network Slice Selection Function (NSSF) provides slice information when queried by AMF. The Network Slice Selection Assistance Information (NSSAI) includes SST and SD parameters. Three SST values are mentioned in Section 1.2.3.1. The SD is an optional parameter to differentiate the same slice users.

For each UE that communicates with a certain DN (which includes operator services, Internet access or 3rd party services), a PDU session is established between DN and UE going through UPF and with the help of other functions in the control plane (see section 5.2 PDU work flow). The PDU session is usually initialized by an UE: UE dialogs with AMF first and then AMF consults its database. According to the profile of the UE, the AMF chooses one SMF and this SMF then selects UPF.

In 5G, by moving UPF near DN, which is close to the final customers in metro/access networks, the transmission distance of the network can be reduced. It can be expected to improve the user experience with more bandwidth, less latency/jitter and data technologies. Figure 1.18 shows the two positions of UPF and DN. The red path in Figure 1.18 is the traditional data plane path with UPF in the core network with other 5G core functions. The green path in Figure 1.18 shows the mobile data path with UPF on the edge somewhere in the metro or access networks.

From 5G, business campus (with their private networks) has first started to consider more scenarios with large bandwidth and strict latency, jitter and reliability requirements when compared to the common public network. In [START_REF] Simon | MEC and Fixed Access Networks Synergies[END_REF], we discussed MEC synergies in FAN for industrial needs with virtualization technologies. According to a white paper from ZTE [START_REF] Zte | Full-Scenario UPF Deployment White Paper[END_REF], we could expect upto 100 Gbps throughput and 10-30 ms E2E latency for UPF at the edge. For the most strict cases, UPF and DN should be inside a campus, 50 Gbps throughput and ¡15 ms E2E latency are expected.

In 2020, ZTE and China Unicom completed the industry's first OLT built-in MEC live network demonstration with millisecond level latency [START_REF] Zte | ZTE and China Unicom complete the industry's first OLT built-in MEC live network verification[END_REF]. An algorithm for the optimal selection between two UPFs is proposed in [START_REF] Alevizaki | Dynamic User Plane Function Allocation in 5G Networks enabled by Optical Network Nodes[END_REF], for each attached UE to access DN or a local MEC. More Our contributions in Chapter 6 and 7 focus on the improvement of latency/jitter performance and on the improvement of reliability in access networks for future mobile technologies by implementing a UPF/MEC enabled OLT on a general server.

In conclusion, from data-based 4G to service-based 5G, we expect to support a wide range of services with access-dependent methods in 5G. However, a new generation of mobile phones appears around every 8-10 years, 5G is of course not the last generation of mobile networks. In the next section, we will analyze the research work and some expected KPIs of 6G.

Future Requirements for 6G

In the research area, 6G has officially begun its journey since the first worldwide 6G summit in 2019 in Finland [START_REF]6G Vision[END_REF]. Based on different white papers given by companies all over the world [START_REF] Orange | Orange's vision for 6G-white paper[END_REF][START_REF]White Paper 5G Evolution and 6G[END_REF][START_REF]6G Vision Samsung -The Next Hyper Connected Experience for All[END_REF][START_REF]NGMN 6G Use Cases and Analysis[END_REF], we identified three important milestones of the implementation of 6G in the telecommunication ecosystem.

• In 2025, the objective is to define 6G requirements, start standardization of 6G technology and also launch technical studies.

• In 2028, the objective is to have the first specifications and to start the evaluation phases (i.e. PoC design).

• In 2030, 6G commercialization will be available in some countries.

The Hexa-X European research project has been launched in 1st January, 2021 led by Nokia (overall lead) and Ericsson (technical manager), participated by Orange and other participants for beyond 5G and 6G studies [START_REF]Hexa-X[END_REF]. Five objectives are targeted towards 6G by Hexa-X: Foundations for an E2E system, radio performance, connecting intelligence, network evolution and expansion, and impact creation . Until now, some first research studies have been published in conferences and journals [START_REF] Uusitalo | Hexa-X The European 6G flagship project[END_REF][START_REF] Uusitalo | 6G Vision, Value, Use Cases and Technologies From European 6G Flagship Project Hexa-X[END_REF].

6G aims to improve 5G KPIs (bit rate, latency, reliability, density) and extends other new use cases such as location accuracy, mapping, environmental or body sensor data [START_REF]NGMN 6G Use Cases and Analysis[END_REF]. [START_REF] Orange | Orange's vision for 6G-white paper[END_REF][START_REF]White Paper 5G Evolution and 6G[END_REF][START_REF]6G Vision Samsung -The Next Hyper Connected Experience for All[END_REF][START_REF] Li | Gradual and smooth evolution towards 5G advanced and 6G. Technical report[END_REF][START_REF] Chih-Lin | 6G vision and requirements[END_REF]67] Moreover, besides the seamless mobile connection between the physical world and the human world, a new horizon as the digital world is also envisaged. For example, this digital world runs like a twin of the physical/human world to help us better control and predict the unforeseen.

Figure 1.19 summarizes the key KPIs of 6G compared to 5G by different actors in the telecommunications ecosystem. Generally, they expect the performance to be improved by ten to a hundred regarding bitrate, reliability and positioning (see the second column). For example, in 5G the reliability requirement is 4-6 nines for URLLC usages; however, in 4G this value is around 3-4 nines. We note that packet jitter is not provided in 5G requirements, but is mentioned in the Huawei white paper for 6G with +/-0,1 µs [67]. In addition to data rate/latency/reliability/density that are already discussed in Section 1.2.2, positioning/mobility/battery life are quantified and listed by different actors for 6G. The high-precision positioning of mobile user devices can help the accuracy of distance-based positioning systems such as full autonomously moving robots for smart factories and hospitals with centimeter precision. The cases of mobility requirements are usually related to the high speed of the transport system. According to [START_REF]6G Vision Samsung -The Next Hyper Connected Experience for All[END_REF], the exposure demands for mobile services and the requirements to maintain user security need a longer battery life and greater computing capacity for mobile devices. This point can also expand to the green aspect with the goal of optimizing maximum energy consumption.

Conclusion

With more than 700 million FTTH customers and more than 8 billion mobile subscribers today in the world, access networks continue to increase their importance to provide the connection for the last kilometers for the final customers. Driven by service requirements and other political or business demands, a new standard for PON appears every 5-10 years; however, each country and operator has its choice of PON standards (IEEE or ITU) and the deployment is not universal. Unlike the fixed access network, mobile networks evolve with a universal standard: 1G, 2G, 3G, 4G, etc. with an average of 10 years between each generation.

The development of fixed and mobile access networks is not always in phase and was developed separately until optical fiber was widely adopted as the transport medium. Equipment OLT that aggregates both residential and mobile traffic in access networks took the first step to converge these two networks. In addition, whether fixed or mobile access networks face other evolution in the near future, operators are considering other possible fixed and mobile convergence scenarios to economize deployment cost in access networks by benefiting from new technologies (e.g. cloud, virtualization).

We highlight that for different fixed and mobile generations, there is not only an architectural change but also the management systems. Moreover, in the management area, virtualization introduces the reorganization of some control/management function's implementation places. Thus, before giving more details about virtualization technologies impact on infrastructure and management layers in Chapter 3, an introduction to the current management system and its limitations becomes as important as the state-of-the-art will be given in the next chapter.

Chapter 2 Access Networks Management System

We gave an overview of the architecture of the fixed and mobile access network infrastructure in Chapter 1, however, the management plane is also important to make the data and control plane work correctly with network policies defined by operators.

This chapter provides an overall view of the management plane of fixed access networks. The idea of introducing the current management plane is to compare it with its changes in the next chapter using virtualization technologies. Section 2.1 describes the Telecommunications Management Network (TMN) model proposed by ITU that is generally applied throughout the networks by operators around the world. The implementation of the management system for each operator can be very different for historical and marketing reasons. In Section 2.2, we take an example of the current access network management architecture of Orange France to show one possibility of the deployed management system. We discuss the problems in access management to support future service requirements in Section 2.3.

Traditional Management Layer Model

The concept of TMN architecture is defined in [START_REF]Principles for a telecommunications management network[END_REF] by ITU-T with the idea of providing a general network management model. As indicated in each word, Fault, Configuration, Account, Performance, Security (FCAPS) describes the fundamental functions of network management system, thus, for every management system, the FCAPS functionalities must be satisfied.

TMN includes 5 layers, as depicted in Figure 2.1. A definition of each layer is given from the bottom to the top in the following list.

• The element corresponds to the physical element in telecommunication networks. An element can be a switch, a router, an OLT and so on.

• EMS is the element manager that only takes charge of a single element or a group of elements of similar nature in a network.

• Network Management System (NMS) manages EMSs at the network level. A network includes different elements and the connections of all elements. • Operation Support System (OSS) takes charge of different NMSs and provides a complete vision of the entire network. The NMS can be different from one vendor to another, OSS is generally owned by operators and developed to ensure the interaction between NMSs to correctly create a service.

• Bussiness Support System (BSS) is used by operators for business implementation. As mentioned in [START_REF] Simon | Optical access evolutions towards SDN and disaggregated hardware: an operator perspective[END_REF], OSS provides the following services: customers for sales, offer bundles, revenue and order management to enable the service. In brief, BSS focus on service management and OSS ensures operational management according to service requirements.

However, the implementation of the TMN model by operators for different network segments may differ from the proposed standard. In the next section, we focus on EMS /NMS for access networks, since this thesis is based on optical access networks.

Current Access Networks Management System

In fixed access networks, the PtMP infrastructure is totally different from a traditional IP network with interconnected routers/switches.

For example, Orange France does not differentiate the EMS and NMS layers in access management (see Figure 2.2) since the access network is relatively simple and OLT is considered as a layer two equipment.

Moreover, OLT vendors provide their proprietary EMS together with the OLT chassis, and some operations cannot be performed without using this EMS. The vendor lockedin EMS uses vendor-specific data models for OLT control plane configuration and software upgrades. Operators must buy the EMS and pay for some usages. Therefore, some operators, such as Orange in France, decided to develop their own FCAPS applications to minimize their dependence on vendor-provided EMS. In Figure 2.2, in parallel to OLT EMS from vendors, FCAPS applications developed by the operator are presented. These operatordeveloped applications are classified as part of their OSS (surrounded by the orange-colored block in Figure 2.2). The operator orchestrator on the top of OLT EMS and OLT FCAPS applications provides a global vision of the access nodes.

Today, the reference configuration of OLT is saved as data models in Management Information Bases (MIBs) [START_REF] Presuhn | Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)[END_REF]. The reference configuration stored in MIBs is also called the Single Source of Truth (SSoT) in information systems. Having a single reference configuration means that all configuration information saved in the data model is saved and mastered in only one place. For the architecture shown in Figure 2.2, SSoT is within each OLT noted as a reference configuration. Management systems need to interact with the OLT first to obtain configuration information and then set the new configuration if necessary.

Management applications (EMS from OLT vendors or OSS from operators) use Simple Network Management Protocol (SNMP) protocol to interact with MIB within an OLT. SNMP was created in 1993 to manage and monitor network devices over User Datagram Protocol (UDP)/IP [START_REF] Case | Simple Network Management Protocol (SNMP)[END_REF]. Indicated in Figure 2.2, the connection between the infrastructure layer and the management layer uses vendor-specific protocols such as Command-Line Interface (CLI) (a text-based user interface to interact with computer systems).

SNMP/MIB is a relatively old method used by vendors for the configuration of optical access equipment. It still works in today's networks since operators can complete proprietary MIBs data models with their needs according to different vendors. Today, SNMP also works for monitoring and troubleshooting tasks. However, very little effort has been made to standardize the MIB models and SNMP has limits (i.e. no roll-back configuration option, scaling problems) for further evolution. The RFC3535 listed in 2001 the limitations of MIBs and SNMP, which will be detailed in the next section [START_REF] Schoenwaelder | Overview of the 2002 IAB Network Management Workshop[END_REF]. The tenants of optical access networks reacted by adopting Network Configuration Protocol (NETCONF), a new protocol for control and management employing data models presented in Yet Another Next Generation (YANG).

Problems of Current Access Management and Can-

didates for Future Access Management

Limits of SNMP/MIB

The lack of standard data models and no standard interfaces increased the difficulty for operators to control a heterogeneous network. To be specific, the vendor lock-in EMS for OLTs prevents a high interoperability between different equipment and increases the cost to operators for configuration implementation. This limitation becomes more problematic for 5G slicing scenarios. As described in Section 1.2.3.1, a dynamic E2E reconfiguration needs to be done including access TN. However, the current fixed access network management system does not have a standard interface that communicates with the mobile network management system. Therefore, mobile and TN operators should make great efforts today to coordinate a configuration across all segments of the network. Moreover, agile network slice instances creation needs an automated configuration process instead of manual reconfiguration that can take hours.

In terms of protocol and data model, Internet Engineering Task Force (IETF) lists different limits related to SNMP/MIB or CLI. Here, we select some representative points mentioned in [START_REF] Schoenwaelder | Overview of the 2002 IAB Network Management Workshop[END_REF].

• SNMP has scaling problems if a large amount of data needs to be processed.

• SNMP transaction session to implement MIB must be held until the operation is completed or failed. In case of failure, no rollback action is triggered to ensure a functional service. Furthermore, the implementation of SNMP is more complex than that of CLI.

• A mapping is necessary between task-oriented requirements from operators and datacentric models (MIB). However, SNMP/MIB does not offer a trivial solution for the management side to match the data model MIB.

• It is difficult for humans to read MIB modules so that different procedures can be created to complete the same high-level task, thus reducing interoperability and increasing the cost for operators.

• CLI implementation is fast, however, due to the lack of data models, the same command could behave differently for equipment from different vendors.

• Similarly to OLT EMS, CLI is also proprietary. Automation tasks are difficult to accomplish within an heterogeneous network.

Future Requirement and Proposed Protocols

As far as the operators are concerned, future management requirements in access networks will include avoiding vendor lock-in situation and using standard interfaces and data models. As described in Section 1.2.4, advanced 5G and 6G KPIs consider a more strict and more specific network support than the current mobile network for new services. The future management system needs better monitoring performance with large amounts of data, more automated tasks for dynamic reconfiguration and more agile cooperation with other management systems using standard interfaces.

In 2011, IETF published the NETCONF standard [START_REF] Enns | RFC6241 Network Configuration Protocol (NETCONF)[END_REF] to overcome the limits of SNMP. The NETCONF compatible data model is YANG [START_REF] Bjorklund | The YANG 1.1 Data Modeling Language[END_REF], which replaces MIB in the old world. The client-server communication mode is used between equipment and management tools. NETCONF uses Remote Procedure Call (RPC) messages to facilitate this communication. In addition, NETCONF/YANG has a candidate configuration stored in parallel with the running configuration. For each configuration, the modification is first noted in the candidate data store without impacting the running configuration. If we want these modifications to have an effect on running configuration, a commit action should be done following by a check phase to see if the modification is compatible with all running configurations.

Following the trend of virtualization technologies, NETCONF/YANG has been chosen by BBF for its reference SDN architecture with numerous advantages. Meanwhile, Openflow is used by ONF for their proposed SDN architecture. More details about virtualization technologies and reference architectures in fixed optical access networks will be given in Chapter 3, so we return to the subject concerning management systems and related protocols.

Other protocols are currently proposed for management evolution at the same time as NETCONF. All these protocols allow operators to benefit from a more agile and economic control method of network equipment. Here, we briefly introduce some related protocols that are most discussed in access networks; however, other choices may exist that are not covered in the list below.

• Representational State Transfer (REST) is coming usually with the Representational

State Transfer Configuration Protocol (RESTCONF). REST is not a protocol, but an architecture style for manipulating data resources using HyperText Transfer Protocol (HTTP) Create, Read, Update, Delete (CRUD) methods. REST uses REST Application Programming Interface (API) (introduced below) as an interface. Predating the creation of RESTCONF API [START_REF] Bierman | RESTCONF Protocol[END_REF], REST includes features similar to those of RESTCONF API.

• RESTCONF was standardized in 2017 by IETF [START_REF] Bierman | RESTCONF Protocol[END_REF]. Unlike NETCONF which uses RPC for the interaction between a NETCONF client and server, RESTCONF is an HTTP-based protocol that interacts with the HTTP server. It exposes YANG models through REST API. The typical operations with data models that can be performed using RESTCONF are CRUD.

• Openflow is pushed and standardized by ONF [START_REF] Onf | OpenFlow Switch Specification[END_REF]. It was considered to be the first protocol in 2012 between SDN controllers and Openflow-enabled equipment in the SDN architecture [START_REF]Software-Defined Networking (SDN) Definition[END_REF] (see more about Openflow and SDN in Section 3 a specific control plane protocol for implementing switch-like functionalities for data plane paths. Openflow is more dedicated to forwarding traffic between the control plane and the data plane, while NETCONF/RESTCONF is generally used between the control plane and the management plane. With a very limit management aspect brought about by Openflow, the Table 2.1 does not compare Openflow with other management protocols. In Section 5.1.4, our virtualized switch implemented on a generic server uses Openflow with its controller.

• Google Remote Procedure Call (gRPC) is a telemetry protocol using RPC framework between service and client [START_REF] Google | gRPC: A high performance, open source universal RPC framework[END_REF]. gRPC uses Protocol Buffers (serializing structured data), but is also compatible with other data formats. The main interest of gRPC is the high performance in terms of bitrate and latency for interconnected services in data centers [START_REF] Ons | Programming Network Devices with gRPC and OpenConfig[END_REF]. Based on gRPC, gRPC Network Management Interface (gNMI) is created by OpenConfig to carry any tree-structured data (i.e. YANG). A disadvantage of gRPC is that its updates are dependent on Google although it is an open-source project. In some degree, it can still be considered as a vendor-lock-in product.

In conclusion, RESTCONF provides some core functionalities of NETCONF. As indicated in [START_REF] Bierman | RESTCONF Protocol[END_REF], RESTCONF is not intended to replace NETCONF, but rather to provide an HTTP interface that follows REST principles and is compatible with the NETCONF data model. In this thesis, we choose using REST and RESTCONF for PoC to simplify the development procedure. RESTCONF and gRPC have similar goal using a HTTP related mechanism. gRPC has a main advantage in performance compared to REST. Table 2.1 provides a quick summary of SNMP, NETCONF, RESTCONF and gNMI to conclude their characteristics.

As discussed in this chapter, the current management layer has its limits in addressing potential requirements from fixed and mobile services in the future. Control and management functions must adapt to the new demands and evolution that occurred in the infrastructure layer. In addition to the new management protocol given in this chapter, the whole philosophy of the management system can be redefined with the wave of virtualization. Some of the virtualization technologies make dedicated hardware be replaced by more generic hardware, and other virtualization solutions appear to help operators better deploy the data plane, control plane and management plane on their physical infrastructure.

In the next chapter, we will introduce the evolution of access networks driven by virtualization technologies for management systems, as well as architecture and hardware aspects.

Chapter 3 Reference Architectures for Virtualization Technologies in Optical Access Networks

In the last chapter, we noticed that the management protocols in the optical access network are in full evolution, as well as infrastructure layer. In this chapter, we point out other evolution in management and infrastructure driven by virtualization technologies in access networks.

In fact, ATT has initiated virtualization of network elements using SDN and NFV technologies in the last few years due to the complex and cumbersome telecommunication hardware that creates the barrier to technological evolution [START_REF]AT&T Unveils 5G Roadmap Including Trials In[END_REF].

A panorama of virtualization technologies in optical access networks is presented from the point of view of a telecommunication operator. The different protocols and architectures proposed by different organizations and research entities are analyzed and discussed. In Section 3.1, we start by introducing the history of virtualization, the definition of SDN and NFV and a panorama of the development of telecommunication operators. The topic focuses on SDN and NFV on fixed access networks in the next sections 3.2 and 3.3.

Virtualization, a Brief Introduction

The concept of virtualization came from the demand for more efficient use of physical resources. Thus, virtualization technologies increase computing efficiency by sharing computer resources. Virtualization was first proved by Robert A. Nelson and David Sayre from IBM in the 1960s and 1970s. The first time the term "Virtual machine" appeared was with the realization of the IBM M44/44X computer that simulated several virtual machines in an experimental computer system [START_REF]Virtual Machines[END_REF]. Virtualization technology has developed rapidly since the first x86 virtualization product (x86 is a set of computer architecture based on Intel microprocessors), the VMware workstation produced by VMware in 1999 [START_REF]VMware Workstation from[END_REF].

Today, the definition of virtualization is more oriented to a virtualization of the operating system on generic hardware. In this configuration, users benefit from the abstraction of computing platform without need for a knowledge of hardware utilization.

The "Cloud computing" paradigm, which focuses on the on-demand availability of computer system resources, benefits from the virtualization technologies and provides an environment for using resources for private/public/mixed entities. In our daily lifes, "Cloud computing" may refer to a remote service subscription allowing rich computer performance or storage through a low-cost terminal at home. The general definition of virtualization and cloud is as follows: virtualization is the abstraction of IT resources and cloud computing is an abstraction of high-level business services capacity for enterprise or personal usages based on virtualization.

In the industrial world, SDN and NFV are commonly used to define virtualization in a technical way. In Section 3.1.1, the definition and development of SDN and NFV will be introduced. In section 3.1.2, an analysis of virtualization technologies implemented in operator networks will be given.

SDN and NFV

In the network domain, virtualization produced two major concepts: SDN and NFV technologies. The two technologies are highly related but independent of each other.

SDN

The idea of SDN was originally proposed by Standford University to realize a centralized control system facing a security problem: the traditional network is not suitable for applying a unified security policy [START_REF] Casado | Flow-Cookies: Using Bandwidth Amplification to Defend Against DDoS Flooding Attacks[END_REF]. Since then, SDN represents a revolutionary network architectural approach to abstract network elements and provides a new way of network management. The first SDN company, Nicira, was created in 2007. Starting from Nicira Ethane project [START_REF] Casado | Ethane: Taking control of the enterprise[END_REF] (considered as pre-SDN phase), which used centralized control system for deployed switches, SDN technologies such as Openflow, Open vSwitch (OvS) and Openstack networking started their journey. In [START_REF] Casado | From ethane to SDN and beyond[END_REF], the panorama of the evolution from Ethane to SDN and beyond is given.

SDN attracted the attention of the industrial world (equipment vendors, technology providers, operators) from 2011. In 2011, ONF was founded to pursue the SDN project [START_REF]About the Open Network Foundation : Mission[END_REF]. Since then, the Openflow standard for interfacing the SDN control layer with the forwarding layer was defined by ONF. Other SDN related projects studied by ONF cover broadband, mobile, private 5G and infrastructure domains. In Section 3.2, we will precisely detail the projects that are the most relevant to this manuscript on access networks.

The definition of SDN varies slightly in different periods for different entities. Here, we list three definitions from the ONF, the industrial point of view of Cisco and the idea of researchers, respectively.

• Definition by ONF [START_REF]Software-Defined Networking definition ONF[END_REF]: "the physical separation of the network control plane from the forwarding plane where a control plane controls several devices".

• Definition by Cisco [START_REF]Software-Defined Networking definition Cisco[END_REF]: "an architecture designed to make a network more flexible and easier to manage. SDN centralizes management by abstracting the control plane from the data forwarding function in the discrete networking devices.

• Definition by the research survey [START_REF] Benzekki | Software-defined networking (SDN): a survey[END_REF]: "an approach to network management that enables dynamic, programmatically efficient network configuration in order to improve network performance and monitoring, making it more like cloud computing than traditional network management". We schematically synthesize the basic idea behind SDN in Figure 3.1 (a). Today's network equipment has both data-plane (blue-colored square) and control-plane functions (orange-colored square) for forwarding instructions inside the dedicated hardware. With SDN technologies, the control plane will be physically separated from the hardware to facilitate management tasks. As a result, a new interface emerges that connects the data and control planes, which may exploit the protocols of Table 2.1. Compared to the TMN management model shown in Figure 2.1, we could consider that the control plane functions that were originally inside the "element" layer (the equipment) are moved to the upper control and management layers (EMS, NMS etc.) and only the data plane stays in the infrastructure layer.

Actually, the SDN controller is the official name for holding the "separated" control plane and providing an abstraction layer to upper layers. We can summarize the definition of controller SDN as a software application that manages the flow control of the data plane. It provides an abstraction layer of all nodes in the data plane to improve the management of networks and the performance of applications [START_REF] Neto | SDN Controllers-A Comparative approach to Market Trends[END_REF][START_REF]What is SDN controller[END_REF]. The configuration inside the SDN controller is also the SSoT which means that the reference configuration is no longer inside the legacy equipment.

ONF [START_REF]Software-Defined Networking (SDN) Definition[END_REF] proposed a three-layer SDN architecture, shown in Figure 3.2. The SDN controller (control layer) is found between the infrastructure layer (similar to element layer in the TMN system) and the application/management layer (OSS/BSS layer in the TMN system). The Northbound Interface (NBI) and Southbound Interface (SBI) are the interfaces between the control layer with the application layer and the infrastructure layer, respectively. In this architecture, there are no "upstream" or "downstream" flows anymore, but NBI and SBI. The NBI of an element (e.g. the controller) is the interface employed to communicate Figure 3.2: Three-layer based SDN architecture based on ONF [START_REF]Software-Defined Networking (SDN) Definition[END_REF] with the higher-level component (e.g. the OSS), while the SBI is the interface employed to communicate with the lower-level component (e.g. the elements of the infrastructure level). The new standard protocols discussed in Section 2.3.2 are candidates for NBI and SBI. In Section 3.2, we will detail the choice of protocol by different organizations for inter-SDNlayer in access networks.

NFV

The journey of NFV has started officially in 2012. The ETSI white paper [4] (and the updated version [START_REF]Network Functions Virtualization[END_REF]) introduced NFV and announced the creation of Network Functions Virtualisation Industry Specification Group (NFV ISG).

NFV is defined as "a network architecture that transforms the network function of proprietary hardware devices to software and runs them on generic servers to create, deliver and manage communication services" [START_REF]Network function virtualization[END_REF]. The definition of NFV is presented schematically in Figure 3.1 (b). It is important to note that both the control plane (surrounded by orange squares) and data plane (surrounded by blue squares) functions can generally be implemented as software on generic hardware.

Based on the benefits and challenges listed by NFV [4], we list the related advantages and challenges in the following list to better understand the development path of NFV.

• NFV may reduce CapEx and power consumption using centralized servers; however, it is necessary to ensure high-performance applications compared to hardware vendors.

• NFV can reduce the maturation cycle for operators, but a smooth migration from hardware to software must be investigated. The co-existence phase and reutilization of OSS/BSS are desirable.

• NFV enables multi-version, multi-tenancy and rapid scale-up/down functionalities. However, to achieve the mentioned features, we need an advanced management system and automation implementations. SDN answers these demands.

• NFV and SDN try to build an open ecosystem that encourages individual and academic entities to participate in this evolution. Operators should remain vigilant to be able to "mix and match" hardware from different vendors without much integration costs thus avoiding the vendor lock-in situation.

Figure 3.3 shows a high-level NFV architecture proposed by ETSI. The interfaces are not precisely shown here since this thesis has no contributions in this part. However, more details are given in [START_REF]Network Functions Virtualization Architecture[END_REF]. In Figure 3.3, the three colors (light blue for the infrastructure layer, dark blue for the control/management layer and red for the application layer) used in ONF's triple layers SDN architecture (Figure 3.2) are reused to show the correspondence with ONF architecture.

• NFV Infrastructure (NFVI) includes all necessary hardware and software to provide an environment to ensure the deployment and management of Virtual Network Functions (VNFs). • VNF are implemented on NFVI that includes traditional network functions (i.e. Dynamic Host Configuration Protocol (DHCP), firewall etc.)

• NFV Management and Orchestration (MANO) is responsible for the life cycle of hardware, software and VNF resources in order to optimize deployment in terms of efficiency and cost.

There are different technologies that can be used to implement the proposed NFV architecture. For each virtualized computing entity, usually management tools are also in place. Since this thesis is not focused on the NFV infrastructure layer, we only draw a simple comparison of the main solutions, namely VMs and containers shown in Table 3.1.

In previous sections, we introduced SDN and NFV separately to help the understanding of virtualization technologies. Although they are independent, we usually find that the two technologies appear together to allow to maximize the benefits brought by virtualization.

Panorama of SDN and NFV in the World

According to [3] in 2019, telecommunication operators around the world expressed their considerations about SDN/NFV, 51 operators are involved in virtualization transformation (SDN/NFV). This number was 36 and 42 in 2016 and 2017 respectively. The market for SDN and NFV investment is projected to reach 67 billion dollars in 2025, which doubles the total investment in 2022 according to the OMDIA report in 2021 [START_REF] Gibbons | Operators Move Closer to Telco Cloud Operations with SDN/NFV[END_REF]. Figure 3.4 shows the analysis of global operator expenditure on virtualization technologies from 2019 to 2015 and the increase speed of SDN and NFV separately.

Operators target on the 5G core network and related mobile functions to be virtualized in the first step of introducing the virtualization in their networks. This explains the higher spend on NFV compared to SDN for each year in Figure 3.4. For example, CenturyLink had the objective in 2020 of 100% of core network locations virtualized and NTT DOCOMO targeted 75% of the mobile core network to be virtualized by 2020 [3]. The interconnection between data centers and enterprise services using NFV-based servers and SDN also interests operators. In 2017, ATT operator had 105 data centers deployed for VNF. Verizon has 15 data centers dedicated to virtualization usages [START_REF] Tiana | Virtualisation in telco networks: Which markets for SDN and NFV, and what perspectives with network slicing for 5G? Technical report[END_REF]. Other operators such as Orange, To date, fixed access and mobile access have the lowest virtualization implementation compared to other network segments. For access networks, the mobile base station and OLTs are essential equipment for mobile and fixed services. As discussed in Section 1.2.1, by virtualizing the some entities of RAN, mobile processing functions can be implemented in vCU, vDU and vRU with more flexibility. O-RAN Alliance initiated different 5G trials with v-RAN and this attracts the attention of many operators. The ongoing trails are driven by Verizon, Orange, China Mobile, SKT and SoftBank [START_REF] Tiana | Virtualisation in telco networks: Which markets for SDN and NFV, and what perspectives with network slicing for 5G? Technical report[END_REF].

However, a totally virtualized OLT is still in a rudimentary state and far from being deployed. To date, two organizations (ONF and BBF) have contributed to different projects to follow the evolution of access networks. We will discuss it in the next section.

Reference Projects in Optical Access Networks

ONF and BBF are two leading organizations that have introduced SDN, NFV technologies to access networks in recent years.

ONF was founded by telecommunication operators with the idea of "Open source, open hardware" for all network segments, including access networks (see Section 3.1.1). ONF proposed an SDN architecture using Openflow protocols, which was introduced in Figure 3.2. In Section 3.2.1, we will explain two ONF projects named SEBA and Virtual OLT hardware abstraction (VOLTHA) that focus on optical access networks.

Unlike the open source organization ONF founded in recent years, BBF was the traditional standards development organization for broadband networks (such as Asynchronous In parallel to R-CORD, there were Mobile CORD (M-CORD) and Entreprise CORD (E-CORD) that followed a similar objective but on other network segments. Before introducing SEBA, it is worth noting that M-CORD evolved to Converged Multi-Access and Core (COMAC) that takes charge of the convergence of the mobile and broadband access network segment with the 4G mobile core (EPC). Specifically, O-RAN Alliance controller and SEBA/VOLTHA are planned in COMAC but have not yet been developed. In Chapter 8, we will introduce a wider context on the convergence of mobile and optical access networks in management layer and introduce our proposal to realize a 5G slicing scenario. Our setup in Chapter 8 goes beyond COMAC by using a 5G mobile core.

SEBA is the broadband project that most concerns this thesis on the optical access network segment. SEBA supports virtualized access technologies including PON. As we know, OLT in CO is the key element for both residential access and wireless traffic today; thus SEBA re-architecture OLT and aggregation switches to optimize the data path on access networks. SEBA project is deployed on compute nodes, using containers (e.g., dockers) through the Kubernetes platform (indicated in Figure 3.5).

Figure 3.5 shows an introduction to the SEBA project with the reference ONF triplelayer SDN architecture line on the right (introduced in Section 3.1.1). As we can see, SEBA is between physical equipment (switch, OLT and ONUs) and legacy OSS/BSS. Compared to Figure 2.2, SEBA reorganizes FCAPS, EMS and orchestrate functionalities into projects Network Edge Mediator (NEM) and Open Network Operating System (ONOS) (yellow and pink squares in Figure 2.2). Furthermore, the philosophy of ONF (including the project SEBA) is to manage access networks as switches and disaggregate the control plane from the dedicated equipment to the SDN controller(ONOS).

VOLTHA (turquoise square in Figure 3.5) is between the ONOS SDN controller and infrastructure layer. It is optional if the physical equipment is OpenFlow enabled to communicate directly with the SDN controller. We will have a closer look at VOLTHA in the following paragraph.

VOLTHA

VOLTHA is a physical abstraction layer included in SEBA (see the detailed architecture of VOLTHA in Figure 3.6 (a)). For non Openflow-ready physical equipment, VOLTHA hides all complexity from physical nodes for the SDN controller, ONOS. ONOS considers the total access network as a switch.

The SBI of VOLTHA uses vendor-specific protocols through adapters to communicate with whitebox (the generic hardware that is open to firmware implementation from other entities) and dedicated PON hardware. VOLTHA core functions build the abstraction layer to represent infrastructure parameters as a switch node. VOLTHA exposes the PON network to ONOS as a programmable switch and the protocol used for NBI is Openflow.

As mentioned in Section 3.1.1, Openflow is the first standardized SBI interface of the SDN controller that communicates with the switch or other data paths [START_REF] Onf | ONF SDN Evolution[END_REF]. The goal of Openflow is to create a normalized/common solution that is independant of constructors' software (Operation System (OS)). This can help SDN controller to have a global vision of network data plane paths and implement optimization algorithms to forward different flows.

Figure 3.6 (b) shows the main components of an Openflow switch. The switch consists of flow tables to forward the flows. According to the match rules inside flow tables, the packet-in from one port will (or will not) be sent to another port. There are two ways to configure the flow table and rules. The first way is to use Openflow protocol with the Openflow agent inside a controller. The second way is to use CLI (see configuration point in Figure 3.6 (b)) and modify directly the associated rule to flow tables.

BBF Solutions and Architecture: CloudCO, BAA CloudCO

As previously mentioned, VOLTHA is not the only project introducing virtualization technologies in optical access networks. The CloudCO project from the BBF recasts the CO hosting infrastructure that utilizes SDN, NFV and Cloud technologies to support network functions [START_REF] Georgios | Cloud Central Office Reference Architectural Framework[END_REF]. Similarly to SEBA, CloudCO works on access and aggregation networks and uses Docker and Kubernetes technologies as well.

The CloudCO architecture is shown in Figure 3.7. Although BBF does not follow the ONF triple-layer SDN architecture particularly, we can always quickly distinguish the infrastructure layer, the control layer and the application layer with the arrow indicated to the right of Figure 3.7. In the infrastructure layer, Physical Network Function (PNF) and VNF notions are introduced in this figure. The PON is presented inside the PNF category as an example. However, besides physical transport infrastructure (i.e. optical fiber), other software functions can be developed in the NFVI indicated at the bottom of Figure 3.7.

The SDN controller (pink square) and Virtualized Infrastructure Manager (VIM) block handle related PNF and VNF operations. The domain orchestrator (yellow square) is organized on the top of SDN layer to finally provide NBI interface to OSS/BSS and other high-level orchestration [START_REF]Bringing the Cloud to your Broadband neighborhood[END_REF].

BAA provides an abstraction as named in its name "Broadband Access Abstraction". However, since CloudCO has a different approach to bring virtualization technologies to access networks, BAA has different functionalities compared to VOLTHA. In the next paragraph, we specify the BAA architecture.

BAA

BAA is also named Open Broadband Broadband Access Abstraction (OB-BAA) and was demonstrated in 2018 for the first time [START_REF]Open Broadband -Broadband Access Abstraction (OB-BAA)[END_REF]. The turquoise square in the middle of Figure 3.8 shows this project. VOLTHA shows a programmable switch-like topology to the controller and uses Openflow as a standard protocol on the NBI. However, BAA has a different philosophy from VOLTHA. BAA exposes the standard YANG model of access networks to the upper layer (SDN controller). BAA layer is always necessary even if OLT is NETCONF/YANG (standard) compatible because the the SSoT is implemented inside BAA.

The South Bound (SB) layer hosts OLT/ONU drivers that have equivalent the function to adaptors in VOLTHA. They communicate with physical equipment with device-specific interfaces and provide the obtained configuration parameters to the BAA core. The BAA core draws a PON abstraction using the information from the SB layer to expose the standard YANG models to its NBI and redirects the requests coming from the North Bound (NB) layer to correct the component. It performs different management tasks, as indicated in Figure 3.8. The NB layer disposes of different protocol agents to support NETCONF, RESTCONF, HTTP etc. with an SDN controller or legacy EMS.

It is important to mention that BAA aims to develop the Openflow compatible NB layer as well. This is due to the merge initiative between ONF's SEBA and BBF's CloudCO since 2018 [START_REF]Relationship between BAA and VOLTHA open source projects for automating the access network for any operator deployment[END_REF]. The motivation of this merge effort between ONF and BBF is to ease the virtualization transformation of operators with high compatible devices [START_REF]ONF's SEBA and BBF's CloudCO Bringing Two Worlds Together[END_REF].

Conclusion

We could conclude that ONF brings SDN/NFV to different network segments, including access networks whereas BBF adapts traditional access networks to SDN/NFV approach. BBF contributes to broadband standardization from early times, starts to adapt the virtualization tendency brought by ONF with legacy equipment recently. Today, BBF produces standard YANG models for access networks, such as ITU PON [START_REF] Pauwels | Common YANG Modules for Access Networks[END_REF][START_REF] Ternovsky | ITU-T PON YANG Modules[END_REF]. The merge effort started between ONF and BBF stimulates telecommunication operators and equipment vendors to take a step forward on virtualization technologies for access networks.

OLT Access Evolution

An overview of two reference SDN/NFV architectures proposed by ONF and BBF on optical access networks was given in the last section. Based on these referenced work, in this part, we outline the industrial solution for OLT hardware with virtualization technologies and the research aspect of DBA software implementation.

Commercial OLT Hardware and SDN Solutions

Legacy OLT chassis and management system were introduced in sections 1.1.4 and 2.2 respectively. With the development of SDN, NFV and Cloud computing, some commercial OLTs or prototype OLTs were developped using virtualization technologies. Industry companies made their choice to follow the initiative of ONF-SEBA or BBF-CloudCO to propose new OLTs.

Whitebox OLT

A new ecosystem is built based on the principle of SEBA. The solutions are Open source software components that not compatible with legacy OLTs. Openflow is used between the hardware and SDN controller. The typical whitebox OLT is proposed by Radisys [START_REF]White Box Optical Line Terminals Leveraging VOLTHA[END_REF] and Adtran [START_REF]Fiber Access.The Way It Should Be[END_REF] shown in Figure 3.9. Please note that the Adtran OLT hardware have two firmwares that support Openflow and NETCONF separately. The Openflow firmware is open to other SDN controllers that speak Openflow, however, the NETCONF firmware works together with its controller, called Mosaic (see next part "NETCONF enabled OLTs"). Figure 3.9: Whitebox OLTs: Radisys RLT-1600C [START_REF] Series | XGS-PON and Combo PON for FTTx[END_REF] and Adtran SDX 6320 OLT [START_REF]Fiber Access.The Way It Should Be[END_REF].

The whitebox OLT allows network designers to implement software on any vendor's whitebox hardware. It is a kind of the disaggregated OLT that separates the control plane inside SDN controller and keeps the necessary hardware that is suitable for an open-computing project with Openflow. Together with whitebox OLT, there is whitebox switch that plays a role of Ethernet aggregation cards. An example of whitebox switch is given in Figure 3.9 on the right.

Vendors/operators can deploy OLT applications on the whitebox hardware. This enables the SEBA/VOLTHA integration on OLT and the combo PON technology implemented on one whitebox OLT. The telecommunication operators that are showing interests on SEBA based solutions are Deutsche Telekom [START_REF]Deutsche Telekom Announces Access 4.0 in Production, Leveraging ONF's VOLTHA Open Source Software Stack and SEBA Reference Design[END_REF], NTT [START_REF]NTT's Flexible Access Systems Architecture envisions white-box OLTs[END_REF] and Turk Telekom [START_REF]Türk Telekom Announces Production Broadband Network Based on ONF's SEBA Reference Design and Using VOLTHA and ONOS Open Source Platforms[END_REF].

NETCONF enabled OLT Legacy vendors, however, are more motivated to develop a solution that supports both legacy and SDN-ready solutions for OLT for a smooth transition to virtualization technologies. The reason behind that is economical, as the added-value of vendor is lesser by definition in open source solutions. Moreover, they reached a consensus about using NETCONF/YANG for SDN control platform instead of Openflow [120,[START_REF]Network Management, Control, and Analysis Software[END_REF]. Therefore, an adoption of Software Defined Access Network (SDAN) by different vendors is done. SDAN is a marketing concept of CloudCO.

As mentioned previously, Adtran provides an OLT hardware that supports both Open- Other OLT solutions Other commercial propositions around OLT products with SDN/NFV features exist as well.

We introduce here the general-server build-in blade OLT and microplug type OLT.

As discussed in Section 1.2.3.2, ZTE has performed industry's first MEC network integrated OLT using a build-in blade server [START_REF] Zte | White Paper of Built-in Blade in OLT[END_REF]. See in Figure 3.11 (a), a general-server type blade (takes two server blades place) is inserted directly into an OLT chassis. This solution pushes the NFV and cloud implementation in access networks.

Tibit's OLT is a miniature Small Form-factor Pluggable Transceiver (SFP) disaggregated OLT [START_REF]Broadband On-Ramp To Cloud-Based Services and Agility[END_REF]. The pluggable OLT works with traditional Layer 2/3 switch or a generic server to design an OLT chassis. The photo of Tibit OLT is shown in Figure 3.11 (b). In this thesis, Tibit OLT is used in different setups. We describe more technical description of this product and discover the reason why we use this product for virtualization study in optical access networks in Section 5.1.2.

Build-in blade server in OLT and Tibit disaggregated µOLT bring legacy OLT one step closer to fully-virtualized OLT. Some research work continues the virtualization journey of OLT trying to virtualize time-critical functions of an OLT such as DBA. In the next part, we discuss related studies about the implementation of PON physical layer function and time-critical DBA algorithm on generic servers.

DBA and PON PHY Functions on a Generic Server

Two research entities are going further than disaggregated OLT (µOLT and switch) using general propose servers to run DBA algorithms and other PON physical layer functions. NTT's Flexible Access System Architecture (FASA) project was launched in November 2018 to make a modularized and easy combinable access networks using virtualization tech-58 The DBA running on an X86 server enables a more flexible configuration for multitenancy use-cases. Trinity College publications on multi-tenant vDBA have started on the same period as FASA project. Implementation of vDBAs in a general server that shares the same PON hardware is realized and their study contributes to increasing PON performance on generic servers as well [START_REF] Elrasad | Virtual dynamic bandwidth allocation enabling true PON multi-tenancy[END_REF][START_REF] Slyne | Experimental Demonstration of DPDK Optimised VNF Implementation of Virtual DBA in a Multi-Tenant PON[END_REF][START_REF] Ruffini | Virtual DBA: virtualizing passive optical networks to enable multi-service operation in true multi-tenant environments[END_REF]. v-DBA enables another use case in the context of fixed-mobile convergence in access networks. When a PON is used to support mobile fronthaul/midhaul traffic, Cooperative Dynamic Bandwidth Allocation (Co-DBA) is proposed to better organizing uplink time slots for time-critical services. See Section 4 for more details about Co-DBA.

Conclusion

The two key words in this chapter are SDN and NFV. In brief, SDN separates the control plane from the data plane while NFV avoids dedicated hardware solutions and replaces by software implementation on generic server. According to the analysis provided, global operators continue to investigate SDN/NFV technologies since 2019.

This tendency for virtualization triggers ONF and BBF to propose two reference SDN/NFV access network architectures. Openflow is chosen by ONF and NETCONF is used by BBF. Some standards are produced for Openflow and YANG. Commercial vendors are inspired by ONF and NFV and propose their solution using different components from SEBA and CloudCO according to different technical, political and marketing strategy considerations. The disaggregated µOLT solution shows the path to fully-virtualized OLT. Researchers are contributing to "virtualizing" generic time-critical PON functionalities inside servers and the feasibility of the functions of the vDBA or virtualized physical layer has been demonstrated. We place all mentioned SDN/NFV efforts from organizations and research entities on optical access network in Figure 3.12. The numbers in Figure 3.12 represent different organizations and projects and are placed next to their contribution points in the scheme based on our understanding of each work. In Figure 3.12, NFV effort is only given on the infrastructure layer. However, other layers are also eligible for NFV implementation, as described for the SEBA and CloudCO projects in this chapter. Commercial solutions do not exactly follow the reference architecture of SDN/NFV since the real implementation of commercial solutions is more complicated than theoretical models. Thus, we have not included these solutions in this figure .  According to this analysis, we can conclude that standardization efforts are concentrated on control and management (YANG model, NETCONF, Openflow etc.). The research domain is working on more challenging tasks to virtualize physical layer functions or timecritical functions, such as DBA.

From using the same OLT for PON and PtP links in the access networks, the fixed and mobile access networks had its first step of convergence in physical placement. The SDN and NFV initiatives accelerate this convergence beyond the physical convergence of residential and mobile services within the same OLT, for example, reuse the deployed PON to transport mobile services with the help of Co-DBA or vDBA. However, the different degrees of fixed and mobile convergence bring the advantages and challenges at the same time. In the next Chapter 4

Challenges in Converged Fixed Mobile Access Network

In the past years, when both FTTH and mobile networks were in the early stages of deployment, mobile traffic from the antenna sites went directly to the gateway without passing through the same equipment (OLT) as residential traffic does. The OLT that serves both fixed and mobile networks with PON and PtP cards was only recently deployed where optical fibers are massively implemented. Therefore, this kind of OLT is considered as the first step of fixed and mobile convergence in optical access networks and the tendency of a fixed and mobile converged access network keeps growing.

The basic definition of Fixed-Mobile Convergence (FMC) is a transition point reached by the telecommunications industry that will finally remove the distinctions between fixed and mobile networks, providing seamless services delivery, regardless of the access network technology used [START_REF] Leitão | Fixed-mobile convergence towards the 5G era: Convergence 2.0: The past, present and future of FMC standardization[END_REF]. FMC topic in access networks becomes a hot topic nowadays for several reasons:

• The ongoing deployment of FTTH provides a wide coverage of optical fibers on the territory (see Section 1.1.3), but also many COs, from which mobile networks can benefit from. Also, fixed access operators are often mobile operators who are keen to reduce the exploitation cost by mutualizing the infrastructure.

• At the same time, the mobile network experiences an unprecedent development, stressing out the need for mobile antennas. The evolution of D-RAN, C-RAN and v-RAN (see Section 1.2.1) introduced new interfaces whose requirements are in the scope of optical access networks in terms of reach, throughput, etc. It is thus natural to assess the ability for optical access technologies to transport RAN interfaces and enable new FMC convergence scenarios.

• Also, as we mentioned in Chapter 3, optical access also experienced evolution in both hardware domain (OLT virtualization flavors potentially enabling cohabitation with v-RAN functions) and software domain (with new management protocols, architectures, and standard interfaces).

The next two sections will talk about the challenge and related studies of FMC on infrastructure layer, data plane and control/management plane of optical access networks.

Fiber Infrastructure and Data Plane Convergence

Data plane transmissions rely on the development of the physical infrastructure. Today, in fixed access networks, the CO distributes PtP fiber to connect antenna sites or enterprises and PtMP fibers to provide Internet services for FTTH clients using PON technology. Both PtP and PtMP fibers are connected to OLT in COs, therefore, OLTs takes in charge both mobile and fixed traffics of PON cards and PtP cards, and connects to metro networks via OLT network cards.

Challenges of Using FTTH infrastructure to Increase Network Availability

As mentioned above, the deployment of fiber in access networks already makes OLT a fixedmobile converged equipment. With the requirements of seamless coverage and ultra-high availability for 5G, new fibers are needed to connect the OLT and antenna sites. Meanwhile, operators are interested in CapEx profit solutions for infrastructure deployment. All these requirements make the convergence of infrastructure layer going further in access networks including sharing the deployed fiber to mobile uses. As discussed in Section 1.2, up to 6-nines availability is required by 5G and beyond. Core networks, metro networks and mobile wireless transmissions have redundancy paths to ensure high availability of services. Optical access network becomes the most fragile part today, where only one fiber is used to link antenna sites to CO. Adding the redundancy path (a second optical fiber that connects the antenna site to an OLT) for the optical access network that connects antenna sites is a solution to largely increase the availability for 5G services.

As we know that massive deployment of FTTH has been done in France, around 6000 OLTs are deployed by Orange in France in 2020 [START_REF] Despas | FTTx, Programme NRO/OLT[END_REF]. The majority of OLTs chassis are alone inside one CO. Each OLT can aggregate 3000 to 5000 FTTH clients and the typical numbers of 5G antenna sites connectable to a single CO is around 5. This value can be 16 in very dense areas [137]. Moreover, fiber for FTTH is usually over-dimensioned comparing to the current demand to be prepared for future increased fiber connection requirement. This over-dimensionning strategy is applied in two segments: from COs to SAPs and from SAPs to end-customers.

Based on all the information mentioned above, the reuse of fiber trenches or fiber infrastructure can become a cost-efficient possibility of FMC at the infrastructure level. Thus, it is natural for operators to think about reusing the deployed FTTH fiber to connect antenna sites for new mobile requirements (i.e. using PON to provide a redundant link for the antenna site for high availability of 5G/6G). By doing so, mobile network coverage and mobile network resilience can be improved with small investment.

However, there are two challenges when FTTH fibers are reused as a redundancy link for antenna sites. The first challenge is that an automated recovery mechanism is needed to detecte and reroute the traffic from the principle path to the secondary one. The second challenge concerns the performance of PON (specially the upstream) for mobile services. The redundancy problem and the two challenges are studied in this manuscript in Chapter 7.

By using PON to connect antenna sites, it is economically possible to reduce new fiber deployment. However, challenges in terms of PON performance for some mobile services exist (see Section 8.2). Furthermore, if mobile services share the same PON with FTTH services, it is extremely important to adjust QoS inside PON according to different constraints.

As operators do not have access to modify DBA (see Section 1.1.5), in this thesis, we try to realize QoS reconfiguration of PON by adjusting T-CONT parameters for time-critical mobile services. Our contribution will be detailed in Chapter 7. For other research entities, the approach would consist of reprogramming the DBA algorithm directly to provide better latency and jitter performance for mobile usages. The concept of Co-DBA is described as follows: when the CU/DU has the uplink traffic arrival time and the size of the packet, it transmits this scheduling information to DBA. The DBA algorithm generates a Bandwidth (BW) map according to the scheduling information of mobile uplink traffic received and directly sends to all ONUs for the next grant time without waiting the requirement from ONUs as in a traditional SR-DBA (see Section 1.1.5). By doing so, when the uplink data arrive at an ONU as the green arrow indicated in Figure 4.1, the ONU can immediately forward the data to the CU/DU. Some research papers have proposed similar studies on the PON uplink latency issue.

[139] addressed the fronthaul performance issue with converged access network and mentioned the Co-DBA solution to reduce the fronthaul uplink latency. However, in this paper, the experimental performance is not evaluated. The first Co-DBA demonstration for 5G and IoT usages was published in 2019 [START_REF] Uzawa | First Demonstration of Bandwidth-Allocation Scheme for Network-Slicing-Based TDM-PON toward 5G and IoT Era[END_REF]. In this paper, the uplink latency with the proposed DBA algorithm can be reduced to 80.1 µs, which is 30% reduction compared to the fixed bandwidth allocation solution.

Besides Co-DBA related work, new DBA algorithms are studied to satisfy fronthaul traffic in [START_REF] Mohammed Mikaeil | Performance evaluation of XG-PON based mobile front-haul transport in cloud-RAN architecture[END_REF][START_REF] Hatta | Feasibility demonstration of low latency DBA method with high bandwidth-efficiency for TDM-PON[END_REF][START_REF] Bidkar | Low-Latency TDM-PON for 5G Xhaul[END_REF]. These solutions focus on reducing uplink latency by decreasing DBA grant processing time. For example, instead of using 125 µs, 31.25 µs is used. However, more frequently assigning bursts in one frame can impact the data plane efficiency, since a gap is required between bursts. The challenge is to find the most adaptive DBA cycle with all consequences considered. Recently, some vendors, such as Broadcom [START_REF]Broadcom drives infrastructure development for 10G fiber broadband[END_REF][START_REF]Edgecore OLT setup[END_REF] started to propose flexible DBA schedulers that can be configured by operators for mobile usages.

Finally, research articles show that optimized DBA can better carry mobile traffic using PON with a significant reduction in terms of uplink latency. However, as mentioned above, most operators today do not have access to the proprietary DBA yet. Furthermore, an interface is needed between the CU/DU and the OLT to realize the concept Co-DBA, and we will introduce such interface in the next part. The CTI client is a process inside O-DU that communicates with the CTI server. The capacity requirement (bandwidth, volume and time indication) to PON transport network is generated by the CTI client. CTI server is a process inside OLT that receives requests from the CTI client. An interpretation of CTI message inside OLT is realized as input of Co-DBA. Precisely, Co-DBA reads CTI report messages from OLT and looks for the corresponding T-CONT and maps the requests in different time slots.

The CTI is a pioneering initiative, however, we can going further by converging the control and management plane as well as CTI in data plane. In the next section, we start by explaining some FMC commercial solutions in control/management plane and the possible problems of these solutions for future 5G services (i.e. 5G slicing). We then discuss the advantage and perspectives of introducing virtualization technologies to ease the FMC in control and management planes.

Control and Management Plane Convergence

The FMC does not only concern fiber infrastructure and data plane, as the control and management plane are in full evolution for fixed and mobile convergence as well. Moreover, virtualization technologies inside OLTs accelerate the deep sharing between fixed and mobile segments to support new mobile use cases (i.e. 5G slicing).

Commercial Solutions for FMC: VULA, BSA and FANS

As we indicated above, OLT today is starting to converge already the fixed and mobile traffics to metro networks. Virtual Unbundled Local Access (VULA) and BitStream Access (BSA) are commercial solutions today for multi-providers in GPON [START_REF]iskratel. Executive Whitepaper Unbundling and Wholesale in GPON Networks: Unbundling GPON networks for multi-provider access[END_REF]149]. Generally, the existing solutions are proposed to support multi-tenancy of fixed access network operators (i.e. FTTH). Nevertheless, the same principle can be used to support fixed and mobile operators.

The two solutions are summarized in Figure 4.3. In brief, VULA allows multiple service providers to share the PON infrastructure. In Figure 4.3, we distinguish the operator who owns PON infrastructure (black parts) and the other operators (green parts). In this scenario, different service providers need to connect their backhaul network to the OLT. The configuration of each service provider's traffic (i.e. QoS) in the PON should be done by black-colored operator. BSA provides a similar control/management aspect for service providers compared to VULA. However, in BSA, the bandwidth of an OLT network port that connects the backhaul network can be shared as well.

Although VULA and BSA initiate the reuse of PON infrastructure and provide a method for control and management, only the operator that has the OLT infrastructure can finally "put in" the configuration inside the OLT. Other operators always need to agree with the operator that possesses infrastructure before configuring the OLT for their own traffic. BBF published a FAN related documents [START_REF] Bbf | Fixed Access Network Sharing (FANS)[END_REF][START_REF] Cornaglia | Fixed Access Network Sharing -Architecture and Nodal Requirements[END_REF] to describe the new network model that simplifies the sharing of fixed access network. A simplified scheme of Fixed Access Networks Sharing (FANS) is shown in Figure 4.4. Different from VULA or BSA, FANS has a centralized sharing system on the top of the infrastructure layer that supports multi-tenancy (indicated as Virtual Network Operators (VNO) in Figure 4.4). In this case, operators have their own access to a centralized sharing system that allows them to apply their configuration to the equipment.

SDN and NFV help this new way of sharing the management system in access networks. So in Figure 4.4, that is why we added SDN and NFV indicators to better understand the position of each element in FANS from the point of view of a reference virtualization architecture. Studies of vDBA for multi-tenancy complements the FANS model if DBA is virtualized away from physical nodes (see Section 3.3.2). As mentioned previously, operators are interested in reuse PON infrastructure to support future mobile traffic. DBA process contributes to a significant latency and jitter in the PON uplink, which hinders time-critical mobile services. Thus, multi-tenancy enabled vDBA for fixed and mobile operators becomes a key technology for FMC in both control and management layers.

New Challenges brought by FMC with Virtualization Approach

Apart from the shared management of fixed access network for fixed and mobile access operators, FMC needs an enhanced coordination between 3GPP (i.e. system architecture for 5G [START_REF]3GPP. System architecture for the 5G System (5GS)[END_REF]) systems and fixed access management system in order to provide dynamic reconfiguration for 5G slicing.

The cooperation work of FMC concerning 5G management plane in access networks is studied between the two most relevant standard organizations: 3GPP and BBF. Besides, IETF, O-RAN Alliance and other entities contribute with related work to help to smooth the convergence between fixed and mobile access networks. Some standard documentations [START_REF] Kavanagh | Interworking between Next Generation Fixed and 3GPP Wireless Networks[END_REF][START_REF] Behcet | Nodal Requirements for Interworking between Next Generation Fixed and 3GPP Wireless Access[END_REF][START_REF] Kavanagh | 3GPP system -fixed broadband access network interworking[END_REF] concerning the requirement for UE inter-networking between fixed and mobile domains have been produced by the 3GPP and BBF following the FMC initiative. The convergence policy control system between fixed and mobile networks is mentioned in [START_REF] Bill | Policy Convergence for Next Generation Fixed and 3GPP Wireless Networks[END_REF][START_REF] Kavanagh | Policy and charging control architecture[END_REF]. However, the FMC work here is focused on the IP gateway.

Regarding 5G demands, the project 5G-Fixed Mobile Convergence (5G-FMC) from BBF is treated as a high priority project to realize seamless service experience, on-demand network services (i.e. 5G slicing) and multiple simultaneous attachments for certain devices and applications [157]. The marketing report [158] clarified the 5G convergence work focus on converged core network functions interfaces and E2E networking slicing. Specifically, technical reports [START_REF] Halpern | Marketing Report on 5G Network Architecture -Overview[END_REF][START_REF] Song | Mobile-transport network slice instance Management Interfaces -Overview[END_REF] in 2022 from BBF noted the progresses on the 5G transport architecture (the transport segment between UPF and RAN) and the management interfaces to support 5G network slices in access TNs.

To date, operators such as Orange still use separated management systems for mobile and fixed networks, and the FMC system in control/management plane is not deployed at all. SDN and NFV can help improve the coordination between fixed and mobile control/management systems, however, standard cooperation interfaces are still in full discussion today. During this thesis, the coordination method between fixed access networks and 5G mobile networks for dynamic slice instance creation scenarios are studied in Chapter 8. But before going into the contributions of this thesis, the different hardware and software used for our test bed to realize the contributions in Chapters 6, 7 and 8 will be presented in the next chapter. The thesis contributions are regrouped into three axes in the following three chapters (Chapters 6, 7 and 8)). Different equipment is used in our experimental test beds, and there is a virtualization evolution for the hardware of an OLT during this thesis. We centralize all information about our test beds in this chapter and present each element of to clarify our choices: OLT hardware, 5G core, RAN/UE software implementation and our SDN software development. The elements introduced are used for different scenarios in different chapters for further evaluation.

In terms of the OLT hardware evolution, a disaggregated OLT is used at the beginning of this thesis. The disaggregated OLT, as we consider it here (see Section 3.3 for more details), is composed of several modular SFP+/OLTs and a legacy programmable L2/3 switch. The SFP+/OLT is designated hereafter as µOLT. Each µOLT embeds the PHY and MAC layer of PON stacks that are traditionally inside a PON port of legacy OLT. However, the aggregation/switching functionalities are not included inside the µOLT. The legacy switch, in this case, provides the legacy PtP port, network port and switching capacity among them. We have also continued on the path of using generic hardware, replacing the legacy switch with virtual switches (OpenFlow enabled OvS) running on generic servers (accelerated by Data Plane Development Kit (DPDK)). We defined the µOLT plus generic server as a partially virtualized OLT. Some performance measurements of our setup are compared with current legacy equipment to have a clear comparison of solutions.

Since 5G development affects all network segments, we focused on different 5G scenarios for optical access networks in this thesis; therefore, to transport 5G traffic as realistic as possible on the optical access network, we deployed the 5G core and RAN/UE within different VMs using Open source projects. The 5G traffic between the 5G core and RAN/UE is sent out of the VM on the generic server to transmit the real-time 5G traffic in our experimental setup.

By introducing SDN technologies into the access networks, we developed our own "SDN controller" in the control and management layer using some open source projects based on our scenarios and our equipment in laboratory, however, we were not contributing on specific open source project during this thesis. Our SDN prototype consists of the adapters on the SDN controller SBI to match the chosen hardware and software. We developed some core functions inside the SDN controller to realize our scenarios and on the SDN controller NBI, we use the REST server/client to communicate with orchestrator applications.

PON Hardware Setup

In Section 3.3, different OLT products are introduced with SDN and NFV features, including Tibit OLT. Actually, Tibit OLT was used during this thesis in our set up to introduce the virtualization in optical access networks. To justify our choice and look closely this µOLT product, we start by giving a brief history of the Tibit company and the technical specifications of Tibit OLT. Based on this information, we explain the reason for using the Tibit OLT product for this thesis.

Why we choose Tibit Communications

TiBiT Communications, Inc. is a company founded in California, United States, in 2014. In 2015, the vice president of engineering and Chief Executive Officer (CTO) co-founder of Tibit Communications, Inc. Edward Boyd wrote the paper "Remote PON Network Performance" [START_REF] Boyd | Remote PON network performance[END_REF] that reveals the initial motivation of Tibit products for broadband networks. This paper indicates that operators prefer to simplify maintenance, reduce operational costs and improve reliability with a centralized network architecture. These motivations drive the solution for distributed OLT embedded in the MAC and PHY functions.

Indeed, the distributed OLT solution with OLT modular realizes the low-cost, scalable and flexible features compared to the legacy OLT chassis. Moreover, with such a distributed OLT, the control and management mechanism can be deployed inside CO or on a remote server. This feature provides great flexibility for operators and allows them to enrich their services without using vendor lock-in EMS.

In addition to the advantages mentioned above, we choose the modular Tibit µOLT for this thesis because of its easy configuration with Graphical User Interface (GUI) or the Web interface and its open API in Python. Thanks to their Python API, we can easily develop monitoring and automation scenarios during the thesis.

µOLT and µONU

Tibit MicroPlug OLT or ONU (also named µOLT or µONU as well in this document) [START_REF]Broadband On-Ramp To Cloud-Based Services and Agility[END_REF] are miniature hot-pluggable SFP+ modules (see Figure 5.1 (a)). The µOLT works as an OLT PON port when plugged into a legacy switch or server (see Figure 5.1 (b) (c)), and the switch with several µOLTs can replace the traditional OLT chassis. The µONU, embedded in a switch, works as a legacy ONU (see Figure 5.1 (d)). The photo of a legacy ONU is given in Figure 5.1 (e).

According to the datasheet [162], a µOLT includes the PON optical transceiver and OLT MAC layer (see Chapter 1.1 the description of PON protocol stack). For the OLT MAC layer, some typical functions are included: • PLOAM for the discovery and registrar of new ONUs.

• BW mapping and grant upstream traffic slots.

• DBA function for upstream traffic.

• GEM port framing and OMCI Communications Channel (OMCC) management.

• Segmentation and reassembly of the Ethernet frame.

As listed, the time-critical DBA function is embedded in the µOLT, which means that the DBA algorithm is predefined and cannot be modified by the operators.

In addition to the physical component and MAC layer, the µOLT provides some management methods to configure a PON. At the beginning of this thesis in 2019, there were two ways to manage the µOLT: the Tibit Application Programming Interface (TAPI) (coded in Python 2) and the GUI (see Figure 5.2 (a)). Starting from 2021, we upgraded the software (coded in Python 3) and installed the PON manager, which provides a Web interface for configuration (see Figure 5.2 (b)).

The following list explains the three key words for Tibit OLT management interfaces.

• TAPI is the Python interface (coded on Python 2) that we used to collect the management requirement and configuration from µOLT. OMCI messages are encapsulated in an s-Virtual Local Area Network (VLAN) or c-VLAN tagged Ethernet frame that is sent between the TAPI and µOLT. We developed most of our scenarios by interfacing with this TAPI during this thesis.

• Tibit GUI is the management system [163]. It runs on a Linux based graphic user interface OS and provides the basic configuration by interacting with TAPI. Figure 5.2 (a) shows the provided GUI: the menu (management interfaces) on the left shows the µOLTs and ONUs with their configuration. For each modification, the console output on the right gives log messages between GUI and TAPI.

• Tibit MicroClimat is the new management system based on Python 3 that we discovered only at the end of this thesis. It consists of a database (MongoDB), PON manager, NETCONF server and World Wide Web (WEB) interface to approach the SDN development. The PON manager provides configuration and monitoring possibilities. Tibit YANG models are saved in the database and a NETCONF server is enabled for applications. The WEB server communicates with MongoDB and the Tibit WEB interface shows the related information as shown in 5.2 (b).

It should be noted that the performance of the DBA algorithm is important for PON to carry mobile services. Although the DBA algorithm is proprietary, the T-CONT parameters are always accessible for QoS of upstream traffic. We can find the red squares for Tibit GUI in Figure 5.2 (a) where different BW types can be defined for T-CONT. As listed in Figure 5.2 (a), three BW types are configurable for Tibit OLT: fixed rate, guaranteed rate and best effort rate. The configuration of BW types can be done via GUI or the previous mentioned python 2 Tibit API. In the new Python 3 Tibit management system, the BW types are accessible from the SLA configuration indicated in the WEB interface in Figure 5.2 (b).

We compared the variation in latency and jitter of Tibit's solution with different T-CONT configurations with a legacy OLT before and after the 2021 software upgrade (see Appendix A). It shows that for µOLT performances are increased after the software upgrade. However, the experimental results in Chapter 6, 7 and 8 are based on the original 2019 software.

Orange started the µOLT evaluation in 2019 as previously mentioned in this section. In 2021, ONF announced a VOLTHA and ONOS new release with the feedback of Deutsche Telekom and Türk Telekom using Tibit µOLT. Orange research paper [START_REF] Simon | Ftth and optical LAN synergy enabled by virtual OLT for home, office and campus[END_REF] demonstrated in 2019 a PON for home Local Area Network (LAN) using using µOLT. This experimental setup proved the idea of Fiber to the Room (FTTR) where its use cases were defined by ITU-T in 2021 [START_REF] Gstp-Fttr | Technical Paper: Use cases and requirements of fibre-to-the-room (FTTR)[END_REF].

As will be presented in Chapters 6, 7 and 8, the µOLT is used for different test beds during this thesis, and we classify all setups into two architectures. The next two sections provide more details on the two architectures using µOLT one after the other.

Disaggregated OLT: µOLT and Legacy Switch

A disaggregated, as we consider it, OLT is composed of a µOLT with a legacy switch as shown in Figure 5.1. Our related contributions based on the disaggregated OLT setup are given in Section 6.3 and Section 7.4.1. As depicted in Figure 5.3, in our experimental setup, we use the existed legacy switch in our laboratory Juniper QFX5120 switch [166] to hold the µOLT and we develop an SDN controller to realize control and management tasks.

The QFX5120 switch is a Layer 2/3 programmable switch with 48×10 Gbps ports and 8×25 Gbps ports. Here are some specifications that interest us for this thesis:

• This switch runs Junos OS [START_REF] Juniper | Enabling Network Automation with Junos OS[END_REF] and provides a Python API called PyEZ. This facilitates our development of remote management and automation using Python.

• This switch is based on NETCONF/YANG, which means that it has the commit/rollback functions.

• Furthermore, since NETCONF is widely accepted for the SDN architecture, communication between the management entity and the switch uses the NETCONF protocol.

As we can see in Figure 5.3, our SDN controller has two parts: the algorithms in the yellow block for interactions with the switch and the PON manager (described above using Python 2 based Tibit API) in the blue block for µOLT and µONU configuration. The use cases realized during this thesis consist of a dynamic reconfiguration of T-CONT according to the bandwidth utilization in Section 6.3. NETCONF is used between the yellow 'alg' block and the switch. The functionalities developed in 'alg' concerns monitoring and dynamical automation processes. For example, in Chapter 7, the algorithm applied for switch allows an autodetection of port status and recovery strategy for mobile traffic protection. Thanks to Junos, the Python script can run in the switch and thus we can find the yellow 'alg' block inside the switch as well.

Partially Virtualized OLT: µOLT and Generic Server

The disaggregated OLT combined of µOLT and legacy switch enables many new control and management scenarios described previously compared to a legacy OLT chassis. The first approach for the separation of data plane and control plane is realized as well. To continue bringing more virtualization characteristics to access equipment, we aim to virtualize some functions on a generic server.

The so-called "partially virtualized OLT" is composed of a µOLT and a virtual switch on the generic server (see µOLT + generic proposed server in Figure 5.1). Our contributions in Section 7.4.2 and Chapter 8 uses the setup of partially a virtualized OLT. Compared to the disaggregated OLT in Section 5.1.3, the switching capacity of the OLT is virtualized on the server using OvS. Ryu is the manager of OvS. To achieve better performance in data plane traffic, DPDK is implemented on this server. We introduce more precisely the generic server, OvS and its SDN controller Ryu, DPDK in the following parts.

Generic Server

The generic servers used in this thesis is Dell PowerEdge T640 (see Figure 5.1 (c)), with 32 Intel(R) Xeon(R) Silver 4110 CPU at 2.10GHz and an X86 64 CPU architecture. The OS installed is Ubuntu 20.04.4 LTS (Focal Fossa) [START_REF] Dell | Server tour Dell EMC PowerEdge T640[END_REF]. Each server has six 10 Gbps interfaces and two 25 Gbps interfaces. All our setups use 10 Gbps interfaces to be adapted with the µOLT modular that supports XGS-PON.

Since the generic server is to be placed inside the CO in access networks, it provides more possibilities to implement edge functions inside the same server. In Figure 5.4, the white block inside the X86 server represents other functions than those of the legacy OLT. For example, the UPF belongs normally to the 5G core. Since it plays a role as a data plane gateway to the access DN, it is interesting to implement this function near the final user to reduce the impacts of latency and jitter. The deployment of MEC on the hardware resources of the access network is an example. Our related contribution is explained in Section 6.4.

OVS and Ryu

OvS is an open source project written in the C language [169] that provides a forwarding layer abstraction and enables the control layer switching functionality to work as a virtual switch based on servers or VMs (yellow block with the logo OvS in Figure 5.5). The choice for OvS because it is a well-known solution and compatible with DPDK. Ryu is chosen for its simplicity of deployment and its Python API.

Different functionalities such as VLAN mode, QoS configuration, policing configuration and etc. are supported by OvS as legacy switch. However, the concept in the OvS project of organizing the forwarding path is different from the legacy switches: for the OvS project, a deep visibility of traffic is accessible. Each virtual switching entity is called a "bridge" The protocol used to define the control plane rules for data plane flows on each bridge is Openflow. Described in Section 2.3, Openflow is pushed and standardized by ONF.

Ryu is an open source controller created by NTT Labs for network management. Ryu uses OpenFlow, NETCONF, or other protocols to communicate with network equipment. In our setup, the protocol used between the Ryu controller and the OvS is Openflow. The API Python provided in Ryu controller eases the development of automatic applications for programmers. In this thesis, we use Ryu in the SDN controller to interact with the OvS bridges (see the light yellow part in the SDN controller in Figure 5.4).

DPDK

DPDK is a set of libraries to accelerate packet processing on the generic server [170]. The advent of DPDK was started in 2010 by Intel, it is known today as a project of the Linux Foundation. With different releases since more than 10 years, DPDK supports all major CPU architectures of varies vendors and becomes an interesting tool for virtualized platform's acceleration.

Basically, DPDK uses two key techniques to improve the packet throughput performance. In order to give an intuitive idea of these two techniques, we summarize them in Figure 5.6 and describe them one by one in the following list.

• The first technique is called Fast-path or Kernel bypass. The kernel space is strictly reserved for the operating system and the user space is for applications and some drivers. Unlike the traditional way, where a packet arriving at Network Interface Card (NIC) goes through the kernel space to reach the user space, DPDK bypasses the kernel space, thus forwarding the frame from NIC to the user space directly.

• The second technique is the application of PMD to manage the network Tx and Rx queues for NIC. Unlike the Interrupt Service Routine (ISR) mode, each packet processing is performed only after each requirement. PMD can access the Tx and Rx descriptors directly without interruption, thus optimizing the processing delay.

As we can see in Figure 5.7, we compared OvS performance with (bottom) and without (top) DPDK on the generic server. The bit rate of traffic sent are 1, 5, 10 Gbps, and for each bit rate configured, the packet size is changed from 100 to 1500 bytes, while the received throughput is measured. With XGS-PON used for this thesis, the throughput for each OvS port can reach 10 Gbps. In Figure 5.7, for the results without DPDK, OvS has minimum 15% of packet loss using 10 Gbps for packet sizes larger than 1500 bytes. Furthermore, the latency without DPDK is always high compared to other results with DPDK regardless of the packet length. The performance difference verifies our decision to implement DPDK assisted OvS for our experimental setup.

5G Core and RAN UE Software Implementation

Motivation

In order to show the correct transport of mobile flows, employ flows as realistic as possible, and demonstrate a deep fixed-mobile convergence involving mobile core functions (mainly UPF) hosted by access network equipment, we proposed to employ a real 5G-Core and an emulated RAN and UE. More precisely:

• To transmit real 5G backhaul traffic through the access network segment, we need the PDU session established between UE and the 5G core; therefore, a real 5G core and UEs are needed.

• 5G traffic priority indicator for 5G slicing is generated by the 5G core; thus, to realize 5G slicing in access networks in Chapter 8, the 5G core is needed to provide the related information.

In this section, we present the 5G core solution we chose and the RAN/UE project: Open5GS

[172], UERANSIM [173]. We focus on some core functions that we used in this thesis.

Open5GS and UERANSIM Deployment

Open5GS is an open source project for EPC and 5G Core (5GC) implementation sponsored by numerous entities. In 2019, the NextEPC project was renamed Open5GS to gradually evolve the 4G core to the 5G core [START_REF]Open5GS -Splitting Network Elements[END_REF].The Open5GS project contains the software functions built in C language that implement 4G and 5G core functions. A WEB user interface is developed to visualize and interact with the subscriber data; however, it is possible to interact with the data base using the command line or programming language (e.g. Python). As shown in Figure 5.8, we implemented the Open5GS project in two VMs: VM1 includes all control plane functions (i.e. SMF, AMF, NSSF etc.) and VM2 includes UPF function for data plane. The RAN and UE are implemented within VM3 use the UERANSIM project [173]. The UPF can be implemented together with all control plane functions on the same VM as well, in this case, the N4 interface in Figure 5.8 becomes an internal interface such as the N11 interface between SMF and AMF. However, with the UPF apart from other core functions inside the second VM, the UPF can be placed close to final customers in access/metro networks to enable the execution of services closer to the final user, as discussed in Section 1.2.3.

Open5GS control plane functions are not all listed in Figure 5.8, however, the functions given in this figure are used for different scenarios for this thesis. The NSSF function provides a way to select the network slice and the subscriber Mongo database is what we use to collect the network slice instance information for each UE in Chapter 8.

It can also be seen on Figure 5.8 that the interfaces N2 and N4 belong to the control plane network and the interface N3 between UPF and RAN/UE belongs to the data plane network. The data plane network here presents a logical tunnel called PDU session that is established between the selected UPF and UE. In our test bed, each VM has one virtual interface attached to a physical interface on a generic server, that is, the control plane network and the data plane network in Figure 5.8 use the same physical link.

As demonstrated in Figure 5.9, both the N2 (control plane) and N3 (data plane) frames are captured by Wireshark from the same interface of RAN/UE VM. The control plane and While other open source 5G Core project exist (such as Free5GC [175] and Magma [START_REF]magma-Linux Foundation Project[END_REF]), Open5GS appeared as a good solution, regarding the detailed online tutorial, easy implementation of the separated UPF function, and its MongoDB access to realize the 5G slice configuration. Thanks to Open5GS and its advantages, our PoCs scenarios for UPF and MEC enabled OLT in Section 6, and the management coordination in the access network for 5G slicer in Section 8 have been carried out successfully during this thesis. For further information, an analysis of three 5G Core frameworks (Open5GS, Free5GC and Magma) is done in [START_REF] Joaquim | Analysis for Comparison of Framework for 5G Core Implementation[END_REF] in 2021.

SDN Architecture and Interfaces of Test Beds

Our infrastructure layer's setup is all explained up to now, during this thesis, we developed a prototype of SDN controller that contains the control plane, management plane with the µOLT, switch, OvS etc.

In Chapter 3, we explain the notion of SDN and two reference architectures in optical access networks proposed by ONF and BBF. The two architectures have two philosophies, especially when it comes to the SBI of the SDN controller. Here, we recall the two reference architectures based on switch-like OLT and legacy OLT to compare with our prototype of the SDN controller based on our setup using µOLT.

ONOS (the SDN controller of ONF) uses the Openflow protocol on its SBI, since all the equipment are considered as switch nodes. For equipment such as OLT that is not compatible with Openflow, VOLTHA was created to provide hardware abstraction to ONOS. Thus, NBI of VOLTHA uses Openflow. However, the SDN controller within the CloudCO project from BBF is a combination of legacy EMS and PNF/VNF architecture. A standard NETCONF/YANG interface is used for its SBI. Unlike VOLTHA which is optional in SEBA, the abstraction layer inside CloudCO called BAA is necessary for all cases. BAA has not only the OLT and ONU adapters, but based on its PON abstraction, some of the management features are also included in BAA, making BAA indispensable.

Our SDN controller is not following the ONOS or CloudCO projects due to the different interfaces (Tibit API, NETCONF, Openflow...) of the physical equipment chosen. Although some joint efforts are being made between Tibit Communications and these open source projects, at the beginning of this thesis, the concept was given, but the implementation was not mature. We kept using Tibit API coded in Python 2 as the SBI of the SDN controller. Figure 5.10 extracts our control and management layer construction and the NBI and SBI to connect the infrastructure and the application layer, respectively.

The infrastructure layer at the bottom of Figure 5.10 is colored blue. The legacy switch and the generic server can both host the µOLT and realize the switching capacities to connect the PON and PtP ports to the network ports. Therefore, the adapters of our SDN controller are based on the chosen physical equipment. Depending on each physical element, we use different protocols: NETCONF with customed YANG models for Juniper switch, Openflow for OvS and vendor-specific protocols µOLT and ONUs.

We combined the different adaptors, the control and management algorithms and the YANG models in our SDN controller. The YANG model is not standard and only contains the parameters used for thesis scenarios. This is why the SDN controller in Figure 5.10 has an aquamarine & dark blue color, since they represent the abstraction layer and the control layer according to the three-layer architecture of ONF (see Section 3.2, the aquamarine and dark blue color represent the abstraction layer and the control layer,respectively). Finally, our SDN controller provides a REST API agent to REST web client in the application layer (see the red square in Figure 5.10) based on the YANG models and REST-CONF).

It should be noted that our SDN controller presented in Figure 5.10 and used through different contributions during the thesis is only a prototype made from scratch, which evolved over 3 years. Typically, our SDN controller does not host the reference configuration of all equipment: sometimes physical equipment (i.e., the legacy switch) are only compatible with NETCONF while its reference configuration is still inside the physical equipment.

Conclusion

We introduced different elements used for experimental setups for both fixed and mobile infrastructure layer and control/management layer. This thesis studies scenarios of fixed and mobile converged networks using SDN and NFV, so it covers many axes at the same time. The idea of centralizing the basic and common elements of our experimental setup in this chapter is to provide the reader details on the involved technologies and on the proposed scenarios in the contribution chapters. Of course, along with each of the following contribution, a section of experimental setup will be presented as well for further details that concern the applied scenario. We start by describing the related work on OLT with the introduced virtualization technologies in the next chapter.

Chapter 6 Evolution of OLTs Through Virtualization Technologies for Mobile Services

To introduce the notions SDN and NFV in current access networks, dedicated equipment should be replaced by more generic equipment with SDN-enabled control interfaces. In this chapter, we address the evolution of OLT equipment, especially on OLT hardware from legacy OLT to disaggregated OLT and (partially) virtualized OLT. We focus on how mobile services can benefit from these new OLT architectures. Our disaggregated OLT and partially virtualized OLT experimental setup are described in Chapter 5, two contributions based on these setups are published in [START_REF] Wang | Dynamic Traffic Management of OLT Backhaul/Service Ports with SDN Controller[END_REF][START_REF] Wang | A MEC and UPF Compatible OLT for Time-Critical Mobile Services[END_REF] and will be presented in this chapter.

The context in Chapter 4 paved our study of the opportunities brought by virtualized or disaggregated OLT for converged fixed-mobile services in access networks in Section 6.1. In Section 6.2, we summarize and discuss related research work on disaggregated OLT, vOLT, with SDN controller and MEC application in access networks.

Our first contribution is detailed in Section 6.3. This section is more oriented to SDN development based on disaggregated OLT (legacy switch with µOLTs). We use our SDN controller to demonstrate the dynamic management of OLT network card ports for fixed and mobile traffic congestion.

Our second contribution is given in Section 6.4. The work focuses on the evolution of OLT with respect to NFV. Partially virtualized OLT is evaluated using the generic server plus µOLT. We implemented the MEC and mobile core function in virtualized OLT and compared the performance.

Introduction

The next PON generation will not only target higher bandwidths, but will also focus on a wider range of applications: optical LAN for campuses [START_REF] Wong | Tactile internet capable passive optical LAN for healthcare[END_REF], home LANs for in-house connectivity [START_REF]New ETSI group steers FTTH towards 'Fibre To Everything Everywhere[END_REF], and mobile applications for RAN support [8]. Since new PON technologies are intended for diversified applications, operators are interested in more generic hardware and new ways to manage equipment in PON to reduce CapEx, OpEx and avoid vendor lock-in as much as possible.

Virtualization technology enables operators to satisfy fixed and mobile convergence requirements in both infrastructure and management aspects. As introduced in 3, we identified two technologies of virtualization: SDN and NFV.

The definition of SDN by ONF is: the physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices [START_REF]Software-Defined Networking (SDN) Definition[END_REF]. NFV moves the dedicated function on an equipment to a generic server. The definition of NFV by ETSI is: implementing network functions in software that can run on a range of industry standard server hardware, and that can be moved to, or instantiated in various locations in the network as required, without the need to install new equipment [182]. SDN and NFV are highly complementary without dependence on each other.

With the great progress of SDN and NFV, virtualization technologies finally arrive at the optical access network. For example, the concept of Cloud-CO, defined by BBF in 2018 [START_REF] Georgios | Cloud Central Office Reference Architectural Framework[END_REF], recasts CO that utilizes cloud technologies, SDN and NFV. In parallel, many research works have been published with different technical focuses and will be detailed in Section 6.2. All of these contributions and the current state of standardization and specification bodies highlight the benefits and drawbacks of virtualization in optical access networks today.

Related Research Work for Virtualized OLT and SDN controller

Virtualization technologies (SDN/NFV) are redefining a legacy OLT to OLT software functions running on a generic server. Explained in Section 3.3, the OLT can be virtualized to different levels according to performance constraints. Management functions and other non-time-critical functions are the easiest to be virtualized. However, time-critical functions (i.e. DBA) and physical layer functions are more difficult to perform on a generic server with performance similar to OLT with dedicated hardware. We classified three degrees of OLT hardware virtualization according to the virtualized functions implemented on the generic server in Section 3.3:

• Disaggregated OLT that is typically composed of a legacy switch with several µOLTs.

• Partially virtualized OLT uses a general-purpose server to realize some OLT functional blocks (i.e. switching capacity), while keeps some other time-critical functions (i.e. DBA) in a dedicated modular µOLT.

• Fully virtualized OLT uses general-purpose server to emulate all functions (specially DBA) of a legacy OLT.

We explain our different experimental test beds in Chapter 5 using disaggregated OLT and partially virtualized OLT terms in 5.1.3 and 5.1.4 respectively.

For simplicity, here we use the term vOLT to describe the three degrees (disaggregated, partially virtualized and fully virtualized OLT) of virtualized OLT. However, as mentioned in Figure 1.8 and Figure 1.9, PON stack contains different functional blocks, from more physical layer to upper layers, there are PMD, TC layer and SDU layer. Among them, TC Reference CPU GPU Memory [START_REF] Tadokoro | Design of softwarized EPON OLT and its transmission jitter suppression techniques over MPCP[END_REF] Intel® i5-3570 3. [START_REF] Tadokoro | Design of softwarized EPON OLT and its transmission jitter suppression techniques over MPCP[END_REF][START_REF] Suzuki | Software Implementation of 10G-EPON Upstream Physical-Layer Processing for Flexible Access Systems[END_REF][START_REF] Slyne | Experimental Demonstration of multiple Disaggregated OLTs with Virtualised Multi Tenant DBA, over General Purpose Processor[END_REF] for fully virtualized EPON, 10G-EPON and XGS-PON.

has three sublayers: phy adaptation sublayer, framing sublayer and service adaptation layer. Hence, when describing related work, we will analyze the degree of OLT virtualization by identifying the virtualized functions of these layers. Different research efforts have been made to virtualize OLT. Here, we give three papers as an example, to show and compare the realization of virtualized EPON, 10G-EPON (physical layer) and XGS-PON on a general-purpose server in [START_REF] Tadokoro | Design of softwarized EPON OLT and its transmission jitter suppression techniques over MPCP[END_REF][START_REF] Suzuki | Software Implementation of 10G-EPON Upstream Physical-Layer Processing for Flexible Access Systems[END_REF][START_REF] Ruffini | Evolution of access network sharing towards software based passive optical network: can virtual OLTs run at full line rate?[END_REF] in 2017, 2019 and 2020 respectively.

The work in [START_REF] Tadokoro | Design of softwarized EPON OLT and its transmission jitter suppression techniques over MPCP[END_REF] compares the jitter performance with two DBA algorithms according to the numbers of ONUs on PON for their vOLT. The add-on modules have been proposed side by side with the generic server to emulate EPON. This add-on module has a small Field Programmable Gate Arrays (FPGA) and EPON transceiver for physical layer frame conversion. The focus of [START_REF] Suzuki | Software Implementation of 10G-EPON Upstream Physical-Layer Processing for Flexible Access Systems[END_REF] is 10G-EPON physical coding sub-layer's virtualization (including FEC) using CPU and GPU on generic proposed server. The add-on modules used are PMD and Physical Medium Attachment (PMA). The paper realized 10 Gbps upstream physical bit rate with parallel GPU computation. The time constraint for physical layer processing is 25.9 ms using the parameters CPU and GPU indicated in Table 6.1. The last paper [START_REF] Ruffini | Evolution of access network sharing towards software based passive optical network: can virtual OLTs run at full line rate?[END_REF] carried out two forms of vOLT. The first is called the "high level split" which implements the SDU layer of the PON stack (see Figure 1.9). For "high level split" a full line rate of 10 Gbps for XGS-PON for both downlink and uplink is supported. The second is called the "low level split" which has a TC layer on the generic server in addition. In this case, the line rate is 4.9 Gbps and 3.3 Gbps for downlink and uplink respectively.

Considering that hardware parameters are one of the factors that can affect the performance of virtualized OLT, as an example, table 6.1 shows the technical specifications of the servers currently used in the research work mentioned above. Since it is not our focus in this thesis, we will not detail all these parameters. However, we can remark that from [START_REF] Tadokoro | Design of softwarized EPON OLT and its transmission jitter suppression techniques over MPCP[END_REF], to [START_REF] Suzuki | Software Implementation of 10G-EPON Upstream Physical-Layer Processing for Flexible Access Systems[END_REF] and [START_REF] Slyne | Experimental Demonstration of multiple Disaggregated OLTs with Virtualised Multi Tenant DBA, over General Purpose Processor[END_REF], CPU and memory become more and more efficient. With DPDK enabled in [START_REF] Ruffini | Evolution of access network sharing towards software based passive optical network: can virtual OLTs run at full line rate?[END_REF], the XGS-PON bitrate is totally satisfied in the "high level split" case.

Our setup in this thesis (see Chapter 5) uses µOLT modular with generic server (similar to the "high level split" case indicated in [START_REF] Ruffini | Evolution of access network sharing towards software based passive optical network: can virtual OLTs run at full line rate?[END_REF]), thus the generic server performs the virtual switching capacity of OLT chassis. With DPDK implementation, our XGS-PON can reach a full line rate without difficulty.

As we know, DBA is a time-critical function in OLT for Time Division Multiplexing PON (TDM-PON) upstream time slots allocation with a typical assignment period of 125µs (see Section 1.1.2); therefore, virtualizing DBA on general-purpose servers is one of the most challenging tasks of all virtualization of the OLT function to allow a fully virtualized OLT. The papers [START_REF] Nishimoto | Predictive dynamic bandwidth allocation based on the correlation of the bi-directional traffic for cloud-based virtual PON-OLT[END_REF][START_REF] Nishimoto | Software module-based 10G Optical Line Terminal for enhancing flexibility of access networks[END_REF][START_REF] Slyne | Demonstration of Real Time VNF Implementation of OLT with Virtual DBA for Sliceable Multi-Tenant PONs[END_REF][START_REF] Afraz | DBA Capacity Auctions to Enhance Resource Sharing across Virtual Network Operators in Multi-Tenant PONs[END_REF][START_REF] Slyne | Experimental Demonstration of DPDK Optimised VNF Implementation of Virtual DBA in a Multi-Tenant PON[END_REF][START_REF] Ruffini | Virtual DBA: virtualizing passive optical networks to enable multi-service operation in true multi-tenant environments[END_REF] focus on implementing vDBA in generic hardware and increasing its performance. Moreover, there are VULA and BSA [START_REF]iskratel. Executive Whitepaper Unbundling and Wholesale in GPON Networks: Unbundling GPON networks for multi-provider access[END_REF] commercial solutions today for multi-provider cases in GPON (see Section 1.1.5). Thus, vDBA is in full discussion to support multi-tenancy in access networks. Different DBA algorithms are proposed for multi-tenancy scenarios in these papers. The optimized DBA algorithms enable time sensitive mobile traffic to pass through PON to realize fixed mobile convergence in access networks.

Certainly, the study of fully virtualized OLT and more sophisticated vDBA is essential for higher performance. However, the DBA algorithm was not in the scope of the standards in legacy PONs, and will then depend on different manufacturers. Operators have no direct access to modify or optimize this algorithm in order to use PON for high performance mobile services in a converged fixed-mobile context. T-CONT is the only parameter today that operators can reach for uplink bandwidth allocation prioritization (see Section 1.1.5). To date, T-CONT is a set-and-forget configuration without further automated effort. Moreover, no latency or jitter promises are given with T-CONT and these performance can be very different from one DBA algorithm to another. Section 2 pointed out the advantages of SDN aspects of the flexible and automated control and management layer with disaggregated or virtualized OLT. This is why SDN attracts a great deal of attention from access network operators. Based on a disaggregated OLT configuration, zero-touch service provisioning for 32 ONUs is achieved in less than 30 seconds in [START_REF] Yoshino | Zero-Touch Multi-Service Provisioning With Pluggable Module-Type OLT in Access Network Virtualization Testbed[END_REF]. Based on project SEBA, the IEEE PON SDN layers are implemented in [START_REF] Suzuki | Demonstration of IEEE PON Abstraction for SDN Enabled Broadband Access (SEBA)[END_REF]. In [START_REF] Nishimoto | Two-Stage Abstraction for Disaggregated Modular OLT Architecture Supporting OpenFlow Control[END_REF] a two-stage abstraction of PON has been made for the Openflow SDN controller, and the reconfiguration time to reroute the flow takes more than 10 seconds. Our study in Section 6.3 uses a self-developed SDN architecture to perform some dynamic configuration on the disaggregated OLT.

In addition to the general aspects of vOLT or SDN, new services (mobile services and MEC) can benefit from virtualization in access networks: the generic server gives possibilities to hold MEC functions and SDN controller enables a deep convergence of fixed and mobile traffics. The survey [START_REF] Mehrabi | Device-Enhanced MEC: Multi-Access Edge Computing (MEC) Aided by End Device Computation and Caching: A Survey[END_REF] analyzed the research efforts of MEC to reduce latency for mobile services. A mathematical model is proposed in [START_REF] Wang | Joint Optimization of Latency and Deployment Cost Over TDM-PON Based MEC-Enabled Cloud Radio Access Networks[END_REF] to choose the deployment site of the MEC server weighing the latency and deployment cost.

Moreover, with the development of fully virtualized OLT, this converged mobile-fixed access equipment in CO can be a perfect candidate to host other 5G core functions on edge such as UPF. This possibility is studied in Section 6.4.

Disaggregated OLT and SDN Controller for eCTI

Dynamic Traffic Management

Motivation of Proposed eCTI for Converged Fixed-Mobile Access Networks

When fixed optical access technologies are used for mobile applications, some considerations need to be taken into account. Today, RAN interfaces are mostly transported by PtP topologies with layer 2 or 3 switching nodes and independently of FTTH architectures.

Since the next generation RAN will need more fiber connections with high data rate and 5G antenna sites and small cells to improve coverage, reusing overdeployed FTTH fiber or PON technology could therefore be interesting for operators. The optical access system is supposed to deal with different constraints in terms of latency, bit rate and reliability associated with different mobile services [START_REF] Chanclou | Mobile fronthaul architecture and technologies: A RAN equipment assessment[END_REF]. CTI, recently proposed by the O-RAN Alliance [START_REF]O-RAN Fronthaul Cooperative Transport Interface Transport Control Plane Specification[END_REF], enables cooperation between the mobile and PON schedulers. The function of CTI is completed by Co-DBA [START_REF]-Gigabit-capable passive optical networks (NG-PON2): Transmission convergence layer specification[END_REF], which optimizes PON traffic allocation according to mobile applications. Unlike DBA, that relatively allocates bandwidth, Co-DBA proactively reserves the needed upstream bandwidth in advance for time sensitive services (See Section 4 for more details on CTI reference architecture and Co-DBA). However, Co-DBA is not the only key element that allows the use of PON for fixed and mobile applications. Today's residential networks typically aggregate several thousands of users on a single OLT and several tens of PON trees. The PON deployment architecture and traffic engineering rules at OLT depend on specific policies that vary from operator to operator. As introduced in the technical context, a legacy chassis includes both network cards and line cards, network cards connect to metro network and line cards provide connections to antenna sites, houses etc. For some operators, each PON line card corresponds The obvious benefit of this over-provisioning deployment strategy is that there is very little traffic congestion in OLT between the network cards and the line cards. However, all network ports must be connected to a Wide Area Network (WAN) node (metro network) to aggregate the traffic before going to the rest of the network. The disadvantage of this approach is the higher CapEx compared to Case 2 (Figure 6.1): in Case 2, each network card in the OLT chassis is connected to all line cards [197,198]. Thus, OLT combines and dispatches the traffic as an aggregation node between the access and the metro network. Actually, there are two congestion points between PON client and metro networks in our case. The first is caused by ODN with the mechanism TDMA and the second in the backplane of OLT.

We propose to extend the concept of CTI to extended-Cooperative Transport Interface (eCTI), also considering the ports of the network OLT (see Figure 6.2). The fixed-mobile convergence required by field deployments in the same access node requires the O-RAN Alliance community to rethink OLT not only in view of the potential upstream latency introduced in the PON segment, but also taking into account the network ports segment, the management of the different interfaces and their type (PtP or PtMP), alarms and energy consumption.

Proposed Architecture with SDN Controller

To realize eCTI, we propose complete management and adaptation of QoS from OLT network card ports to PON clients (OLT backplane switching and DBA) by our network controller to meet different tenant strategies. In this thesis, we focus on joint dynamic management between the network ports of an OLT and the PtP / PtMP links between OLT and ONUs.

As shown in Figure 6.3, disaggregated OLT with µOLT and legacy switch is used in this setup. The network card ports (the switch ports connected to the metro network) are dynamically enabled when the downstream or upstream traffic required approaches their maximum capacity thanks to an algorithm implemented on top of our SDN controller.

When not used, these ports are disabled to reduce the energy consumption of the access equipment on the central side. This dynamic port allocation system could potentially avoid a deployment based on over-provisioning of OLT and also allow footprint savings in central offices, thus allowing for CapEx and OpEx reductions.

We take advantage of recent advances in virtualization aspects (SDN) in network technologies to disaggregated OLT and replace it with generic hardware, which will be more detailed in the next section. Basically, we propose using a regular switch as the aggregation element with µOLT modules as shown in Figure 6.3. The regular switch plus µOLT form a fully-fledged OLT that is more scalable than a traditional OLT chassis, as it could evolve in a pay-as-you-grow strategy. This is done to demonstrate that the mobile backhaul could intelligently reuse the PON architecture for some of its services and interfaces in the future.

The proposed disaggregated OLT is controlled and managed through a REST client [START_REF] Bierman | RESTCONF Protocol[END_REF], which holds the traffic management intelligence of the network and line cards. The different equipment (switch and µOLT) with their different hardware specificities are equivalent to OLT and are modeled by a unified YANG data model in our controller shown on the left of Figure 6.3. The generic OLT can then be managed through the network controller using the RESTCONF protocol shown in Figure 6.3.

Other management features are also enabled by the proposed approach, namely:

• Allow seamless selection of PtP or PtMP links according to different mobile services in a zone covered by macro and small cells thanks to VLAN tag management [8].

• OLT link redundancy with switch layer 2 redundant solutions or developed automated scripts from the SDN controller (see our two contributions in Chapter 7).

Figure 6.3: SDN control layers architecture with an example of our YANG model.

Experimental Setup and Tested Scenario

Based on the experimental setup and SDN controller functions explained in Chapter 5, we implemented some algorithms in addition to dynamic allocation of the network ports. We detailed our experimental setup of this contribution in this section with the following order: the setup infrastructure, the controller mechanism and the provisioning scenarios. In the infrastructure (or physical) layer as shown in Figure 6.4, a PtP link on the switch uses regular 10 Gbps Ethernet SFP modules for the connectivity of macro-cell antennas and latency-constrained mobile services. Three PtMP links, traditionally used only for residential clients, are supposed to connect fixed subscribers and small cells in a PON tree. Three µOLTs are inserted into the 10 Gbps switch ports (blue SFP-OLT in Figure 6.4) and each of them is connected to two ONUs. Three 10 Gbps ports (on the left of the switch in Figure 6.4 are available as OLT network ports. As already mentioned above, such regular switch with µOLT combination enables pay-as-you-grow strategy. Moreover, this approach will allow other vendors (i.e. switch and router vendors) in addition to traditional vendors of OLT to enter the market for access equipment.

The SDN controller abstracts and controls every port of the switch (network ports on the left and PtP port, PtMP ports on the right in Figure 6.4), µOLTs and ONUs. When the application layer interrogates the current configuration on the physical layer, the SDN controller communicates on its southbound interface with the switch and µOLT via NETCONF protocol [START_REF] Bjorklund | YANG -a data modeling language for the networkconfiguration protocol (NETCONF)[END_REF] and an API, respectively. The adapter collects physical parameters, such as traffic flow, and updates the YANG data structures. Then, on its northbound interface, the SDN controller exposes the network configuration through a programmable REST interface based on the unified YANG model partially shown in Figure 6.3. Web client can operate CRUD on the disaggregated OLT configuration (switching and DBA parameters) through the unified and generic data model.

The dynamic management of the OLT network card ports algorithm is activated by the REST client in the orchestration layer on top of the SDN controller. We defined two operation modes in the algorithm: the "regular" mode and the "intelligent" mode. The "regular" mode corresponds to an operational regime in which no energy saving mechanism in the OLT are applied. The "intelligent" mode deallocates or reallocates dynamically the network ports to adapt the bit rate of the data plane and saves energy by doing so. Thus, an optimization of network ports in real time is applied to the system based on the OLT-ONU traffic of the different PON ODN. Here, we set two thresholds for the capacity of the downstream network card. Those will trigger an action of opening or closing a 10 Gbps network port of the switch. A probe developed in our controller, interrogates the µOLTs in average each 800 ms to read the total bit rate of all ports on the PtMP line.

Experimental Results and Discussion

Figure 6.5 shows the downstream and upstream throughput of all network ports on the switch that includes the total traffic of a PtP client and six PtMP ONUs over time. We assume that the downstream bitrate is generally higher than the bitrate for upstream traffic, and our algorithm deals with the total downstream bitrate with a threshold to decide the actions on network ports. The downstream and upstream throughput of three network port links over time is shown with four remarkable time stamps t1, 2, 3, and 4 in Figure 6.5.

At first, all network card ports that have a maximum capacity of 30 Gbps downstream and upstream are opened. The total traffic of PtMP and PtP users is 27 Gbps downstream and 420 Mbps upstream. A decrease of downstream bit rate from PtMP users before t1 causes a decrease of the total downstream bit rate in Figure 6.5 (downstream sum line). When the downstream sum line (purple) crosses threshold2 (17 Gbps) at t1, only two network ports are required instead of three. The same phenomenon occurs at t2 with threshold1 (7 Gbps). Port 3 and port 2 are shut down at t1 and t2 respectively, so that the downstream and the upstream of Link 3 and 2 decrease to zero. Meanwhile, the downstream and upstream links that passed through Link 3 and 2 are automatically redirected to the remaining links. This traffic redirection can be achieved thanks to Link Aggregation Group (LAG) applied to all network card ports in the switch. LAG combines several physical ports together to represent one logical link, and this method is often used between switches and routers to improve bandwidth.

For each link shutdown, we measured that at least 3600 J energy was saved in one hour, which corresponds to the consumption of the transceiver. Equivalently, when the throughput exceeds the two thresholds at t3, Links2 and 3 are enabled and share the load with Link 1. At t4, all the traffic is re-established with all network card ports reconnected.

To better quantify the exact execution time, a high-resolution (100 ms) measurement was performed for the second time using the same setup but only with two LAG links as example (the two links used are link 1 and link 3 in Figure 6.5). Three curves in Figure 6.6 show the bit rate variation of the total downstream, and the two upstream links in time. Using the same principle as in Figure 6.5, in Figure 6.6, the total execution time (noted as 2.5 s and 2.8 s) are calculated starting from the cross-point between the total downstream and threshold (noted as t1 and t3), ending by a total balance of all traffic to the active ports (noted as t2 and t4). In the two zoomed graphics around 8th second and 22nd second in Figure 6.6, we could find the performance of LAG implementation in this setup, the traffic switching time is around 200 ms.

For each modification, the whole network reconfiguration procedure takes around 1.5 s from the moment when a bit rate crosses the threshold to the moment when all needed configurations are finished. As observed in Figure 6.7, the reconfiguration scenario includes three steps: Monitoring (in pink), algorithm (in purple) and switch reconfiguration (in green). The performance of each step is also indicated in Figure 6.7 with 800 ms, 200 ms and 1.5 s, respectively.

Today, dynamic reconfiguration of OLT network ports with real-time traffic is not applied with legacy OLT due to monitoring performance. In this work, we successfully showed the feasibility of a dynamic configuration according to the throughput value. Some possible improvements can be made for better performance.

• The monitoring probe interacts every 800 ms with disaggregated OLT to obtain the packet counter number and return an average value of the bit rate for 800 ms. This time duration can be reduced if the algorithm can approach closer to the equipment (i.e. inside the switch as edge function). Now this algorithm is in another machine 10-20 meters away from infrastructure setup in the same local area, however, in real deployment, the algorithm can run in local from somewhere of metro networks with management systems. Furthermore, the performance of the algorithm to calculate the bit rate together with µOLT API impacts the monitoring performance; this can be further optimized by improving the algorithms.

• It should be noted that NETCONF was used between the SDN controller and the switch, so the reconfiguration phrase takes about 1.5 s due to the commit phase of the candidate configuration. The possible solution is to optimize some configuration procedure with NETCONF or use other telemetry management protocols (see 6.5).

To conclude, this work points out the importance of taking into account the possible congestion within OLT in addition to DBA at PON level for fixed-mobile converged access network. Based on the proposition eCTI, the dynamic management of the network ports of OLT according to the traffic status in real time is demonstrated using SDN-oriented architecture.

As mentioned above, one of the solutions to improve monitoring performance is to integrate some time-critical management scripts on the edge inside the data plane equipment. This principle is also available for time-critical mobile services. In the next section, we will introduce our second contribution to improve the performance of 5G time-critical services with virtualization technologies.

A MEC and UPF Compatible OLT for Time-Critical

Mobile Services

Introduction and Proposition

The core of the 5G mobile network has been fully revisited, compared to 4G. It provides several new entities to improve QoS: 5G's network slicing concept that ensures the endto-end QoS from the core network to the UE) with the help of SDN controllers. Another approach introduced in Section 1.2.3.2 is to redeploy the UPF closer to the access segment for an optimal UEs' experience, the UPF being the data plane's gateway to "the outside world" which is called the DN in the mobile network terminology. Section 1.2.3.2 explained the MEC network solution with standard definition, industrial realization and research work for possible scenarios. The innovative idea of replacing an OLT chassis (see Figure 6.8 (a)) by a generic server enables many new opportunities. The original optical node for the optical transmission layer 2 replaced by the generic server can not only act as OLT but can also hold other functions from all network segments. For example, this server in CO can add mobile core network functionalities such as UPF. Thus showcasing a deep fixed and mobile convergence. Furthermore, this server can become a cloud/fog/edge entity such as the MEC services see In Figure 6.8 (a), legacy OLT is deployed in CO that connects FTTH and mobile antenna sites. 5G core functions are in core network, UPF core is connected to DN0. In Figure 6.8 (b), legacy OLT is replaced by an X86 generic server with OLT functionalities, MEC and mobile core function for data plane (UPF edge). The UPF edge is connected to the DN1 inside the generic server in CO.

Our motivation is to experimentally demonstrate that an advanced and virtualized optical access architecture such as the one proposed in Figure 6.8 b) can be used to meet the Figure 6.9: Experimental setup and test traffic paths: UPFcore in the 5G core (path 0) and UPF edge in the OLT generic server (path 1). latency and jitter constraints of time-critical mobile services, with the help of optical access technologies.

We supposes the use case where a mobile network carries two types of service, with very tight or relaxed constraints in terms of latency and packet jitter to bring out the advantage of edge UPF compared to the core UPF. The traffic with very tight constraints is associated with an UPF closer to UEs (UPF edge) and is implemented with a MEC functionality in our OLT. On the other hand, traffic with very relaxed restrictions can be associated with a distant UPF (UPF core in Figure 6.8 b), which is located in the core network. Since it is transmitted through the metro network segment (with distances typically of the order of 500 km in France [START_REF] Elbers | Optical metro networks 2.0[END_REF]), it could be subject to severe and variable latency and jitter depending on the network load. An enhanced convergence between the OLT, UPF and MEC functions is proposed and experimentally evaluated by implementing all these functions on a generic server located in the access segment, as shown in Figure 6.8 b).

Experimental Setup

The experimental setup in Figure 6.9 includes four parts:

• The real-time 5G core and the simulated RAN / UE that communicate through a real-time backhaul interface.

• The latency and jitter generator that emulates the metro network.

• The MEC / UPF enabled OLT on a generic server.

• The traffic generator and analyzer.

Our test bed provides different types of optical access connectivity with optical PtP or PtMP topologies, allowing for more flexible optical transport in future fixed-mobile convergent architectures [START_REF] Wang | SDN-oriented Disaggregated Optical Access Node for Converged 5G Mobile and Residential Services[END_REF]. The UPF 0 / mobile core (Open5GS) implemented in VM 1 and the RAN / UE emulator (UERANSIM) are implemented in another VM, called VM2, thus the 5G backhaul interface is implemented between these two VMs. The air propagation interface between RAN and UE is not implemented in this work with RAN / UE emulator (UERANSIM). The second UPF is in VM 3 inside the OLT generic server. All three VMs are configured with 8 CPU cores and 10 GB memory; however, VM 1 and VM 2 use Intel(R) Xeon(R) CPU E5-2630v4@2.20 GHz and VM 3 uses Intel(R) Xeon(R) Silver4110 CPU@2.10 GHz. The latency and jitter simulator can emulate two paths:

• Bypass/reference, without latency and jitter.

• The simulated latency of the metro path is configured with normal distributed law mean value 2.5 ms and standard deviation of 0.1 ms considering the distance of the metro network 500 km and 3-4 interconnected routers / switches [START_REF] Biswanath | Springer Handbook of Optical Networks[END_REF].

The generic x86 server in CO includes OvS for OLT switching capabilities with µOLT for PtMP links and standard black & white SFPs for PtP links. The VM 3 interconnects with an internal port of OvS. The traffic generator generates additional downlink and uplink traffic between DN and UE. The circles 0 and 1 marked in Figure 6.9 represent the two data paths with UPF 0 and UPF 1, respectively. The analyzer measures both latency and jitter values with different bit rates for mobile traffic. The performance of CPU for VM is shown to give an idea of its computing resources' occupation status based on traffic throughput. However, it is important to note that the optimization of the generic server resource is not the objective in this thesis. We give some measurements in computing resources and VM performance to polish and explain the limitation of our bitrate in this setup and invoke the importance of the study for generic server in access that includes OLT, UPF, MEC functionalities.

Results and Discussion

Figure 6.10 shows the results of the two possible locations of UPF (located in CO in the access network or in the core network) and the optical access architecture (either PtP or PtMP). As introduced previously, for each chosen bit rate in the X-axis, the CPU performance of the VMs and the latency / jitter of uplink traffic are measured. The results in Figure 6.10 allow us to conclude that:

• VM 2 (RAN/UE) saturates earlier than the other VMs (VM UPF core and VM UPF edge). Figure 6.10 (b) shows that the CPU performance of RAN / UE VM is always higher than that of the 5G core VM. For the two cases where UPF is located with the other 5G core functions, the limitation of the bit rate to saturate CPU is around 150 Mbps (CPU utilization reaches 100%). When UPF is in the CO, this limit reaches 1 Gbps. This is because VM3 is dedicated to the UPF functionality, while VM 1 also provides resources for other mobile core functions.

• Additional uplink latency and jitter are introduced in PtMP due to DBA processing. However, by optimizing the best type of PON T-CONT type, the performance difference between PtMP and PtP could be reduced. We call the reader's attention here that the total capacity PON stays the same, and a high priority for mobile traffic can For the sake of completeness, an additional measurement was performed with a legacy chassis OLT in Figure 6.11 as a reference. The T-CONT is configured as fixed 7 Gbps, assured and best effort 0 Gbps. The common latency is 55 µs and the common jitter is less than 5 µs. The best uplink latency for µOLT is 350 µs and the jitter varies between 5 and 20 µs.

• Since the MEC and UPF entities are implemented on the same disaggregated OLT server, there is a trade-off between latency / jitter performance and resource allocation for each function hosted by the generic OLT server. Such a trade-off is not the focus in this thesis, but can be considered as a deeper fixed-mobile scenario to realize with the help of SDN controllers.

• A data-plane accelerator such as DPDK could dramatically reduce latency if applied on the generic server. Based on our experimental results, the latency of OvS forwarding traffic is somewhere around 100 µs but can be reduced to 10-12 µs with DPDK. In other words, each latency value in Figure 6.10 could be reduced by 90 µs with DPDK. The latency for the 5G air interface is normally around 5 ms for non-time-critical services and could go down to 100 µs for time-critical services [START_REF] Najib | Mission-Critical Machine-Type Communication: An Overview and Perspectives Towards 5G[END_REF]. Thus, in our best case where UPF is in optical access CO and using the PtP topology, the uplink latency at 600 Mbps will be around 200 µs.

According to vertical industry use cases in [START_REF] Gpp | Service requirements for the 5G system[END_REF], the most strict latency demand is realtime control for discrete automation with less than 1 ms, and non-time-critical automotive usage could tolerate up to 100 ms end-to-end latency. So, by implementing the functions of MEC and UPF in the optical access CO with PtP topology, a 1 ms latency is achieved with an optimized resource allocation of VM in the general-purpose OLT server. Moreover, the PtMP architecture could be considered for most use cases with more relaxed latency constraints such as media entertainment, IoT, health, wellness, etc. The specification [START_REF] Inaty | Generalized Multi-Access Dynamic Bandwidth Allocation Scheme for Future Generation PONs: A Solution for Beyond 5G Delay/Jitter Sensitive Systems[END_REF] defines that the jitter for deterministic data delivery should be less than 10 µs for 5G networks beyond. Our best-case experimental result allows for 8-9 µs jitter.

Conclusion

This chapter described the evolution of OLT in access networks in two axes: evolution of a new type of management using SDN technology and implementation of OLT in a generic server using NFV technology.

Our first setup in Section 6.3 used a disaggregated OLT and focused on the feasibility of dynamic control of OLT with a SDN controller. For example, the dynamic allocation could avoid an over-provisioning deployment strategy of OLT in central offices and reduce CapEx and OpEx for operators. We tested a monitor probe for every 800 ms and justified a total reconfiguration time of 2,5 s. Our second setup in Section 6.4 used a generic server to perform OLT functions with help of µOLT. The innovation point of this contribution is that we implemented the mobile core function (UPF) and MEC in the server that hosts the OLT. By co-hosting UPF from mobile network and edge cloud with OLT, we showed an end-to-end latency decrease of 93% and 80% in our real-time test bed with PtP and PtMP topologies, respectively, and 90% and 11% reduction for packet jitter.

We evaluated different vOLT with our experimental work. From an operator perspective, we found out that using the SDN controller for OLT management and generic server to replace the OLT chassis can avoid vendor lock-in EMS in OLT and easily enable deep fixedmobile convergence. A good performance can be achieved in terms of latency and jitter compared to legacy equipment, however, these performances of OLT could have a huge difference according to different vendors' products.

By using generic server in CO, OLT server can hold other edge function (such as UPF function for 5G) and enable the MEC capacity. However, energy consumption is another aspect to study when it comes to edge computing subject. Meanwhile the legacy OLT vendors are studying on MEC enabled solution as well. The white paper from ZTE about a build-in blade server adapted with OLT chassis [START_REF] Zte | OLT Built-inBladeServerWhite Paper 2.0[END_REF] is an example of providing computing capacity in OLT chassis. All these efforts emphasize the importance of vOLT aspect.

Furthermore, OLT today is a layer 2 equipment (MAC layer) without packet routing functionality. With UPF on the edge or MEC implemented on OLT, IP routing becomes necessary; thus OLT is no longer a layer 2 equipment but a layer 3 equipment (IP layer). For layer 3 equipment (i.e. routers), it has to be vigilant about the traffic security since the traffic can be routed easily into Internet with different paths and analyzed by unwanted countries/companies/etc. So far, edge computing-related solutions implemented in OLT raise security considerations for operators.

The performance of vDBA is essential to realize a fully virtualized OLT. However, since the NETCONF commit phase from the candidate configuration to the running configuration needs some seconds, other telemetry protocols can be more efficient for dynamic configuration, such as gRPC [START_REF] Google | gRPC: A high performance, open source universal RPC framework[END_REF]. Some research papers [START_REF] Vilalta | GRPC-based SDN control and telemetry for soft-failure detection of spectral/spacial superchannels[END_REF][START_REF] Sgambelluri | Telemetry-driven validation of operational modes in openconfig disaggregated networks[END_REF][START_REF] Casellas | Advances in SDN control and telemetry for beyond 100G disaggregated optical networks[END_REF] have begun to investigate the telemetry aspect of long-distance transport networks (metro networks), and this remains an interesting topic for future research work.

Chapter 7 Access Networks' Protection for 5G Availability and Reliability

In this chapter, we focus on 5G availability and reliability topics and our contributions to ensure these criteria. We introduce the 5G requirements in terms of availability and reliability, the challenge of the current infrastructure to ensure such requirements and the necessary mobile protection link in access networks in section 7.1. In Section 7.2, we give the general and telecommunication-specific definition of availability, reliability, Mean Time Between Failures (MTBF) and Mean Time To Repair (MTTR) to better understand the 5G requirements on availability and reliability. We analyze related research work in Section 7.3 and present our two protection proposals for mobile protection in optical access networks using the architecture PtP and PON in Section 7.4.1 and Section 7.4.2. We ends with a conclusion for this chapter.

Introduction

The target availability of the 5G access network is expected to reach 99,999% or more depending on certain services, according to 3GPP [START_REF] Gpp | Service requirements for the 5G system[END_REF]. In parallel, 5G requires a very short recovery time. To date, the O-RAN Alliance initiative has defined 50 ms as the recovery time (the repair time needed for service traffic to be sent as usual after breakdown) of xhauling for the data plane regardless of the type of 5G service [START_REF]WG9. Xhaul Transport Requirements[END_REF]. However, 4G and 5G KPIs do not have specific availability requirements [START_REF] Gpp | Requirements for further advancements for Evolved Universal Terrestrial Radio Access (E-UTRA) (LTE-Advanced)[END_REF]. Therefore, the availability of 4G is generally taken as the same as the availability of international Ethernet link SLA, which is generally 99,9% for public customers and more than 99,99% for industries [211,[START_REF] Sabella | Optical transport for Industry 4.0 [Invited[END_REF].

The availability can be affected by each element of all segments of the network. Protection solutions are needed to achieve high availability. We list the current protection status for core, metro and access networks (air interface for mobile and fiber optical access segment).

• Core and transport/aggregation optical networks are recurrently ensured using mesh and ring topologies with Ethernet protocols such as Link Aggregation Control Protocol (LACP).

• The protection link in the optical access network is still relatively rudimentary; To date, no protection link has been deployed. However, it must evolve to meet the needs of next-generation mobile services.

• Each UE is attached to one antenna site at a time; so far, there is no air interface protection link for the availability of UE. Regarding the weak availability of UE, multiple antenna connections for one UE are proposed in [START_REF] Rao | Packet duplication for URLLC in 5G dual connectivity architecture[END_REF] to improve the availability of RAN air interfaces.

Regarding the last miles of fiber-based transport (optical access network), ITU has listed different considerations for PON protection (Types A to D) in fixed access networks [START_REF]Passive optical network protection considerations[END_REF]. Redundancy is a way to protect an equipment or a link by doubling the element with a switching protection mechanism between the primary and the secondary elements.

• Type A protects only the feeder fiber between OLT and the optical splitter by providing a second fiber link in this segment. This solution is dedicated to cover cases of damage to the ODN feeder fiber caused by animal, human or natural events.

• Type B protects the feeder fiber and the OLT equipment by separating the OLT blades or the OLT chassis. The two OLT chassis can be placed in the same CO or at different COs. Automated link monitoring and switching capabilities might be necessary.

• Type C protects OLT, ODN and ONUs. The fully redundant link is provided for subscribers. Double ONUs or double ports in one ONU are both possible.

• Type D combined Type B and C that allow protected ONUs and non-protected ONUs to connect to OLT.

In fact, radio network functions are implemented on different equipment at CO, antenna sites, and possibly intermediary locations depending on the RAN functional split chosen by the operator [START_REF] Line Mp Larsen | A survey of the functional splits proposed for 5G mobile crosshaul networks[END_REF]. The risk of unavailability comes mainly from RAN connectivity: nowadays, CO equipment, which can be an OLT or a layer 2/3 device such as a switch or a router, is connected to each cell site gateway at the antenna premises through a single fiber (employing bidirectional transmissions) by means of a PtP link. Failure can occur when the equipment in CO malfunctions or if the single fiber is cut between CO and the antenna site. Starting from a complaint by a mobile antenna operator, a technical intervention will occur from an infrastructure operator. The recovery time guarantee is usually on the order of hours, depending on the SLA negotiated between the infrastructure provider and the mobile operator. Moreover, the repair starts only from the mobile operator's complaint: If the complaint does not arrive quickly after the fiber has been cut, the recovery time may be longer, and the availability gets worse.

A way to reduce unavailability is to provide redundancy to the network. This can be provided by a protection link, established on an independent path, and an auto-recovery mechanism should be applied between the main link and the protection link for 5G URLLC services in fixed access networks [START_REF] Chanclou | Workshop: Converged 5G and heterogeneous services access networks: How to achieve ultra-low latency and high reliability?[END_REF].

Similarly to Type B protection for PON [START_REF]Passive optical network protection considerations[END_REF], a complete PtP protection for OLT chassis and fiber link is shown in Figure 7.1. A protection link (dotted orange line) from the second PtP blade of OLT in the second CO using a PtP topology can cover outages from both the CO and the physical fiber link. The Inter-Channel-Termination Protocol (ICTP) [START_REF]10-Gigabit-capable symmetric passive optical network (XGS-PON)[END_REF] proposed by ITU is the state coordination between OLTs within the chassis and COs for protection management. However, this solution would need a high CapEx upon deployment and also a high OpEx to maintain the backup site in a different geographical location. Figure 7.1 depicts the most complete but expensive approach. For the sake of conciseness, the protection of OLT by doubling the second OLT in another CO is not further studied in this thesis. We focus on improving the availability of the fiber segment by using OLT blades from the same CO.

The current fiber deployment for access network in France is introduced in Figure 1.7 of Section 1.1.3. Based on this, two possible PtP fiber protection paths for the antenna site are identified in Figure 7.2 noted as orange dotted lines.

The first option, marked with "protection link A" in Figure 7.2, is to use a second fiber and a new trench to deploy the protection PtP link. Therefore, an effort is needed to dig such a trench. The second choice, marked with "protection link B" in Figure 7.2, is to reuse the trench already deployed, which was originally used for residential customers. Since the FTTH fibers are usually over-provisioned by operators. It is possible to not only reuse the trench to connect antenna sites, but also take advantage of the already deployed fibers until the connection airline/underground point. In this case, the protection fiber selected from the FTTH connection point can be a dedicated PtP fiber from the PtP card or one of the PtMP fibers from PON for residential customers. In the latter case, one PON is shared for both residential and mobile services.

Definition of Reliability and Availability

The idea of this section is to specify the definitions of reliability and availability due to the difference between basic definitions and the definitions taken into account in mobile networks. We try to extract the important variables to improve the availability of 5G and use it as an indicator for Section 7.4.1 and Section 7.4.2.

The basic definition is referenced in [START_REF] Morvan | Optical networks[END_REF][START_REF] Tornatore | The challenges of end-to-end network resilience[END_REF] and their expressions are listed below.

• MTBF is the average duration between two consecutive failures of an element (e.g.: a segment of fiber, an OLT etc.).

M T BF = total operational time duration number of f ailures (

• MTTR is the average time needed to repair the failed network element. MTTR is often used as a "recovery time" in technical documents.

M T T R = total f ailed time duration number of f ailures (7.2)

• Reliability is the probability of being fully operational over a period of time. Reliability is related to MTBF and calculated using Equation (7.3):

Reliability = 1 M T BF (7.3)
• Availability is the average probability to be operational at any moment. Availability can be calculated using Equation (7.4):

Availability = M T BF M T BF + M T T R (7.4)
The result of Equation 7.4 is usually written in percentage form, such as 99.9999%. Another way of presenting the availability of 5G is to use the expression "x-nines", where x is the number of nines appearing in the result. Network availability is defined only by the state of the network element, whether it is operational or not. As we can see, QoS is not included in the definition of reliability or availability. In this case, some conditions, such as latency, jitter and bit rate, are needed to complete the requirement of QoS for the next generation of mobile network.

In 5G technical documents [START_REF] Gpp | Service requirements for the 5G system[END_REF], new considerations are added on the definition of availability and reliability. 3GPP redefined "communication service availability" and "communication service reliability" taking into account QoS agreement.

• Communication service availability is the percentage of time that an E2E communication service is delivered with the agreed QoS.

• Communication service reliability is the percentage of packets sent and successfully delivered within the given QoS restriction divided by the total number of sent network layer packets. Communication service reliability reflects the availability of the communication network.

According to [START_REF] Gpp | Service requirements for the 5G system[END_REF], the difference between the communication service availability and the communication service reliability is the concept of E2E. The "ends" here mean the two extremities of the communication link. The communication service reliability refers only to certain network segments (e.g., mobile network segment) without end-node communication interfaces, while the availability of communication services includes all segments. This explains why the reliability is also written in "x-nines" form as the availability in [START_REF] Gpp | Service requirements for the 5G system[END_REF] and is generally less constrained than the availability values. Despite different explanations of availability and reliability, MTBF is a common factor that influences both availability and reliability, the larger MTBF, the better the availability and reliability. In the case of 5G, the smaller MTTR, the greater the availability and reliability of the communication service.

The failure of any network component and the repair time of this element can affect the availability of network services. In access networks, OLT, ONU and optical splitters are not the only source of risk of unavailability; a fiber cut (feeder fiber) can also cause serious service unavailability specially when there is no physical redundancy link and no self-healing mechanism [START_REF] Tsubokawa | Reliability and scalability of access networks with ladder structure[END_REF][START_REF] Chen | Cost vs. reliability performance study of fiber access network architectures[END_REF]. To date, fiber protection has not been implemented in access networks, so our studies focus on providing fiber protection link with an auto-recovery algorithm to minimize the unavailability time thus to improve network availability. We use SDN-based solution to realize this algorithm.

Related Research Work for Optical Access Network Protection

We analyze research articles that focus on the topics of access network protection. PtP, PtMP and ring topologies are candidates to be employed for fiber protection. TDM and Wavelength Division Multiplexing (WDM) PON are two possible technologies when PtMP or ring topology is concerned. A cost-effective reliability analysis was performed early in 2009 for PtP and PON with Type A, C and D protection in [START_REF] Wosinska | How much to pay for protection in fiber access networks: Cost and reliability tradeoff[END_REF]. The article shows that for business users, neighboring connections (two neighboring ONUs protect each other using interconnecting fiber) for PON protection can reach the availability of 99.999% while still being cost-effective. However, Type B protection is unfortunately not addressed. Moreover, if the PtP or PtMP link serves 5G services, a performance analysis should be provided in terms of bit rate, latency and recovery time.

In terms of recovery time, [START_REF] Kang | Restoration of Ethernet Services over a Dual-Homed GPON System -Operator Requirements and Practical Demonstration[END_REF][START_REF] Rafel | Automatic restoration over a type B dual parented PON using VLAN switching[END_REF] demonstrates a recovery time of 30 s and less than 9 s for Type B PON protection using commercial OLTs.

For TDM, WDM PON protection solutions, in [START_REF] Grigoreva | Energy consumption and reliability performance of survivable passive optical converged networks: public ITS case study[END_REF][START_REF] Shahid | Comparative analysis of protection schemes for fixed mobile converged access networks based on hybrid PON[END_REF], a disjoint fiber from the deployed TDM and WDM combined hybrid PON is proposed in different protection schemes. The protection link uses a wavelength different from that of residential customers in the hybrid PON. The paper [START_REF] Yang | Hybrid fiber and microwave protection for mobile backhauling[END_REF] considers hybrid fiber and microwave protection using mobile backhauling based on Wavelength Division Multiplexing PON (WDM-PON). However, an additional optical switch and Arrayed Waveguide Grating (AWG) filter are needed in [START_REF] Grigoreva | Energy consumption and reliability performance of survivable passive optical converged networks: public ITS case study[END_REF][START_REF] Shahid | Comparative analysis of protection schemes for fixed mobile converged access networks based on hybrid PON[END_REF][START_REF] Yang | Hybrid fiber and microwave protection for mobile backhauling[END_REF] using WDM-PON.

Ring topology with WDM/TDM-PON in optical access networks is proposed by [START_REF] Sakaue | Optical path protection with FEC switching in WDM/TDM-PON for ring access networks[END_REF] and an automatic FEC switching function is applied according to the selection of the paths in the ring. In 2021, the theoretical of ring topology design for the optical access network was established in Japan for Innovative Optical and Wireless Network (IOWN) [START_REF] Ntt | Optical access network design theory based on concatenated loop topology was established for supporting IOWN[END_REF].

All references that have just been mentioned focus on a physical layer approach for protection. Meanwhile, SDN can be an interesting tool to provide a protection mechanism at the network layer. Operators aim to apply a pragmatic SDN solution to access networks that benefit directly from the transition phase from legacy telecommunication equipment to a fully virtualized setup.

A recent research paper [START_REF] Pan | SDN Controlled Edge Computing Metro Access Network with Network Slicing and Load-Aware End-to-End Service Protection for 5G Applications[END_REF] in 2020 showed an SDN approach to protect access-metro networks with ring topology. Local traffic protection with guaranteed QoS is realized using orchestrated function in a SDN architecture. However, access equipment such as OLT is not included in their experimental setup. Some other papers have proposed a variety of PON protection and SDN-enabled reconfiguration for Long-Reach (LR)-PON [START_REF] Mcgettrick | Experimental End-to-End Demonstration of Shared N:M Dual-Homed Protection in SDN-Controlled Long-Reach PON and Pan-European Core[END_REF][START_REF] Talli | Technologies and architectures to enable SDN in converged 5G/optical access networks[END_REF]. The idea of LR-PON is to place OLT closer to the core networks with a higher transmission distance and a greater split ratio to extend the fiber sharing with such centralized architecture. It could reduce the initial deployment cost in non-dense areas [START_REF] Ruffini | DISCUS: End-to-end network design for ubiquitous high speed broadband services[END_REF].

In [START_REF] Mcgettrick | Experimental End-to-End Demonstration of Shared N:M Dual-Homed Protection in SDN-Controlled Long-Reach PON and Pan-European Core[END_REF], a dual OLT protection (Type B [START_REF]Passive optical network protection considerations[END_REF]) is proposed near the core network with a feeder fiber of 100 km to PON trees. The SDN controller that uses Openflow to its SBI with a switching time for the protection link around 125 ms. In [START_REF] Talli | Technologies and architectures to enable SDN in converged 5G/optical access networks[END_REF], protection of the feeder fiber is provided for different wavelengths. Openflow is used by the SDN controller and a recovery time of 41 ms is measured. Moreover, a Dynamic Wavelength Allocation (DWA) change for an increased traffic to another PON channel is realized in 250 ms.

Both [START_REF] Mcgettrick | Experimental End-to-End Demonstration of Shared N:M Dual-Homed Protection in SDN-Controlled Long-Reach PON and Pan-European Core[END_REF][START_REF] Talli | Technologies and architectures to enable SDN in converged 5G/optical access networks[END_REF] showed interesting performance in terms of recovery time with SDN controller and Openflow protocol; however, a redeployment of PON feeder fibers closer to the core networks (LR-PON), or a deployment for the second PtP protection link is the way too expensive for telecommunication operators.

Our Proposition for Protection of Mobile Access Network

Different PON for mobile protection were considered in the state of the art of this chapter (Section 7.3), however, reuse of the already deployed TDM-PON for mobile protection is still rudimentary. Furthermore, a CapEx estimation for the protection using a disaggregated architecture OLT is not included, to the best of our knowledge. We concentrated on mobile protection in an optical access network with an architecture based on SDN implementation. We evaluate different performances for data plane, control plane traffic and analyze the CapEx with a disaggregated OLT architecture in CO.

Our proposal for the protection of mobile services in the optical access network will compare the topologies PtP and PtMP since these two topologies are the most widely used and have been deployed in France. In addition, it is worth mentioning that only TDM-PON standardized by ITU is used in this thesis, as it is the family of technologies targeted by some major operators such as Orange.

Three possible fiber access protection schemes are studied: deploying a second PtP link for each antenna site's protection, deploying a dedicated PON for several antenna sites' protection and deploying a shared PON with FTTH services for antenna sites' protection.

• Our first contribution is detailed in section 7.4.1. The first two protection schemes are compared in terms of latency, recovery time, CapEx and energy consumption. The experimental setup uses the disaggregated OLT: µOLT with legacy switch. The related work was published in [START_REF] Wang | SDN-based RAN Protection Solution for 5G, an Experimental Approach[END_REF].

• Our second contribution is detailed in section 7.4.2. The third protection scheme is studied with the focus on 5G self-healing by means of dynamic SLA coordination in OLT. Latency and recovery time are measured for both FTTH and 5G traffic in real time. The experimental setup uses the disaggregated OLT: µOLT with a generic X86 server. The related work was published in [START_REF] Wang | SDN-oriented Disaggregated Optical Access Node for Converged 5G Mobile and Residential Services[END_REF]. NETCONF/YANG [START_REF] Bjorklund | YANG -a data modeling language for the networkconfiguration protocol (NETCONF)[END_REF] switch together with the intelligent µOLT plays the role of the OLT in the CO [START_REF] Simon | Ftth and optical LAN synergy enabled by virtual OLT for home, office and campus[END_REF]. µONUs5.1.2 are chosen for PON protection solution since such a small and flexible module can be inserted directly into the preexisting switch near the antenna site, the cell-site gateway. Thanks to the µOLT and SFP/ONUs modules, no additional equipment is needed on CO or cell-site gateway. An Ethernet traffic generator and analyzer sends and receives 2x10 Gbps traffic to simulate 10 Gbps traffic for two antenna sites.

As previously mentioned in Section 7.1, the protection link is necessary to rapidly reestablish the data plane traffic. Some features already exist in the switch for a redundant solution by configuring an additional port as the protection port: If the primary link is down, the protection port automatically takes over the traffic from the primary port. To do so, both the primary port and the protection port should have the same configuration. Additionally, in this configuration, only one protection port can back up one primary port.

Therefore, characteristics such as Redundant Trunk Groups (RTGs) are suitable for the protection solution of the PtP benchmark in Figure 7.4 (a), where each primary PtP link has its own secondary link as backup. RTG is a proprietary feature from Juniper, it provides a recovery solution between the primary (active) link and the secondary link. When the primary link goes down, the secondary link automatically takes over as the active link, and traffic returns to the primary link when it is repaired. Although RTG is proprietary, there are similar functionalities for other switches [236,[START_REF]CX91x Series Switch Modules V100R001C00 Configuration Guide 08[END_REF]. For the PON protection scenario, only one port of the CO side hosting a µOLT is needed to connect and backup all antenna sites.

In our solution, an algorithm detailed in Figure 7.5 is implemented to monitor traffic in real time: a probe is developed to permanently dialogue with the switch using NETCONF to get the status of the port for every second. If a primary link outage is detected, traffic is redirecting to protection links (here, the PtMP port) and when the primary link is reestablished, mobile traffic goes back automatically to the PtP port.

This algorithm within the SDN controller named VNF in Figure 7.4 (b) communicates with the switch using the NETCONF protocol. This lightweight VNF shown in Figure 7.4 (b) VNF could be placed flexibly on a generic server, such as in a distant SDN controller node or in CO. In order to more accurately compare the recovery time between two methods, we optimized the transmission delay between CO and the distant generic server. This is why the VNF algorithm is implemented in the switch which hosts the µOLT.

Experimental Results of Latency, Recovery Time and Availability

Thanks to a traffic analyzer, we can determine the recovery time for each solution according to the throughput in the receiver port (Figure 7.6). Table 7.1 shows the criteria for the current deployment, including the recovery time target indicated in [START_REF]WG9. Xhaul Transport Requirements[END_REF]. Both solutions provide a remarkable improvement compared to today's sites that need technical intervention, although none of them respects the 50 ms imposed for future usages. The PtP protection solution is quite close; it only needs 150 ms. For the PON solution, NETCONF is the communication protocol used between the physical equipment (switch) and our VNF algorithm. The commit phase, intrinsic to the NETCONF protocol, takes at least 1.5 s, which causes a 2 -4 s recovery time as a result. This could be minimized by using other protocols such as RESTCONF, gRPC [START_REF] Bierman | RESTCONF Protocol[END_REF] [START_REF] Vilalta | GRPC-based SDN control and telemetry for soft-failure detection of spectral/spacial superchannels[END_REF]. The maximum latency of the uplink and downlink during the experimental scenario is presented in Table 7.1. Both solutions have a reasonable latency and they fit well within 1 ms, which corresponds to the most strict latency goal of backhaul and midhaul. Please note that the uplink latency of PON is much larger than the PtP link. This is related to TDMA technology applied on PtMP architecture and the latency depends on performance of DBA and the numbers of ONUs as well. Our next contribution in this chapter 7.4.2 proved the adjustment of T-CONT can reduce uplink latency. Times of failure are calculated for both solutions and the availability is taken from [START_REF] Chanclou | Workshop: Converged 5G and heterogeneous services access networks: How to achieve ultra-low latency and high reliability?[END_REF] and used to provide the last row in Table 7.1.

Cost Analysis in Terms of CAPEX and Energy

Even if the SDN solution proposed here provides relatively fast recovery times (see Figure 7.6), it is less performing than a PtP-based layer 2 solution. The main disadvantage of the solution based on PtP is that it is realized by doubling the number of access nodes for mobile connectivity. Furthermore, the backup port in the OLTs could not be used for other purposes, as the RTG mechanism binds the primary port to the protection port. On the contrary, our SDN controller offers VNF control function to switch with SFP+/PON in the CO. As a result, only one additional port is needed in OLT to protect all mobile PtP links Assuming that N antenna sites are connected to a single CO by a PtP link, then originally N ports are needed at CO without any protection procedure. In case of a PtP-based protection solution, each PtP connection will have a second PtP link as the protection link, which is twice the number of ports (2N). In the proposed PON protection scenario, assuming that the PON split ratio is 64 and N is less than 64, this number is N+1 because only one additional port is needed in CO: all antenna sites around this CO share a single PON architecture. Another important advantage of our solution is that the OLT in the CO is either a conventional OLT chassis with line cards or a layer 2 switch with smart SFP+/PON. When the maximum number of ports per board (line card for standard OLTs or switch for layer 2 based OLT) is achieved, new boards need to be added which introduces necessarily extra expenses. Assuming M ports (for legacy OLT, M = 8) by board, according to the total number of ports previously mentioned (2N for PtP, N+1 for PON), the solution PtP needs ⌈2N/8⌉ boards while PON needs ⌈(N + 1)/8⌉ boards (here ⌈x⌉ stands for the ceiling operation on the number of x to the closest upper integer).

Furthermore are not negligible. The terms and its values are normalized in Table 7.2, helping us to represent the costs and estimates of energy consumption. We chose the L2/3 switch as the reference equipment for cost and consumption. Normalized values are calculated on the basis of real values of our test bed in the laboratory. For example, the total cost of protection in CO is equal to the cost of transceivers m multiplied by the number of antenna sites N with the cost of the switch q multiplied by the required number of boards, which is ⌈N/M ⌉. The formula is provided by Equation 7.5. More generally, the functions of total cost and total energy consumption are listed below.

T otal Cost without P rotection = mN + q⌈N/M ⌉ (7.5)

T otal Cost with P tP P rotection = 2mN + q⌈2N/M ⌉ (7.6)

T otal Cost with P ON P rotection = mN + q⌈N/M ⌉ + n (7.7)

The energy calculation is fairly similar to the cost calculation, except that a represents the energy consumption of an PtP-SFP, b for the energy consumption of an µOLT and e the energy consumption of a switch. = 5 until the cost efficiency cross point at N = 8, the two solutions have a similar cost. The PON protection provides significantly better results of cost than the PtP solution after the cross point of N=8. For energy consumption aspect, the PON solution consumes less energy than the PtP solution starting from 4 antenna sites connected to a CO according to Figure 7.7. In addition, µOLTs and ONUs are energy-efficient modules that can be disabled when not used. By using these modules for protection links, there is as low energy consumption as in the architecture without protection.

Deployment Considerations with Respect to an Actual Network

In this section, we have experimentally compared an SDN-oriented PON with a layer 2 PtP protection scheme for next-generation fixed access mobile site connectivity in terms of recovery time and latency. Both solutions demonstrate remarkable progress compared to today's recovery time (which require a technical intervention, see section 7.1), since they allow for only a few seconds of service interruption compared to today's hour-long reaction times. Nevertheless, none of them fits the 50 ms long O-RAN Alliance requirements yet, although they are more or less close to the maximum required.

The cost and energy consumption of both protection solutions compared to the existing architecture are essential information for telecommunication operators to plan their deployment. In high-density areas in France, a single CO could have more than 10 macro-sites connected to it. Figure 7.8 shows the distribution of the COs and associated antenna in Paris, France, based on Orange data from 2019 (4G sites) [137]. The red links show the logical fiber connections from each CO to the antenna sites. With the deployment of 5G antennas, the number of macro-sites will potentially increase to allow high-performance transmissions with seamless coverage.

In this sense, we performed calculations to quantify CapEx and OpEx in CO and compared each proposition in details. The proposed PON allows energy savings compared to the PtP solution and also allows CapEx reduction if there is more than 9 antennas connected to one single CO, which is very likely to happen according to our field data. As a result, the proposed PON protection solution is a pertinent architecture in dense areas. Furthermore, using a PON solution in dense areas would allow saving space in COs compared to the PtP backup solution, which doubles all infrastructure needed, including the boards in COs.

Civil construction costs related to trenching the protection path from CO to antenna sites were not considered due to the complexity of the calculation in different scenarios (cities, mildly dense zones, green-field areas, etc.). However, it is not hard to estimate that PON could save money since a single trench is shared in the PON feeder segment. Another possibility lies in using more than one PON tree for protection services, in which case each PON tree has fewer antenna sites so that a higher QoS can be ensured if more than one site needs to use the protection link.

Finally, although the SDN approach with PON solution is less effective in terms of recovery time, its topology is much more advantageous in terms of energy consumption and infrastructure cost. Furthermore, since the OLT legacy chassis is replaced by a switch and a modular µOLT, the VNF function could take into account the entire OLT including the backplane of the switch and the PtP and PON connections. This enables a next step towards an evolution in terms of flexibility and scalability in optical access networks.

Shared PON for FTTH Services and Mobile Protection

The Section 7.4.1 used an SDN controller, a µOLT, a layer 2 switch and several PtP/SFPs in lieu of a traditional OLT chassis. Comparison of the PtP protection scheme based on the legacy layer 2 redundancy protocol and an SDN-based PON protection solution with respect to different metrics such as recovery time, latency, power consumption, CapEx and flexibility / scalability has been made. This section continues on this path by using SDN based PON for the protection of mobile access. However, a shared PON for both FTTH and mobile protection service is proposed (see Figure 7.9 (a)). Furthermore, a virtualized switch implemented in the X86 generic server with data plane acceleration tool is used instead of the legacy switch to strengthen the virtualization flavor in our setup.

With more than 700 million FTTH customers around the world today [1], PON is a mature technology that is used for FTTH. PtMP is the main topology for PON. A natural answer for operators is to reuse the widely deployed FTTH infrastructure based on PON technology to provide the protection link to reach 99,999% or more 5G availability (see Figure 7.9 (a)). Compared to the two previous propositions, we propose here to reuse not only the PON technology, but also the deployed fiber infrastructure. Compared to Paris, Rennes is less dense and more representative as a common city in France. Thus, Figure 7.9 (b) shows an example of the density of FTTH access points (red marks) and antenna sites around one CO (green circle) in Rennes. We remark that the number of FTTH access points is much larger than the number of antenna sites around one CO. Furthermore, there are always links available at ODNs to connect antenna sites, since the FTTH deployment is over-provisioned to facilitate operational management (7.1).

Two main challenges appear when one ODN serves both FTTH and antenna services. Firstly, the complexity of sharing the PON infrastructure and the management tool for two separated operators (one for mobile services, the other for residential services). Therefore, this requires an appropriate and dynamic multi-tenancy strategy [START_REF] Kerpez | Fixed Access Network Sharing[END_REF]. Secondly, optimized DBA strategies have to be applied for critical-time mobile services with less latency or jitter. Although this challenge is not the main focus of this thesis, we introduced some related work [138][146] in Section 4.

In this work, we focus on the first challenge, namely the 5G self-healing scenario that allows for shorter service interruption times for mobile services, with respect to SDN control in a convergent fixed-mobile deployment. We propose to reuse the existing PON infrastructure to allow the protection of mobile sites. Moreover, DBA is considered as a black box for operators and operators have no access to modify the algorithm directly; thus we propose to adapt the DBA profiles automatically and on-the-fly (the latter generally being generally statically programmed) to improve the performance.

Description of Proposal and Experimental Setup

In a study realized in our research team [8], the feasibility of sending a mid-haul Packet Data Convergence Protocol (PDCP)-Radio Link Protocol (RLC) [START_REF] Mackenzie | NGMN Overview on 5G RAN Functional Decomposition[END_REF] mobile functional split traffic between a macro-antenna site connected with a PtP link and a small cell connected with a PtMP link has been demonstrated. Here, we experimentally demonstrate a 5G self-healing application followed by a dynamic PtMP bandwidth allocation reconfiguration according to the prioritization policy when mobile and fixed clients are attached to the PON infrastructure. Figure 7.9 (a) shows an SDN-based OLT that serves both mobile and residential clients in PtP and PtMP topologies. Some NFV functions are implemented on the OLT server.

The antenna site is connected to both PtP and PtMP links from the same CO. As shown in Figure 7.10, a probe is developed in the SDN controller to monitor the status of all links every second. When the SDN controller detects a PtP failure, it triggers the reconfiguration of the OLT to redirect mobile traffic to the PtMP protection link and ensures the continuity of all services even if its performance is lower than normal. During the failure of PtP, PON is configured to prioritize mobile traffic; thus, residential customers could temporally experience a best effort QoS service with a minimum guaranteed bandwidth. However, commercial fiber connection offers today, for example, already adapt the streaming quality according to instantaneous available bandwidth. Hence, we consider that a temporally limitation of bandwidth for residential customers is acceptable. On top of PtP failure cases, the proposed architecture can help in case of PtP overload. Lower priority services could be rerouted to the PtMP link to relieve pressure on the PtP links.

As shown in Figure 7.11, our experimental setup consists of three parts:

• The generic server on CO with µOLT employed as OLT [START_REF]Standard for Management Channel for Customer-Premises Equipment Connected to Ethernet-based Subscriber Access Networks[END_REF] and is used for PON management. Based on TibitAPI (see Section 5.1.2), we developed our functions to dynamically configure DBA parameters of each ONU termination. The abstraction layer with a YANG model and a RESTCONF interface for the overall system exists, as demonstrated in our previous work [START_REF] Wang | Dynamic Traffic Management of OLT Backhaul/Service Ports with SDN Controller[END_REF].

Experimental Results

As mentioned previously, our scenario has two key procedures: self-healing of 5G mobile services and reconfiguration of DBA parameters (fixed rate, guaranteed rate, best effort rate) to prioritize mobile traffic SLA during backup periods. The traffic tester generated a flow 5 Gbps to emulate mobile traffic, and a 4 Gbps flow was generated for residential traffic that includes 3 Gbps streaming and 1 Gbp VoIP for both the uplink and downlink from the generator to build the proposed scenario. Figure 7.12 shows the evolution of bitrate and latency over time for each traffic flow, and we can see that DBA could play a major role in latency performance. Furthermore, the recovery time of mobile traffic was evaluated according to the bitrate variations in Figure 7.12. At first, mobile traffic (blue line in Figure 7.12) passes through the PtP link and only residential traffic uses PtMP PON. At the first arrow on Figure 7.12 (12 seconds) we disconnect the PtP fiber to emulate a failure. It triggers the self-recovery procedure to redirect mobile traffic to PtMP PON. Due to FEC, the maximum upstream bitrate of PON is limited to 8.4 Gbps and congestion occurs when 5 Gbps mobile traffic arrives. Therefore, the reader can notice a 4.5 Gbps rate and a 2.5 ms latency for mobile traffic (with packet loss) from the 13th to 23rd second in Figure 7.12. The reconfiguration of the DBA parameters is performed at the time tag corresponding to the 23rd second (arrow 2 in Figure 7.12), from which a guaranteed rate of 5.1 Gbps is assigned to the mobile traffic. We can see that the mobile traffic rate increases to 5 Gbps without packet loss and its uplink latency is dramatically reduced to about 500 µs. However, streaming and VoIP traffic (orange line and gray line in Figure 7.12), which have less priority than mobile traffic, start to have some packet loss and their latency temporarily increases to 3 ms. Besides, the typical uplink latency of our µOLT is about 400 µs. At the third time tag, corresponding to the 31st second (arrow 3 in Figure 7.12), we reestablish PtP fiber connectivity and mobile traffic is automatically rerouted to the PtP link in less than 200 ms. Meanwhile, since the PON bandwidth is released, a reconfiguration of the DBA parameter is done and both the streaming and the VoIP services go back to their initial state in terms of bit rate and latency. Furthermore, if the total uplink bandwidth of PON is not saturated, the stream latency is 319 µs. This value is observed in all traffic in PON with the T-CONT parameters as follows: fixed 0 kbps, guaranteed 128 kbps, and best effort 10 Gbps. Additionally, Figure 7.12 gives an idea of the availability aspect of 5G, since a really short self-recovery time based on an automated control plane with the SDN controller is made possible. Another aspect important is that by controlling dynamically the T-CONT types, we transform the original "set-and-forget" mechanism into a dynamic and can be further optimized solution.

Conclusion

The previous sections proposed approaches to improve 5G availability and reliability, when using access networks as transport solutions. Several protection schemes were discussed, in the context of the current deployment status in France and on the present and future operators' needs. Different approaches are given: a dedicated PON for the protection of non-public mobile networks and a shared PON for the protection of FTTH and mobile traffic.

By comparing the recovery mechanism of our three setups: the RTG in the legacy switch, the VNF protection algorithm within the programmable NETCONF/YANG switch, and the algorithm in SDN controller for the virtualized switch held by an X86 server, we can determine that the virtualized server could achieve recovery performance (around 150-200 ms) similar to a legacy switch. However, due to the delay in a commit phase in seconds, the NET-CONF/YANG interface cannot be used for services that require a dynamic configuration in real time.

In addition to the recovery time, latency and bandwidth measurements for each proposition, a detailed analysis of CapEx and energy consumption has been performed between the protection scheme using PtP and PON. The analysis in terms of CapEx did not take into account the cost of the trench for the fibers due to its complexity and deployment particularities for each area of each country. To give an idea of the case in France according to the French regulator ARCEP [START_REF]Modèle de coût de déploiement des réseaux de boucle locale en fibre optique -arcep[END_REF], the cost of fiber civil deployment is estimated to 110 euros per meter in dense areas. According to [START_REF]Cost Estimates for FTTP Network Construction[END_REF] the price is somewhere around 74 dollars per meter.

The results showed that energy and CapEx is more efficient if more than four and eight antennas are connected through a single PON.

Furthermore, in the second proposition with shared PON for FTTH and mobile services, DBA is dynamically reconfigured by changing the T-CONT parameter from the SDN controller to temporally prioritize mobile traffic. The change in T-CONT impacts not only the bandwidth but also the latency of the traffic, and we showed successfully that bandwidth and latency optimization can be done by reconfiguring T-CONT dynamically.

In conclusion, protection solutions for fixed access networks are necessary for future mobile services that need more than 99,99% availability and less than 50 ms recovery time. The cost of CapEx and energy are not negligible when implementing the protection architecture. Taking advantage of the virtualization trend, our two SDN-based access protection solutions showed a significant improvement in terms of recovery time (around 150 ms) compared to today's intervention time, which is in the order of hours. The recovery performance of the legacy switch using the LAG protocol showed a similar performance to the virtual switch on the generic server using the VNF recovery script, however, LAG is not adaptable if a PON is used as protection link. All of those points undoubtedly demonstrate the interrest in using the SDN solution with its flexible management for the PtP or PtMP protection architecture.

Chapter 8 5G Slicing Coordination Between Mobile and Access Transport Networks

5G is defined to three advanced type of services: eMBB, mMTC and URLLC (see Section 1.2.4). The new 5G service requirements force operators to rethink the deployment of infrastructure and management solutions. To meet those requirements in terms 5G timecritical services (i.e. self-driving cars and industry automation), the 5G tenants developed new concepts, which some are introduced in Section 1.2.3 . The first concept is 5G network slicing, which promises flexibility in the network and performance characteristics tailored to the needs of different markets. The second concept consists of implementing a mobile core function at the edge thanks to a virtualized optical access node. For example, the UPF with data networks on edge mentioned in Section 1.2.3.2 can help some latency and jitter sensitive mobile traffic to reach data networks on edge without going through all metro and core networks. In this chapter, we focus on the 5G network slicing solution and how access TNs can support 5G slicing for mobile services with a seamless cooperation between the mobile and fixed management entities. We call the reader's attention to the converged fixed-mobile infrastructure and explain the necessity of converged fixed-mobile management.

Before starting the conception of our study to realize 5G slicing in access networks, we recall some challenges in fixed and mobile access networks addressed in Part I and we analyze related work about the new management interface in a FMC access network in Section 8.2 to know what are the existed proposals and what study is not yet done. Then in Section 8.3, we give our proposal to coordinate the mobile and fixed access networks to enable the dynamic management (i.e. creation, edition, etc.) of a 5G low latency slice instance. We show our experimental setup and discuss the experimental results. We finish by a conclusion in Section 8.4, in which we give our thought on this subject based on our work.

Introduction

In the past years, when both FTTH and mobile networks were in the early stages of deployment, mobile traffic from the antenna sites went directly to the gateway router without passing through the same equipment (OLT) as residential traffic does. More recently, with the massive deployment of FTTH fiber, fixed and mobile operators have started to be interested in the possibility of sharing the fiber trench, the OLT, the deployed fiber and even the same wavelength in one fiber.

Compared to 4G service requirements [START_REF] Gpp | Requirements for further advancements for Evolved Universal Terrestrial Radio Access (E-UTRA) (LTE-Advanced)[END_REF], ten times more bandwidth [START_REF]IMT Vision -Framework and overall objectives of the future development of IMT for 2020 and beyond[END_REF], more than 99,9999% availability/reliability, ten times less latency / jitter, and massive connections is required for 5G services. On top of that, 6G is expected to achieve up to a hundred times higher in performance for bitrate, reliability, positioning (see Section 1.2.4). PON can be an easy-to-implement and economical candidate to support mobile services, as discussed in Chapter 7. However, there are several challenges in terms of bitrate, latency, control and management etc. So the more possible first step to introduce PON for mobile services is to use PON as primary link for small cells since the services supported by small cells have lower critical latency and throughput constraints than macro antenna sites [START_REF]ITU. 5G small cell backhaul/midhaul over TDM-PON[END_REF] or use as optical access network protection link for antenna sites.

In this case, fixed-mobile infrastructure convergence is introduced in access networks (see Section 4). In order to realize an E2E 5G network slicing [START_REF]3GPP. System architecture for the 5G System (5GS)[END_REF], not only are mobile network configurations concerned, but also different TNs configurations are included. Consequently, the operator's infrastructure and management system should be able to forward different services according to each requirement in equipment as different as OLTs, routers, switches, core functions of the mobile network, or RANs.

In the next section, we provide the work related to two subjects:

• Proposal from standard organizations and research teams on how PON technologies can support 5G services and beyond.

• Studies about control and management cooperation between the 3GPP mobile networks and other transport networks to realize 5G slicing. Actually, there are different interpretations of reusing PON infrastructure for mobile services. We resume them in three points and announce our focus on the last point. The first option is mentioned in Section 1.1.3, that new PtP fibers reuse the fiber trenches and fibers deployed for FTTH. Since PtP fibers from CO to FTTH SAP are usually overdimensioned, some fibers can be directly linked for mobile PtP usages.

The second option is that the mobile service reuses PON infrastructure of FTTH by overlaying PON with another wavelength than FTTH.

The third option is that mobile and FTTH share the PON infrastructure and wavelength resource of PON. In this case, TDM or TWDM PON is the target technology to use, and therefore our contribution is to focus on the third option.

The reuse of TDM PON technologies to support 5G services attracts the attention of different standardisation groups and telco, vendor consortia. ITU-T and Fifth Generation Fixed Network (F5G) are currently contributing on the PON slicing subject. In [START_REF] Itu | Network slicing in a PON context[END_REF][START_REF]Fifth Generation Fixed Network (F5G); F5G Network Architecture[END_REF], the transport of 5G services in PON is considered, and the parameters to use for 5G slicing in PON are discussed, such as VLAN and T-CONT. O-RAN Alliance proposed the CTI to reduce uplink latency in PON for 5G traffic. The CTI enables the cooperation between mobile and PON schedulers and is achieved by Co-DBA, which optimizes PON uplink traffic allocation according to the mobile applications (see Section 4). Different interfaces between RAN equipment have different latency and bitrate criteria. Thus, XGS-PON may potentially support backhaul or midhaul interfaces and some related work is given in [START_REF] Samuel | Performance of PON Dynamic Bandwidth Allocation Algorithm for Meeting xHaul Transport Requirements[END_REF][START_REF] Chanclou | FTTH and 5G Xhaul Synergies for the Present and Future[END_REF]. A discussion of the cost-effective choice to support the backhaul/midhaul traffic of small cells between TWDM NG-PON2 and WDM-PON can be found in [START_REF] Weis | Assessment of fixed mobile converged backhaul and fronthaul networks[END_REF][START_REF] Gosselin | Converged fixed and mobile broadband networks based on next generation point of presence[END_REF][START_REF] Buttaboni | Virtual PON assignment for fixed-mobile convergent access-aggregation networks[END_REF]. These papers assess the mobile traffic over Time Wavelength Division Multiplexing PON (TWDM-PON) by isolating wavelength or by optimizing the time efficiency in PON. The authors in [START_REF] Das | Optimal virtual PON slicing to support ultra-low latency mesh traffic pattern in MEC-based Cloud-RAN[END_REF] discuss the choice of optimal virtual PON slice allocation in PON for fronthaul usages.

All these proposals try to use PON for mobile traffic. However, OLT may not be able to provide a stable and optimal low latency slice instance based on currently existing DBA performance with T-CONT configurations.

Management Cooperation Between Mobile and Fixed Networks

With the development of virtualization technologies over the last few years, the management system of access networks is in full evolution as well. As mentioned in Section 3, the two reference projects SEBA and CloudCO have their SDN controllers that interconnect orchestrators and infrastructure equipment using NBIs and SBIs. However, details on an eventual cooperation interface between mobile and residential entities (software or hardware) at the level of SDN controllers are not included. Meanwhile, 5G slicing applications require such an interface to realize the E2E slice instance and the dynamic interaction with all relevant TN equipment. Figure 8.1 gives a panorama of standard organizations' efforts on fixed and mobile management coordination. Network slicing layers (see Section 1.2.3.1) are presented in gray on background of all functions in this figure. Based on 5G physical layer functions and TN, management layer functions for 5G slicing are shown in different colors. 3GPP management functions are colored orange, non-3GPP parts' (i.e. IETF and BBF) contributions are colored green and blue, respectively.

The IETF specifications [START_REF] Farrel | Framework for IETF Network Slices[END_REF][START_REF] Flinck | Network Slicing Management and Orchestration[END_REF][START_REF] Geng | Network Slicing Architecture[END_REF] propose a reference network slicing architecture which include the control and management architecture. On the left of Figure 8.1, a summary scheme (in green) from our comprehension is given. IETF Network Slice Controller (NSC) is identified with its NBI (IETF Network Slice Service Interface) and SBI (Network/device configuration) to connect customer high-level operation system (indicated as BSS/OSS in Figure 8.1) and physical network functions, respectively.

3GPP and BBF works are presented on the right of Figure 8.1. Basically, 3GPP network slicing management distinguishes Network Slice Management Function (NSMF) and Network Subnet Slice Management Function (NSSMF) for high-level slice information and corresponded slicing realization of mobile network entities. The NSMF and the NSSMF's po-Figure 8.1: An analysis of the coordination efforts made between the 5G and TN management systems for 5G slicing from 3GPP [START_REF] Gpp | 5G;Management and orchestration;Concepts, use cases and requirements[END_REF] (in orange), IETF [START_REF] Farrel | Framework for IETF Network Slices[END_REF][START_REF] Flinck | Network Slicing Management and Orchestration[END_REF][START_REF] Geng | Network Slicing Architecture[END_REF] (in green), BBF [259] (in blue). sition in the traditional TMN architecture [START_REF]Principles for a telecommunications management network[END_REF] can be considered as BSS/OSS and Network Management (NM)/Element Management (EM).

The "TN Mgnt Sys" in Figure 8.1 is at the same level of NSSMF for TN control and management. Since this entity is not included in 3GPP management system, an interface should be established between "TN Mgnt Sys" and 3GPP management system to realize 5G slicing in TNs. BBF specifies the connections in Figure 8.1 in blue in order to align with IETF's work on network slicing [259]. Additionally, Mobile -transport network slice Management Interfaces (MMI)'s requirements are given by BBF for a mobile and transport network communication, but no more precision is given about whether NSMF or NSSMF should communicate with "TN Mgnt Sys" and in which case. So far, O-RAN Alliance is working on the management interface for transport network elements with some use cases [START_REF] Oran | Management interfaces for Transport Network Elements[END_REF]. However, there is still no standard definition of the fixed-mobile coordination interface.

As far as research works are concerned, contributions on the transportation of 5G interfaces over optical access networks have been proposed. The contribution [START_REF] Das | Virtualized EAST-WEST PON architecture supporting low-latency communication for mobile functional split based on multiaccess edge computing[END_REF] considers the use of TWDM-PONs to connect antenna sites to better adapt future access networks. An East-West communication is created inside OLT to offload mobile traffic from ONUs to other OLTs according to reflected wavelength. However, no consideration on how the 5G core communicates with the OLT and coordinates with TWDM-PON TN to achieve the slice instance is given in this paper. The paper [START_REF] Matrakidis | A Converged Fixed-Wireless TDMA-based Infrastructure Exploiting QoS-Aware End-to-End Slicing[END_REF] uses T-CONT as the parameter to realize mobile traffic slice in PON, and our previous work [START_REF] Wang | SDN-oriented Disaggregated Optical Access Node for Converged 5G Mobile and Residential Services[END_REF] experimentally shows dynamic reconfiguration within OLT to prioritize mobile traffic using T-CONT (see Chapter 7). The T-CONT could be reconfigured for 5G slicing in access transport network, but the separated mobile and fixed SDN controllers or a cooperation interface between the fixed and mobile management entities has not been proposed and evaluated in both [START_REF] Matrakidis | A Converged Fixed-Wireless TDMA-based Infrastructure Exploiting QoS-Aware End-to-End Slicing[END_REF][START_REF] Wang | SDN-oriented Disaggregated Optical Access Node for Converged 5G Mobile and Residential Services[END_REF]. Furthermore, in this experiment, no 5G core slicing function is implemented to coordinate the slicing information (SST value) with access TN. Paper [START_REF] Martínez | Experimental SDN control solutions for automatic operations and management of 5G services in a fixed mobile converged packet-optical network[END_REF] proposes the SDN/NFV orchestration architecture to address upcoming 5G challenges in a fixed-mobile converged network. The solution addresses the management layer of the core/metro/access network without applying the reconfiguration of the PON infrastructure layer. The paper [START_REF] Suvidha Sudhakar Mhatre | Slicing enabled 5G experimentation platform for the Robotics vertical industry[END_REF] analyzed the end-to-end slicing architecture based on references from 3GPP and IETF. Their experimental test bed gives an example of vertical-oriented slicing of 5G RAN. However, we notice that none of these works propose an interface between the transport access network and the SDN controllers of the mobile network. Our proposition of a cooperative interface between fixed access network and 3GPP 5G network to realize 5G slicing will be given in the next part Section 8.3.

SDN-based Cooperation Interface in a Converged

Fixed-Mobile Access Network for 5G Slicing

Proposition

Our proposition involves an "East-West" interface between fixed and mobile SDN controllers for a dynamic reconfiguration enabling 5G slicing over optical access TN. To the best of our knowledge, this is the first time an interface has been experimentally demonstrated to establish direct communication between fixed and mobile SDN controllers.

The proposed architecture with a 5G slicing reconfiguration procedure is given in Figure 8.2: In this figure, 3GPP related mobile entities use orange-colored rectangles and fixed access network parts use gray-colored rectangles. The SDN control layer connects the orchestrator layer through its NBI and connects the infrastructure layer with its SBI. Since the current mobile and fixed management system is entirely separated, two SDN controllers are separated in the control layer as well. However, an East-West interface (see Figure 8.2, the interface is highlighted in green) exists between mobile and fixed SDN controllers.

Two ways of realizing the slice instance for fixed access transport network will be ex-plained in the following paragraphs. We realized the second one experimentally by using our proposed East-West interface because we believe that such an East-West interface offers a more efficient and rapid configuration for the realization of 5G low-latency slice instances than the orchestrator does with a "regular" north-south interface. This is due to a certain latency that can be introduced for each interface whatever between the SDN controllers or between the control layer and orchestrator layer. Also, we suppose that the SDN controller is closer to physical equipment than orchestrators in a network infrastructure.

The first method and the associated steps are indicated in red in Figure 8.2: in step 1, the 5G NSMF function in the orchestrator initiates the creation of slices and pushes the creation of the slice instance toward the NSSMF function inside the mobile controller SDN. The mobile controller communicates with the 5G core NSSF for the information of the mobile profiles, then translates the value of each profile SST in step 3 and responds to the orchestrator. The orchestrator then communicates with the TN SDN controllers to trigger the corresponding SST in step 4.

The second way to deploy an instantaneous network slice instance is indicated in green in Figure 8.2. In this case, once the NSMF in the orchestrator receives the slice creation order from the operator, it communicates with the NSSMF from the mobile SDN controller in step 1. The mobile SDN controller gets the current profile's SST information in step 2 and communicates directly with the fixed SDN controller for further reconfiguration in the TN using an "East-West" interface between the mobile and fixed SDN controllers in steps 3 and 4. By using the proposed East-West interface, there is no need to go through the orchestrator layer (NSMF) for the slice configuration to reach each network segment, so an instant slice can be created between the two NSSMFs developed inside the mobile and fixed SDN controllers.

Experimental Setup and Scenario

We will describe the implementation of our setup based on ONF's reference architecture [START_REF]Software-Defined Networking (SDN) Definition[END_REF] and will detail the procedures for this scenario. As depicted in Figure 8.3, our experimental test bed uses an open source 5G core project and a disaggregated OLT at the infrastructure layer. We develop the SDN controllers and the orchestrator to coordinate the control of the mobile and fixed networks. We will start with the infrastructure, then we will detail the SDN controller, and finally we will cover the orchestration layer.

Infrastructure Layer

The infrastructure layer consists of three network segments: core network, metro network, and access network. In the following paragraphs, we describe our main contribution, which is focused on the optical optical access network. Since we identified the importance of (re)using PON for mobile access networks in Part I, this setup continues using PON topology to connect antenna sites together with FTTH services in a single PON ODN. . We implemented a standalone 5G core in a virtual machine (using a Linux operating system) called VM 5GCore (Figure 8.3, bottom left side) on a generic server (see Section 5.2). Among the numerous core functions, we concentrate on two functions: UPF and NSSF. The UPF ("UPF #core" in Figure 8.3, bottom left side) is the data plane gateway for 5G mobile networks (see Section 1.2.3.2). UPF's placement in the network (in the core network or at the edge) is important for time sensitive 5G services. If the UPF and the data network are both hosted in the OLT, the latency and jitter impact of the metro network can be excluded. This is a considerable advantage brought about by a virtualized OLT implementation. Our contribution in Section 6.4 measured the data plane traffic's latency and jitter performance with UPF at core network and at the edge. In this chapter, we keep the UPF at the core network with all other 5G core functions. The NSSF is the service responsible for the slicing configuration. In our test bench, a Mongo database hosts all the data of the 5G core functions, including the UE traffic profile information from NSSF. We interact with this database using the Python Mongo client.

For the sake of being realistic, we also emulated the metro network, separating the core from the access. The metro network is approximately 500 km in France and is shown in gray in Figure 8.3. Our contribution detailed in Section 6.4 used a real-time latency and jitter simulator equipment to emulate the 500 km metro network and measured the total latency/jitter between the 5G core and UE using PtP and PtMP architectures in access networks. In this chapter, we bypass the metro network without added latency/jitter since we focus on the slice application in access networks.

The access network is composed of three parts: a disaggregated and partially virtualized OLT (made from a µOLT and general server see Chapter 5), a PtMP PON infrastructure for FTTH and antenna sites, a RAN and UE emulator implemented inside the VM called VM RANUE in Figure 8.3. We recall that all traffic from 5G core functions is sent out to other equipment with physical interfaces on the generic server (see Section 5.2).

Control Layer

The SDN control layer (Figure 8.3, middle) consists of the mobile SDN controller, the fixed access SDN controller and the East-West coordination interface between the two controllers. Compared to ONF and BBF architectures, our SDN control layer comprises different adapters for the vendor-specific protocol in the mobile/fixed equipment on the SBI for different specific mobile/fixed protocols.

The Mobile SDN Controller interconnects the 5G infrastructure and the orchestrator. We explain the functionality of each block inside the mobile SDN controller represented in the left part of Figure 8.3, starting from the SBI, towards the NBI. The 5G core adapter is responsible for mobile SDN controller's SBI that connects to the database of 5G core network using a Transmission Control Protocol (TCP) session coded in Python provided by Mongo database. The RAN adapter is linked to the simulated RAN and UE through SBI. The slicing application inside the mobile controller is an equivalent entity to the NSSMF which plays the role of Network/Elements Management (NM/EM) for slice FCAPS tasks. It includes a client agent with a TCP socket for East-West coordination to provide slice information from the 5G core database to the fixed access controller. The REST API agent connects to the orchestrator using its NBI. An abstract of slice information written in the simplified YANG model file is exposed to the orchestrator thanks to the REST API. In our test bed, only the configuration aspect is implemented without all the FCAPS functions (e.g., security aspects were not implemented), allowing us to realize the network slicing scenario.

The Fixed Access SDN Controller, which interconnects the OLT and the orchestrator, is shown on the right part of Figure 8.3. The fixed access network has the OvS, µOLT and ONU adapters in the south with their SBI, and the REST API agent in the north for NBI. OvS adapter communicates with OvS using Openflow since Openflow client is implemented inside OvS on generic server. The NBI is based on a REST API for its relative simplicity in terms of implementation.

The East-West Interface socket server, named NSSMF slicing application in Figure 8.3, continuously listens to requests from the mobile operator represented by mobile SDN controller on the figure. Once the update slice information is received from the client side (NSSMF on the left side of the mobile SDN controller), it triggers the access TN slice template. To be precise, this slice template detects the received SST value and automatically reconfigures the T-CONT parameter needed to ensure the creation of the TN slice on the OLT equipment. It is worth to note that the current management system applies a "set-and-forget" policy without a dynamic reconfiguration mechanism according to the instant slice. This network slicing application on the fixed access controller is equivalent to NSSMF for the access TN node in Figure 8.1. With intelligent functions developed on each side of the NSSMF and the East-West interface, a 5G low-latency slice instance for access TN can be configured automatically. However, this prioritization of traffic could temporarily downgrade other services in the PON.

Orchestrator Layer

The orchestrator layer in this paper has a simple REST client to perform CRUD actions related to the mobile and fixed access control layer. Web visualization is enabled for NSMF applications.

Procedures in Our Scenario

We set up the dynamic coordination between the mobile controller and the fixed controller for TN reconfiguration using our East-West interface. Apart from the impact of the 5G URLLC service performance with respect to the UPF's location, the optimized TN slice is also an important factor. Since the simulated RAN and UE have no air interface, the radio protocol layers are not encapsulated in our 5G traffic.

To better understand the highlighted arrows in green in Figure 8. In our proposition, the network slicing deployment procedure can use the following steps:

• In step 1, the NSMF at the orchestrator activates the auto-configuration algorithms inside the NSSMFs at the mobile and fixed SDN controller. The related modules for slicing are triggered to realize the East-West interface communication between the mobile and fixed SDN controllers.

• In step 2, the Mobile SDN controller NSSMF queries the 5G core database for the current slice's configuration of each registered International Mobile Subscriber Identity (IMSI) via the 5G core adapter. Once the message is returned in step 3, the YANG model inside our mobile SDN controller is updated and the mobile NSSMF sends this information via the East-West Interface to the fixed access SDN controller in step 4.

• The slicing profile sent in step 4 reaches the fixed SDN controller (which is permanently listening) through the East-West Interface. In step 5, a local slice template of SST and OLT T-CONT parameters is triggered for an optimized reconfiguration of the OLT.

• In step 6,The Fixed SDN controller uses the µOLT adapter to push the configuration to the µOLT and to the ONUs via the OMCI interface. Meanwhile, since the OLT configuration is changed, the fixed access YANG model in the SDN controller is autoupdated. This action shows that the SDN controller is the referenced configuration in our setup.

The communication between the mobile SDN controller and the fixed/TN SDN controller through the East-West interface has no need to go through the orchestrator. However, the orchestrator, in a more general architecture, could consult the current configuration of the whole network since the YANG models are always updated.

We justify here the choice of using the T-CONT parameter in OLT to carry out the TN slicing, along with the possible risks of this strategy (see Section 1.1.5). Generally, the fixed T-CONT option reserves a fixed bandwidth for each burst, so it has the best latency and jitter performance, but it is also the most bandwidth-hungry option. The assured T-CONT option provides the necessary bandwidth without permanently reserving bandwidth. The best effort T-CONT option only delivers information when it is possible, without any guarantee. Thus, the DBA algorithm could directly affect the uplink latency/jitter, and the T-CONT type could indirectly impact the uplink latency/jitter. Due to the TDMA mechanism and the DBA algorithm's processing delay, the PON uplink latency and jitter are much higher than the downlink latency. In the current deployed infrastructure, the DBA algorithm is provided by the equipment vendor and the operators depend on its implementation. Therefore, the only reasonable way for an operator to optimize uplink latency and jitter is to use the T-CONT type.

It was already demonstrated in Chapter 7 that adjusting the type of T-CONT can improve uplink latency and jitter in PON. Here, we complete more latency and jitter measurements and try to vary the bit rate and packet length to see the impact of T-CONT on those aspects. However, the DBA algorithm's performance could be different from one vendor to another, so operators should use the T-CONT types for 5G services in PON with caution. In other words, Class of Service (CoS) in optical access networks for slicing deserves a clear definition regarding the performance of bit rate, latency, jitter, etc.

Furthermore, in the paper [START_REF] Wang | SDN-oriented Disaggregated Optical Access Node for Converged 5G Mobile and Residential Services[END_REF] we noticed that such an approach would impact FTTH clients from the same PON ODN when a T-CONT changes temporally for 5G services, hence 8.6. With TDM mechanism, downlink latency (purple line) is always around 300 µs in this setup using µOLT. The orange and blue colored zones before and after the 19th second in Figure 8.6 show the applied "no priority type" T-CONT and the applied "priority type" T-CONT. We noticed that a decrease by 200 µs in the uplink latency around the 19th second is obtained when the network slicing requirement is deployed by the fixed access network's SDN controller and a reconfiguration is sent to the OLT. The results thus showed the correct dynamic deployment of a latency-optimized network slice instance employing state-of-the-art OLT for mobile transport, using a real 5G core.

Since the T-CONT type is designed to ensure the uplink traffic bandwidth needs, latency and jitter performance may not be stable if packet length and bit-rate change. In Figure 8.7, some complementary measurement results are given by varying not only the "priority" T-CONT type and "no priority" T-CONT type, but also the packet length and bit rate. First, 1500 bytes for Maximum Transmission Unit (MTU)-size packets and 100 bytes for small packets are tested by sending 100 Mbps traffic. Second, 100 Mbps, 500 Mbps and 1 Gbps are measured for 1500 bytes traffic.

As shown in Figure 8.7, despite the different bit rates or packet lengths chosen, the difference between the uplink latency for priority T-CONT type and no priority T-CONT type is always around 200 µs and corresponds to 25% of the no-priority traffic's latency. The uplink jitter has no significant changes between the two types of T-CONT chosen in this experimental test; however, a reduction in jitter is observed for small packets. Although changing T-CONT can improve the uplink jitter as shown in Figure 8.5 with legacy OLT , it is difficult to tuning precisely the performance of µOLT without access to the algorithm DBA. The downlink jitter is stable and around 0,1 µs and 0,2 µs. It is important to note that in our test bed OLT is connected to a limited number of ONUs (one ONU in Figure 8.7), so latency and jitter performance could be further affected with a large number of ONUs in a real deployment.

In summary, our tests show that uplink latency and jitter performance change with different packet lengths and bit rates, even when the same T-CONT is used.

Conclusion

Re-using the already deployed PON architecture for FTTH appears to be a better candidate than deploying a new PtP architecture to more rapidly ensure 5G availability and reliability. Some 5G time-sensitive services, such as self-driving cars and industry automation, need a slicing E2E network to ensure critical latency and jitter requirements. The E2E reconfiguration for 5G slicing should be realized in different transport networks as well as 3GPP defined mobile entities. Since we discussed the reuse of FTTH PON to carry mobile services, the entire management system should also evolve to cope with the new features of the mobile transport network. The evolution of virtualization technologies gives the opportunity for the evolution of management systems.

In this chapter, an East-West interface was proposed to enhance the collaboration between fixed access TN and the 5G mobile network. The proposed interface partially fills the gap required for the mobile network to dynamically instantiate network slices over optical access network technology. A PoC of this coordination between the fixed access TN and the 5G core network has been experimentally demonstrated. The dynamic reconfiguration of access TN according to the SST given from the 5G core was shown. We have demonstrated that it is affordable to reduce latency up to 50% by dynamically tuning the DBA parameters (here, the T-CONT type) in the access TN networks. This shows the first step of using PON for URLLC applications. However, to send time-sensitive services via a PON solution, CoS in PON for 5G slicing deserves a clear definition regarding the performance of bit rate, latency, jitter, etc.

T-CONT types can impact uplink latency and jitter performance in PON and we observed that a priority T-CONT provides better performance than a guaranteed T-CONT. However, the degree of improvement that is provided by applying a priority T-CONT instead of an assured T-CONT depends on vendor-specific DBA algorithm. Hence, the DBA algorithm should be re-studied to provide a stable and optimal 5G mobile traffic slice in the PON infrastructure. As the performance of the type T-CONT depends on the specific implementation of OLT of different vendors, we also conclude that if PON is used as a transport solution for low latency and low jitter services, the algorithm DBA needs to be redesigned with CoS that satisfies the demands of 5G standardization instances.

Our study focused on the 5G network slicing deployment employing optical access networks as a transport medium. We showed the feasibility of the East-West interface between mobile and fixed SDN controllers. Theoretically, the communication of the slice requirement between the two SDN controllers is faster than passing through the centralized orchestrator between these two entities. However, this could depend on the position of SDN controllers, orchestrator and the hierarchy organization for SDN controllers in the network infrastructure. For this reason, further study can be launched taking into consideration the physical position of SDN controllers and orchestrators.

General Conclusion and Perspectives Conclusion

Our research in this thesis was driven by two keywords, "virtualization" and "fixed-mobile convergence". We made different proposals in optical access networks with SDN architecture for FMC scenarios, while using disaggregated or virtualized equipment. We also paid attention to the aspects of cost and energy efficiency for some contributions, although they were not the main objectives of this thesis.

In Part I, the state of the art of the current technological contexts and research of optical access networks, virtualization technologies and FMC were detailed in three chapters.

Chapter 1 provided the current status of access networks in the infrastructure layer. As shown in Figure 8.8, OLTs are used today to collect both residential and mobile traffic. However, only a single PtP link is deployed today from the CO to antenna sites, and this single link can hardly meet the very high availability requirements in access networks of some 5G services (e.g., five-nines availability for URLLC services). Also, we showed that the evolutions of PON technologies and mobile networks are decorrelated, even if they may exploit the same equipment (OLT). The legacy dedicated OLT chassis is not flexible enough to host new edge or cloud functions for future mobile services.

Chapter 2 explained the current management system and its limitations to support future services. As detailed in Figure 8.8, the proprietary management system used today (EMSs shown in Figure 8.8) is not cost-effective enough for operators because some upgrades and equipment configurations are completely dependent on EMS provided by vendors. Operators then have to choose between being locked with management systems provided by vendors or spending time and money to develop their own. Chapter 3 detailed the initial motivation of the virtualization concept and how it spreads into access network. Actually, SDN and NFV technologies are key enablers in addressing some limitations with the current architecture for future services. However, how to correctly apply each of them on optical access networks remains an important challenge. In this chapter, a summary and a comparison of the two most popular projects, CloudCO and SEBA, are given.

Starting from an OLT that collects both the traffic from FTTH clients and antenna sites, FMC begins its journey to eliminate the frontier between the world of fixed and mobile in optical access networks. FMC can help operators deploy and manage their networks in a more flexible way. Thus, operators could benefit more from converged fixed and mobile infrastructure and management faced with more strict services requirements. Chapter 4 summarized the efforts to better converge fixed and mobile networks by indicating the chal-Figure 8.8: Current access network with legacy infrastructure and management system. lenges that remain. Typically, in the management and control layer, current management entities cannot easily automate the cooperative configuration between the mobile core and OLTs for access networks. However, such cooperation is essential to ensure the emerging application of slicing in 5G or other future access networks).

Contributions in this thesis are included in Part II that focused on the challenges mentioned previously. Four chapters are included in this part and we summarize in Figure 8.9, all of our work is based on the future architecture of access networks that benefit from SDN and NFV technologies.

The experimental test bed was presented element by element in Chapter 5. Among others, we observe that by implementing OvS with DPDK on a generic server, we can reach a similar switching performance in terms of latency and jitter than a legacy OLT.

Chapters 6, 7 and 8 regrouped our contributions into three mobile/fixed convergence possibilities indicated with yellow triangles in Figure 8.9. The following list details our work related to converged services on disaggregated or generic server, converged fiber infrastructure and converged control and management system in order.

• The already existing fixed and mobile convergence approach in access networks was brought about by the deployment of legacy OLT with PON and PtP cards. Since both fixed and mobile traffic are going through the same OLT within a CO, a deeper convergence at the level of CO can be conceived by replacing a legacy OLT by a disaggregated or a virtualized OLT. In this way, the generic server inside COs can hold edge functions, mobile core functions in addition to the basic OLT functions. Virtualization technologies are essential keys to realize such a scenario, therefore, our study in Section 6.4 demonstrated a MEC and UPF compatible OLT for time-critical 5G mobile services with around 140 µs latency for upstream traffic in the best case. However, with UPF (layer 3 routing capacity) inside the OLT server, some security concerns about IP traffic routing strategies are raised since the virtualized OLT is not a layer 2 equipment that is transparent to service providers and operators any more. This is left for future research.

• The second convergence point given in Figure 8.9 is also in the infrastructure layer but for the passive architecture (optical fibers and splitters). With the massive deployment of PtMP fibers for FTTH, the reuse of PON for mobile services can be cost efficient for operators to increase the service reliability. This experimental test bed was established in Chapter 7 with both PtP and PON solutions to provide the protection link. We concluded that for more than 4 antenna sites connected to a PON tree, energy efficiency point is reached and for more than 8 antenna sites, cost efficiency point is reached. Furthermore, to better organize resources in PON for mobile and residential services, we explored the dynamic reconfiguration of QoS. As the DBA algorithm is proprietary, the only possible uplink QoS parameter for operators to modify in PON is the T-CONT. The T-CONT is the input parameter of DBA that is used to define the priority of bandwidth allocation. Although the T-CONT configuration follows "setand-forget" rules today, we proved that it is certainly possible to dynamically adjust the T-CONT parameter thanks to the SDN controller. Operators should be vigilant today that the performance of each T-CONT differs from vendor to vendor, as the underlying algorithm is not standardized. Without a standard, operators cannot apply this strategy and ensure QoS, since the minimum assured latency or jitter performance of a T-CONT is undefined.

• The third convergence point occurs in the control and management layer. Unlike the traditional management layer indicated in Figure 8.8, where the data and control plane configurations (reference configuration) are embedded in the chassis OLT, in an SDN architecture, the reference configuration is separated from the physical equipment to the SDN controller as indicated in Figure 8.9. This is also due to the separation of the control plane from the data plane, which is originally defined by the SDN proposal to deploy unified network configuration with ease. In Chapter 8, we identified two key elements to enable mobile network slicing when employing the optical access networks (e.g. the deployed PON as mobile transport networks). First, it is required to develop standard interfaces between the 3GPP mobile networks and all TNs. Secondly, in order to meet the strong E2E latency constraints required by 5G services (e.g. self-driving cars), an adaptation in the optical access networks is required. Moreover, if PON is used to transport mobile traffic, the upstream SLA for each slice need to be defined clearly instead of tuning T-CONT that impacts the proprietary DBA inside the OLT.

Perspectives

Whatever the form of the network deployed for mobile or fixed use, one of the main objectives of network operators is to provide the best user experience with various services.

To achieve this goal, operators must take into account cost, energy and other criterias. We evaluated virtualization technologies in optical access networks and proposed some scenarios to eliminate the barriers between fixed and mobile network architectures in both the data and control planes during this thesis. In the following, we give some perspectives based on our work. When TDM/TDMA PON is reused to support 5G or 6G mobile services, the existing T-CONT parameters in PON can be adjusted to better support mobile services with critical latency and jitter criteria. Although it can indirectly impact latency and jitter, the performance is not stable enough to support mobile services as mentioned above. Moreover, as mentioned above, DBA is proprietary in presently-deployed networks and operators do not have control over it, which complicates the organization of time slots for mobile usages. To solve the mentioned problem, Co-DBA was proposed to solve the uplink latency problem in PON, (although this concept is still to be demonstrated at the time of writing). Otherwise, the use of WDM-PON instead of TDM/TDMA PON to support converged fixed and mobile services could be a possible alternative solution.

Furthermore, operators wish to avoid vendor lock-in solutions; however, will vendors lose their competitive strength and motivation for innovation without producing proprietary solutions? Meanwhile, one of the goals of SDN and NFV is to provide an open and more flexible solution for operators faced with technology evolution and different vendor solutions. However, will SDN-compatible equipment and control platforms become the new vendor locked-in "EMS" for operators?

A possible option to benefit from the advantages brought by new technologies with less security or vendor lock-in concerns is to first target the market of private networks, introduced with 5G. This is specially the case of implementing the private UPF and MEC for private campus (industry, university, harbor, etc.)

Finally, we hope that a compromise will be achieved at a certain level among vendors, operators and standardization organizations to release new technologies and help people better benefit the best deal in the future. Among all these, may researchers continue to think dialectically and use their passion and their work for a better world. • Only one ONU is connected to the used PON port.

• Packet length is 1500 Mbytes.

As we can see, some latency and jitter values are extremely high. This is because of a packet loss occurs and the traffic analyzer takes into account the waiting time for all packets.

The assured and best effort performances are very similar when there is no packet loss. The typical uplink latency is around 450 µs.

A.2.2 Recent Firmware

Figure A.5 shows the latency and jitter performance of Tibit µOLT with the recent upgraded firmware at the end of this thesis in 2022. This time, we take into consideration of the different packet length at 100, 500 and 1500 bytes. The measurements have been done with the following configuration:

• Only one ONU is connected to the used PON port.

• T-CONT configurations are set to 4Gbps with fixed, assured or best effort option.

We remark that the packet length has minor influence on latency but a huge influence on jitter. Moreover, compared to the Tibit old µOLT firmware, both latency and jitter performances are improved. The most encouraging improvement is that with the new firmware, fixed type T-CONT has the best performance than assured or best effort types as it was not the case with the old firmware. In this work, solutions are proposed and evaluated with an experimental test bed developed during this thesis. Firstly, we reused FTTH infrastructure as protection link to meet strong availability requirements of mobile services with minimum deployment effort from operators. Secondly, we realized down to 140 µs uplink latency for timesensitive 5G services with Multi-Access Edge Computing (MEC) and specific 5G core functions inside a disaggregated OLT. Thirdly, we proposed a cooperation interface between fixed and mobile SDN controllers and we demonstrated a 5G slicing scenario.

Our contributions for future virtualized fixed and mobile optical access networks architectures shows important benefits and lead to new future research opportunities.

Figure 1 . 1 :

 11 Figure 1.1: Telecommunication networks representation according to hierarchical inter networking model [10].

Figure 1 . 2 :

 12 Figure 1.2: Optical access networks.

•Figure 1 . 3 :

 13 Figure 1.3: PON architecture.

Figure 1 . 4 :

 14 Figure 1.4: The timeline of ITU and IEEE PON standards.

Figure 1 . 5 :

 15 Figure 1.5: Left: FTTH/B progression worldwide in terms of subscribers and homes passed, 2014-2025 [1]. Right: Evolution of the Broadband Internet customers by technology in France, 2018/12 -2021/12.

Figure 1 . 6 :

 16 Figure 1.6: FTTH fiber coverage in France (updated in 2022) [18].

Figure 1 . 7 :

 17 Figure 1.7: Simplified view of the fiber deployment in France.

Figure 1

 1 Figure 1.8: a) OLT chassis. b) OLT functional blocks.

Figure 1 .

 1 Figure 1.10: (a)TDM for PON downlink transmission. (b)TDMA for PON uplink transmission.

Figure 1 . 11 :

 111 Figure 1.11: RAN protocol stacks (L1, L2, L3) inside eNB

Figure 1 . 12 :

 112 Figure 1.12: Evolution of RAN from Distributed-RAN to Centralized-RAN. a) D-RAN with BBU, RRH at antenna site. b) C-RAN with BBUs some kilometers away (max. 20km) from antenna sites. c) C-RAN with CU DU and RU.

Figure 1 . 13 :

 113 Figure 1.13: Functional split options and an example of CU DU RU using different split options.

Figure 1 .

 1 Figure 1.14: Total mobile subscriptions per technology (2G-5G) by 2025 [39].

Figure 1 .

 1 Figure 1.15: 5G KPI triangle for eMBB, mMTC and URLLC services.

Figure 1 . 16 :

 116 Figure 1.16: An example of E2E slicing with two network slice instances.

Figure 1 .

 1 Figure 1.18: UPF on core compared with UPF on edge for time-critical mobile services.

Figure 1 .

 1 Figure 1.19: 6G KPI vision compared to 5G considered by Orange, NTT, Samsung, ZTE, China Mobile and Huawei.[START_REF] Orange | Orange's vision for 6G-white paper[END_REF][START_REF]White Paper 5G Evolution and 6G[END_REF][START_REF]6G Vision Samsung -The Next Hyper Connected Experience for All[END_REF][START_REF] Li | Gradual and smooth evolution towards 5G advanced and 6G. Technical report[END_REF][START_REF] Chih-Lin | 6G vision and requirements[END_REF] 67]

Figure 2 . 1 :

 21 Figure 2.1: ITU proposed five-layers TMN.

Figure 2 . 2 :

 22 Figure 2.2: Current access management functions and interfaces in Orange in France.

Figure 3 . 1 :

 31 Figure 3.1: (a) Schematic explication of SDN definition. (b) Schematic explication of the principle of NFV definition.

Figure 3 . 3 :

 33 Figure 3.3: ETSI NFV Architecture Framework [100].

Figure 3 . 4 :

 34 Figure 3.4: OMDIA analysis of global operator spend on SDN/NFV from 2019-2025 [102].

Figure 3 . 5 :

 35 Figure 3.5: Architecture of SEBA based on ONF three-layers SDN model.

3. 2 . 1 ONF

 21 Solutions and Architecture: SEBA, VOLTHA SEBA SEBA emerged from one of the Central Office Re-architected as a Datacenter (CORD) projects called Residential CORD (R-CORD).

Figure 3 . 6 :

 36 Figure 3.6: (a) Architecture of VOLTHA. (b) Major blocks in Openflow switch [82].

Figure 3 . 7 :

 37 Figure 3.7: Architecture of CloudCO.

Figure 3 . 8 :

 38 Figure 3.8: Architecture of BAA.[108]

Figure 3 . 10 :

 310 Figure 3.10: Nokia Lightspan 7360 ISAM OLT [122].

  Figure 3.10 shows an example of the Altiplano solution enabled OLT hardware used by Nokia.

Figure 3 .

 3 Figure 3.11: (a) ZTE Titan, Built-in Blade server in OLT [126]. (b) Tibit microplug OLT.

Figure 3 . 12 :

 312 Figure 3.12: Analysis of SDN/NFV efforts from ONF, BBF and research entities.

4. 1 . 2

 12 Challenges of PON for Mobile Traffic and Related Studies 4.1.2.1 Reduction of PON Upstream Latency: coDBA Co-DBA was first proposed in the NG-PON2 specifications in 2015 by ITU to support low-latency services in TDM/TDMA PON systems [138].

  Figure 4.1 shows the use case of Co-DBA to meet the fronthaul uplink latency requirements.

Figure 4 . 1 :

 41 Figure 4.1: coDBA working procedure for uplink traffic in fronthaul mobile network [138].

Figure 4 . 2 :

 42 Figure 4.2: The detailed view of CTI proposed by ORAN [146].

Figure 4 .

 4 Figure 4.2 shows the detailed view of CTI between Open Distributed Unit (O-DU) and OLT. Thanks to this interface, Co-DBA method can be realized to support low latency mobile services. CTI packet is based on Ethernet protocol in layer 2 and IP in layer 3.

Figure 4 . 3 :

 43 Figure 4.3: Simplified architecture of VULA and BSA solutions.

Figure 4 . 4 :

 44 Figure 4.4: Management plane sharing in FANS with SDN and NFV indicators [150].

Figure 5 . 1 :

 51 Figure 5.1: Active modules for PON infrastructure in labs: (a) µOLT and µONU. (b) legacy switch hosted µOLT. (c) generic-proposed server hosted µOLT. (d) legacy switch hosted µONU. (e) legacy ONU.

Figure 5 . 2 :

 52 Figure 5.2: The upstream SLA configuration with two Tibit graphical interfaces. (a) Tibit GUI. (b) Tibit PON manager WEB interface.

Figure 5 . 3 :

 53 Figure 5.3: Schematic representation of our "disaggregated OLT" experimental setup.

Figure 5 . 4 :

 54 Figure 5.4: Schematic representation of our "partially virtualized OLT" experimental setup.

Figure 5 . 5 :

 55 Figure 5.5: An extract of OVS bridge information and related configuration on each ports.

Figure 5 .

 5 Figure 5.5 shows an example of the configuration of our bridge called br0. Following the bridge name in this figure, a controller address is given. This allows OvS and its controller (i.e. Ryu controller) to know each other and connect once detected. The port3 and port1 are attached to DPDK-enabled physical ports on the generic server. Each port has its access/trunk mode with one or several VLAN numbers.The protocol used to define the control plane rules for data plane flows on each bridge is Openflow. Described in Section 2.3, Openflow is pushed and standardized by ONF.Ryu is an open source controller created by NTT Labs for network management. Ryu uses OpenFlow, NETCONF, or other protocols to communicate with network equipment. In our setup, the protocol used between the Ryu controller and the OvS is Openflow. The API Python provided in Ryu controller eases the development of automatic applications for programmers. In this thesis, we use Ryu in the SDN controller to interact with the OvS bridges (see the light yellow part in the SDN controller in Figure5.4).

Figure 5 . 6 :

 56 Figure 5.6: DPDK key techniques: Kernel bypass and Poll Mode Driver [171].

Figure 5 . 7 :

 57 Figure 5.7: Results of OVS performance (latency, jitter, packet loss) with and without DPDK implementation with different bit rates and packet lengths.

Figure 5 . 8 :

 58 Figure 5.8: The implemented 5G core architecture on based on Openf5GS project and UERANSIM.

Figure 5 . 9 :

 59 Figure 5.9: Wireshark capture of N2 and N3 traffic from the interface of RAN/UE VM.

Figure 5 .

 5 Figure 5.10: SDN development summary for our test beds.

Figure 6 . 1 :

 61 Figure 6.1: Different capacity calculation of line cards and network cards in OLT chassis, case 1 for overprovisioning strategy, case 2 for congestion strategy.

Figure 6 . 2 :

 62 Figure 6.2: Identified two-level aggregation for PON and inside OLT. CTI and coDBA for the first PON aggregation, eCTI for the second aggregation inside OLT.

Figure 6 . 4 :

 64 Figure 6.4: Experimental setup by using µOLTs with a legacy switch.

Figure 6 . 5 :

 65 Figure 6.5: Downstream and upstream bit rate in variation in time of OLT switch network ports.

Figure 6 . 6 :

 66 Figure 6.6: High time resolution measurement for recovery performance.

Figure 6 . 7 :

 67 Figure 6.7: Performance of monitoring, algorithm and reconfiguration in time.

  Figure 6.8 (b).

Figure 6

 6 Figure 6.8: a) Traditional architecture with UPF in the mobile core and legacy OLT. b) Proposed architecture with MEC and UPF compatible OLT.

Figure 6 . 10 :

 610 Figure 6.10: Different experimental results with UPF in the core network (CN) or access network (AN) with PtP or PtMP optical topology. a) Experimental results of uplink latency, jitter. b) CPU performance of the VMs that holds UPF (VM UPF and VM Core), the VM of RAN/UE.

Figure 6 .

 6 Figure 6.11: Legacy OLT's short-term/max latency and jitter with the best performance's T-CONT (fixed 7 Gbps, assured 0 Gbps and best effort 0 Gbps)

Figure 7 . 1 :

 71 Figure 7.1: A complete PtP blades and fiber protection solution (dotted CO and protection link) for antenna sites.

Figure 7 . 2 :

 72 Figure 7.2: Possible fiber paths (dotted orange links) for antenna sites' protection based on the current deployment in France (scheme in grey).

Figure 7

 7 Figure 7.3: a) PtP protection solution b) PON protection solution.

7. 4 . 1

 41 Comparison of a PtP with a Dedicated PtMP Topology for Access Network ProtectionOur proposal is based on the fact that an OLT is an aggregation node that traditionally consists of different embedded cards (see section 1.1.4). Line cards for residential services use PON technology with PtMP architecture and the line cards for mobile services or enterprise services use PtP architecture. We replace a legacy OLT chassis by a legacy switch with µOLT 5.1.2 to benefit from the numerous advantages brought by virtualization tendencies in optical access detailed in section 3.1. We introduce an SDN-oriented self-healing solution (developed specially for our purpose) based on PON technology and we compare it with the conventional PtP layer 2 solution (i.e. LAG).

Figure 7 .

 7 3 (a) and (b) show examples of a typical protection for a mobile access connectivity network. Compared to Figure 7.1 that a second CO provides the second PtP protection link for antenna sites, Figure 7.3 (a) shows a less effective protection architecture, but interesting from CapEx. This time only one CO device is used both for protection and normal links. However, both protection and normal links are still implemented in separated fibers in different trenches.

  Figure 7.3 (a) would enable protection when a fiber cut occurs, but not when a malfunction of the equipment occurs, unlike Figure 7.1.

Figure 7 . 4 :

 74 Figure 7.4: Experimental setup: a) PtP protection solution b) PON protection solution.

Figure 7 . 5 :

 75 Figure 7.5: Flowchart of our developed protection algorithm with legacy switch.

Figure 7 . 6 :

 76 Figure 7.6: Experimental results of recovery time for PtP and PON protection solutions.

Figure 7 . 7 :

 77 Figure 7.7: Cost and energy consumption comparison between PtP and PON protection solution.

TFigure 7 .

 7 Figure 7.7 shows all functions above with the number of OLT ports without protection (N) varying from 0 to 50. As we can see in Figure7.7, if the number of antennas connected to a CO is less than 5, the cost of PtP protection is cheaper than the PON solution. From N

Figure 7 . 9 :

 79 Figure 7.9: a) Residential PON for mobile protection link (dotted line in orange) enables the converged residential and mobile scenario. b) Orange antenna sites and FTTH's Fiber Distribution Terminals (FDTs) distribution in Rennes, France.

Figure 7 . 10 :

 710 Figure 7.10: Flowchart of our developed protection algorithm with OLT server.

Figure 7 . 11 :

 711 Figure 7.11: Experimental setup of residential PON for mobile protection with SDN controller, 5G backhaul traffic and general server with µOLT.

•

  The SDN controller to control the OLT • The traffic generators and analyzers. Mobile traffic has two sources. The first is 5G backhaul traffic between a 5G New Radio core [172] and an emulated RAN and UE [173]. The second traffic is generated by the traffic generator and received by the analyzer to accurately assess the latency. The generator also emulates two residential traffic flows that represent streaming and Voice over Internet Protocol (VoIP) services. A generic x86 Linux server accommodates the µOLT (see section 5.1.2). The latter directly embeds OLT functions, allowing for an alternate solution to custom, dedicated hardware PON system based on the conventional OLT chassis (see Section 1.1.4). OvS with DPDK (see Section 5.1.4) is integrated in the server to allow switching capabilities at high bit rate and low latency for generic server-based OLT. Our SDN controller has real-time control of bridges in OvS and the T-CONT parameters of PON (see Section 5.1.4). Two protocols are used as control plane messages between the controller and access equipment. The first is the OpenFlow protocol [241] and is used for OvS management. Based on RYU [242] (see Section 5.1.4), our controller detects the main mobile link failure, the throughput of each flow in real time, and reconfigures flows' priority and bandwidth via OvS protocol. The second is OMCI over Ethernet

Figure 7 . 12 :

 712 Figure 7.12: Bit rate (left) and latency (right) measurements for mobile and fixed traffic in real time.

Figure 8 . 2 :

 82 Figure 8.2: Two procedures for the 5G slicing configuration in the proposed SDN architecture.

Figure 8 . 3 :

 83 Figure 8.3: Detailed experimental setup scheme with the functionalities in orchestrator, SDN controllers and infrastructure layer.

Figure 8 . 4 :

 84 Figure 8.4: Workflow of 5G slicing application on optical access networks.

  2 and Figure 8.3, we precise the scenario procedures in a workflow shown in Figure 8.4.

Figure 8 . 6 :

 86 Figure 8.6: UPF core-to-UE latency variation during the network slice reconfiguration in PON with µOLT.

Figure 8 . 7 :

 87 Figure 8.7: The average values of uplink latency (left) and jitter (right) as a function of bit rate and packet length using the configuration of the setup in Figure 8.3.

Figure 8 . 9 :

 89 Figure 8.9: SDN and NFV application with different convergence scenarios for future access networks.

Figure A. 2 :

 2 Figure A.2: Legacy OLT (Huawei MA5800) uplink latency and jitter performance with Assured T-CONT.

  Figure A.4 shows an example of the measurement with T-CONT configuration at 5 Gbps.

Figure A. 3 :

 3 Figure A.3: Tibit µOLT performance with fixed T-CONT (a) Uplink latency (b) Uplink jitter.

Figure A. 4 :

 4 Figure A.4: Tibit µOLT uplink latency and jitter performances. (a) Assured T-CONT. (b) Best effot T-CONT.

Figure A. 5 :

 5 Figure A.5: Tibit µOLT uplink latency and jitter performances with new firmware. (a) Bitrate at 100 Mbps. (b) Bitrate at 1000 Mbps. (c)Bitrate at 4000 Mbps.

Titre:

  La Virtualisation (SDN/NFV) dans les Réseaux d'Accès Optiques : Contributions pour une Convergence Fixe-Mobile Améliorée Mots clés : Virtualization, SDN, NFV, Convergence du fixe et mobile, 5G, Réseaux d'accès Résumé : Les réseaux d'accès optiques fournissent les services mobiles et résidentiels pour les derniers kilomètres entre l'abonné et l'opérateur. L'Optical Line Terminal (OLT) d'aujourd'hui peut collecter le trafic des sites antennaires en plus des utilisateurs du Fibre to the Home (FTTH). Les nouveaux services 5G et 6G nécessitent une bande passante plus élevée que la 4G et aussi une haute disponibilité, une latence/jigue faible, une connexion massive et une faible consommation d'énergie. Cela pose de nouveaux défis aux opérateurs pour les réseaux fibres et la gestion des infrastructures d'accès. Le développement des technologies de cloud computing permet d'imaginer de nouveaux scénarios où les réseaux d'accès fixes et mobiles convergent à différents niveaux et fonctionnent au-delà de la simple agrégation des flux mobiles. Dans ce travail de thèse, des solutions sont proposées et évaluées avec un banc expérimental développé. Tout d'abord, nous avons réutilisé l'infrastructure FTTH comme lien de protection pour répondre aux fortes exigences de disponibilité des services mobiles avec un minimum d'effort de déploiement pour des opérateurs. Ensuite, nous obtenons une latence montante de 140 µs pour les services 5G, grâce au Multi-Access Edge Computing (MEC) et des fonctions spécifiques de réseau-coeur 5G et un OLT désagrégé. Finalement, nous avons proposé une interface de coopération entre les contrôleurs SDN des réseaux fixes et mobiles et démontré un scénario de slicing 5G. Nos contributions à l'architecture des futurs réseaux d'accès optiques fixes et mobiles virtualisés montrent des avantages importants et ouvrent la voie pour des sujets de recherche futurs. Title: Virtualization (SDN/NFV) in Optical Access Networks: Contributions for Enhanced Fixed-Mobile Convergence Keywords: Virtualization, SDN, NFV, Fixed-mobile convergence, 5G, Access networksAbstract: Optical access networks provide both mobile and residential services for the last kilometers between the subscriber and the provider. The legacy Optical Line Terminal (OLT) can now collect traffic from both antena sites and Fiber to the Home (FTTH) users. 5G and 6G new services require not only higher bandwidth than 4G but also high availability, ultra-low latency/jitter, massive connection and low energy consumption. This brings new challenges to fiber networks and access infrastructure management for operators. The recent development of cloud-computing technologies enables new scenarios where fixed and mobile access networks converge at different levels, and work in synergy beyond the simple aggregation of mobile flows.

  Contents 6 Evolution of OLTs Through Virtualization Technologies for Mobile Services 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Related Research Work for Virtualized OLT and SDN controller . . . . . . . 6.3 Disaggregated OLT and SDN Controller for eCTI Dynamic Traffic Management 6.3.1 Motivation of Proposed eCTI for Converged Fixed-Mobile Access Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Proposed Architecture with SDN Controller . . . . . . . . . . . . . . 6.3.3 Experimental Setup and Tested Scenario . . . . . . . . . . . . . . . . 6.3.4 Experimental Results and Discussion . . . . . . . . . . . . . . . . . . 6.4 A MEC and UPF Compatible OLT for Time-Critical Mobile Services . . . . 6.4.1 Introduction and Proposition . . . . . . . . . . . . . . . . . . . . . . 6.4.2 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.3 Results and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.1.3 Cost Analysis in Terms of CAPEX and Energy . . . . . . . 7.4.1.4 Deployment Considerations with Respect to an Actual Network117 7.4.2 Shared PON for FTTH Services and Mobile Protection . . . . . . . . 7.4.2.1 Description of Proposal and Experimental Setup . . . . . . 7.4.2.2 Experimental Results . . . . . . . . . . . . . . . . . . . . . 7.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5G Slicing Coordination Between Mobile and Access Transport Networks125 8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Related Work for Fixed-Mobile Convergence and Management System Coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 PON Technologies for 5G Services and Beyond . . . . . . . . . . . . . 8.2.2 Management Cooperation Between Mobile and Fixed Networks . . . 8.3 SDN-based Cooperation Interface in a Converged Fixed-Mobile Access Network for 5G Slicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Orchestrator Layer . . . . . . . . . . . . . . . . . . . . . . . 8.3.2.4 Procedures in Our Scenario . . . . . . . . . . . . . . . . . . 8.3.3 Results and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Conclusion and Perspectives Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Legacy OLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 Tibit µOLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2.1 Old Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2.2 Recent Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

	A OLT Performance
	A.1 Bibliography
	Glossary
	List of Figures
	List of Tables

7 Access Networks' Protection for 5G Availability and Reliability 7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Definition of Reliability and Availability . . . . . . . . . . . . . . . . . . . . 7.3 Related Research Work for Optical Access Network Protection . . . . . . . . 7.4 Our Proposition for Protection of Mobile Access Network . . . . . . . . . . . 7.4.1 Comparison of a PtP with a Dedicated PtMP Topology for Access Network Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1.1 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . 7.4.1.2 Experimental Results of Latency, Recovery Time and Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78.3.1 Proposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.2 Experimental Setup and Scenario . . . . . . . . . . . . . . . . . . . . 8.3.2.1 Infrastructure Layer . . . . . . . . . . . . . . . . . . . . . . 8.3.2.2 Control Layer . . . . . . . . . . . . . . . . . . . . . . . . . . iii 8.3.2.3

Table 2 .

 2 1: A quick comparison of SNMP, NETCONF, RESTCONF and gRPC.

	). Openflow is

Table 3 .

 3 1: A brief comparison of VM and container.

	Compared item	VM	Container
	Definition [101]	Software that provides a computing resource to run programs and deploy applications	Software that contains code and all its dependencies, allowing an appli-cation to run reliably across different computing environments
	Size	large	small
	Start up	long	fast
	Security	more secure	less secure
	Hypervisors	KVM, VMware, VirtualBox etc.	Docker, Kubernetes etc.

Table 6 .

 6 1: CPU, GPU and memory characteristics of vOLT server in

		4 GHz	-	DDR3 1600 MHz 4 GB
	[129]	two 2.2 GHz Intel® Broadwell Xeon® E5-2699v4	NVIDIA P100 Tesla	DDR4 128 GB
	[185]	16-core 2.3 GHz Intel® Xeon® D-2100	-	DDR4 DRAM 32 GB

Table 7 .

 7 1: Comparison of experimental results for PtP protection solution and PtMP protection solution.from a CO. Considering that reduction in CapEx and energy consumption is essential for telecommunication operators, we propose a model to estimate and compare the cost and energy consumption of the two protection architectures. This model is based on the number of PtP ports used in one CO. It takes into account only equipment used at CO since we always need two ports at the antenna site, and the cost is considered the same regardless of the protection solution used.

	Comparison items	Current;	Goal	PtP;	PtMP;
		status		solution	solution
	Recovery time	1-2 h	50 ms	150 ms	2-4 s
	Latency (ms)	Backhaul: 50	Backhaul 1-50 Midhaul 1,5-10	UL 0,008 DL 0,009	UL 0,771 DL 0,016
	Unavailability per year	8,76 h	5 min	-	-
	= 1-availability%
	Number of failures per year	4	6000	2000	100
	= unavailability/recovery time

Table 7 .

 7 , the cost and energy consumption for SFP+/PON and SFP+/PtP at CO 2: Normalized cost and consumption of each component.

	Unit items	µOLT PtP-SFP Switch
	Cost ($)	n	m	q
	Normalized cost	1	0.025	1
	Energy Consumption (W)	b	a	e
	Normalized Consumption	0.02	0.0067	1

Acknowledgements

chapter, we will investigate the challenges for fixed mobile converged access networks because the scenarios studied during this thesis aim at fixed and mobile convergence. it is necessary to study the impact of transporting 5G and FTTH services in the same PON and define CoS accordingly. In the next part, the result of the feasibility of applying 5G slicing in access TN and a refined T-CONT measurement will be given.

Results and Discussion

Our proposal to place the NSSMFs in the fixed/mobile SDN controllers and the East-West interface is applicable with legacy OLT and disaggregated OLT. We first performed some measurements on a legacy OLT as benchmark results to compare with the Tibit µOLT and we tried to confirm that there is really a difference in latency and jitter values depending on the T-CONT configuration for conventional and non-conventional equipment. Secondly, we realized the scenario with our disaggregated OLT by using T-CONT as the TN slice parameter. Thirdly, we complete the measurement of disaggregated OLT by varying the packet length and bit rate to verify the performance stability with respect to each T-CONT.

In Figure 8.5, uplink latency and jitter of the legacy OLT (Huawei MA5800) are given for the fixed and guaranteed T-CONT configuration. Two combinations of T-CONT configuration are used: T-CONT 1 called "priority T-CONT" with only a fixed bit rate of 7 Gbps and T-CONT 2 called "no priority T-CONT" with only an assured bit rate of 7 Gbps. For the sake of simplicity, only two ONUs are used for these measurements. The 1500 bytes traffic are sent for test. The typical downlink latency and jitter values with a legacy PON system are 30 µs and 0,3 µs, respectively. In terms of uplink latency and jitter, around 50% latency reduction and 50% jitter reduction are enabled by the "priority T-CONT" type.

Based on the uplink latency and jitter results from the legacy OLT, we chose two types of T-CONTs for the µOLT setup: the "no priority type" T-CONTs and the "priority type" T-CONTs. The "no priority type" T-CONT is the default configuration in our setup for all traffics, while the "priority type" T-CONT is applied only when an URLLC mobile traffic is detected. The latency variation is tracked in real-time during the reconfiguration steps. Uplink and downlink latency for 1 Gbps traffic are presented in green and purple in Figure • Only one ONU is connected to the used PON port.

• Packet length is 1500 Mbytes