Rapport Pfe 5G C-RAN

Table des matières
1 5G, INTERACTON DU CLOUD COMPUTING AU SEIN DES RESEAUX

CELLULAIRES ET PRESENTATION DU PROJET 2
1.1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 La nouvelle génération des réseaux mobiles :la 5G . . . . . . . . . . . . . . . . . . . 2
1.2.1 Evaluation vers une 5éme génération de réseaux mobiles . . . . . . . . . . . 2
1.2.2 Exigence et défis de la 5G . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.3 Technologies clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Vers l’intégration du Cloud dans l’architecture des réseaux cellulaire . . . . . . . . . 9
1.3.1 Définition et caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.2 Les modèles en services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.3 Les modèles de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.4 La virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Objectif de projet et cahier des chargess . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.1 Objectif de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.2 Cahier des charges et étapes du projet . . . . . . . . . . . . . . . . . . . . . 13
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 ARCHITECTURE C-RAN ET MISE EN PLACE DE LA VIRTUALISATION 14

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Composants de l’architecture C-RAN . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Remote Radio Head (RRH) . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.2 Fronthau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.2.1 Fibre optique dédiée (fibre noire) . . . . . . . . . . . . . . . . . . . 17
2.2.2.2 Multiplexage en longueur d’onde (Wavelength Division Multiplexing
(WDM)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.2.3 Micro-ondes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.2.4 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.3 Baseband Unit (BBU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.3.1 Couche physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.3.2 Couche MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.3.3 Couche Radio Resource Control (RRC) . . . . . . . . . . . . . . . . 20
2.3 Avantage du C-RAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Architecture C-RAN proposer par les industriels . . . . . . . . . . . . . . . . . . . 21
2.5 Modèles de centralisation du C-RAN . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5.1 Centralisation complète (Full centraization) . . . . . . . . . . . . . . . . . . 28
2.5.2 Centralisation partielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6 Procédure de la virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1
TABLE DES MATIÈRES
2.6.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6.2 Plateforme choisie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.6.2.1 Plateformes disponibles . . . . . . . . . . . . . . . . . . . . . . . . 31
2.6.2.2 Création de plateforme OpenAirIntarface . . . . . . . . . . . . . . . 32
2.6.2.3 OpenAirInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6.2.4 Mise en place de la virtualisation . . . . . . . . . . . . . . . . . . . 34
2.6.3 Mise en place de la virtualisation . . . . . . . . . . . . . . . . . . . . . . . . 36
2.6.3.1 Virtualisation d’OAI eNB . . . . . . . . . . . . . . . . . . . . . . . 36
2.6.3.2 Virtualisation de cœur (epc) . . . . . . . . . . . . . . . . . . . . . 38
Conditions préalables . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Extraction d’images des conteneurs . . . . . . . . . . . . . . . . . . . 40
Création des images de conteneur . . . . . . . . . . . . . . . . . . . . 42
Configurer la mise en réseau . . . . . . . . . . . . . . . . . . . . . . . 44
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3 Développement d’application web C-RAN TT 46

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2 Analyse et spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.1 Les acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.1.1 Diagramme de cas d’utilisation (administrateur) . . . . . . . . . . . 49
3.3.1.2 Diagramme de cas d’utilisation globale . . . . . . . . . . . . . . . . 49
3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.1 Environnement matériel et logiciel . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.2 Principales interfaces avec description . . . . . . . . . . . . . . . . . . . . . . 51
3.4.2.1 L’interface administrateur . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.2.2 Le menu de l’administrateur . . . . . . . . . . . . . . . . . . . . . 51
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2
Table des figures
1.1 Traffic internet mobile(source [1]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Modèles en service du Cloud Computing (source [22]) . . . . . . . . . . . . . . . . . 10
1.3 Les modèles de déploiement(source [24]) . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 Le concept de virtualisation(source [26]) . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1 Composition de l’architecture C-RAN(source [29]). . . . . . . . . . . . . . . . . . . 15

2.2 Les propositions d’architectures C-RAN dans l’industrie . . . . . . . . . . . . . . . . 22
2.3 Répartitions fonctionnelles des C-RAN proposés dans la littérature. . . . . . . . . . 23
2.4 Le concept RANaaS (source ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 Modèles de « centralisation » des couches protocolaires dans une architecture C-RAN. 27
2.6 Architecture de l’hyperviseur et le container. . . . . . . . . . . . . . . . . . . . . . . 30
2.7 Logo EURECOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.8 Logo OpenAirInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.9 La virtualisation des composants de réseau avec OAI(source [51]) . . . . . . . . . . 33
2.10 sudo apt-get install cpufrequtils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.11 Editez le fichier suivant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.12 Ajoutez-y les lignes suivantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.13 Désactiver le démon à la demande . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.14 Installions d’OAI eNB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.15 Run OAISIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.16 Vérifier les interface OAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.17 L’exécution d’oaisim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.18 les options de l’application web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.19 Exemple de performance de cpu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.20 Installez docker et python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.21 Tirez les images de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.22 Confiduration du reseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.23 Exemple tirez hss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.24 re-etiquetez les composant des epc . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.25 Synchroniser les composant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.26 Initialiser la base de données Cassandra . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.27 Déployer le reste de l’EPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.28 parametre DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.29 Etape 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.30 Recuperez l’addresse ip de MME . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1 Digramme de cas d’utilisation d’administrateur . . . . . . . . . . . . . . . . . . . . 49
3
TABLE DES FIGURES
3.2 Digramme de cas d’utilisation globale . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.3 Interface "authentification admin" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4 Page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.5 Ajouter un admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.6 Liste d’administrateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.7 Modifier un admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.8 Supprimer un admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.9 Ajouter un BBU pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.10 Modifier BBU pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.11 Supprimer un admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.12 Ajouter une BBU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.13 Supprimer une BBU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4
Liste des tableaux
2.1 Le tableau 1 synthétise les potentialités et les limites des différentes architectures
C-RAN proposées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1 L’administrateur et leurs rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5
Introduction général
L’émergence du cloud computing mobile dans les réseaux sans fil a permis le développement de
nouveaux services dans des contextes plus agiles qui doivent également considérer les RANs. Les
terminaux mobiles foisonnent et deviennent omniprésents, des smartphones aux objets connectés
(véhicules, machines, villes, etc.). Par conséquent, le trafic de données a connu une croissance
exponentielle durant ces dernières années qui semble devoir s’accélérer.
Pour faire face à cette augmentation, les opérateurs de réseaux mobiles doivent doubler d’ingé-
niosité pour accroître la capacité de leurs réseaux d’accès. La densification du réseau a été proposée
comme solution à ce problème. Mais cette solution est très coûteuse car elle nécessite l’implémenta-
tion de nouveaux points d’accès. C’est dans ce contexte et afin de limiter les CAPEX et OPEX que
le réseau C-RAN a été proposé offrant l’ensemble des avantages du paradigme Cloud Computing
et virtualisation.
L’opérateur tunisien Tunisie Télécom s’apprête à faire évoluer son réseau pour la préparation
de l’introduction de la 5G. Pour cela, l’équipe technique de Direction des Berges du Lac s’intéresse
à la mise en place du C-RAN et notamment à la virtualisation des BBU. C’est dans ce contexte
que s’insère notre Projet de Fin d’Etudes. Nous sommes amenés à faire. . ... (cahier des charges)
Structure du rapport
Le présent rapport est organisé comme suit : Les listes sont faciles à créer :
— Le premier chapitre expose les notions préliminaires nécessaires à la compréhension du
rapport. Il présente l’évolution des réseaux d’accès ainsi leurs exigences pour répondre à
l’explosion du trafic ainsi que les différentes technologies clés permettant de répondre à
ces exigences. Ce chapitre décrit aussi l’évolution des technologies cloud dans les réseaux
mobiles et montre comment le cloud a intégré les systèmes de communication sans fil à
travers diverses architectures et la notion de virtualisation. A la fin de ce chapitre, nous
présenterons l’objectif et cahier des charges du projet .
— Le deuxième chapitre présentera l’architecture détaillée du C-RAN, puis les étapes de vir-
tualisation d’une BBU dans un VRAN en utilisant une plateforme open source.
— Le dernier chapitre présente les étapes de développement de notre application Web VRAN-
TT pour la visualisation de la virtualisation des BBU pour les ingénieurs de TT ainsi que
sa réalisation illustrée avec des captures d’écran.
1
Chapitre 1
5G, INTERACTON DU CLOUD

COMPUTING AU SEIN DES RESEAUX
CELLULAIRES ET PRESENTATION DU
PROJET
1.1 introduction
Les réseaux de communication mobile ont toujours connu une évolution continue et rapide
depuis leur lancement en tant que réseaux téléphoniques uniquement. D’une génération à l’autre,
les services se sont multipliés et diversifiés pour inclure les données dans un premier temps puis la
vidéo et de nombreux autres services au fur et à mesure.
Ce progrès a été suivi par une croissance exponentielle du nombre d’utilisateurs et des dispositifs
mobiles, et par conséquence, du volume de trafic de données. Grâce aux différentes générations de
réseaux mobiles, l’architecture a été et est toujours en évolution et de nouveaux mécanismes sont
encore proposés pour améliorer la qualité des services et les performances pour l’intégration de
nouveaux services.
Dans ce chapitre, nous allons présenter l’évolution de ces réseaux mobiles vers la 5G, notamment
celle des réseaux d’accès radios sur lesquels notre travail est axé. Nous allons ensuite, décrire
l’évolution de l’architecture de ces réseaux en mettant l’accent sur l’intégration des technologies
cloud.
1.2 La nouvelle génération des réseaux mobiles :la 5G

1.2.1 Evaluation vers une 5éme génération de réseaux mobiles
D’après la figure 1.1, le volume du trafic mobile et sans fil n’a cessé d’augmenter depuis le
déploiement des réseaux mobiles. Cette croissance est aujourd’hui de nature exponentielle et rapide.
Il est prévu que le trafic de données mobiles se multipliera par un facteur 1000 entre 2010 et 2020
avec un taux qui double environ chaque année [1]. Cette augmentation est due à plusieurs facteurs.
Par exemple, l’augmentation continue du nombre d’abonnés mobiles, et du nombre de dispositifs
sans fil connectés génère un trafic supplémentaire qui s’approche des limites de ce que les réseaux
cellulaires actuels peuvent fournir en termes de capacité. En effet, les prévisions sur le nombre
2
Chapitre 1. 5G, INTERACTON DU CLOUD COMPUTING AU SEIN DES
RESEAUX CELLULAIRES ET PRESENTATION DU PROJET
d’appareils connectés d’ici 2021 prévoient qu’il y aura 1,5 appareil mobile par habitant, c’est-à-
dire que le nombre d’appareils mobiles dépassera le nombre de personnes sur terre en 2021 [2].
De plus, les services proposés sont sde plus en plus innovants et variés. Certains de ces services
sont liés à des aspects essentiels de la vie quotidienne des gens tels que les services de e-banking, e-
health et l’apprentissage en ligne (e-learning), et seront donc d’autres sources importants de trafics
mobile [3]. Il y a aussi les services en ligne qui sont lancés directement par des utilisateurs mobiles ou
par des applications mobiles. Ce type de services évoluent tous les jours et incluent des applications
de plus en plus complexes qui génèrent beaucoup de données telles que la reconnaissance faciale,
le jeu en ligne, la réalité augmentée, la traduction instantanée et le décodage de vidéos.
L’expansion des applications en nombre et en diversité entraîne une augmentation explosive
du trafic des données. Le côté interactif de certaines de ces applications nécessite un réseau plus
performant en termes de latence et de débit (le nom utilisé pour ce type de réseau est l’internet
tactile). Tandis que le monde des réseaux informatiques et celui des télécommunications convergent,
l’explosion du trafic de données a poussé les acteurs du domaine à lancer une nouvelle génération
de réseaux mobiles sous le nom de la 5G.
Parallèlement à cela, les différents acteurs du domaine des réseaux sans fils ont poussé la concep-
tion de cette nouvelle génération de réseau de communication sans fil. Par exemple, l’Internet des
objets (IoT) et son large éventail d’applications qui prolifèrent très rapidement dans le domaine
des services de communication sans fil. La technologie IoT devrait s’élargir à l’avenir et imposer
le déploiement de milliards de périphériques qui doivent compter sur une architecture de réseau
hautement évolutive. En plus de l’évolutivité, le réseau doit offrir un haut niveau de fiabilité car
certaines applications IoT concernent des domaines très sensibles de la société comme la téléméde-
cine, les systèmes cyberphysiques, etc. En outre, avec les applications IoT tels que le smart grid et
la surveillance d’infrastructure critiques (critical infrastructure monitoring), la latence des réseaux
actuels peut être supérieure au délai maximum requis par ce type d’applications.
Ainsi, même si la 4ème génération de réseaux cellulaires a apporté des avancées significatives
en termes de conception et d’évolutivité, la tendance du marché et l’augmentation croissante des
dispositifs et des objets intelligents connectés imposent une nouvelle évolution dans le domaine des
réseaux cellulaires.
1.2.2 Exigence et défis de la 5G

Les réseaux 5G ont fait l’objet de nombreuses recherches ces dernières années. En dépit du
fait que la 5G n’a pas encore été complètement définie, ses exigences techniques ont été définies à
l’aide d’une formulation explicite, par l’un des premiers projets de grande envergure sur la 5G, le
projet européen METIS (Mobile and Wireless Communications Enablers for the 2020 Information
Society) [?], comme suit [5] :
— Volume de données mobile 1000 fois supérieur par zone.
— Taux de données utilisateur de 10 à 100 fois plus élevé.
— 10 à 100 fois plus de périphériques connectés.
— Durée de vie 10 fois plus longue pour les appareils à faible consommation.
— Latence de bout en bout réduite 5 fois.
La 5G est alors confronté à des objectifs ambitieux qui, s’ils sont satisfaits, permettront au
réseau de faire face à la croissance exponentielle du trafic de données et aux exigences croissantes
des services mobiles. De nombreux industriels, organismes et centres de recherche ont présenté leur
vision globale sur les futurs réseaux 5G. Ericsson [6], Nokia [7], Huawei [8], NTTDOCOMO [9],
GSMA intelligence [10], et d’autres ont tous publié des white papers dans lesquels chacun présente
3
Figure 1.1 – Traffic internet mobile(source [1])
ses attendus de la 5G. Les exigences ainsi exprimées par l’ensemble de ces travaux, convergent vers
un même ensemble de défis qui sont les suivants :
— Une plus grande capacité
Le nombre d’appareils mobiles qui devraient être connectés au réseau 5G est de l’ordre
de milliards. Nous nous attendons à ce que le volume de trafic soit plus important de
plusieurs ordres de grandeur par rapport à celui d’aujourd’hui. La demande en capacité
pourrait même attendre plus de 1 000 fois la demande actuelle. La capacité requise pour
gérer un si grand nombre de connexions, y compris la signalisation et le volume de trafic de
données, constitue un défi technique très important. Cette exigence est considérée comme
la plus difficile pour les réseaux 5G. L’objectif de capacité établis par NTTDOCOMO vise à
atteindre une capacité de système 1000 fois supérieure par km2 par rapport à celle du réseau
LTE [9]. Il est bien sûre sous-entendu que cette augmentation de la capacité de traitement
ne devra pas se faire au détriment de la QoS ou de la QoE des utilisateurs mobiles.
— Un débit plus élevé
Etant donné que la 5G est la prochaine évolution des réseaux cellulaires, elle devrait au moins
être en mesure d’offrir un débit plus élevé par rapport à ses prédécesseurs. Cependant, pour
les générations précédentes l’accent a été mis sur le pic du taux de transmission de données
au lieu du débit individuel. Avec la prolifération de nouveaux services et applications qui
peuvent être lancés par les utilisateurs mobiles n’importe quand et n’importe où, les pics de
débit seront moins significatifs. L’accent devrait maintenant être accordé aux scénarios de
la vie réelle. Différents scénarios avec différents débits cibles devraient être étudiés. Selon
[6], un débit supérieur ou égal à 10 Gbps devrait être garanti aux utilisateurs mobiles dans
les environnements intérieur et extérieur denses. Pour les scénarios urbains et suburbains,
Ericsson a fixé un débit cible de l’ordre de 100 Mbps. En outre, un débit minimal de 10 Mbps
devrait être garanti sans interruption et à n’importe quel endroit, même dans les zones peu
peuplées. NTT-DOCOMO s’est fixé comme objectif d’assurer un niveau de QoS uniforme
pour tous les utilisateurs mobiles avec une cible de 1 Gbps de débit maximal partout.
4
— Disponibilité, connectivité et fiabilité massives

Le réseau 5G doit être capable de supporter tous les cas d’utilisation qui seront intégrées au
réseau cellulaire. Des services cloud aux périphériques IoT, tous les composants doivent tou-
jours trouver le moyen de se connecter au réseau. Le réseau 5G devrait avoir une connectivité
massive permettant de prendre en charge simultanément le nombre croissant de périphé-
riques connectés. Il devrait également permettre une grande fiabilité et disponibilité, en
particulier dans les cas de situations critiques ou de gestion des crises. Dans d’autres cas
tels que celui des services cloud, le réseau devrait être disponible lorsque des ressources à
la demande sont requises du côté des utilisateurs. Une autre exigence clé pour les réseaux
5G est la robustesse. Un réseau robuste et fiable est nécessaire pour garantir la sécurité des
données des utilisateurs et de l’infrastructure. Enfin, le réseau 5G deviendra la plate-forme
de base des applications de gestion et de surveillance de la vie courante, telles que la sécu-
rité publique, la distribution de l’eau et du gaz et la sécurité des maisons. Ceci confirme la
nécessité d’un réseau avec une grande disponibilité et une grande fiabilité.
— Une latence très faible
La 5G rassemblera des cas d’utilisation hétérogènes avec des exigences très différentes en
termes de latence. Certaines applications à implémenter sur les réseaux 5G nécessitent un
délai très faible, de l’ordre de millisecondes. Les jeux 3D interactifs et la réalité augmentée
sont de très bons exemples de ce type d’applications. L’objectif a été fixé à une latence
globale de l’ordre de 1ms, c’est-à-dire une réduction en latence de 5 à 10 fois par rapport
aux générations précédentes de réseaux cellulaires.
— Coût réduit et efficacité énergétique plus élevée
La consommation d’énergie des réseaux mobiles peut être vue sous deux angles différents.
Une première perspective est liée à la consommation d’énergie du côté du réseau. Une façon
de réduire la consommation globale d’énergie du réseau est d’accroître l’efficacité du spectre.
Toutefois, en raison de l’explosion du volume de trafic, il convient également d’accorder une
attention particulière à la consommation d’énergie par bit (Joules/bit) qui a un effet direct
sur l’efficacité énergétique du réseau. En outre, la performance énergétique des réseaux est
un élément très important pour réduire les coûts opérationnels [6].
Dans une autre perspective, la consommation d’énergie du côté des dispositifs sans fil devrait
également être considérée. Une faible consommation d’énergie pour les appareils sans fil a
toujours été recherchée. Avec l’intégration de l’IoT qui pourrait inclure différents types de
capteurs, la durée de vie de la batterie est très importante. Les objectifs ont été fixés pour
la durée de vie des batteries d’environ une décennie. Par conséquent, les dispositifs 5G
devraient être en mesure de fonctionner sur une très faible consommation d’énergie, menée
à la fois par une conception matérielle adéquate et des protocoles et des techniques de
communication à haut rendement énergétique.
1.2.3 Technologies clés

Sur les principes de déploiements décrits en I.1 et des performances attendues des réseaux
5G, plusieurs technologies clés ont été définies. Ces technologies permettront de relever les défis
posés par la croissance du trafic des données. Elles contribueront à accroître la capacité, à améliorer
l’efficacité énergétique et à réduire l’utilisation du spectre. En outre, elles permettront une meilleure
évolutivité et fiabilité du réseau.
— MIMO massif
Le MIMO massif (Multiple Input Multiple Output) est l’évolution du MIMO point à point
5
unique et du MIMO multi-utilisateur (MU-MIMO). Dans MU-MIMO, un ensemble de sta-

tions de base équipées de plus d’une antenne (moins de 10) sert un ensemble d’utilisateurs.
Chaque utilisateur est servi par une seule antenne. Le MIMO massif est le résultat d’une
volonté d’étendre la vision MU-MIMO en un système d’antenne à grande échelle où chaque
station de base est équipée d’environ 100 antennes ou plus. Le concept a été proposé par
Marzetta [11]. Ses travaux ont montré que lorsque le nombre d’antennes dans une cellule
MIMO augmente jusqu’à l’infini, l’effet de fading à petite échelle est éliminé et l’énergie par
bit requise pour la transmission devient nulle. Lorsqu’un très grand nombre d’antennes est
disponible, desservant notamment un nombre nettement plus faible d’utilisateurs, beaucoup
de degrés de liberté sont alors possibles [12]. Les antennes supplémentaires permettent au
système d’atteindre un débit plus élevé et d’améliorer l’efficacité énergétique rayonnée. De
plus, une capacité 10 fois plus élevée peut être obtenue grâce aux systèmes MIMO massifs.
Ceci grâce au fait que le MIMO massif repose sur le multiplexage spatial. Le MIMO massif
s’appuie sur la loi des grands nombres et le beamforming qui permettent d’éviter les clips de
fading et d’améliorer ainsi la latence de transmission globale, d’éliminer l’effet de division
du domaine fréquentiel et, par conséquent, chaque terminal reçoit la totalité de la bande
passante, ce qui simplifie l’accès multiple. Enfin, les systèmes MIMO massifs peuvent être
construits avec des composants non coûteux et de faible puissance.
Les systèmes MIMO massifs présentent aussi plusieurs défis. L’un des défis les plus impor-
tants est la contamination des pilotes. Elle est causée par la réutilisation des pilotes des
liaisons montantes (utilisés dans l’estimation du canal TDD) d’une cellule à l’autre. Les
pilotes doivent être orthogonaux pour tous les utilisateurs. Cependant, le nombre de pilotes
orthogonaux existants est limité. Par conséquent, les pilotes sont répétés et ainsi l’estima-
tion du canal pour un seul utilisateur est contaminée par une combinaison linéaire du canal
des autres utilisateurs utilisant le même pilote.
— Les systèmes de communication D2D (Device-to-Device)
La communication Device-to-Device est une communication directe entre deux équipements
sans passage par l’infrastructure réseau. Dans les réseaux cellulaires, ces systèmes forment
une couche supplémentaire permettant d’améliorer la capacité du réseau. Les nœuds du
réseau collaborent ensemble lors de la transmission des informations afin de profiter des
avantages de la diversité spatiale. Les dispositifs peuvent communiquer ensemble en utilisant
soit le même spectre que les macros cellules, soit le spectre non licencié. Avec les nouvelles
tendances du marché sans fil et l’introduction de nouveaux services qui nécessitent des
informations de localisation et de contexte, la communication entre les périphériques voisins
peut être utile. En effet, plusieurs dispositifs ou un groupe de dispositifs peuvent agir comme
des relais les uns par rapport aux autres et former un réseau spontané maillé ad hoc. Ce
réseau peut absorber le trafic D2D, libérer des ressources dans le réseau et augmenter la
capacité par zone.
En outre, la technologie D2D permet de réduire également les retards et la consommation
d’énergie de bout en bout. En effet, par exemple au niveau des bords de cellule, les terminaux
mobiles ont besoin de plus d’énergie pour communiquer avec la station de base. Cependant,
si les utilisateurs mobiles qui communiquent sont géographiquement voisins, leurs terminaux
peuvent servir de relais locaux et éviter des communications plus lointaines, réduisant ainsi
la consommation d’énergie et le délai de bout en bout.
Néanmoins, la technologie D2D présente aussi des défis. Les questions de sécurité et de
confidentialité sont probablement les plus contraignantes dans les communications D2D. Un
des défis consiste à protéger les données des utilisateurs contre toute attaque potentielle.
6
Deux modes d’accès aux appareils sont alors définis : l’accès fermé et l’accès ouvert. Un
autre défi significatif pour la communication D2D est la gestion des interférences. Deux
types d’interférences sont identifiés dans le cas des communications D2D. Le premier est
entre les communications avec l’infrastructure du réseau opérateur et des communications
D2D. Si les deux communications utilisent les mêmes bandes autorisées, les dispositifs de
communication D2D interféreront avec les dispositifs communiquant avec les stations de base
du réseau. Le deuxième type est l’interférence entre les différents équipements qui utilisent
des communications D2D. L’utilisation de ce type de communication dans la même bande
par des appareils voisins entraîne automatiquement des collisions qu’il faut obligatoirement
traiter.
— Réseaux hétérogènes ultra-denses (HetNets)
La 5G connaitra une expansion énorme du nombre d’utilisateurs et une grande diversifica-
tion des technologies opérant sur des bandes différentes. La densification du réseau est un
mécanisme clé pour le 5G et pour l’évolution des réseaux mobiles en général. Elle permet
au réseau de répondre aux exigences de très grande capacité, connectivité et disponibilité.
Pour réaliser des réseaux ultra-denses, l’hétérogénéité des nœuds du réseau jouera un rôle
important [13].
En effet, les réseaux hétérogènes introduisent un aspect dynamique au réseau cellulaire.
Avec le déploiement massif et aléatoire de périphériques à faible puissance d’émission, le
nombre de nœuds du réseau augmente, et le réseau devient ultra-dense. Cette approche
améliorera l’efficacité spectrale car elle réduira la distance entre les stations de base et les
utilisateurs mobiles. Selon un travail de Bhusnan et al. [14], la densification des réseaux est
une combinaison de densification spatiale et d’agrégation spectrale. La densification spatiale
consiste à augmenter le nombre de stations de base déployées dans une zone géographique.
Elle peut être également obtenue en augmentant le nombre d’antennes sur une station de
base.
Plusieurs types de stations de base peuvent coexister dans les réseaux HetNets et elles
peuvent être densément déployées. Toutefois, le déploiement de nouvelles macros cellules
impose des coûts importants à la fois pour les dépenses CAPEX et OPEX. De plus, le
déploiement de nouvelles macros cellules nécessite la planification du site et la recherche
de lieux de déploiement possibles. Par contre, les pico cellules peuvent être déployées plus
facilement et avec un coût beaucoup plus faible. Les pico cellules offrent aussi un accès direct
au réseau de l’opérateur. Un autre type de cellules, les nœuds de relais. Ils peuvent être
déployés là où la liaison filaire n’est pas accessible. Ils ont la caractéristique d’apparaître
comme une station de base pour les appareils mobiles et comme des dispositifs mobiles
pour les stations de base. Enfin, les cellules de petite taille (small cells) telles que les femto
cellules sont les plus faciles à déployer d’une manière intensive. Ce sont des nœuds de faible
puissance et de petite taille qui peuvent être déployés par l’utilisateur. Ils ne nécessitent
pas de planification de site et n’imposent pas d’OPEX et CAPEX significatifs pour les
opérateurs. Les femto cellules permettent aux utilisateurs mobiles d’avoir une station de base
à proximité avec une connexion directe. Ils permettent également de résoudre le problème
de trous de couverture et améliorent la qualité du signal au bord de la cellule et aux milieux
intérieurs (indoor).
Toutefois, les systèmes ultra-denses HetNets présentent également des défis. Par exemple,
le partage de la même fréquence porteuse, entre les cellules macro et femto, entraîne des
interférences. Quant à l’agrégation spatiale, l’agrégation de fragments de bande passante de
différentes bandes de fréquences conduit à des défis de conception des antennes. Le partage
7
du spectre entre plusieurs nœuds du réseau nécessite aussi l’intégration de techniques de

partage du spectre dans le standards 5G. Enfin, il est important de noter que la densification
spatiale et l’agrégation spectrale nécessitent une densification de la partie backhaul du
réseau. Le backhaul est la partie qui connecte les stations de base au cœur du réseau. Par
conséquent, il devrait être en mesure de traiter tous le trafic supplémentaire engendré par
la densification du réseau. Sinon, les réseaux ultra-denses auront un impact très limité sur
les performances globales des réseaux 5G.
— Plus de spectre et d’ondes millimétriques (millimetric waves)
Les systèmes cellulaires mobiles ont presque toujours été déployés dans la bande 300MHz-
3GHz. Toutefois, le spectre est de plus en plus encombré suite à l’augmentation continue du
trafic de données mobiles et du nombre d’appareils connectés. La densification du réseau avec
les cellules de petites tailles est un moyen qui permet la réutilisation du spectre. Cependant,
cette étape n’est pas suffisante puisque la capacité du réseau ne croît que linéairement avec le
nombre de cellules. En même temps, les bandes de fréquences super et extrêmement élevées
(SHF et EHF) dont leur spectre combiné va de 3 à 300 GHz sont sous-utilisées. Les signaux
dans cette bande sont appelés ondes millimétriques (mmW) car leurs longueurs d’onde sont
comprises entre 1 et 100 mm.
Les ondes millimétriques sont caractérisées par une bande passante importante qui se traduit
par un débit très élevé et une très faible longueur d’onde. La petite longueur d’onde présente
l’avantage de permettre la mise en œuvre d’un grand nombre d’antennes très petites dans
une petite zone. Selon Pi et al. [15], l’utilisation des ondes millimétriques offrira un nouveau
spectre de 100 GHz pour la communication mobile, soit un spectre 200 fois plus grand que
celui utilisé dans les bandes inférieures à 3GHz. L’introduction des communications mmW
dans les réseaux cellulaires de nouvelle génération est un pilier important de la 5G. Avec
l’augmentation de la bande passante utilisée, la capacité du réseau augmentera et la latence
diminuera. Cela permettra une meilleure QoE pour les utilisateurs des services temps réel.
Les principaux défis des communications mmW sont les problèmes liés à la propagation
[16]. Le path-loss en espace libre croît avec le carré de la fréquence. Par conséquent, passer
de 3 à 30 GHz ajoute 20dB de perte de puissance du signal. D’après Andrews et al. [16],
si l’ouverture des antennes est maintenue constante, l’effet de perte en espace libre peut
être compensé. D’autre part, les communications mmW sont susceptibles d’être bloquées
par divers objets dans l’environnement. Dans une trajectoire sans ligne de vue (No Line-of-
Sight : NLoS), la perte due au blocage est très élevée, elle est de l’ordre de 15-40dB ajoutée
au path-loss en espace libre qui est d’environ 40dB [17]. De plus, les mmW sont fortement
absorbées par la pluie et l’air.
— Les communications full duplex
La communication Full Duplex (FD) permet à un dispositif sans fil de transmettre et de
recevoir simultanément des données sur la même bande de fréquence. La communication sans
fil a toujours fonctionné en mode semi-duplex, en partant de l’hypothèse que les nœuds sans
fil ne peuvent pas transmettre en recevant des signaux en raison de l’interférence générée
entre les circuits émetteur et récepteur. Ce type de perturbation du signal est appelé auto-
interférence. Pour pouvoir utiliser la communication FD, il faut annuler l’effet de l’auto-
interférence lors du décodage des signaux. Des études récentes ont abordé ce problème afin
d’obtenir un système FD [18]. La communication FD peut doubler l’efficacité spectrale sur
la couche physique en n’utilisant plus des slots distincts pour la liaison montante (uplink)
et la liaison descendante (downlink). Elle peut également améliorer l’efficacité des réseaux
basés sur la contention en éliminant le problème de nœuds cachés. En fait, un problème de
8
terminal caché se produit lorsqu’un nœud B dans le réseau ne peut pas détecter la présence
d’un nœud A qui transmet des données à la même destination en même temps, conduisant
ainsi à une collision au niveau de la station de base de destination.
— Technologies Cloud pour des réseaux d’accès radio 5G flexibles
Une orientation majeure adoptée par la 5G repose sur l’utilisation du cloud. Exploitant
le concept C-RAN (Centralized Radio Access Network), également appelé Cloud RAN, les
stations de base utiliseront des ressources partagées et un cloud centralisé. C-RAN permet
le déploiement d’un grand nombre de cellules ce qui permet d’améliorer l’évolutivité des
réseaux 5G ainsi que d’augmenter leurs capacité et couverture. L’architecture Cloud RAN
sera détaillée dans la section suivante.
En plus de l’architecture Cloud RAN qui offre les fonctionnalités du réseau d’accès en tant
que service, les services cloud ont été proposé comme une véritable technologie 5G. En effet,
avec la prolifération d’une large panoplie d’applications et de services innovants générant
un grand trafic de données, les appareils mobiles sont confrontés à un défi majeur qui est
l’incapacité d’effectuer les calculs efficacement et de traiter des volumes de données aussi
élevés. La séparation de la partie software de la partie hardware par l’intermédiaire du
cloud computing constitue une solution pour des tels problèmes. En fait, la proposition de
solutions basées sur le cloud dans le domaine informatique a révolutionné l’industrie ces
dernières années [19].
En outre, l’intégration du cloud dans un réseau sans fil a ouvert la porte au déploiement
du Mobile Cloud Computing (MCC). Le MCC consiste à offrir aux utilisateurs mobiles des
capacités de calcul et de stockage supplémentaires localisées dans le cloud. La fourniture de
ressources à la demande crée un nouveau niveau de souplesse et d’élasticité dans les services
réseau.
1.3 Vers l’intégration du Cloud dans l’architecture des ré-

seaux cellulaire
1.3.1 Définition et caractéristiques
Tel que défini par le NIST (National Institute of Standards and Technology) [20], le cloud
computing est un modèle qui permet un accès omniprésent et à la demande à un ensemble de
ressources configurables. Les ressources accessibles sont rapidement approvisionnées et nécessitent
de faibles efforts de gestion ou d’interactions avec les fournisseurs de services. En d’autres termes,
le cloud computing fournit des ressources informatiques comme les logiciels ou les applications en
tant que service.
Le cloud computing est constitué grâce à une coalition géographique d’un ensemble de serveurs
puissants connectés à Internet appelés des data centers. Ces serveurs gèrent le calcul d’une façon
distribuée. Les utilisateurs du réseau déchargent leur calcul, leurs applications et services dans
ces serveurs centralisés afin de réduire le coût et améliorer la QoS. Situés dans un seul site, les
groupes de serveurs gèrent le calcul à travers un système distribué, offrant ainsi aux utilisateurs
un traitement plus rapide.
Le cloud computing offre à ses utilisateurs une grande capacité de calcul et de stockage. Le
paradigme du cloud computing est également désigné dans la littérature comme le on-demand
computing, utility computing, ou bien le pay as you go computing. Les ressources offertes par
le cloud sont disponibles sur le réseau et sont accessibles par n’importe quel appareil connecté à
9
travers des mécanismes bien définis. Le cloud peut servir plusieurs utilisateurs simultanément en
affectant et en réattribuant les ressources. Des ressources de calcul, stockage, mémoire et d’autres
ressources possibles sont regroupés dans des data centers et ne dépendent pas de l’emplacement de
l’utilisateur. En d’autres termes, les utilisateurs du cloud ne connaissent pas l’emplacement exact
de la source des ressources fournies.
Le regroupement des ressources permet une meilleure gestion et allocation des ressources pour
couvrir un plus grand nombre d’utilisateurs. Dès lors, les mécanismes pour l’allocation et la li-
bération des ressources cloud doivent être suffisamment rapides pour pouvoir s’adapter aux de-
mandes variables. L’élasticité est une caractéristique très importante pour les plates-formes de
cloud computing. Elle leur permet de toujours donner aux utilisateurs l’impression d’avoir accès
à des ressources illimitées. Pour résumer, le cloud computing est caractérisé par des ressources
partagées, une fourniture des services à la demande, un large accès au réseau, l’élasticité rapide et
une tarification mesurée (Pay per use).
1.3.2 Les modèles en services

Les modèles en services du cloud sont définis par : Software as a Service (SaaS), Infrastructure
as a Service (IaaS), et Platform as a Service (PaaS). Ils sont représentés dans la figure 1.2.
Figure 1.2 – Modèles en service du Cloud Computing (source [22])
Le SaaS est défini comme étant la capacité des utilisateurs d’accéder aux services déployés
par leurs fournisseurs sur le cloud. Les utilisateurs atteignent l’application via une interface sur
leur périphérique. Cependant, ils n’ont aucun contrôle sur l’infrastructure en dessous, y compris
le stockage, les systèmes d’exploitation et les serveurs. SaaS est un marché en croissance où les
applications sont livrées dans un modèle un-à-plusieurs. Déployés sur le cloud, les services sont
gérés d’une manière centralisée et non par les terminaux des utilisateurs. Les mises à jour des
applications sont directement installées par les fournisseurs sur les serveurs cloud.
10
PaaS donne accès à la plate-forme de développement déployée dans le cloud. Les utilisateurs
ont la possibilité de créer et de déployer leurs propres applications sur le cloud à l’aide d’une plate-
forme qui recouvre un environnement de développement complet (langages de programmation,
bibliothèques, services et outils). Comme dans le cas du SaaS, les utilisateurs n’ont aucun contrôle
sur l’infrastructure cloud sous- jacente. Comme indiqué dans [21], SaaS et PaaS peuvent être
considérés comme des analogues où le premier est un logiciel livré sur le web tandis que le deuxième
fournit la plate-forme pour la création de logiciels sur le web.
IaaS offre aux utilisateurs la possibilité de contrôle et d’approvisionnement des ressources. Ils
leur donnent accès aux ressources du cloud telles que les ressources de traitement, les systèmes
d’exploitation et le stockage, où ils sont capables de déployer des logiciels et des applications et
de lancer des tâches de calcul. Même si les utilisateurs ne contrôlent pas l’infrastructure cloud, ils
peuvent avoir un contrôle sur les ressources, les applications déployées et certains composants du
réseau. En utilisant IaaS, ils n’ont plus à investir dans un matériel coûteux, de plus, le dimension-
nement du matériel est beaucoup plus facile et automatique.
1.3.3 Les modèles de déploiement
Figure 1.3 – Les modèles de déploiement(source [24])
Les services cloud, avec leurs trois modèles définis, peuvent être obtenus à travers différents
types de déploiement cloud. Quatre modèles de déploiement ont été définis : le cloud public, le
cloud privé, le cloud communautaire et le cloud hybride.
Tout d’abord, les services du cloud peuvent être livrés par le biais de clouds publics auxquels
l’accès est accordé publiquement pour tous types d’utilisateurs. Cela n’impose pas d’offrir la même
qualité de service à tous les utilisateurs. Les fournisseurs peuvent toujours proposer différents
11
plans cloud avec différents coûts en fonction de la quantité de ressources accessibles. Ces clouds
ne peuvent être gérés que par les fournisseurs, ou par les institutions (entreprises, gouvernement,
universités) qui les déploient dans les locaux des fournisseurs de services cloud.
Contrairement aux clouds publics, qui accordent un accès ouvert au grand public, les clouds
privés n’autorisent l’accès qu’à un ensemble fermé d’utilisateurs. Les services cloud privés sont
exclusivement dédiés à un ensemble spécifique d’utilisateurs définis par le propriétaire du cloud.
Ce type de déploiement est largement utilisé par les organisations professionnelles qui possèdent
leurs propres clouds ou utilisent un cloud privé fourni par un fournisseur de services clouds. Les
coûts de déploiement de ce modèle sont certes plus élevés mais il est plus sécurisé.
Un cloud communautaire tel que défini dans [21] est exclusivement utilisé par une communauté
d’organisations partageant les mêmes intérêts et exigences. Un tel cloud peut appartenir à une de
ces organisations, à un fournisseur de cloud ou à une combinaison des deux. Ainsi, ces organisations
partagent les coûts de déploiement ce qui les aidera à réduire leurs dépenses.
Toute combinaison de deux modes d’accès privé, public ou communautaire conduit à un mode
d’accès en cloud hybride. Dans les clouds hybrides, deux clouds ayant deux ou plusieurs modes de
déploiement sont opérationnellement liés. Ce type de déploiement est parfait pour pouvoir répartir
ses moyens en fonctions des avantages recherchés.
1.3.4 La virtualisation
Figure 1.4 – Le concept de virtualisation(source [26])
La technique de virtualisation est le principal mécanisme pour l’environnement du cloud com-

puting. Comme dans le cloud, tous les utilisateurs partagent le même matériel, les ressources sont
alors rendues abstraites sous forme de machines virtuelles (VM) [22]. Il s’agit d’une séparation
entre la partie matérielle (hardware) et la partie logicielle (software). La virtualisation crée des
ressources virtuelles telles que des systèmes d’exploitation, des serveurs ou des périphériques de
12
stockage. Les ressources sont disponibles à la demande, ce qui introduit un nouveau niveau de
flexibilité, d’évolutivité et d’automatisation dans le déploiement des services.
La virtualisation est possible grâce à un hyperviseur ajouté au-dessus de la couche matérielle.
Plusieurs machines virtuelles peuvent alors s’exécuter sur la couche hyperviseur, et donc au-dessus
de la couche physique exécutant le système d’exploitation habituel. Les machines virtuelles n’ont
pas accès au matériel, mais à la couche hyperviseur. Par le biais de la virtualisation, plusieurs
machines virtuelles peuvent s’exécuter sur une seule machine physique.
Pour les environnements de cloud computing, la virtualisation est alors un outil clé qui permet
à plusieurs utilisateurs d’exécuter diverses tâches sur le même matériel. Elle crée actuellement une
évolution et une transformation majeures dans l’industrie de la communication en offrant des solu-
tions efficaces qui augmentent l’évolutivité et la flexibilité du réseau. Le concept de virtualisation
est représenté dans la figure 1.2.
1.4 Objectif de projet et cahier des chargess

1.4.1 Objectif de projet
Dans sa politique de migration vers la 5G, TT s’apprête à étudier la mise en place d’un réseau
5G V-RAN dans lequel les BBUs sont transformées en des Machines Virtuelles (VMs). Le Projet a
pour objectif d’examiner le modèle de migration des BBUs actuelles du réseau de TT en des VMs
dans la future architecture 5G V-RAN de TT.
1.4.2 Cahier des charges et étapes du projet

Les tâches demandées sont :
— Recherche bibliographique sur les architectures Cloud-RAN/V-RAN/Open-RAN dans la
5G
— Examiner les modèles de migration vers les réseaux V-RAN
— Développer une application web qui illustre cette migration
— Développer un module de migration vers un réseau V-RAN adapté au réseau de TT.
1.5 Conclusion
Le nombre d’appareils connectés au réseau sans fil ne cesse d’augmenter. Par conséquent, le
trafic généré explose aujourd’hui. L’architecture de réseau traditionnelle limitée en termes de ca-
pacités, en particulier dans le domaine du calcul, se trouve rapidement inadaptée à de tels change-
ments et à l’augmentation des exigences et des demandes. Ceci a imposé une série de changements
dans l’architecture du réseau afin de satisfaire l’augmentation exponentielle parallèle du trafic de
données et des exigences de traitement.
Dans ce chapitre, nous avons présenté une description de l’évolution vers la future génération
des réseaux sans fil, la 5G, dont les exigences ont été définies afin de répondre à l’évolution de la
demande des utilisateurs. Ensuite, nous avons décrit l’impact de l’intégration du cloud computing
et la virtualisation dans l’architecture des réseaux cellulaires.
13
Chapitre 2
ARCHITECTURE C-RAN ET MISE EN

PLACE DE LA VIRTUALISATION
2.1 Introduction
L’importante augmentation du nombre d’utilisateurs mobiles ainsi que l’accroissement de la
quantité de données échangées, à travers les infrastructures de télécommunications, ont poussé les
opérateurs et les manufacturiers réseau à concevoir une nouvelle génération de réseaux mobiles, plus
flexible, plus efficiente en terme de consommation d’énergie et qui pourrait répondre aux contraintes
de performance et de QoS, imposées par les nouvelles solutions IT (IoT, réalité augmentée, etc.).
Ainsi, Cloud Radio Access Network (C-RAN) a été définie pour être la nouvelle architecture d’accès
radio des ré- seaux mobiles 5G. Introduit par IBM sous le nom de Wireless Network Cloud (WNC)
[23], le C-RAN a été par la suite décrit dans [24] comme une architecture « green », conçue pour
pallier à certaines limitations présentes dans l’architecture RAN (LTE-A) actuelle. Pour ce faire,
le C-RAN devrait relever les défis suivants :
— Réduire les dépenses d’investissement (CAPEX), liées à l’acquisition de sites d’installation,
à l’achat d’équipements composant une cellule, à l’installation du réseau d’accès, ainsi que
celles d’exploitation (OPEX), liées aux opérations de maintenance, d’entretien des équipe-
ments et de la mise à jour des systèmes logiciels.
— Réduire la forte consommation d’énergie dans les réseaux d’accès, causée par le déploiement
d’un grand nombre de stations de base, nécessaire pour offrir une meilleure couverture. Pour
cela, le C-RAN doit intégrer des solutions logicielles et matérielles, permettant d’optimiser
la consommation d’énergie tout en améliorant les performances réseau. De plus, de nouvelles
stratégies de déploiement d’antennes doivent être pensées pour améliorer la couverture du
réseau.
— Augmenter la capacité du réseau d’accès afin de prendre en charge le nombre croissant
d’utilisateurs ainsi que les données générées par leurs terminaux mobiles.
— Améliorer la gestion de la mobilité des utilisateurs et l’impact de leur consommation de
données sur les stations de base, se trouvant dans leur zone géographique. Pour ce faire, il
est nécessaire de prendre en considération le taux d’utilisation de chaque station de base,
en fonction de la période de temps, pour déterminer les zones à forte densité d’utilisateurs.
Cette solution aurait également pour objectif d’optimiser la consommation d’énergie en
mettant en veille active les stations localisées dans des zones à très faible densité humaine.
— Ouvrir le réseau d’accès radio aux fournisseurs de services pour le déploiement de solu-
tions logicielles qui permettraient, d’une part, d’offrir aux utilisateurs de nouveaux services,
14
Chapitre 2. ARCHITECTURE C-RAN ET MISE EN PLACE DE LA
VIRTUALISATION
contenus et applications avec de meilleures QoE et de performances possibles, et d’autre

part, de pouvoir traiter et acheminer le trafic de données au plus près des terminaux, sans
forcément passer par le réseau cœur de l’opérateur (EPC), ce qui permettrait de réduire le
coût de transport des données vers l’EPC.
Nous présenterons, dans ce chapitre, le concept du C-RAN. Nous décrirons notamment les
éléments qui composent son architecture. Ensuite, nous énumérerons les avantages apportés par le
C-RAN. Enfin, nous détaillerons les deux modèles définis pour la centralisation du système radio
dans le C- RAN.
2.2 Composants de l’architecture C-RAN
Figure 2.1 – Composition de l’architecture C-RAN(source [29]).
Dans l’architecture actuelle des réseaux LTE, l’eNodeB représente l’élément principal de la
partie d’accès radio. Il se charge de la réception/transmission des signaux radio à partir de/vers
les terminaux utilisateurs (UE), de la gestion des ressources radio (Radio Resource Management
(RRM)), de la compression des entêtes IP, de la sécurité, etc. Distribués aux extrémités du ré-
seau, les eNodeB servent de stations de base aux UE ainsi que de relais vers l’EPC et internet.
Dans l’architecture C-RAN (figure29), les eNodeB sont remplacés par de simples antennes radio
qui permettent de réceptionner et/ou de transmettre les signaux radio. Nommées Remote Radio
Head/Unit (RRH/RRU), ces antennes sont déployées au plus près de l’utilisateur et de ses termi-
naux. Les fonctions de traitement de l’interface radio, appelées BaseBand Unit (BBU), sont par
ailleurs séparées des antennes pour être rassemblées et centralisées au sein d’un nouvel élément ap-
pelé BBU pool ou Cloud BBU (C-BBU). A la manière d’un Cloud, le pool BBU permet de traiter
tous les signaux reçus à partir des différentes RRH reliées à lui. Cet élément va alors exécuter les
fonctions BBU en offrant de meilleures performances et en consommant moins d’énergie que les
eNodeB qu’il remplace dans le réseau.
15
VIRTUALISATION
2.2.1 Remote Radio Head (RRH)

La RRH est composée des éléments suivants :
— Un filtre permettant d’enlever certaines bandes ou fréquences du signal transitant par l’an-
tenne.
— Un amplificateur qui permet d’accentuer la puissance du signal.
— Un convertisseur de signal analogique-numérique (ADC) et numérique-analogique (DAC).
— Un convertisseur up/down et un module de conversion d’échantillons du signal (Sample
Rate Conversion (SRC)).
— Un module d’encapsulation des données In-phase/Quadrature (IQ) dans des paquets, utili-
sant.
le protocole d’interface, Common Public Radio Interface (CPRI) [25] ou d’autres standards tels
que, Open Base Station Architecture Initiative (OBSAI) et Open Radio Interface (ORI) [26].
Les RRH sont généralement déployées aux extrémités du réseau mobile et sont localisées à une
distance, pouvant atteindre les 40 km de la BBU [27]. Elles permettent d’amplifier, filtrer et récu-
pérer/transmettre les signaux radio à partir/vers des UE ou du pool BBU. Les RRH n’exécutent
pas de calcul en local et un certain nombre d’entre elles peuvent être connectées à une passerelle
appelée RRH Gateway (RRH GW) (figure 2), qui se charge de grouper les signaux reçus par les
antennes pour les transmettre au pool BBU.
2.2.2 Fronthau
L’ensemble des RRH sont reliées au pool BBU à travers un réseau FH, lequel permet de
transporter les données IQ généralement encapsulées par le protocole CPRI à travers un lien
point-à-point. Alors que dans une architecture LTE-A, l’échange des signaux entre l’antenne et
la BBU se fait au niveau d’un eNodeB (en interne), cet échange peut être étendu sur plusieurs
kilomètres dans une architecture C-RAN. Par conséquent, l’infrastructure réseau du fronthaul
doit prendre en considération les contraintes strictes, citées ci-dessous :
— Une large bande passante, avec un débit supérieur à 10 Gbit/s, en raison de la charge
supplémentaire apportée par le transport des données IQ à travers le fronthaul [28].
— Une faible latence de transmission nécessaire pour le traitement des signaux par la couche
PHY du réseau d’accès (se trouvant dans le pool BBU). De ce fait, selon [28], le Round Trip
Time (RTT) ne doit pas excéder les 5 µs. Néanmoins, selon [29], cette valeur variera entre
100 µs et 400 µs et dépendra des équipements utilisés ou/et de l’architecture adoptée par
les opérateurs.
— Une synchronisation des horloges de l’équipement radio (Radio Equipment (RE)), se trou-
vant dans la RRH et celle du contrôle de l’équipement radio (Radio Equipment Control
(REC)) qui se trouve dans le pool BBU.
— Une faible fraction de fréquence du signal Fractional Frequency Offset (FFO) qui ne doit
pas dépasser les 2 parties par million (Part Per Million (ppm)) [30], ainsi qu’une faible gigue
(variation de latence au niveau du FH).
Afin de répondre à ces contraintes techniques, un certain nombre de solutions réseau ont été
proposées pour intégrer le fronthaul et transporter le trafic radio entre les RRH et le BBU pool.
Les avantages et les inconvénients de chaque solution sont décrits ci-dessous.
16
VIRTUALISATION
2.2.2.1 Fibre optique dédiée (fibre noire)

La fibre optique dédiée peut fournir un débit puissant (jusqu’à 100 Gbit/s) sur de longues
distances (jusqu’à 50 km) et elle représente la solution la plusefficace, en terme de performance.
De ce fait, elle permet de relier les antennes radio au pool BBU et de satisfaire toutes les contraintes
liées au transport des données IQ à travers le fronthaul. En outre, elle peut être déployée de manière
rapide et ne nécessite pas d’équipements particuliers pour son fonctionnement. Cependant, la fibre
optique dédiée reste coûteuse à étendre et à maintenir, en raison de la forte utilisation de ressources
de fibre et pourrait par conséquent ne pas atteindre un des principaux objectifs, définis pour le
C-RAN qui est celui de la réduction des CAPEX/OPEX sur l’infrastructure réseau.
2.2.2.2 Multiplexage en longueur d’onde (Wavelength Division Multiplexing (WDM))

WDM est une technique qui permet de transporter plusieurs longueurs d’ondes optiques (40-
80) sur une seule et même fibre [27], en utilisant différents canaux (chaque canal correspond à une
longueur d’onde) grâce à l’intégration de modules de transpondeur au niveau des deux parties du
C-RAN. L’avantage de WDM est son coût d’exploitation réduit comparé à celui de la fibre optique
dédiée et son optimisation des ressources optiques. En outre, cette technique garantit des débits
élevés et une faible latence, paramètres indispensables pour le transport du trafic de données à
travers le FH. Il existe deux différents types de multiplexage en longueur d’onde :
— Dense Wavelength Division Multiplexing (DWDM) : pouvant obtenir entre 80 et 160 ça-
naux optiques, méthode utilisée lorsque les espacements entre les longueurs d’onde doivent
être très courts. L’avantage de DWDM, est son utilisation d’ondes amplifiables, sans passer
par un amplificateur électrique, ce qui permet d’éviter la reconversion du signal optique en
signal électrique et vice versa. Néanmoins, cette technique reste coûteuse car elle nécessite
une régulation de la température du laser d’émission de longueurs d’onde, en raison de
l’intervalle court, présent entre chaque impulsion du signal procédée par le laser.
— Coarse Wavelength Division Multiplexing (CWDM) : technique moins coûteuse, car ne
nécessitant pas de régulation de la température des lasers (les intervalles d’impulsions sont
plus longs que pour DWDM) et n’utilisant pas d’amplificateur optique pour une raison
d’incompatibilité. Ainsi, cette méthode peut effectuer du multiplexage avec des composants
moins chers mais sur de courtes distances.
WDM est considéré actuellement comme la solution la plus appropriée pour l’architecture
C-RAN en raison de ces performances, sa scalabilité, ainsi que son coût amoindri (notamment la
méthode CWDM). Par conséquent, son déploiement dans le fronthaul à travers un réseau de trans-
port optique (Optical Transport Network (OTN)) est envisagé par un grand nombre d’opérateurs
[31].
2.2.2.3 Micro-ondes
Pouvant être utilisée sur de larges bandes de fréquence (70-80 GHz [32]), la transmission par
micro- ondes représente une alternative intéressante pour le transport des données IQ à travers
le FH. Cette solution peut être mise en place dans des stades, campus universitaires ou encore
dans des aéroports, où il est généralement difficile de déployer de la fibre optique. Les micro-ondes
offrent une faible latence et permettent d’atteindre des débits de 10-40 Gbit/s sur de courtes
distances (inférieures à 1.5 km [33]). Néanmoins, Ces performances restent en deçà de celle définies
pour le fronthaul C-RAN. Les micro-ondes restent tout de même une solution envisageable pour
17
VIRTUALISATION
une utilisation dans le backhaul [34], notamment dans certaines régions où il peut être compliqué
d’établir des connexions filaires.
2.2.2.4 Ethernet
Ethernet représente un standard réseau mature, largement déployé dans les infrastructures
existantes. Alors qu’il constitue le médium de transport principal dans le backhaul, l’adoption de
ce protocole dans le FH est sérieusement envisagée par un grand nombre d’opérateurs et d’équipe-
mentiers qui voient en Ethernet un moyen peu coûteux et efficace de relier les RRH au pool BBU.
En outre, Ethernet présente de nombreux avantages pour le transport des données, tels que :
— Utilisation de fonctions d’opération, d’administration et de maintenance (Operations, Ad-
ministration and Management (OAM)) pour la détection et la localisation d’erreurs, le
diagnostic des données ainsi que l’apport d’informations liées aux performances du réseau.
— Faible coût d’exploitation des équipements Ethernet actuellement déployés dans les réseaux
d’accès des opérateurs, ainsi que la possibilité de les partager avec d’autres infrastructures
pour le transport des données.
— Possibilité de contrôler, gérer et orchestrer le trafic de données transitant dans le réseau
grâce à l’utilisation de technologies de type SDN.
— Transmission des données à très haut débit, pouvant atteindre les 100 Gbit/s entre deux
extrémités du réseau [35].
Bien qu’Ethernet soit une alternative intéressante et moins coûteuse que WDM, cette solution
possède néanmoins des limitations, pouvant restreindre son utilisation dans le FH. La première
limitation est l’absence de synchronisation des horloges qui est nécessaire lors de la transmission
des données IQ entre l’émetteur et le récepteur qui peut conduire à l’apparition d’erreurs de trans-
mission et/ou à la corruption du signal source. La seconde limitation concerne les performances de
latence et de gigue apportées par Ethernet qui restent en deçà du seuil requis pour le transport de
données dans le FH. Ces performances peuvent par ailleurs se dégrader si des nœuds ou switches
intermédiaires se trouvent entre les RRH et la BBU.
Afin d’adapter Ethernet à la transmission radio, un certain nombre de travaux a été mené pour
répondre aux contraintes imposées par le transport des données IQ à travers le protocole CPRI.
Nous citons, comme exemple, le standard Synchronous Ethernet (SyncE), protocole défini par
l’Union Internationale des Télécommunications (International Telecommunication Union (ITU))
sous les recommandations G-8261, G-8262±et G-8264. Le pri±ncipe de SyncE est de fournir une
synchronisation stricte des horloges avec une fraction de fréquence de 4.6 ppm, contre 100 ppm
pour la norme Ether- net IEEE 802.3, dans la couche physique du modèle Open Systems Intercon-
nection (OSI), nécessaire pour le transport des fréquences radio à travers un réseau Ethernet [36].
D’autres standards ont par ailleurs été définis prenant en considération cette synchronisation des
transmissions à travers Ethernet, tels que, IEEE 1588 Precision Time Protocol (PTP) (synchroni-
sation dans la couche liaison) [37] et IETF Network Time Protocol (NTP) (synchronisation dans
la couche réseau) . Une nouvelle spécification du protocole CPRI, appelée eCPRI, est à l’étude
pour intégrer la 5ème génération de réseaux mobiles. Proposé par de grands noms de l’industrie
des télécommunications, tels que, Huawei, Ericsson, Nokia et NEC, eCPRI aura pour objectif de
réduire l’utilisation de la bande passante (de 10 fois), d’exploiter les infrastructures existantes à
travers Ethernet, d’adopter Ethernet comme la principale solution de transport dans le fronthaul,
etc. Des projets de recherche ont été également lancés pour faire converger les architectures 4G et
5G afin de réduire les coûts CAPEX/OPEX liés à la mise en place d’une nouvelle architecture de
réseau d’accès. Nous citons notamment, le projet Elastic Network qui prévoit d’adopter Ethernet
18
VIRTUALISATION
comme protocole de transport des données radio à travers le FH.
2.2.3 Baseband Unit (BBU)

Appelée également Radio Cloud Center (RCC) dans certaines architectures, la Baseband Unit
(BBU) est composée d’un ensemble de couches et de fonctions, servant à traiter les signaux radio,
transitant par le réseau d’accès. Alors qu’elle est associée à l’unité radio (RU/RH) dans un eNodeB
dans l’architecture RAN de la 4G, la BBU est séparée de cette même RU (appelée alors RRH/RRU)
dans une architecture C-RAN pour être, par la suite, regroupée avec d’autres unités de traitement
au sein d’un même élément, appelé pool BBU. Ce dernier est généralement virtualisé et centralisé
dans un serveur (ou un mini Datacenter) se trouvant entre les RRH et le réseau cœur (EPC). Le
pool BBU fournit ainsi les ressources physiques nécessaires pour le traitement des signaux.
La centralisation des unités BBU en un seul pool offre un grand nombre d’avantages, tels que,
le partage des ressources virtuelles et matérielles entre les différentes BBU, l’efficience énergétique
grâce à la possibilité de désactiver le fonctionnement de certaines unités BBU selon leur charge
de traitement, la simplification des opérations de configuration des cellules, l’augmentation de la
capacité de calcul pour le traitement des signaux radio, la gestion améliorée de la mobilité des
UE ainsi que des opérations de handover, etc. Néanmoins, afin de fournir ces performances, il est
nécessaire d’intégrer des algorithmes d’ordonnancement des ressources partagées en sein du pool
BBU et de déterminer le bon placement de ce dernier par rapport aux RRH déployées dans le
réseau.
Une unité BBU intègre les trois couches protocolaires composant l’eNodeB : la couche phy-
sique (PHY/L1), la couche (Media Access Control (MAC)/L2) ainsi que la couche contrôle (Radio
Resource Control (RRC)/L3). Les fonctions de chacune de ces couches sont présentées ci-dessous.
2.2.3.1 Couche physique

La couche physique représente la couche basse (L1) de la BBU. Elle se charge de la transmis-
sion/réception des données IQ à travers le fronthaul grâce à l’exécution des fonctions suivantes :
— Codage de canal : permet de détecter les changements (erreurs) produits sur les bits de
données reçues grâce à l’utilisation du code Cyclic Redundancy Check (CRC). Ces erreurs
sont par la suite corrigées grâce à l’utilisation des fonctions Forward Error Correction (FEC),
lequel permet d’ajouter des bits redondants à la donnée ainsi que de la fonction Automatic
Repeat Request (ARQ) qui, en cas d’existence d’erreur, va solliciter une retransmission du
paquet de données erroné.
— Adaptation de lien : nommée également Adaptive Modulation and Coding (AMC). Cette
fonction permet de moduler les bits à transmettre avec un code rate correspondant à la
qualité du canal de transmission.
— Multiple-Input Multiple-Output (MIMO) : technique de multiplexage permettant de trans-
mettre les données vers plusieurs RRH en simultané.
— Modulation multiporteuse : permet de transmettre les données modulées sur de multiples
porteuses en même temps.
— Mesures radio : estime la qualité du signal et du canal de transmission, ainsi que la puissance
des signaux émis par les différentes RRH (cellules).
— Synchronisation : notamment celle des horloges entre la RRH et la BBU.
— Signalisation des informations de contrôle : entre l’UE et les réseaux d’accès.
19
VIRTUALISATION
2.2.3.2 Couche MAC

La Couche MAC, appelée également couche 2 (L2), est composée de trois sous couches qui
interviennent pour la transmission des paquets de données (le DP) et pour le CP. La description
de chacune de ces sous couches est donnée ci-dessous :
— Packet Data Compression Protocol (PDCP) : intégrant plusieurs fonctions. La sous couche
PDCP permet de compresser les entêtes des paquets, en utilisant des mécanismes tels que
Robust Header Compression (RoHC) pour améliorer l’efficacité spectrale sur des services
de type voix sur IP (VoIP). Elle permet également de chiffrer et de protéger l’intégrité
des données de signalisation RRC. Enfin, cette sous couche se charge de la détection et de
la suppression des doublons (paquets de données) qui apparaissent généralement lorsqu’un
handover se produit entre deux cellules.
— Radio Link Control (RLC) : assure le contrôle des liaisons de données grâce à des fonctions
de détection d’erreurs, de retransmission de paquets (en cas d’erreur), d’ordonnancement
de ces derniers et d’optimisation des transmissions grâce à l’utilisation de fenêtres d’émis-
sion/réception.
— Medium Access Control (MAC) : permet d’accéder et d’adapter la transmission des don-
nées au canal de transport correspondant. Pour cela, la sous couche MACutilise desfonc-
tions d’allocation dynamique des ressources radio, de maintien de synchronisation (en lien
montant) et de priorisation des flux de données. La sous couche MAC utilise également le
mécanisme Hybrid Automatic Repeat Request (HARQ) pour une transmission fiable des
paquets.
2.2.3.3 Couche Radio Resource Control (RRC)

Troisième couche de la pile protocolaire, RRC assure la configuration et le contrôle des couches
sous-jacentes. Elle est ainsi responsable des fonctions suivantes :
— Diffusion et décodage des informations système liées aux couches Access Stratum (AS) et
Non- Access Stratum (NAS).
— Gestion des envois/réceptions de radio messagerie (paging),
— Gestion des connexions entre les couches RRC de l’UE et de l’unité de traitement.
— Établissement, configuration et maintenance des connexions point à point des Radio Access
Bearer (RAB).
— Gestion des fonctions et des clefs de sécurité.
— Gestion et contrôle de la mobilité des UE en mode connecté et en mode veille.
— Gestion de la QoS et des mesures de l’UE.
2.3 Avantage du C-RAN

Le C-RAN présente de nombreux avantages, comparé aux architectures d’accès radio actuelles.
Nous allons énumérer dans cette section les principaux avantages apportés par le C-RAN aux
utilisateurs ainsi que pour les opérateurs mobiles :
Efficience énergétique : grâce à la centralisation de la partie traitement de l’interface radio.
L’architecture C-RAN permet de réduire considérablement (de dix fois) le nombre de stations de
base déployées, par rapport aux architectures actuelles [28]. Cela implique une baisse significative
de la consommation d’énergie qui est habituellement élevée au niveau de ces stations de base.
En outre, le partage des ressources entre les différentes unités BBU présentes dans le pool offre
20
VIRTUALISATION
la possibilité de mettre en veille certaines de ces unités, lorsque leur charge de travail est faible.
Les traitements restant peuvent alors être migrés vers d’autres unités au sein du pool pour plus
d’efficience énergétique. Le C-RAN réduit également la quantité d’énergie consommée, lors de la
transmission du signal, grâce à une gestion plus efficace des interférences et un déploiement plus
dense des RRH qui vont alors former de petites cellules dans le réseau.
Réduction des CAPEX-OPEX : le regroupement des BBU en un petit nombre de pools
permet de réduire leur coût de déploiement, de gestion et de maintenance. De plus, la distribution
des RRH aux extrémités du réseau est plus simple à effectuer en comparaison avec les eNodeB
actuels, ce qui diminuera les dépenses réalisées par les opérateurs dans les infrastructures d’accès.
Le C-RAN pourra également exploiter les installations déjà présentes dans les réseaux mobiles,
notamment les infrastructures Ethernet déployées dans les réseaux LTE. Enfin, tel que ne l’avons
mentionné précédemment, l’efficience énergétique de l’architecture C-RAN permettra de considé-
rablement baisser les coûts liés à la consommation d’électricité et d’autres énergies nécessaires au
fonctionnement du réseau.
Amélioration de la capacité spectrale : l’architecture C-RAN facilitera la mise en place
de nouveaux mécanismes de détection et d’atténuation d’interférences intercellulaires, grâce no-
tamment à la simplification du partage d’informations (au sein du pool BBU), liées aux signaux
envoyés par les UE actifs et les données liées à l’état des canaux (Canal State Information (CSI)).
Cela garantie une plus grande efficacité spectrale, en comparaison avec l’architecture LTE.
Adaptabilité au trafic de données non-uniforme : la virtualisation des unités de BBU au
sein d’un pool centralisé permet de gérer l’allocation et le partage des ressources entre les BBU.
Par conséquent, les périodes de forte/faible charge, à un endroit particulier du réseau, sont mieux
traitées par le C-RAN. En outre, l’utilisation des ressources est optimisée grâce à la possibilité
d’activer/désactiver des unités BBU ou encore de répartir le traitement dans tout le pool. Enfin,
le load balancing intégré au FH permet de prendre en charge le trafic de données non-uniformes,
généré par des UE en mouvement.
Amélioration des performances réseau : en raison de la séparation des parties RRH
et BBU dans le C-RAN, il est devenu nécessaire de mettre en place une infrastructure réseau
performante dans au sein du FH. En particulier, en termes de bande passante et de latence. Cela
profitera donc aux utilisateurs qui auront accès à des débits élevés (dépassant les 10 Gbit/s) et à
de nouveaux services, lesquels pourront exploiter ces performances et offrir une meilleure QoE aux
les utilisateurs.
2.4 Architecture C-RAN proposer par les industriels

Comme le montre la figure 1., l’histoire de l’architecture C-RAN dans l’industrie remonte à
2010. Le concept a été d’abord proposé par IBM sous le nom de réseau cloud sans fil (WNC :
Wireless Network Cloud) dans le but de réduire le coût du réseau et le rendre plus flexible en
terme de capacité [38].
Ce concept a été ensuite exploité par China Mobile Research Institute en 2011 [39] pour élaborer
l’architecture C-RAN avec les nouvelles technologies et l’analyse de faisabilité. Pour traiter la
pénurie de fibres, ZTE [40] a proposé différentes solutions telles que, la connexion de fibre améliorée,
la connexion de fibre colorée et la porteuse du réseau de transport optique qui peut utiliser quelques
fibres pour répondre aux exigences de la porteuse du réseau C-RAN.
Intel a, par la suite, proposée un GPP (General-Propose Processor) efficace et évolutif en se
basant sur l’architecture des BBU pool [41]. Ce GPP permet d’utiliser les ressources à la demande.
21
VIRTUALISATION
Figure 2.2 – Les propositions d’architectures C-RAN dans l’industrie
Par la suite, Alcatel-Lucent [42] a proposé le concept de station de base cloud qui exploite les
techniques de virtualisation dans le but d’utiliser moins de ressources de traitement et cela sans
dégrader les performances du système.
En 2013, NTT DoCoMo a commencé à développer une architecture C-RAN avancée pour son
futur réseau mobile LTE-Advanced [43]. En 2013 également, Telecom Italia a souligné l’intérêt
du concept RAN-as-a-Service (RANaaS), qui offre les avantages de l’architecture C-RAN avec
plus de flexibilité [44]. En 2014, Nokia a publié son white paper nommé « Liquid Radio », dans
lequel l’architecture C-RAN centralisée est considérée comme un moyen efficace pour améliorer
l’utilisation du réseau [45].
La principale différence entre ces différentes architectures préconisées par les industriels réside
dans le degré de répartition des fonctionnalités entre le RRH et le BBU pool. Par exemple, China
Mobile Research Institute a proposé une architecture entièrement centralisée et une autre par-
tiellement centralisée [39]. L’architecture entièrement centralisée, montre une approche type pour
déployer le réseau C-RAN, dans laquelle les fonctionnalités PHY, MAC et toutes les couches du
réseau sont transférées vers le BBU pool. Le principal avantage de cette approche est qu’elle est
22
VIRTUALISATION
entièrement centralisée et que presque aucun périphérique de traitement numérique n’est néces-
saire dans les RRHs, ce qui pourrait les rendre très petits et peu coûteux. Par contre, le taux de
transmission des liens fronthaul requis pour le renvoi I/Q sera relativement élevé. L’architecture
entièrement centralisée peut atteindre les gains maximaux de LSCP, mais ce gain sera atteint au
détriment d’un coût élevé sur les liens fronthaul car tous les signaux I/Q de tous les terminaux
mobiles devront être envoyés au BBU pool en temps opportun. Dans [43], les auteurs rapportent
que la capacité fronthaul requise dans une architecture entièrement centralisée est de l’ordre de 10
Gbps pour un système LTE avec huit antennes de réception et une bande passante de 20 MHz.
Dans l’architecture partiellement centralisée. Les fonctionnalités de la couche PHY sont inté-
grées dans les RRHs alors que les autres fonctionnalités des couches supérieures sont exécutées
dans le BBU pool. Bien que les fortes exigences sur les liens fronthaul soient atténuées dans cette
architecture partiellement centralisée, le LSCP ne peut pas être efficacement soutenu car les fonc-
tionnalités de la couche PHY restent encore dans le RRH, et seul le gain distribué CoMP peut
être atteint. De toute évidence, la capacité fronthaul requise et la capacité de traitement de signal
nécessaires dans le BBU pool diminuent de façon significative lorsque la répartition fonctionnelle
est décalée vers la couche MAC.
La compagnie NTT DoCoMo a de son côté introduit, dans [43], une architecture C-RAN
avancée capable d’utiliser un "carrier aggregation" (CA) entre les porteuses des petites et des
macros cellules. Dans cette architecture, la plupart des fonctionnalités des couches PHY et MAC
sont implémentées dans les RRHs et seules les fonctionnalités des couches supérieures sont déplacées
dans le BBU pool. La solution 3 de la figure 2.3 montre que seules les fonctionnalités du plan de
contrôle sont intégrées dans le BBU pool, ce qui suggère que seul le gain CRRA peut être atteint
bien que les exigences du lien fronthaul puissent être négligées [46].
Figure 2.3 – Répartitions fonctionnelles des C-RAN proposés dans la littérature.
Contrairement à ces répartitions fonctionnelles fixes, Telecom Italia a proposé le réseau d’accès
en tant que service (RANaaS) dans le but d’introduire une répartition flexible entre les fonction-
nalités au niveau du RRH et au niveau du BBU pool comme le montre la solution 4 de la figure 1.
Cette architecture est plus précisément le résultat du projet européen iJoin [47]. Cette flexibilité
vise à permettre le choix, d’un point de fonctionnement optimal, entre la centralisation complète
23
VIRTUALISATION
et l’exécution locale [7], qui est échangé avec des gains LSCP plus faibles en termes d’efficacité
spectrale et des exigences de haute capacité du réseau fronthaul. L’avantage d’une division flexible
est de tirer parti des deux extrêmes : gains en efficacité spectrale (SE : Spectral Efficiency) et éner-
gétique (EE : Energy Efficiency) significatifs pour un fronthaul à capacité élevée, et gains SE/EE
faibles pour un fronthaul à faible capacité.
L’élément central de l’architecture RANaaS est la centralisation des fonctionnalités RAN via
une plate-forme informatique ouverte basée sur une infrastructure cloud. Les fonctionnalités RAN
sont ainsi fournies à l’utilisateur comme un service à la demande. Cependant, bien que l’idée
soit très intéressante, la portée de ce projet était limitée aux réseaux LTE à petites cellules.
Cette architecture est présentée dans la figure 2. Dans la partie gauche de la même figure est
illustrée une implémentation LTE traditionnelle où toutes les fonctionnalités jusqu’au contrôle
d’admission/congestion sont implémentées localement au sein de la station de base. Le côté droit
illustre l’approche C-RAN, où seule la couche radiofréquence (RF) est implémentée localement et
toutes les autres fonctionnalités sont centralisées dans le cloud dans le BBU pool.
Figure 2.4 – Le concept RANaaS (source )
Dans le but de réduire le coût du réseau fronthaul et atténuer les demandes pour une grande
capacité et un retard minimal, NEC Corporation a proposé en 2016 [48] une architecture C-RAN
introduisant des nouvelles interfaces qui séparent les fonctionnalités des RRHs de celles des BBUs
dans la couche de protocole au-dessus de la couche physique. Deux structure C-RAN sont alors
envisagées : (a) L2 C-RAN dans laquelle le RRH couvre les fonctionnalités de la couche physique et
le BBU couvre le reste des couches, (b) L3 C-RAN dans laquelle le RRH couvre les fonctionnalités
des couches physique, MAC et RLC et le BBU couvre celles des couches PDCP, RRC et RRM.
NEC propose aussi de virtualiser les petites cellules pour supprimer les limites entre elles. Ainsi,
un nouvel espace virtuel est créé pour fournir des services à un nombre limité d’utilisateurs à un
instant donné.
En 2017, Nokia a présenté sa dernière solution Cloud RAN intitulée « AirScale Cloud RAN
» [49]. Il s’agit d’un RAN multicouches qui divise l’architecture de traitement bande de base en
fonctionnalités temps réel (RT) et non temps réel (NRT). Une interface X-Haul permet connecte
les fonctionnalités temps réel et non temps réel. Cette solution vise à permettre aux opérateurs de
migrer facilement vers une architecture Cloud RAN 5G quelques soit leur architecture déployée.
24
VIRTUALISATION
Cette solution permet d’utiliser différents types de réseaux fronthaul, y compris Ethernet.
25
VIRTUALISATION
Architecture Avantages Inconvénient

1ère proposition de China Mobile -Entièrement centralisée -Exigences du lien fronthaul
-RRHs simples et peu coûteux très élevé
-Peut atteindre les gains
maximaux de LSCP
2ème proposition de China Mobile -Exigences sur les liens - Seul le gain CoMP
fronthaul sont atténuées distribué peut être atteint
-La capacité de traitement de
signal nécessaire dans
le BBU pool diminue
Proposition de NTT DoCoMo -Exigences négligeable sur -Seul le gain CRRA peut
le lien fronthaul être atteint
-Permet une répartition - La portée du projet
flexible entre les est limitée aux réseaux
fonctionnalités LTE à petites cellules
au niveau du RRH
et au niveau du BBU pool
RANaaS - Permet des gains en
efficacité spectrale et
énergétique significatifs
pour un fronthaul à capacité
élevés
- Permet des gains SE/EE
faibles pour un fronthaul
à faible capacité.
- Réduit le coût du - De nouveaux
réseau fronthaul. protocoles doivent être
La création d’un créés pour les nouvelles
nouvel espace virtuel interfaces.
permet de :
Proposition de NEC - Éviter le handover quand le MT
se déplace d’une petite
cellule à une autre.
- Réduire l’interférence entre
les petites cellules
- Allouer efficacement les ressources
sans fil aux utilisateurs
- Déploiement à faible coût - Tous les composants
- Permet de migrer facilement sont gérés sous forme d’un
vers un réseau 5G seul cloud avec une
AirScale Cloud RAN - Flexible dans la fourniture orchestration commune.
de services
- Compatible avec plusieurs
réseaux Fronthaul
- Plus de souplesse dans - Tous les composants
la création des réseaux pour sont gérés sous forme d’un seul
Ericsson couvrir une grande variété de cloud avec une
cas d’usages 5G orchestration commune.
- compatibles
26 avec la gamme
Ericsson Radio System
2.5 Modèles de centralisation du C-RAN
La division effectuée entre l’unité radio (RRH) et l’unité de traitement (BBU) dans l’interface
radio est la principale innovation apportée par le C-RAN. Bien que cette séparation apporte de
nombreux avantages (voir la Section 3), elle impose cependant des contraintes techniques strictes,
notamment en termes de latence et de gigue. Dans [28], deux modèles de division ont été défi-
nis afin d’adapter l’architecture C-RAN aux infrastructures réseau existantes et aux technologies
utilisées pas ces dernières. Ces deux modèles diffèrent principalement dans le nombre de couches
protocolaires centralisées dans le pool BBU. De ce fait, il existe deux différentes « centralisations
», correspondant à chacun des deux modèles.
Figure 2.5 – Modèles de « centralisation » des couches protocolaires dans une architecture C-
RAN.
27
VIRTUALISATION
2.5.1 Centralisation complète (Full centraization)

Dans ce modèle (figure 6 (A)), les couches PHY, MAC et RRC, séparées de la RRH, sont
centralisées dans le pool BBU. La centralisation complète représente le modèle de division optimal
dans une architecture C-RAN, telle qu’elle a été définie dans [28]. Néanmoins, son implémentation
nécessite la prise en compte des conditions suivantes :
— Une large bande passante pour le transport des données IQ entre les RRH et le pool BBU
distant.
— Une faible latence dans le canal de transmission (au niveau du FH), afin de garantir no-
tamment le bon fonctionnement du mécanisme HARQ (couche L2), pour une transmission
fiable des données ainsi qu’un traitement efficace des signaux radio en temps réel,
— Une synchronisation stricte des horloges, entre la RRH et la couche physique qui est centrali-
sée dans la BBU, pour le transport des paquets CPRI. Cela implique la présence d’une faible
gigue dans le FH et l’utilisation de protocoles pouvant supporter cette synchronisation,
— Un débit élevé de transmission de données dans le FH, généré par le protocole CPRI. P.ex.,
une transmission sur une bande passante de 20 MHz génère au minimum 14.7 Gbit/s de
données [28].
Les conditions décrites ci-dessus exigent le déploiement d’une infrastructure réseau robuste dans
le fronthaul qui permettrai de fournir les performances requises pour la transmission des signaux
radio, à partir des RRH vers le pool BBU. Une telle infrastructure peut s’avérer coûteuse pour les
opérateurs de télécommunications qui seront ainsi contraints de déployer de nouveaux équipements
et de nouvelles liaisons pour adapter leur réseau à l’architecture C-RAN. En outre, seule une
infrastructure utilisant de la fibre optique (dédiée ou pas) avec la technique de multiplexage WDM
pourra supporter une centralisation complète [31]. Cependant, ce modèle de division présente un
grand nombre d’avantages qui sont donnés ci- dessous :
— Un déploiement simplifié et moins coûteux des antennes radio (stations de base) qui ne
nécessiteront plus l’utilisation de ressources de calcul pour le traitement des signaux radio
aux extrémités du réseau d’accès,
— Un partage optimisé des ressources (physiques et virtuelles) dans le pool BBU, pour un
meilleur traitement des signaux/données reçues, impliquant les traitements collaboratifs
intercellulaires ainsi qu’une scalabilité accrue (ajout de la puissance de calcul),
— Des performances élevées, en termes de débit, latence, gigue, etc. Cela offrira aux fournis-
seurs d’accès/services une infrastructure réseau pouvant héberger et supporter un grand
nombre d’applications, nécessitant une bonne qualité de service (jeux vidéo, streaming,
etc.),
— Possibilité de mettre en place des algorithmes de répartition de charge optimisés entre les
différentes BBU, au sein d’un pool,
— Implémentation de techniques avancées de communications radio, telle que Coordinated
Mul- tipoint (CoMP) [50].
2.5.2 Centralisation partielle

Bien que la centralisation totale représente le modèle de division optimal pour une architecture
C- RAN, son implémentation demeure complexe, en raison des contraintes techniques qu’elle im-
pose et du coût que son déploiement implique au niveau du FH. Les opérateurs ont donc réfléchi
à un modèle de centralisation moins exigeant en termes de performances et qui pourra être mis en
place sur les infrastructures réseau existantes. Appelée centralisation « partielle » (figure 6 (B)),
28
VIRTUALISATION
cette solution alternative consiste à grouper uniquement les couches protocolaires supérieures à
la couche PHY (L1) dans le pool BBU. La couche L1 est alors déplacée vers les RRH où ses
fonctions permettront de traiter les signaux radio reçus aux extrémités du réseau. Cette division
partielle réduit l’utilisation de la bande passante de 20-50/ par rapport à une centralisation com-
plète, grâce notamment au transport des signaux démodulés à travers le FH [31]. En outre, la
charge des données est également considérablement réduite au niveau du médium de transport.
Enfin, les contraintes de performances (latence, gigue, etc.) imposées par la centralisation totale
sont atténuées dans ce modèle de division.
Le principal avantage de la centralisation partielle demeure le coût de son déploiement/ mainte-
nance (OPEX/CAPEX) dans le FH qui est inférieur au modèle de centralisation complète. Il n’est
en effet plus nécessaire d’établir un réseau de fibre optique pour connecter les RRH au pool BBU,
en raison des contraintes moins fortes requises par la centralisation partielle. Par conséquent, les
infrastructures réseau déjà établies peuvent être réadaptées ou même directement réutilisées pour
déployer un C-RAN. Des projets sont par ailleurs menés par les opérateurs de télécommunications
dans le but de concevoir de nouvelles méthodes et architectures qui permettraient d’exploiter des
solutions largement déployées telles qu’Ethernet pour l’établissement d’un médium de transport
dans le FH. Nous avons notamment mentionné précédemment la spécification eCPRI qui a pour
but d’adapter le standard CPRI à une utilisation à travers Ethernet. Une nouvelle architecture
C-RAN a été également proposée, appelée Next Generation Fronthaul Interface (NGFI).
La centralisation partielle possède néanmoins un certain nombre de limitations en comparaison
à la centralisation complète. Ces limitations sont les suivantes :
— Consommation d’énergie élevée aux extrémités du réseau d’accès, en raison de la présence
de ressources de calcul, utilisées par la couche L1 pour le traitement des signaux radio au
niveau des RRH. Le déplacement de ces ressources vers les stations de base, impliquera un
déploiement plus coûteux et plus complexe, en comparaison avec la centralisation complète.
— Flexibilité réduite, en termes de partage de ressources, entre les unités BBU au sein du
pool. Cela entraîne une baisse d’efficacité dans le traitement collaboratif entre les cellules
du réseau.
— Performances réseau affaiblies au niveau du FH, pouvant impacter le déploiement de certains
services sensibles à la latence réseau,Utilisation inefficace de certaines fonctions avancées de
communication radio telles que CoMP, ainsi qu’une interaction complexifiée entre la couche
physique et la couche L2, notamment lors de l’exécution du mécanisme HARQ.
29
2.6 Procédure de la virtualisation
2.6.1 Principe
Figure 2.6 – Architecture de l’hyperviseur et le container.
Il existe deux approches principales de la virtualisation : l’application radio logicielle s’exécute

dans un environnement virtualisé, dans lequel le matériel est entièrement, partiellement ou non
virtualisé. Il existe deux approches principales de la virtualisation : l’application radio logicielle
s’exécute dans un environnement virtualisé, dans lequel le matériel est entièrement, partiellement
ou non virtualisé. Il existe deux approches principales de la virtualisation :
— Machines virtuelles (par exemple, Linux KVM, Xen) : dans une machine virtuelle (VM),
un système d’exploitation complet (OS invité) est utilisé avec la surcharge associée en
raison de l’émulation du matériel virtuel, tandis que les conteneurs utilisent et partagent
le système d’exploitation et les pilotes de périphérique de l’hôte. Les machines virtuelles
30
VIRTUALISATION
s’appuient sur l’hyperviseur pour les demandes de CPU, de mémoire, de disque dur, de
réseau et d’autres ressources matérielles ; les conteneurs exploitent les capacités au niveau
du système d’exploitation.
— Conteneurs (par exemple LXC, Docker) : les conteneurs préservent l’avantage de la virtua-
lisation en termes de flexibilité (conteneuriser un système ou une application), de provision-
nement des ressources, de découplage, de gestion et de mise à l’échelle. Ainsi, les conteneurs
sont légers car ils n’émulent pas de couche matérielle (partagent le même noyau et donc
l’application est native par rapport à l’hôte) et ont donc une empreinte plus petite que
les machines virtuelles, démarrent beaucoup plus rapidement et offrent des performances
d’exécution proches du bare metal. Cela se fait au détriment d’une isolation moindre et
d’une plus grande dépendance vis-à-vis du noyau hôte.
2.6.2 Plateforme choisie

2.6.2.1 Plateformes disponibles
— RAN
- free5GRAN
free5GRAN est une pile RAN 5G open source. La version actuelle comprend un récepteur qui
décode les données MIB et SIB1. Il agit également comme un scanner cellulaire. free5GRAN
fonctionne en mode SA [51].
- OpenAirInterface5G
Le projet met en œuvre le réseau d’accès radio 4G LTE et 5G. Le nœudB et l’équipement
utilisateur (UE) sont tous deux implémentés [52].
- UERANSIM
UERANSIM (prononcé "ju-i ræn SIM"), est l’UE et le RAN 5G à la pointe de la technologie
open source (gNodeB) la mise en oeuvre. Il peut être considéré comme un téléphone mobile
5G et une station de base en termes simples. Le projet peut être utilisé pour tester le réseau
central 5G et étudier le système 5G [53].
— Cœur de réseau
- ree5gc Le free5GC est un projet open source pour les réseaux centraux mobiles de 5e
génération (5G). L’objectif ultime de ce projet est de mettre en œuvre le réseau central 5G
(5GC) défini dans 3GPP Release 15 (R15) et au-delà. [54].
- Internship-5GCN Il s’agit d’une implémentation de services Web reposants entre certaines
des fonctions du réseau de contrôle 5G (AMF,SMF,UDM,NRF) selon spécifications 23.501,
23.502, 23.503, 29.501, 29.502, 29.503, 29.510 défini par le groupe 3GPP [55].
- OAI-CN Openair-cn est une implémentation des spécifications 3GPP concernant la Evol-
ved Packet Core Networks, cela signifie qu’il contient la mise en œuvre de l’élément de
réseau suivants [56] :
• MME,
• HSS,
• S-GW + P-GW.
31
2.6.2.2 Création de plateforme OpenAirIntarface
EURECOM est une école doctorale et un centre de recherche en systèmes des communications,
situé dans le parc scientifique international de Sophia Antipo- lis (France), et au sein du nouveau
Campus Sophia Tech. Elle a été fondée en 1991 en tant que consortium et composé d’un large
éventail de partenaires académiques et internationaux1 industriel. Par la suite, en raison de sa
taille, EURECOM a décidé de se concentrer sur trois activités : réseaux et sécurité, communications
multimédias et communications mobiles.
Observer l’évolution rapide des systèmes sans fil et la demande de solutions ouvertes et flexibles,
a conduit EURECOM à créer, en 2014, l’OpenAir interface software Alliance en tant qu’entité
juridiquement indépendante et sans fins lucratives. De plus, il a décidé de transférer gratuitement
tous les projets 4Gs développés sous une licence de logiciel open source.
Figure 2.7 – Logo EURECOM Figure 2.8 – Logo OpenAirInterface
2.6.2.3 OpenAirInterface
Le logiciel OpenAirInterface (OAI) fournit une implémentation open source et conforme aux
normes d’une pile 3GPP 4G LTE qui s’exécute sur un processeur x86 de base et un périphérique
radio USRP. OAI a été initialement développé par Eurecom mais est désormais géré par l’Ope-
nAirInterface Software Alliance (OSA), une organisation française à but non lucratif qui fournit
des logiciels et des outils open source pour la recherche sans fil 4G et 5G. Le logiciel OAI fournit
une implémentation LTE expérimentale complète (3GPP Releases 8 et 9, et partiellement 10 et
11) qui s’exécute en temps réel et est capable de fonctionner avec des combinés LTE commerciaux
(UE). Le logiciel OAI couvre la pile de protocoles complète des normes 3GPP LTE et inclut les
implémentations d’EUTRAN (à la fois eNB et UE) et EPC (MME, S+P-GW et HSS).
La disponibilité du code source OAI est gratuite à des fins de recherche non commerciale et
universitaire. Les implémentations eNB et UE sont concédées sous licence OAI Public License v1.1,
qui est une version modifiée de la licence Apache v2.0, avec une clause de brevet modifiée qui per-
met aux contributeurs de mettre des licences de brevet à la disposition de tiers dans des conditions
justes, raisonnables et conditions non discriminatoires (FRAND). L’implémentation EPC (MME,
S+P-GW et HSS) est concédée sous licence Apache v2.0.
Le logiciel de couche physique eNB implémente 3GPP 36.211, 36.212, 36.213 et fournit les fonc-
tionnalités suivantes :
32
VIRTUALISATION
Figure 2.9 – La virtualisation des composants de réseau avec OAI(source [51])
— Configurations FDD et TDD : 1 et 3.

— Bandes passantes porteuses : 5, 10 et 20 MHz.
— Modes de transmission : 1, 2 (stable) ; 3, 4, 5, 6, 7 (expérimental).
— Nombre max d’antennes : 2.
— PRACH preamble format 0.
— Tous les canaux de liaison descendante (DL) pris en charge : PSS, SSS, PBCH, PCFICH,
PHICH, PDCCH, PDSCH, PMCH.
— Tous les canaux de liaison montante (UL) pris en charge : PRACH, PUSCH, PUCCH
(format 1/1a/1b), SRS, DRS.
— Prise en charge HARQ pour UL et DL
— Débits DL possibles :
— 5 MHz, 25 PRB / MCS 28 = 16-17 Mbps
— 10 MHz, 50 PRB / MCS 28 = 34-35 Mbps
— 20 MHz, 100 PRB / MCS 28 = 70 Mbps
— Débits UL possibles :
— 5 MHz, 20 PRB / MCS 20 = 9 Mbps
— 10 MHz, 45 PRB / MCS 20 = 17 Mbps
— 20 MHz, 96 PRB / MCS 20 = 35 Mbps
Remarque :La prise en charge de Carrier Aggregation (CA) et de la gestion des écarts de mesure
est actuellement incomplète.
Les fonctionnalités eNB nouvelles et à venir incluent :
— Gestion DRX/eDRX et CDRX.
— Gestion et synchronisation de plusieurs RRU.
— Interface X2 et passation.
— Release 13 LTE-M.
La couche MAC eNB implémente un sous-ensemble du 3GPP 36.321 v8.6 prenant en charge
les canaux BCH, DLSCH, RACH et ULSCH.
33
VIRTUALISATION
La mise en œuvre de l’eNB MAC comprend :

— Interface RRC pour CCCH, DCCH et DTCH.
— Prise en charge de HARQ.
— Interface RLC.
— Contrôle de puissance UL.
— Contrôle d’intégrité et chiffrement à l’aide des algorithmes AES et Snow3G.
— La couche RLC implémente la spécification complète du 3GPP 36.322 v9.3.
2.6.2.4 Mise en place de la virtualisation

OAI ne recommandons pas l’utilisation de l’utilisation de la machine virtuelle pour OAI en
raison du fait que certaines machines virtuelles n’exportent pas correctement les indicateurs de
CPU et que les indicateurs de CPU doivent être transmis manuellement, ce qui peut/pourrait ne
pas fonctionner en raison de la configuration de la machine virtuelle.
Nous avons besoin d’Ubuntu 16.04 ou d’une version ultérieure en mode natif sur l’ordinateur.
Au moment de la rédaction, nous testons intensivement OAI sur Ubuntu 16.04 LTS. Pour un
fonctionnement en temps réel l’utilisation d’un noyau à faible latence est fortement recommandée.
Puis il faut faire gestion de l’alimentation
-Supprimez toutes les fonctionnalités de gestion de l’alimentation dans le BIOS (états de veille, en
particulier les états C) et la mise à l’échelle de la fréquence du processeur (cpufreqtool). Désactivez
également l’hyperthreading dans le BIOS et il faut désactiver sous Linux.
— Vérifiez ceci en utilisant cette commande
$ watch grep \"cpu MHz\" /proc/cpuinfo
— Nous devons désactiver p-state et c-state sous Linux, nous devons donc ajouter intel_pstate=disable
options de démarrage Linux, c’est à dire :
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_pstate=disable"
— Dans /etc/default/grub, puis exécuter update-grub. Nous pouvons éventuellement ajouter

les éléments suivants :
"processor.max_cstate=1 intel_idle.max_cstate=0 idle=poll"
— Ajoutez "blacklist intel_powerclamp" à la fin de /etc/modprobe.d/blacklist.conf, pour bla-

cklister le module intel_powerclamp. Si le fichier n’existe pas, créez-en un et ajoutez-y la
ligne.
— Installez l’utilitaire i7z pour vérifier le processeur
$ sudo apt−get install i7z
$ sudo i7z
Puis, désactiver la mise à l’échelle de la fréquence du processeur (installez cpufrequils, éditez

le fichier /etc/default/cpufrequtils), désactiver le démon à la demande.
34
VIRTUALISATION
Figure 2.10 – sudo apt-get install cpufrequtils
Figure 2.11 – Editez le fichier suivant
Figure 2.12 – Ajoutez-y les lignes suivantes
35
Nous devons maintenant désactiver le démon à la demande, sinon après le redémarrage, les
paramètres seront écrasés.
Figure 2.13 – Désactiver le démon à la demande
Enfin, il faut vérifier notre paramètres avec :

$ cpufreq−info
2.6.3 Mise en place de la virtualisation

2.6.3.1 Virtualisation d’OAI eNB
« Nous ne recommandons pas l’utilisation de l’utilisation de la machine virtuelle pour OAI en
raison du fait que certaines machines virtuelles n’exportent pas correctement les indicateurs CPU et
les indicateurs CPU doivent être transmis manuellement, ce qui peut/pourrait ne pas fonctionner
en raison de la configuration de la machine virtuelle [52] »
Clonez le référentiel OAI Git dans ce dossier. Pour ce faire, nous exécutez la commande ci-dessous.
Figure 2.14 – Installions d’OAI eNB
36
Ensuite, allez dans le référentiel configurez l’environnement pour inclure le référentiel OAI.
Pour ce faire, nous exécutez la commande ci-dessous. Il est toujours nécessaire d’avoir le référentiel
OAI inclus dans notre environnement chaque fois que nous créez ou exécutez le logiciel OAI eNB.
figure conf
Puis en va utilisation d’OAISIM (outil de simulation/émulation) et excitez le commande suivant :
Figure 2.15 – Run OAISIM
L’exécutable oaisim (oaisim_nos1) se trouve désormais sous :

OAI_INSTALL_DIR/cmake_targets/oaisim_noS1_build_oai/build/
La signification des paramètres ajoutés est :
— oaisim → Créer le simulateur OAISIM.
— -c → Supprimer les fichiers temporaires pour recommencer la compilation.
— –I → Option pour l’installer des prérequis.
37
Il faut vérifier par le commande ifconfig
Figure 2.16 – Vérifier les interface OAI
Ensuite, en va faire l’exécution d’oaisim :
Figure 2.17 – L’exécution d’oaisim
Lorsque eNB est en cours d’éructation en peut vérifier la performance de Pc (utiliser le Pc

comme un eNB, donc les performances de Pc proche égale aux performances d’eNB) avec notre
application web qui offre plusieurs choix comme performance de cpu, ram, les interface de réseau. . ..
Et comme exemple en prend la performance de Pc au temps d’exaction et en remarque que

l’utilisation des cpus plus faibles (l’utilisation d’oai et plus faible que les autres utilisations de
système).
2.6.3.2 Virtualisation de cœur (epc)

Conditions préalables D’abord, il faut installer docker et python 3.6.9
— Extraire les images de base
Nous avons besoin de 2 images de base : ubuntu :bionic et cassandra :2.1.conecter au docker.
Ensuite, tirez les images de base.
38
VIRTUALISATION
Figure 2.18 – les options de l’application web
Figure 2.19 – Exemple de performance de cpu
Figure 2.20 – Installez docker et python
39
VIRTUALISATION
Figure 2.21 – Tirez les images de base
— Configuration du réseau
Par défaut, le trafic des conteneurs connectés au réseau de pont par défaut n’est pas transmis
au monde extérieur. Pour activer le transfert, nous devons modifier deux réglages. Ce ne sont pas
des commandes Docker et elles affectent l’hôte Docker noyau [53].
Figure 2.22 – Confiduration du reseau
Extraction d’images des conteneurs Actuellement les images sont hébergées sous le compte
utilisateur rdefosseoai. D’abord tirez lzq image de oai-hss ,oai-mme,oai-spgwc et oai spgwu-tiny
Figure 2.23 – Exemple tirez hss
ET ré-étiquetez les pour que le fichier docker-compose fonctionne.
Figure 2.24 – re-etiquetez les composant des epc
— Synchroniser les composants
40
VIRTUALISATION
Figure 2.25 – Synchroniser les composant
41
Création des images de conteneur
— Initialiser la base de données Cassandra
Démarrer et initialiser une base de données cassandra
Figure 2.26 – Initialiser la base de données Cassandra
— Déployer le reste de l’EPC
Figure 2.27 – Déployer le reste de l’EPC
— Paramètres DNS
Notre hôte EPC Docker a sa propre passerelle –> nous devons la fournir en tant que "serveur
DNS local".
42
VIRTUALISATION
Figure 2.28 – parametre DNS
43
Configurer la mise en réseau L’objectif est de pouvoir pinger les conteneurs MME et SPGW-
U depuis le(s) serveur(s) eNB
— Étape 1 : créez un réseau docker sur votre hôte docker EPC.

En déployant simplement les conteneurs Cassandra, nous créerons 2 réseaux de docker :
Figure 2.29 – Etape 1
— Étape 2 : créez une route sur notre serveur eNB

Dans les serveurs qui hébergent le eNB, créez des routes IP :
$ Sudo ip route add 192.168.61.192/26 via 192.168.18.197 dev bond0
- 192.168.18.197est l’adresse IP de l’hôte Docker

-bond0est le contrôleur d’interface réseau (NIC) du serveur eNB (minimassif dans notre cas).
44
VIRTUALISATION
— Vérifiez notre configuration réseau

Sur notre EPC Docker Host : récupérez l’adresse IP MME
Figure 2.30 – Recuperez l’addresse ip de MME
2.7 Conclusion
A travers ce chapitre, nous avons exposé une vue détaillée du Cloud Radio Acceess Network
(C- RAN), en présentant tout d’abord le principe de base de ce concept qui consiste à séparer
l’unité radio (Remote Radio Head (RRH)) de l’unité de traitement (BaseBand Unit (BBU)), géné-
ralement regroupées en un seul élément (eNodeB) dans une architecture RAN-LTE traditionnelle.
En outre, nous avons énuméré les principaux défis à relever par le C-RAN, en perspective des
besoins exprimés par la nouvelle génération de réseaux mobiles, en termes de performance, flexi-
bilité, coût et efficience énergétique. Nous avons par ailleurs décrit les fonctions de chacun des
éléments composant le C-RAN, en détaillant les solutions pouvant être intégrées dans les RRH,
BBU et le réseau FH. Nous avons également indiqué les avantages apportés par cette architecture
aux opérateurs, d’une part, notamment en termes de flexibilité, coût et partage des ressources,
ainsi qu’aux utilisateurs, d’autre part, en termes de QoS, performance et disponibilité. Enfin, nous
avons présenté les deux modèles de centralisation définis dans le C-RAN, la centralisation complète
et la centralisation partielle, en décrivant leurs architectures respectives, en détaillant le schéma de
division de la couche L1 entre la RRH et la BBU ainsi qu’en donnant les avantages et les limitations
de chacun de ces modèles.
45
Chapitre 3
Développement d’application web C-RAN

TT
3.1 Introduction
Ce chapitre consiste le dernier volet du rapport ayant pour objectif d’exposer le travail achevé.
Pour ce faire, nous allons présenter dans premier temps l’environnement matériel et logiciel sup-
portant notre application. Par la suite, nous présentons la plateforme de développement et les
choix technologique. Ensuite, nous allons passer en revue les différentes taches réalisées à travers
quelques interfaces qui décrivent toutes étapes de mettre en œuvre.
3.2 Analyse et spécification des besoins

3.2.1 Les acteurs
Dans cette partie on va présenter les différents acteurs susceptibles d’interagir avec le système,
et avant de ça on donne une petite définition de l’acteur.
Un acteur est l’idéalisation d’un rôle joué par une personne externe, un élément externe qui
interagit avec le système.
Après l’étude du cahier de charge on est arrivé à identifier deux acteurs :
— Administrateur (administrateur de la site web).
46
Chapitre 3. Développement d’application web C-RAN TT
Acteur Rôle
S’authentifie
Ajouter une BBU
Modifier une BBU
Supprimer BBU
Administrateur Ajouter un pool
Modifier un pool
Supprimer un pool
Consulter les informations de pool
Consulter les informations de BBU
Télécharge les performances aux cours d’exécution
Table 3.1 – L’administrateur et leurs rôles
47
3.2.2 Besoins fonctionnels
Les besoins fonctionnels sont les besoins spécifiant un comportement d’entrée/sortie du système,
l’application doit permettre de :
— Gérer les données d’administrateur
— Ajouter un admin.
— Modifier un admin.
— Supprimer un admin.
— Gérer les données concernant les BBUs et les BBUs pools
— Gestion des BBU :
— Consulter une BBU.
— Chercher à une BBU.
— Ajouter une BBU.
— Modifier une BBU.
— Supprimer une BBU.
— Gestion des BBUs pools :
— Consulter un pool.
— Chercher à un pool.
— Ajouter un pool.
— Modifier un pool.
— Supprimer un pool.
3.2.3 Besoins non fonctionnels

Pour mettre en place une solution adéquate aux attentes des utilisateurs, on doit prendre en
considération les contraintes qui peut caractérisent ce système.
Mon application doit nécessairement assurer les besoins suivants :
— Les informations ne doivent pas être accessibles par tout le monde (Authentification).
— Chaque utilisateur ne doit pas accéder vers services s’il n’a pas les permissions de ces
services.
— L’application doit être facile à utiliser.
3.3 Conception
3.3.1 Diagramme de cas d’utilisation
Les diagrammes de cas d’utilisation sont des digrammes UML qui représentent les services les
plus importants rendus par un système.
48
3.3.1.1 Diagramme de cas d’utilisation (administrateur)

Le digramme suivant représente le comportement du système du point de vue administrateur.
Figure 3.1 – Digramme de cas d’utilisation d’administrateur
3.3.1.2 Diagramme de cas d’utilisation globale

Le digramme ci-dessous décrit les différents besoins et cas d’utilisation de l’application
Figure 3.2 – Digramme de cas d’utilisation globale
49
3.4 Réalisation
La réalisation d’application est l’un des objectifs principaux de notre projet, dans ce cadre nous
présentons les outils de développements que nous avons utilisés et aussi les interfaces de notre site
web.
3.4.1 Environnement matériel et logiciel

3.4.1.1 Environnement matériel
Nous avons utilisé un ordinateur portable HP pour réaliser le développement de site. Ces
caractéristiques sont les suivantes :
Ram 4Go
Processeur Intel(R) Celeron(R) 2957U 1.40 GHz
Disque dur 500 Go
Système d’exploitation Windows 10 pro
3.4.1.2 Environnement logiciel

— Application web
PHP :est un langage de script utilisé le plus souvent côté serveur : dans cette architecture,
le serveur interprète le code PHP des pages web demandées et génère du code (HTML,
XHTML, CSS par exemple) et des données (JPEG, GIF, PNG par exemple) pouvant être
interprétés et rendus par un navigateur web. PHP peut également générer d’autres formats
comme le WML, le SVG et le PDF.
WampServer :est une plate-forme de développement Web sous Windows pour des appli-
cations Web dynamiques à l’aide du serveur Apache2, du langage de scripts PHP et d’une
base de données MySQL. Il possède également PHPMyAdmin pour gérer plus facilement
vos bases de données.
Sublime Text :est un éditeur de texte générique codé en C++ et Python, disponible sur
Windows, Mac et Linux. Le logiciel a été conçu tout d’abord comme une extension pour
Vim, riche en fonctionnalités.
Depuis la version 2.0, sortie le 26 juin 20122, l’éditeur prend en charge 44 langages de
programmation majeurs, tandis que des plugins sont souvent disponibles pour les langages
plus rares.
— Outil de virtualisation
VirtuelBox :est un logiciel de virtualisation de systèmes d’exploitation. En utilisant les
ressources matérielles de votre ordinateur (système hôte).
VirtualBox permet la création d’un ou de plusieurs ordinateurs virtuels (machines virtuelles)
dans lesquels s’installent d’autres systèmes d’exploitation (systèmes invités).
Docker : est une plateforme permettant de lancer certaines applications dans des conteneurs
logiciels.
50
3.4.2 Principales interfaces avec description

3.4.2.1 L’interface administrateur
— Authentification
Ces interfaces concernent l’authentification de l’administrateur. Il a un email et un mot de
passe pour s’authentifier.
Figure 3.3 – Interface "authentification admin"
3.4.2.2 Le menu de l’administrateur

Le menu de l’administrateur contient l’ajout des admin, liste d’administrateurs, modifier un
admin, et contient aussi un liste BBU et BBU pool qui en peut ajouter, modifier ou supprimer.
— Page d’accueil :
Ces interfaces concernent l’accueil de l’administrateur.
— Ajouter un admin
Ces interfaces concernent l’ajout d’un administrateur.
En peut voir la liste d’administrateurs
51
Figure 3.4 – Page d’accueil
Figure 3.5 – Ajouter un admin
52
Figure 3.6 – Liste d’administrateurs
53
— Modifier un admin
On va modifier le prénom de l’admin2 (admin2 admin ==> admin2 add)
Figure 3.7 – Modifier un admin
54
— Supprimer un admin
On a decide maintenant de supprimer l’admin2
Figure 3.8 – Supprimer un admin
55
— Ajouter un BBU pool
Ces interfaces concernent l’ajout d’un BBU pool.
Figure 3.9 – Ajouter un BBU pool
56
— Modifier BBU pool

On va modifier la discription de BBU ajouter (zone_beja ==> zone_beja sud)
Figure 3.10 – Modifier BBU pool
57
— Supprimer une BBU pool
On a decide maintenant de supprimer BBU pool de beja
Figure 3.11 – Supprimer un admin
58
— Ajouter une BBU
Voici le formulaire de l’ajout de BBU "BBU3"
Figure 3.12 – Ajouter une BBU
59
— Supprimer une BBU
La suppression de BBU3 est aussi possible
Figure 3.13 – Supprimer une BBU
3.5 Conclusion
Ce chapitre représente une récapitulation de tous les travaux élaborent pendant ce projet de
conception et de développement ainsi qu’une présentation des résultats atteints.En effet, nous avons
décrit les environnements matériels et logiciels sur lesquels nous avons construit notre application
.Nous avons ensuite passé à la présentation de quelques interfaces de notre application .
60
Conclusion général
La prolifération du domaine des services multimédias mobiles a conduit à une explosion du trafic
des données mobiles. Les systèmes de télécommunication sont alors de plus en plus confrontés aux
problèmes de dégradation des performances, en particulier lors des pics de charge du réseau. Malgré
les efforts effectués en termes de dimensionnement de leurs réseaux, les opérateurs ne peuvent plus
faire face à cette augmentation exponentielle.
L’intégration du cloud dans l’architecture du réseau d’accès, à travers le Cloud RAN, a été
proposée comme solution potentielle pour remédier à ce problème. En effet, le réseau Cloud RAN
permet d’augmenter la capacité du réseau grâce à la virtualisation de la station de base et le
partage des ressources cloud. Malgré son potentiel important, plusieurs défis restent à résoudre
pour mettre en place cette solution et améliorer la QoS pour les abonnés.
Dans cette projet, nous nous sommes focalisés sur la virtualisation de BBU avec le plateforme
OAI et l’évaluation des performances des systèmes C-RAN dans un contexte 5G. Nous avons
vérifié les performances de notre approche par des simulations dans une application web pour gère
la performance et la gestion des BBUs.
61
Bibliography
[1] oberlo, "Trafic Internet mobile : quelle part du trafic Internet est mobile ?," [Online]. Available:
https://www.oberlo.fr/blog/trafic-internet-mobile.
[2] 3GPP, "Report of 3GPP RAN Workshop on Release 12 and onwards," Jun 2012.
[3] 2. W. P. “Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, "Cisco. [Online].,"
[Online]. Available: http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-
networking-index-vni/mobile-white-paper-c11-520862.html. [Accessed: 16-Mar- 2017]..
[4] A. O. e. al, "Scenarios for 5G mobile and wireless communications: the vision of the METIS project," IEEE
Commun. Mag., vol. 52, no. 5, pp. 26–35, May 2014.
[5] M. 2020, "METIS 2020," [Online]. Available: https://www.metis2020.com.
[6] A. O. e. al., "The Foundation of the Mobile and Wireless Communications System for 2020 and Beyond:
Challenges, Enablers and Technology Solutions,," in 2013 IEEE 77th Vehicular Technology Conference (VTC
Spring), pp. 1-5, 2013.
[7] Ericsson, "5G radio access, capabilities and technologies,," Apr 2016. [Online]. Available:
https://www.ericsson.com/res/docs/whitepapers/wp-5g.pdf.
[8] Nokia, "5G use cases and requirements.," [Online]. Available: http://resources.alcatel-
lucent.com/asset/200010..
[9] Huawei, "5G Nework Architecture: A High-Level Perspective.," [Online]. Available:

http://www.huawei.com/minisite/hwmbbf16/insights/5G-Nework- Architecture-Whitepaper-en.pdf. .
[Accessed 22 Avril 2021].
[10] N. DOCOMO, "5G Radio Access: Requirements, Concept and Technologies,," [Online]. Available:
https://www.nttdocomo.co.jp/english/binary/pdf/corporate/technology/whitepaper_
5g/DOCOMO_5G_White_Paper.pdf.
[11] G. Intelligence, "Understanding 5G: Perspectives on future technological advancements in mobile,," Dec
2014. [Online]. Available: http://www.gsma.com/network2020/wp-
content/uploads/2015/01/Understanding- 5G-Perspectives-on-future-technological-advancements-in-
mobile.pdf.. [Accessed 22 Avril 2021].
[12] T. L. Marzetta, "Noncooperative Cellular Wireless with Unlimited Numbers of Base Station Antennas,,"
IEEE Trans. Wirel. Commun., vol. 9, no. 11, p. 3590–3600, Nov 2010.
[13] G. Y. L. A. L. S. A. A. a. R. Z. L. Lu, "An Overview of Massive MIMO: Benefits and Challenges," IEEE J. Sel. Top.
Signal Process., vol. 8, no. 5, p. 742–758, Oct 2014.
[14] A. G. a. R. K. Jha, "A Survey of 5G Network: Architecture and Emerging Technologies," IEEE Access, vol. 3, p.
1206–1232, 2015.
[15] N. B. e. al, "Network densification: the dominant theme for wireless evolution into 5G," IEEE Commun.
Mag., vol. 52, no. 2, p. 82–89, Feb 2014.
[16] Z. P. a. F. Khan, "An introduction to millimeter-wave mobile broadband systems," IEEE Commun. Mag., vol.
49, no. 6, p. 101–107, Jun 2011.
[17] J. G. A. e. al., "What Will 5G Be?," IEEE J. Sel. Areas Commun., vol. 32, no. 6, p. 1065–1082, Jun 2014.
[18] T. S. R. e. al., "Millimeter Wave Mobile Communications for 5G Cellular: It Will Work!,," IEEE Access, vol. 1,
p. 335–349, 2013.
[19] P. S. D. G. D. W. B. S. R. a. R. W. A. Sabharwal, "In-Band Full-Duplex Wireless: Challenges and

Opportunities,," ,” IEEE J. Sel. Areas Commun., vol. 32, no. 9, p. 1637–1652, Sep 2014.
[20] "Mobile-Edge Computing – Introductory Technical White Paper,," Sep 2014. [Online]. Available:
https://portal.etsi.org/portals/0/tbpages/mec/docs/mobile- edge_computing_-
_introductory_technical_white_paper_v1%2018-09-14.pdf. [Accessed 02 Jun 2021].
[21] P. M. a. T. Grance, "The NIST Definition of Cloud Computing," The NIST Definition of Cloud Computing, Sep
2011. [Online]. Available: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf.
[Accessed 02 Jun 2021].
[22] stackscale, "cloud service models," [Online]. Available: https://www.stackscale.com/blog/cloud-service-

models/.
[23] "Understanding the Cloud Computing Stack: SaaS, PaaS, IaaS.," [Online]. Available:
https://support.rackspace.com/white-paper/understanding-the-cloud- computing-stack-saas-paas-iaas/.
[24] R. Ian, "Cloud computing : un aperçu," [Online]. Available: https://www.hebergeurcloud.com/cloud-

computing-apercu/.
[25] Intel, "Virtualization and Cloud Computing, Steps in the Evolution from Virtualization to Private Cloud
Infrastructure as a Service.," Aug 2013.
[26] B. M. M. Kiran, "Rapport expérimental sur la mise en place d'un environnement de cloud computing à
l'Université de Bradford," Dec 2014. [Online]. Available: https://www.researchgate.net/figure/illustration-
of-the-concept-of-Virtualization-7_fig1_269636339.
[27] Y. S. L. Z. Z. e. a. LIN, "Wireless network cloud : Architecture and system requirements," IBM Journal of
Research and Development, pp. 1-4, 2010.
[28] I. R. C. H. S. e. a. T. g. a. s. CHIH-LIN, "a 5G perspective," IEEE Communications Magazine, pp. 66-73, 2014.
[29] V. N. H. L. B. L. D. Dao, "Conception de transmission multipoint coordonnée (CoMP) pour les Cloud-RAN
avec des contraintes de capacité de transport frontal limitées," [Online]. Available:
https://www.researchgate.net/figure/Cloud-RAN-architecture_fig1_282266765.
[30] H. T. C. L. N. C. N. N. A.-L. C. S. Ericsson AB, "Common Public Radio Interface (CPRI); Interface Speci-
fication," 2015. [Online]. Available: http ://www.cpri.info.
[31] E. O. (. R. I. ETSI, "https ://portal.etsi. org/tb.aspx?tbid=738&SubTb=738," [Online].
[32] A. C. H. L. Y. Y. e. a. CHECKO, "Cloud RAN for mobile networks—A technology overview," IEEE
Communications surveys & tutorials, pp. 405-426, 2015.
[33] I. R. C. H. S. e. a. CHIH-LIN, "Toward green and soft : a 5G perspective," IEEE Communications Magazine,
pp. 66-73, 2014.
[34] N. J. C. P. T. P. e. a. GOMES, " Fronthaul evolution : from CPRI to Ethernet," Optical Fiber Technology, pp.
50-58, 2015.
[35] J. C. D. W. Y. e. a. LI, "Performance evaluation of cloud-ran system with carrier frequency offset," In :
Globecom Workshops (GC Wkshps) , pp. 222-226, 2012.
[36] A. CHECKO, "Cloud Radio Access Network architecture. Towards 5G mobile networks," Technical University
of Denmark, 2016.
[37] Z. L. K. D. S. e. a. GHEBRETENSAÉ, "Transmission solutions and architectures for heterogeneous networks

built as C-RANs," . In : Communications and Networking in China (CHINACOM), 2012 7th International ICST
Conference on. IEEE, pp. 748-752, 2015.
[38] J. e. W. M. SEGEL, "Lightradio portfolio-technical overview," Technology White Paper, 2011.
[39] J. e. E. J. HANSRYD, "Microwave capacity evolution," Ericsson review, pp. 22-27, 2011.
[40] D. D. D. D. J. e. a. LAW, "Evolution of Ethernet standards in the IEEE 802.3 working group," IEEE
Communications Magazine, pp. 88-96, 2013.
[41] J.-L. G. M. J. S. e. a. FERRANT, " Synchronous Ethernet : A method to transport synchronization," IEEE
Communications Magazine, 2008.
[42] J. e. L. K. EIDSON, "IEEE 1588 standard for a precision clock synchronization protocol for networked
measurement and control systems," In : Sensors for Industry Conference, pp. 98-105, 2002.
[43] L. S. Z. Z. Q. W. a. R. K. S. Y. Lin, "Wireless network cloud:Architecture and system requirements," pp. 1-4,
jan 2010.
[44] C. Mobile, "C-RAN, The Road Towards Green RAN," oct 2011. [Online]. Available:
http://labs.chinamobile.com/cran/wp- content/uploads/CRAN_white_paper_v2_5_EN.pdf.
[45] H. W. a. Y. Zhao, "C-RAN Bearer Network Solution - ZTE Corporation," [Online]. Available:
http://wwwen.zte.com.cn/endata/magazine/ztetechnologies/2011/No6/articles/201111/t20111118_2639
75.html.
[46] L. G. e. al, "Architecture of GPP based, scalable, large-scale C-RAN BBU pool," in 2012 IEEE Globecom
Workshops, p. 267–272, 2012.
[47] B. H. e. al, "Radio base stations in the cloud," vol. 18, p. 129–152, Jun 2013.
[48] N. DOCOMO, "5G Radio Access: Requirements, Concept and Technologies," Jun 2014. [Online]. Available:
https://www.nttdocomo.co.jp/english/binary/pdf/corporate/technology/whitepaper_
5g/DOCOMO_5G_White_Paper.pdf.
[49] D. S. e. al, "RAN as a service: Challenges of designing a flexible RAN architecture in a cloud-based
heterogeneous mobile network," in 2013 Future Network Mobile Summit, pp. 1-8, 2013.
[50] N. S. a. Networks, "Nokia Liquid Radio," 2015. [Online]. Available: http://resources.alcatel-

lucent.com/asset/200157.
[51] O. S. O. S. a. S. S. S. S. H. Park, "Fronthaul Compression for Cloud Radio Access Networks: Signal processing
advances inspired by network information theory," IEEE Signal Process, pp. 69-79, Nov 2014.
[52] iJOIN, pp. http://www.ict-ijoin.eu/.
[53] N. Corporation, "NFV C-RAN for Efficient RAN Resources Allocation," 2016.
[54] Nokia, "Nokia AirScale Cloud RAN," p. https://resources.ext.nokia.com/asset/200965, 2017.
[55] N. A. T. B. H. e. a. MCKEOWN, "OpenFlow : enabling innovation in campus networks," ACM SIGCOMM

Computer Communication Review, pp. 69-74, 2018.
[56] a. A. d. JAVEL, " free5GRAN," [Online]. Available: https://github.com/free5G/free5GRAN.
[57] openairinterface5g, "openairinterface5g," [Online]. Available:

https://gitlab.eurecom.fr/oai/openairinterface5g/.
[58] UERANSIM. [Online]. Available: https://github.com/aligungr/UERANSIM.
[59] free5gc. [Online]. Available: https://github.com/free5gc/free5gc.
[60] Internship-5GCN. [Online]. Available: https://github.com/bubblecounter/Internship-5GCN.
[61] OPENAIRINTERFACE, "OPENAIRINTERFACE," [Online]. Available:

https://github.com/OPENAIRINTERFACE/openair-epc-fed.
[62] F. Kaltenberger, "OpenAirInterface 5G Overview, Installation, Usage," 2017. [Online]. Available:

https://openairinterface.org/docs/workshop/3_OAI_Workshop_20170427/training/OAI_basics_kaltenbe_
2017.pdf.
[63] openaireinterface, "virtualisation enb," [Online]. Available:

https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/OpenAirKernelMainSetup.
[64] docker, "Activer le transfert des conteneurs Docker vers le monde extérieur," [Online]. Available:
https://docs.docker.com/network/bridge/#enable-forwarding-from-docker-containers-to-the-outside-
world.
[65] P. M. a. T. Grance, "The NIST Definition of Cloud Computing," Sep 2011. [Online]. Available:
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf.

Rapport Pfe 5G C-RAN

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Pfe 5G C-RAN

Transféré par

Droits d'auteur :

Formats disponibles

Table des matières

1 5G, INTERACTON DU CLOUD COMPUTING AU SEIN DES RESEAUX

2 ARCHITECTURE C-RAN ET MISE EN PLACE DE LA VIRTUALISATION 14

3 Développement d’application web C-RAN TT 46

1.1 Traffic internet mobile(source [1]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Composition de l’architecture C-RAN(source [29]). . . . . . . . . . . . . . . . . . . 15

3.1 Digramme de cas d’utilisation d’administrateur . . . . . . . . . . . . . . . . . . . . 49

3.2 Digramme de cas d’utilisation globale . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.1 L’administrateur et leurs rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5G, INTERACTON DU CLOUD

1.2 La nouvelle génération des réseaux mobiles :la 5G

1.2.2 Exigence et défis de la 5G

Figure 1.1 – Traffic internet mobile(source [1])

— Disponibilité, connectivité et fiabilité massives

1.2.3 Technologies clés

unique et du MIMO multi-utilisateur (MU-MIMO). Dans MU-MIMO, un ensemble de sta-

du spectre entre plusieurs nœuds du réseau nécessite aussi l’intégration de techniques de

1.3 Vers l’intégration du Cloud dans l’architecture des ré-

1.3.2 Les modèles en services

Figure 1.2 – Modèles en service du Cloud Computing (source [22])

1.3.3 Les modèles de déploiement

Figure 1.3 – Les modèles de déploiement(source [24])

Figure 1.4 – Le concept de virtualisation(source [26])

La technique de virtualisation est le principal mécanisme pour l’environnement du cloud com-

1.4 Objectif de projet et cahier des chargess

1.4.2 Cahier des charges et étapes du projet

ARCHITECTURE C-RAN ET MISE EN

contenus et applications avec de meilleures QoE et de performances possibles, et d’autre

2.2 Composants de l’architecture C-RAN

Figure 2.1 – Composition de l’architecture C-RAN(source [29]).

2.2.1 Remote Radio Head (RRH)

2.2.2.1 Fibre optique dédiée (fibre noire)

2.2.2.2 Multiplexage en longueur d’onde (Wavelength Division Multiplexing (WDM))

comme protocole de transport des données radio à travers le FH.

2.2.3 Baseband Unit (BBU)

2.2.3.1 Couche physique

2.2.3.2 Couche MAC

2.2.3.3 Couche Radio Resource Control (RRC)

2.3 Avantage du C-RAN

2.4 Architecture C-RAN proposer par les industriels

Figure 2.2 – Les propositions d’architectures C-RAN dans l’industrie

Figure 2.3 – Répartitions fonctionnelles des C-RAN proposés dans la littérature.

Figure 2.4 – Le concept RANaaS (source )

Architecture Avantages Inconvénient

2.5.1 Centralisation complète (Full centraization)

2.5.2 Centralisation partielle

Figure 2.6 – Architecture de l’hyperviseur et le container.

Il existe deux approches principales de la virtualisation : l’application radio logicielle s’exécute

2.6.2 Plateforme choisie

Figure 2.7 – Logo EURECOM Figure 2.8 – Logo OpenAirInterface

Figure 2.9 – La virtualisation des composants de réseau avec OAI(source [51])

— Configurations FDD et TDD : 1 et 3.

La mise en œuvre de l’eNB MAC comprend :

2.6.2.4 Mise en place de la virtualisation

— Dans /etc/default/grub, puis exécuter update-grub. Nous pouvons éventuellement ajouter

— Ajoutez "blacklist intel_powerclamp" à la fin de /etc/modprobe.d/blacklist.conf, pour bla-

Puis, désactiver la mise à l’échelle de la fréquence du processeur (installez cpufrequils, éditez

Figure 2.10 – sudo apt-get install cpufrequtils

Figure 2.11 – Editez le fichier suivant

Figure 2.12 – Ajoutez-y les lignes suivantes

Figure 2.13 – Désactiver le démon à la demande

Enfin, il faut vérifier notre paramètres avec :

2.6.3 Mise en place de la virtualisation

Figure 2.14 – Installions d’OAI eNB