Rapport Sarra

+MINISTERE DE L’ENSEIGNEMENT SUPERIEUR
ET DE LA RECHERCHE SCIENTIFIQUE
UNIVERSITE DE SOUSSE
‫المعهد العالي لإلعالمية وتقنيات االتصال بحمام سوسة‬
INSTITUT SUPERIEUR D’INFORMATIQUE

ET DES TECHNIQUES DE COMMUNICATION – HAMMAM SOUSSE
Département Télécommunications
MEMOIRE DE STAGE FIN D’ETUDES
Présenté en vue de l’obtention du diplôme d’ingénieur
Technologies des Communications
Analyseur de trafic en tant que

service sur des infrastructures virtualisées
Réalisé par :
Chhab SARA
Encadré(e)(s) par :
Mme. Kilani KHALED
Mr. Aleya ANOUAR
Société d’accueil
Tunisie Télécom/Direction Régionale Sousse/ROC1 Sousse
Error! Use the Home tab to apply Titre 1 to the text that you want to appear
here.
Année Universitaire 2016 – 2017
ii
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR
ET DE LA RECHERCHE SCIENTIFIQUE
UNIVERSITE DE SOUSSE
‫المعهد العالي لإلعالمية وتقنيات االتصال بحمام سوسة‬
INSTITUT SUPERIEUR D’INFORMATIQUE
ET DES TECHNIQUES DE COMMUNICATION – HAMMAM SOUSSE
Département Télécommunications
MEMOIRE DE STAGE FIN D’ETUDES
Présenté en vue de l’obtention du diplôme d’ingénieur
Technologies des Communications
Réalisé par :
Chhab SARA
Encadrant :…………………….. ……Date :………………………Signature

:…………….
Superviseur :………………….. ……Date :………………………Signature

:…………….
Année Universitaire 2016 – 2017

here.
Dédicaces
A mes très chers parents fathi Chhab & Saida Abbassi Chhab
Affable, honorable, aimable : Vous représentez pour moi le symbole de la bonté

par excellence, la source de tendresse et l’exemple du dévouement qui n’a pas cessé de
m’encourager et de prier pour moi. Vos prières et vos bénédictions m’ont été d’un grand
secours pour mener à bien mes études. Aucune dédicace ne saurait être assez éloquente
pour exprimer ce que vous mérites pour tous les sacrifices que vous n’avez cessé de me
donner depuis ma naissance.
A mes frères Taher Chhab & Mohamed Themer Chhab & Iyed Chhab
Mes chers frères qui me sont le père et la mère, les mots ne suffisent guère pour
exprimer l’attachement, l’amour et l’affection que je porte pour vous. Mes anges
gardien et mes fidèles compagnons dans les moments les plus délicats de cette vie
mystérieuse. Je vous dédie ce travail avec tous mes vœux de bonheur, de santé et de
réussite.
A mon cher Oncle Sghir Ezzedine
Vous avez toujours été présents pour les bons conseils. Votre affection et votre
soutien m’ont été d’un grand secours au long de ma vie professionnelle et personnelle.
Veuillez trouver dans ce modeste travail ma reconnaissance pour tous vos efforts.
A tous les membres de ma famille, petits et grands
i
Error! Use the Home tab to apply Titre 1 to the text that you want to appear here.
Remerciements
Je tiens à remercier toutes les personnes qui ont contribué au succès de mon
stage et qui m'ont aidé lors de la rédaction de ce rapport.
Tout d'abord, j'adresse mes remerciements à mon professeur, Mr Khaled

Kilani qui m'a beaucoup aidé dans ma recherche de stage et m'a permis de
postuler dans plusieurs entreprises. Son écoute et ses conseils m'ont permis de
cibler mes candidatures, et de trouver ce stage qui était en totale adéquation avec
mes attentes.
Je tiens à remercier vivement mon maitre de stage, Mr Anouar Aleya,

responsable du service au sein de l'entreprise, pour son accueil, le temps passé
ensemble et le partage de son expertise au quotidien. Grâce aussi à sa confiance
j'ai pu m'accomplir totalement dans mes missions. Il fut d'une aide précieuse
dans les moments les plus délicats.
Enfin, je tiens à remercier toutes les personnes qui m'ont conseillé et relu lors
de la rédaction de ce rapport de stage.
i
Table de matière
DEDICACES .......................................................................................................................................................... I
REMERCIEMENTS ............................................................................................................................................... I
TABLE DE MATIERE ................................................................................................................................................ II
LISTE DES FIGURES ................................................................................................................................................ 1
INTRODUCTION GENERALE.................................................................................................................................. 1
CHAPITRE I : CADRE DE STAGE ET PRESENTATION DE L’ENTREPRISE .................................................................. 2
I.1 INTRODUCTION ..................................................................................................................................................3

I.2 MOTIVATION .....................................................................................................................................................3
I.3 OBJECTIFS .........................................................................................................................................................3
I.4 TRAVAIL DEMANDE .............................................................................................................................................4
I.5 PLANIFICATION DE PROJET...................................................................................................................................4
I.6 ORGANISATION DU RAPPORT...............................................................................................................................4
I.7 PRESENTATION TUNISIE TELECOM ..........................................................................................................................5
I.7.1 Les missions du groupe ............................................................................................................... 5
I.7.2 Organisation Fonctionnelle........................................................................................................ 5
I.8 PRESENTATION ...................................................................................................................................................6
I.9 CONCLUSION ....................................................................................................................................................6
CHAPITRE II : LTE ET LE RESEAU 4G ...................................................................................................................... 7
II.1 INTRODUCTION ..................................................................................................................................................8

II.2 LTE (4G) ..........................................................................................................................................................8
II.2.1 Les buts de LTE............................................................................................................................. 8
II.2.2 Architecture de LTE..................................................................................................................... 8
II.2.3 L’E-UTRAN (Le réseau d'accès) ................................................................................................. 9
II.2.4 Evolved Packet Core: EPC....................................................................................................... 10
II.2.5 GPRS Tunneling Protocol (GTP) et établissement des porteurs ............................................ 11
II.3 ETABLISSEMENT DE CONNEXION .........................................................................................................................12
II.4 CONCLUSION ..................................................................................................................................................14
CHAPITRE III: SOFTWARE DEFINED NETWORKING (SDN) .................................................................................... 7
III.1 INTRODUCTION ...........................................................................................................................................15

III.2 LES RESEAUX TRADITIONNEL .......................................................................................................................15
III.3 SOFTWARE DEFINED NETWORKING (SDN) ...................................................................................................16
III.3.1 Définition. ................................................................................................................................... 16
III.3.2 Architecture SDN ...................................................................................................................... 16
III.3.3 Les couches SDN....................................................................................................................... 17
III.3.4 Les interfaces............................................................................................................................. 18
III.3.5 Les Concepts de SDN ............................................................................................................... 18
III.4 OPENFLOW ................................................................................................................................................20
III.4.1 Architecture OpenFlow ............................................................................................................ 20
ii
III.4.2 Le protocole OpenFlow ........................................................................................................... 22
III.4.3 Commutateur OpenFlow ......................................................................................................... 22
III.4.4 Le contrôleur OpenFlow .......................................................................................................... 23
III.5 FLOW VISOR ..............................................................................................................................................25
III.6 CONCLUSION ..............................................................................................................................................25
CHAPITRE IV: NETWORK FUNCTION VIRTUALIZATION (NFV) ........................................................................... 26
III.1 INTRODUCTION ...........................................................................................................................................27

III.2 NETWORK FUNCTION VIRTUALISATION ...........................................................................................................27
III.2.1 Définition .................................................................................................................................... 27
III.2.2 Architecture .............................................................................................................................. 27
III.2.3 OSS/BSS (Operation Support System/Business Support System) ........................................... 30
III.2.4 Fonctionnement de bout en bout .......................................................................................... 30
III.2.5 Les avantages de NFV ............................................................................................................. 32
III.3 NFV ET SDN ..............................................................................................................................................33
III.3.1 La distribution du trafic ............................................................................................................. 33
III.3.2 Le contrôle de connectivité .................................................................................................... 34
III.3.3 L’orchestration des services ..................................................................................................... 34
III.3.4 La différence entre NFV et SDN .............................................................................................. 34
III.4 CONCLUSION .............................................................................................................................................34
CHAPITRE IV : ETUDE DE LA SOLUTION .............................................................................................................. 34
IV.1. INTRODUCTION ...........................................................................................................................................35

IV.2. LA VIRTUALISATION ......................................................................................................................................35
IV.2.1. La virtualisation de réseau ....................................................................................................... 35
IV.2.2. La virtualisation de réseau LTE ................................................................................................. 35
IV.3. LA PROBLEMATIQUES ...................................................................................................................................36
IV.4. LA SOLUTION PROPOSEE ...............................................................................................................................36
IV.5. L'INFORMATIQUE EN NUAGE (CLOUD COMPUTING) ........................................................................................37
IV.5.1. Modèles de service et avantages .......................................................................................... 38
IV.5.2. Cloud et NFV ............................................................................................................................. 38
IV.6. CORRELATION SDN/NFV ...........................................................................................................................39
IV.7. ARCHITECTURE SDN/NFV...........................................................................................................................41
IV.8. ENB A BASE SDN ........................................................................................................................................43
IV.8.1. Architecture .............................................................................................................................. 43

IV.8.2. Les avantages de la virtualisation d’eNB ............................................................................... 45
IV.9. EPC A BASE DE SDN ..................................................................................................................................45
IV.10. PLAN DE CONTROLE ....................................................................................................................................47
IV.10.1. Le contrôleur local (LC) ......................................................................................................... 47
IV.10.2. Le contrôleur central (MC) .................................................................................................... 48
IV.11. PLAN D’UTILISATEUR .....................................................................................................................................48
IV.11.1. PDN Gateway User (PGW-U) ................................................................................................. 48
IV.11.2. SGW user.................................................................................................................................. 48
IV.12. MIDLEBOXES ...............................................................................................................................................49
iii
IV.13. LES DEFIS D’EPC/SDN ...............................................................................................................................49
IV.13.1. Pile protocolaire ...................................................................................................................... 49
IV.13.2. Routage centralisée ............................................................................................................... 51
IV.13.3. Agrégation de flux dynamique ............................................................................................. 52
IV.13.4. Politique de chemins .............................................................................................................. 53
IV.14. MOBILITE DE L'UTILISATEUR ............................................................................................................................53
IV.14.1. États inactifs / connectés....................................................................................................... 54
IV.15. FLUX D'APPEL ..............................................................................................................................................55
IV.15.1. Demande déclenchée par l'utilisateur ................................................................................ 55
IV.15.2. Demande déclenchée par le réseau .................................................................................. 57
IV.16. ANALYSE DE LA CONCEPTION ET LES AMELIORATIONS POSSIBLES ........................................................................58
IV.16.1. Flexibilité................................................................................................................................... 58
IV.16.2. Complexité de déploiement ................................................................................................. 59
IV.16.3. La performance ...................................................................................................................... 60
IV.17. SECURITE DE LA VIRTUALISATION DE RESEAU .....................................................................................................61
IV.18. CONCLUSION .............................................................................................................................................62
CHAPITRE V : SIMULATION................................................................................................................................. 63
V.1 INTRODUCTION ...........................................................................................................................................64

V.2 VIRTUALISATION DE L’INTERFACE AERIENNE LTE ...............................................................................................64
V.2.1. Modèle de simulation............................................................................................................... 64
V.2.2. Scénario 1 : Multiplexage ........................................................................................................ 65
ABREVIATIONS ................................................................................................................................................... 34
BIBLIOGRAPHIES ................................................................................................................................................ 34
iv
here.
Liste des figures
Figure 1: Puget de temps ............................................................................................... 4

Figure 2: organigramme Tunisie Télécom .................................................................... 6
Figure 3 : Architecture d'EPC traditionnel .................................................................... 9
Figure 4 : Pile protocolaire de LTE/EPC (3GPP) ....................................................... 11
Figure 5 : Procédure d'établissement de connexion dans LTE .................................... 12
Figure 6 : architecture traditionnel vs architecture SDN ............................................. 16
Figure 7: les couches de l’architecture SDN ............................................................... 17
Figure 8 : les interfaces dans l'architecture SDN ........................................................ 18
Figure 9 : Basic architecture of Openflow................................................................... 21
Figure 10: Flow Table, source ..................................................................................... 23
Figure 11 : architecture flow Visor.............................................................................. 25
Figure 12 : Architecture NFV ..................................................................................... 28
Figure 13 : Interaction des blocs fonctionnels (ETSI) ................................................ 31
Figure 14 : La synergie de NFV et SDN ..................................................................... 33
Figure 15 : NFVIaaS ................................................................................................... 39
Figure 16 : Domaines d'intervention SDN et NFV ..................................................... 39
Figure 17 : Corrélation de SDN, NFV et Application ................................................. 40
Figure 18 : Architecture combinée NFV et SDN ........................................................ 41
Figure 19 : Architecture d'un réseau mobile basé sur la virtualisation et SDN........... 42
Figure 20 : OpeNB Framework ................................................................................... 44
Figure 21 : LTE virtualisé à base SDN ....................................................................... 45
Figure 22 : Classification et direction de trafic ........................................................... 49
Figure 23 : Pile protocolaire de LTE-SDN ................................................................. 50
Figure 24 : Table de contrôle et de flux dans eNB SDN ............................................. 52
Figure 25 : Transition inactive / connectée ................................................................. 54
Figure 26 : Demande de connexion (UE) .................................................................... 55
Figure 27 : Demande de connexion (réseau) ............................................................... 57
Figure 28 : Pile protocolaire d'eNB virtuel ................................................................. 64
1
Introduction générale
Les Smartphones, les tablettes, les ordinateurs portables et les télévisions constituent
aujourd'hui une véritable révolution et leur prolifération ne cesse pas de croître, donc les
modes de consommation de l'internet ont évolué avec l'arrivée de ce nouveau type de
terminal et les nouveaux usagers. Ces changements humains amènent à des changements
technologiques importants dans le monde des réseaux et des télécommunications. En effet,
les statistiques ont montré que Les trafics de données mobiles mondiales ont progressé de
63% en 2016. Ils ont atteint 7,2 exaoctets par mois à la fin de 2016 alors qu’à la fin de 2015
ils ont été 4,4 exaoctets par mois. De plus, les prévisions [1] susmentionnées prévoient que e
trafic de données mobile mondial augmentera sept fois entre 2016 et 2021. Il va croître à un
taux de croissance annuel de 47 % 2016-2021, pour atteindre 49 exaoctets par mois d'ici
2021.
Celle-ci persuade l’opérateur à s'accentuer et à améliorer son infrastructure avec des
meilleures solutions tout en réduisant les coûts.
La superbe tendance d’abstraction physique des ressources informatique est introduite
dans le contexte de la mutation de l’industrie de télécommunication à cause de l’évolution des
besoins des utilisateurs : la diversité de services (voix, vidéo, SMS, IP tv…) et le haut débit
sous la contrainte de temps réel. L’opérateur doit suivre cette tendance et adapter le contrôle
de trafic à fin d’éviter les interruptions par des opérations d’acquisition et d’analyse des
données de trafic.
Pour répondre à ces exigences, les acteurs du domaine de télécommunication pensent
à une quatrième génération représentée par la norme LTE-Advanced « 4G ». La 4G constitue
aujourd'hui une révolution à augmenter le débit, à réduire la latence et à garantir les
multiservices. Mais celui-ci permet d'augmenter la quantité d'information transmise et par la
suite rendre difficile le contrôle et la gestion de trafics. Une prédiction CISCO prouve que’en
2021, Le 4G sera 53 % des connexions et 79 % du trafic total. Par la suite, Les architectures
actuelles des réseaux de télécommunications devraient faire face à des difficultés à la mise à
niveau de cette charge, ce qui amène les opérateurs mobiles à migrer du monde de
télécommunication vers le monde d’informatique à travers la virtualisation des réseaux
mobiles.
Il faut alors opérer une mutation technologique du réseau de façon à le rendre capable
d’analyser les trafics d’une manière adéquate. C’est dans ce contexte est introduit la future
génération 4G ou l’apparition de 5éme génération « 5G » qui est basée sur l’informatique en
here.
nuages dont la migration de la couche supérieure vers le nuage fournit une amélioration de la
latence et du débit ainsi que le partage des ressources.
Dans ce projet de fin d’études intitulé « Analyseur de trafic en tant que service sur des
infrastructures virtualisées » on se verra de présenter les différents services de réseau LTE
(VoLTE : voie et vidéo /SMS/Signalisation), on commencera par présenter LTE (son
architecture, ces protocoles et les canaux de transport) puis on passera à expliquer le
processus d’analyse de trafic tout on introduira notre solution qui consiste à virtualiser
l’analyseur de trafic au niveau d’un réseau LTE.
Le rapport de ce projet est structuré en quatre chapitres :
 Le premier est dédié à la présentation de l’entreprise d’accueil ainsi que le cahier

des charges et les problématiques.
 Le deuxième comprend une étude théorique sur la technologie 4G qui constitue
le noyau de notre sujet.
 Le troisième est consacré à détailler la technologie Software Defined Network
(SDN).
 Le quatrième représente la technologie Network Function Virtualization (NFV).
 Le dernier chapitre consiste à étudier la solution : la virtualisation de
l’infrastructure de réseau en introduisant SDN et NFV.
2
Chapitre I : Cadre de stage
et présentation de
l’entreprise
here.
I.1 Introduction
Ce chapitre consiste à mettre le projet dans son cadre général. On commence par
présenter l'environnement du stage à travers une présentation de la société d'accueil qui a
adopté ce projet de fin d'études. En effet, la qualité et l'efficacité du travail demandé dépend
en grande partie de l'environnement. On finira par une description du sujet à traiter ainsi que
la méthodologie utilisée afin de résoudre les problématiques de ce projet.
I.2 Motivation
La progression spectaculaire d’internet dans tout le monde, la prolifération des

services et l'émergence énorme du trafic de données mettent l’opérateur face à des flux de
données de plus en plus sophistiquées et de multitudes d'applications consommatrices ce que
amène à créer de nouveaux besoins en bande passante et à nécessiter des infrastructures
évolutives. C’est grâce à la virtualisation et l’automatisation de la gestion de réseau par la
mise en place de l’analyseur de trafic le plus adéquat, l’opérateur peut s’adapter à ce rythme
d’innovation. Le présent PFE traitera le sujet en proposant une architecture et configuration
du réseau répondant aux exigences, suivi d’implantation de service d’analyse de trafic sur des
infrastructures virtualisées.
I.3 Objectifs
Ce projet consiste à mettre en place la solution d’étude de virtualisation des

infrastructures de réseaux de l’opérateur « LTE » qui représente la mutation technologique
révolutionnaire introduisant l’apparition des réseaux intelligent « 5G ». Le concept est basé
sur l’extraction et le déploiement de l’intelligence des services des équipements de réseau
dans des nuages informatiques.
C’est dans ce contexte qu’on a choisi d’étudier le service « d’analyse de trafic » tout
en optimisant le processus actuel par l’intégration des outils de virtualisation (SDN, NFV,
OpenStack …).
3
here.
I.4 Travail demandé
L’étude consistera à mettre en place la conception d’un réseau sur des infrastructures
virtualisées répondant aux exigences des utilisateurs en termes de multiservices et de débits
souhaités. La conception sera pris en compte au niveau de :
 Core network
 CPE
La conception sera suivie d’implantation de service d’analyse de trafic sur ces

infrastructures virtualisées de réseau en s’appuyant sur les différentes caractéristiques et
configurations nécessaires.
I.5 Planification de projet
Figure 1: Puget de temps
I.6 Organisation du rapport
4
here.
I.7 Présentation Tunisie Télécom
Tunisie Telecom est un opérateur de télécommunications qui focalise ces travaux à

populariser son couverture sur toutes les régions tunisiennes tout en améliorant la qualité
service et le débit de ces services et à consolider son infrastructure.
La diversification de ces services lui a permis de satisfaire les besoins de ces clients en
leurs offrant une haute gamme de service de téléphonie fixe et mobile, la transmission par
satellite (VSAT), l'ADSL et la fibre optique.
Tunisie Telecom dispose de 24 directions régionales, 80 agences commerciales et point de

vente et plus de 13 mille points de vente privés.
Tunisie Telecom atteint près de 7 millions d’abonnés de téléphonie fixe et mobile.
I.7.1 Les missions du groupe
Le groupe de Tunisie Telecom demeure par un ensemble des missions pour atteindre
ces objectifs :
 La contribution et la participation au développement de recherches

scientifiques liées au secteur de télécommunications ;
 Investir dans le cœur de réseau pour garantir un service à haut débit fixe et
mobile ;
 Amélioration continue de la qualité de service.
I.7.2 Organisation Fonctionnelle
La figure ci-dessous représente l’organigramme général de Tunisie Télécom :
5
here.
Figure 2: organigramme Tunisie Télécom
I.8 Présentation
L’objectif de LTE est de permettre à l’opérateur de fournir à ces clients plus de

médias, plus d’application, et plus de voix, le tout encore plus vite. LTE prévoit un taux de
téléchargements de 100 fois plus rapide que l’existant (à l’ordre de 300 Mbps).
Cette révolution d’amélioration de vitesse amène à une évolution énorme de données.

C’est ce que permet l’apparition de plusieurs incidents au niveau de processus de contrôle, de
gestion et d’analyse de trafic et donc une dégradation de la QOS et dégringole de
performance de réseau. Il nécessite aussi l’utilisation des équipements de haute performance
et de haut de gamme ce que reflète plus des dépenses et c’est le pire cas car l’opérateur
cherche toujours à produire le meilleur service à court délai et à faible coût.
C’est dans ce cadre où il vient important de virtualiser l’analyse de trafic. C’est l’idée
autour de laquelle s’articule ce projet à fin d’améliorer les services de gestion et de
surveillance de réseau tout en offrant aux clients multiples services avec une bonne qualité et
à faible coût.
I.9 Conclusion
Ce chapitre a été consacré pour présenter l'entreprise d'accueil (Groupe Tunisie

Télécom) ainsi que le cadre de ce projet de fin d'études « Analyseur de trafic en tant que
6
here.
service sur des infrastructures virtualisées ». A ce stade, on va étudier et présenter
l’architecture de réseau 4G et définir aussi les concepts liés à l’analyse de trafic, ce qui fera
l'objet du deuxième chapitre.
7
Chapitre II : LTE et le
réseau 4G
here.
II.1 Introduction
Ce chapitre est un état de l'art de la téléphonie radio mobile dans lequel on présentera
le contexte où s'inscrit le présent projet afin de pouvoir se focaliser sur les composantes de
notre sujet. On étudiera successivement les équipements et les protocoles mises en jeu,
ensuite, on traitera le concept d’analyse de trafic.
II.2 LTE (4G)
LTE (Long Term Evolution), aussi connue sous le nom de 4G est standardisé par
l'organisme de télécommunications connu sous le nom 3GPP (Third Generation Partnership
Project). Elle représente une évolution dans le domaine des réseaux. L'objectif principal de la
technologie LTE est :
 D’augmenter la capacité des réseaux ;

 D’accroître les débits offerts aux utilisateurs ;
 D’améliorer l'interactivité grâce à une réduction de la latence.
LTE optimise la technologie d’accès radio, soutient les déploiements de bande

passante flexible. En même temps son architecture de réseau a été conçue dans le but de
soutenir le trafic à commutation de paquets avec une mobilité transparente et une grande
qualité de service.
II.2.1 Les buts de LTE
La 4ème génération a pour ambition d’améliorer l’efficacité spectrale 50 fois plus

qu’aux réseaux cellulaire et à augmenter la capacité de gestion du nombre de mobiles dans
une même cellule. Elle tente aussi d’offrir un haut débit (300Mbps) en situation de mobilité et
à offrir une mobilité totale à l’utilisateur en établissant l’interopérabilité entre différentes
technologies existantes. Elle vise à rendre le passage entre les réseaux transparent pour
l’utilisateur, à éviter l’interruption des services durant le transfert intercellulaire, et à basculer
l’utilisation vers le tout-IP (la voix sur IP (VOIP), streaming multimédia, vidéoconférence).
II.2.2 Architecture de LTE
L'architecture totale de LTE est divisée en quatre domaines principaux: l'équipement

utilisateur (UE), Evolved UTRAN (E-UTRAN), le réseau Evolved Packet Core (EPC) et le
8
here.
domaine de Services. Parmi ces domaines, l'UE, E-UTRAN et EPC ensemble sont appelés la
couche de connectivité de protocole Internet, ou Evolved Packet System (EPS). Cette couche
est utilisée pour fournir une connectivité basée sur IP :
 L'équipement utilisateur (UE): est le dispositif mobile de l'utilisateur qui

communique avec eNB ;
 E-UTRAN (Evolved Universal Terrestrial Radio Access Network) : désigne la
partie radio de réseau LTE assurant la connexion entre l’UE et le Core
Network. Il est constitué d’un ensemble des eNodeBs. Un eNodeB est une
station de base qui Exécuter les fonctions de gestion des ressources radio
(RRM) et le contrôle du support radio.
 L'Evolved Packet Core (EPC) : est le réseau de base pour LTE. Il a diverses
composantes qui réalisent les fonctionnalités de contrôle et de plan de données
pour le réseau sans fil. L'architecture de LTE a été illustrée ci-dessous.
Figure 3 : Architecture d'EPC traditionnel
II.2.3 L’E-UTRAN (Le réseau d'accès)
La partie radio du réseau, est responsable de gestion des ressources radio, la porteuse,
la compression, la sécurité, et la connectivité vers le réseau cœur évolué. L’élément le plus
intéressant de cette partie est :
 eNodeB : est une station de base évoluée qui commande les mobiles dans une ou
plusieurs cellules. Il joue le rôle d’un relais de réseau LTE. La particularité des
eNodeB est qu'elles sont relié à la fois au cœur de réseau ainsi qu'à d'autre relais, cela
apporte la sécurité et la meilleur partage des ressources au réseau.
9
here.
II.2.4 Evolved Packet Core: EPC
Au niveau de cette partie on va montrer une brève description de chacun des

composants représentés dans l'architecture ci-dessus:
 Le HSS : (Home Subscriber Server) est une base de données centrale dans
EPC contenant des informations sur tous les abonnés de réseau d'opérateur ;
 PDN-GW: (Packet Data Network GateWay) est la passerelle qui relie l’EPC
avec le monde extérieur (interface SGi). Le PGW fournit la connectivité de
l'UE au PDN externe en étant le point d'entrée ou de sortie pour ces trafics. Il
gère également les politiques, le filtrage des paquets des utilisateurs et le
support de charge ;
 S-GW : (Serving Gateway) : S-GW est la passerelle qui agit comme un routeur
des données entre la station de base et la passerelle PDN. SGW permet
d’acheminer les paquets de données, de maintenir la connexion de l’inter-eNB
handover, puis inter-système handover entre LTE et GSM/UMTS et de
réserver les paramètres de la porteuse de service et le routage des informations;
 MME (Mobile Mobility Equipement) : est l’entité principale de contrôle de
réseau d'accès LTE, car il traite la signalisation entre l'UE et l'EPC (interface
S1-MME). Il est responsable des procédures d'activation / désactivation du
porteur et chargé de choisir le SGW pour un UE dans le processus de
l'Attachement initial. Le MME gère Tracking Area (TA), la procédure de
paging, et la gestion du mode de veille de l'UE.
Le MME est responsable de l'authentification de l'UE en moyen de HSS. En
cas de roaming, elle met la fin de l’interface S6a de l’UE vers le HSS. Il fournit
également la fonction de plan de contrôle pour la mobilité entre les réseaux
LTE et 2G/3G par l'interface S3 (de SGSN à MME).
 PCRF : L’élément de contrôle de la politique, la gestion de la QoS et les règles
de facturation dans Policy Control Enforcement Function (PCEF) qui réside
dans le P-GW. Le PCRF est responsable du contrôle des politiques, et du
contrôle des fonctionnalités de facturation dans la fonction de contrôle de la
politique (PCEF), qui réside dans la PGW. Il décide le traitement de certain
flux de données. PCRF contrôle et gère dynamiquement toutes les sessions de
données et fournit des interfaces appropriées aux systèmes de facturation.
10
here.
II.2.5 GPRS Tunneling Protocol (GTP) et établissement des
porteurs
Le GTP est le protocole principal dans EPC: il utilise le protocole UDP et il ajoute
essentiellement un en-tête contenant deux identifiants: Identificateur de la source et de la
destination (TEID), utilisé par Les nœuds terminaux pour identifier les tunnels de chaque
utilisateur. Le trafic utilisateur est encapsulée dans les tunnels GTP au sein de l'EPC, pour
gérer facilement la mobilité des abonnés à travers les stations de base, c'est-à-dire la mobilité
dans la zone de couverture d'un seul eNB est gérée par L'eNB lui-même et n'a pas d'impact
sur le noyau.
Le protocole GTP correspond aux plans de l'utilisateur et de contrôle:
 GTP-C : est un protocole de plan de contrôle qui prend en charge

l'établissement de tunnels pour la gestion de la mobilité et des porteurs pour la
gestion de la QoS de backhaul câblé, de la QoS de paquets de la QoS de la
liaison radio. Il est utilisé pour la signalisation spécifique au réseau (activation
/ suppression / modification du support…).
 GTP-U : est un protocole de plan de données utilisé pour la mise en œuvre de
tunnels entre le SGW, le PGW et le réseau câblé de la station de base radio
(eNodeB).
Figure 4 : Pile protocolaire de LTE/EPC (3GPP)
11
here.
Le trafic utilisateur (plan de données) est transmis sur l'interface radio LTE de l'UE à
l'eNB, qui l'encapsule dans un tunnel GTP et le transmet sur un réseau IP de transport (tel que
Metro Ethernet) vers un SGW. Ceci, à son tour, encapsule le trafic dans un nouveau tunnel
GTP vers une PGW. Enfin, le PGW décapsule le trafic et le transmet à l’extérieur de l'EPC
(l'interface SGi) vers sa destination.
Un porteur EPS est établie lorsque l'UE se connecte à un PDN et qu'il reste établi tout
au long de la durée de cette connexion pour fournir à l'UE une connectivité IP «toujours en
ligne». Ce porteur est appelé porteur par défaut. Tout porteur EPS supplémentaire qui est
établi pour la même connexion PDN est un porteur dédié.
II.3 Etablissement de connexion
Un UE qui souhaite se connecter à un réseau LTE envoie une requête de connexion au

MME via son eNodeB.
Figure 5 : Procédure d'établissement de connexion dans LTE
12
here.
Avant d'envoyer la demande de connexion, la connexion radio de l'interface aérienne
est établie entre l'UE et eNodeB. L'UE envoie son IMSI (International Mobile Subscriber
Identity) comme son identifiant ainsi que la requête attach. Après avoir reçu la demande, le
MME procède à la mise en œuvre des différentes procédures d'authentification et de
configuration de sécurité comme suit:
 Authentification UE : MME authentifie l'UE à l'aide du HSS et une

authentification mutuelle entre l'UE et le réseau a lieu.
 Configuration de sécurité: Ensuite, diverses procédures de configuration de
sécurité ont lieu, pendant lesquelles les clés de cryptage et d'intégrité sont
échangées entre l'UE, eNodeB et MME, afin d'assurer une communication
sécurisée entre elles.
 Configuration du tunnel de données: après une configuration de sécurité
réussite, un "porteur" par défaut est créé pour l'UE via le noyau du paquet. Au
cours de ce processus, l'UE reçoit une adresse IP de la PGW et les valeurs de
l'identificateur de point final du tunnel (TEID) pour ce support sont échangées
entre eNodeB, MME, SGW et PGW. À la fin de cette procédure, un tunnel de
plan de données est établi pour l'UE d’eNodeB à PGW via le SGW.
 Transfert de données Uplink / downlink d’UE: Une fois qu'un UE attache et
établit un tunnel via l'EPC, il peut envoyer / recevoir des données vers / depuis
le PDN via eNodeB et EPC. L’UE envoie les paquets de données via
l'interface aérienne à l’eNB. L'eNB encapsule le paquet reçu dans un en-tête
GTP avec des en-têtes UDP / IP puis envoie le paquet au SGW. Le SGW
supprime l'en-tête externe du paquet reçu, ajoute des en-têtes GTP / UDP / IP,
puis le remonte à PGW. La PGW décapsule le paquet reçu en décapant les en-
têtes externes (IP / UDP / GTP), puis le dirige vers le PDN. De même, le
transfert de données de liaison descendante passe du PDN à l'UE.
13
here.
II.4 Conclusion
14
Chapitre III: Software
Defined Networking (SDN)
here.
III.1 Introduction
Actuellement, la technologie de réseau connaît sa troisième vague majeure de

révolution. Le premier était le passage du mode de commutation de circuit au mode de
commutation par paquets, et le second est le passage du mode câblé au mode sans fil. La
troisième révolution, est l’objectif de notre projet, c’est le passage du matériel au mode
logiciel. Dans ce contexte, on examine la technique SDN/OpenFlow qu’est certainement la
technique émergeante qui agite le monde des réseaux.
III.2 Les réseaux traditionnel
Les réseaux traditionnels sont des réseaux fermés qui rencontrent plusieurs problèmes
qu’on va les expliquer par la suite:
Difficulté de gestion des réseaux à grande échelle : Les réseaux existants se

composent de nombreux périphériques réseau fermés et de nombreux protocoles réseau
complexes. Il n'existe pas de plate-forme unifiée de gestion. Par conséquent, la configuration
et la gestion du réseau doivent être mises en œuvre par des administrateurs de réseaux
spécialisés. De plus, la proximité des périphériques réseau augmente les difficultés de gestion.
Difficulté de garantie des services réseau : Les réseaux traditionnels fonctionnent de

la manière « best-effort ». Les routeurs transmettent les données en fonction de la charge de
trafic actuelle sans garantir la qualité de service. Comme les routeurs sont distribués, chacun
contrôle individuellement la transmission des données. Donc l’absence d’une vue globale du
réseau empêche le réseau d’avoir une planification du trafic pour améliorer la qualité du
service.
Difficulté de contrôle des périphériques réseau : Les périphériques réseau existants

sont des boîtes noires composées de matériel et de logiciels. Pour préserver leurs profits, les
fournisseurs de périphériques réseau sont averses à la fourniture d'interfaces ouvertes standard
pour le contrôle des périphériques, ce qui réduit la flexibilité du contrôle du réseau.
Difficulté de déploiement de nouveaux protocoles réseau : Les dispositifs de réseau

existants sont conçus sur la base de protocoles de réseau traditionnels. Il est difficile
d'implémenter de nouveaux protocoles sans interfaces de programmation d'applications (API)
appropriées. Un manque d'API ouvert limite la capacité de la programmation réseau. Les
15
here.
utilisateurs ne peuvent pas personnaliser les réseaux en fonction des besoins pratiques, ce qui
entrave l'innovation du réseau.
Pour résoudre les problèmes ci-dessus, l'architecture de réseau fermée devrait être
découragée et l'architecture de réseau ouverte devrait être promue. À cette fin, une mise en
réseau adoucie (SDN) a été proposée comme base pour la construction de réseaux futurs.
Contrôleur
Plan de Plan de
Plan de Plan de
contrôle gestion contrôle gestion
Open Flow Protocol
Open Flow API

Plan de données
Plan de données
Figure 6 : architecture traditionnel vs architecture SDN
III.3 Software Defined Networking (SDN)
III.3.1 Définition.
SDN (Software Defined Networking) est une technologie de mise en réseau

représentant un terme générique englobant plusieurs types de technologies de réseau visant à
rendre le réseau aussi agile et flexible. Il permet d’avoir des plans de commande centralisés et
programmables pour que les opérateurs de réseau puissent contrôler et gérer directement leurs
propres réseaux virtualisés.
III.3.2 Architecture SDN
L’architecture SDN prétend à être dynamique, gérable, rentable et adaptable à la

nature dynamique des applications actuelles. Elle dissocie les fonctions de contrôle de réseau
et celles d'acheminement, permettant d’avoir un contrôle réseau directement programmable et
16
here.
une abstraction des applications et des services réseau. Les différentes couches de
l’architecture sont représentées dans la figure ci-dessous
Couche Orchestration cloud Application
Applicative (OpenStack, CloudStack) Application SDN
APIs
Contrôleur SDN
Couche de
Management
Programmation Calcul Topologie Statistique
Contrôle
OpenFlow
Couche Nœud de Nœud de Nœud de

réseau réseau réseau
Physique
Figure 7: les couches de l’architecture SDN
III.3.3 Les couches SDN
Afin de répondre au principe fondamental de l’intégration de SDN au sein d’un réseau.

L’architecture est subdivisée en trois couches comme suit :
 La couche physique : est appelé aussi la couche des ressources. Elle est
constituée par les équipements physiques ou virtuels de réseau (routeurs,
commutateurs…).
 La couche de contrôle : est une couche des fonctions de programmation et
d’abstraction des ressources ainsi que la gestion des nœuds et des liens
associés.
 La couche d’application : est constituée par l’ensemble des services applicatifs
tel que : service de connectivité cloud NAAS…
Ces couches sont séparées au moyen de deux types d’interfaces ouvertes.
17
here.
III.3.4 Les interfaces
Pour connecter les trois plans expliqués ci-dessus, on distingue deux principaux types
des interfaces au niveau de l’architecture SDN
 Southbound API : L'API ouverte vers le sud est l'interface de

communication entre le plan de données et le plan de contrôle
permettant le contrôleur d’envoyer les décisions d'acheminement de
flux aux commutateurs.
 Northbound API : L'API ouverte vers le nord est l'interface de
programmation réseau fournie par le plan de contrôle. En utilisant cette
l'API, le contrôleur peut concevoir et mettre en œuvre des nouveaux
protocoles et des applications d'innovation de réseau.
 East-West API : est l’interface introduite par SDN pour la
communication entre les contrôleurs dans le même domaine ou dans un
domaine différent.
Business Application SDN Application
Northbound API
API
SDN Contrôller SDN Contrôller SDN Contrôller
Southbound API
Network Device Network Device
Figure 8 : les interfaces dans l'architecture SDN
III.3.5 Les Concepts de SDN
Les trois concepts les plus intéressants des réseaux définis par logiciel (SDN) sont la
séparation des plans de contrôle et de données, la programmation, et la gestion de l'état du
18
here.
réseau dans un modèle de contrôle centralisé. En fin de compte, ces concepts sont incorporés
dans un cadre SDN idéalisé, comme on les décriera ci-dessous :
III.3.5.1 La séparation des plans
Les réseaux définis par logiciel (SDN) sont basés sur la séparation des plans de
données et de contrôle. L'abstraction de plan de contrôle permet une flexibilité et un
déploiement facile d'applications basées sur une vue centrale du réseau ce que amène à suivre
la prolifération des nouvelles applications en accélérant leur temps de mise sur le marché. Ce
découplage permet également une vue de haut niveau sans aucune configuration du réseau
précédemment.
Plan de données: Le plan de données représente les ressources matérielles de transfert

dans l'architecture de réseau SDN en fournissant des modèles de programmation riches et des
abstractions pour gérer ces ressources.
Plan de contrôle: Le plan de contrôle est habituellement le contrôleur SDN, qui est
également un Système d'exploitation réseau (OS). Dans l'architecture SDN, le contrôleur se
connecte tous les dispositifs d'acheminement dans le plan des données, par lesquels la gestion
du réseau passe de la distribution à la centralisation.
A un niveau très élevé, le plan de contrôle établit l'ensemble de données local utilisé
pour créer les entrées de la table de transfert qui sont à leur tour utilisées par le plan de
données pour acheminer le trafic entre les ports d'entrée et celles de sortie d'un dispositif.
RIB et FIB: L'ensemble de données utilisé pour stocker la topologie de réseau

s'appelle la base d'informations de routage (RIB). Le RIB est souvent maintenu cohérent par
l'échange d'informations entre d'autres instances de contrôle à l'intérieur du réseau. Les
entrées de table de transfert sont communément appelées base d'informations de transfert
(FIB) et sont souvent mises en miroir entre les plans de commande et de données d'un
dispositif classique. La FIB est programmée une fois que le RIB est jugé cohérent et stable.
Pour exécuter cette tâche, l'entité / programme de commande doit développer une vue du
réseau.
19
here.
III.3.5.2 La gestion de l’état de réseau
SDN est le cerveau de réseau. Son promesse est de simplifier et d'optimiser la gestion
du réseau en offrant une réactivité face aux pannes et il peut aussi améliorer la disponibilité
du réseau. Alors avec SDN, la configuration des périphériques et le dépannage peuvent être
effectués à partir d'un seul point du réseau qui nous rapproche de la réalisation du but ultime
d'un «réseau dynamique» configurable et adaptable en fonction des besoins.
L’orchestration et la visualisation de l'ensemble du réseau possède comme objectif de

renforcer le contrôle et la surveillance.
III.3.5.3 La programmation
SDN peut s'attaquer à la complexité du réseau traditionnel en automatisant les

fonctions du réseau, réduisant ainsi les coûts d'exploitation. La programmation permet aux
utilisateurs de construire des applications SDN pour surmonter les problèmes de gestion de
réseau, de qualité de service (QoS) et de conception de routage sans affecter la performance et
la fiabilité tout en éliminant la complexité de la couche infrastructure. En outre, ils peuvent
construire des applications SDN pour datacenter networks, cloud-based networks, mobile
networks, and Big data.
Avec l'approche SDN, les administrateurs réseau n'ont plus besoin de mettre en œuvre
des stratégies et des protocoles personnalisés sur chaque périphérique du réseau.
III.4 OpenFlow
OpenFlow est le nouveau paradigme promue avec l’apparition des SDN. Il permet
également d’assurer la communication entre le plan de données et le plan de contrôle.
III.4.1 Architecture OpenFlow
Fondamentalement, l'architecture OpenFlow se compose de nombreuses pièces

d'équipement de commutation activées par OpenFlow qui sont gérées par un ou plusieurs
contrôleurs OpenFlow, comme indiqué dans la figure ci-dessous.
20
here.
Figure 9 : Basic architecture of Openflow

 Table de groupe : Une table de groupe est constituée d'entrées de groupe
offrant des méthodes supplémentaires de transfert (diffusion multicast,
diffusion, redirection rapide, agrégation de liens, etc.).
Une entrée de groupe se compose d'un identifiant et d'un type de groupe, de
compteurs et d'une liste d'action, chaque segment d'action contenant un
ensemble d'actions à exécuter et des paramètres associés.
 Table de flux : Chaque entrée dans la table de flux a trois champs :
Un en-tête de paquet : elle est spécifique au flux. Ses champs contiennent des
informations telles que l'ID VLAN, les ports source et de destination, l'adresse
IP et l’adresse Ethernet source et destination.
L'action spécifie : comment les paquets d'un flux seront traités. Une action peut
être l'une des actions suivantes: Transférer le paquet vers un ou plusieurs ports,
rejeter le paquet ou transférer le paquet au contrôleur.
Les statistiques : comprennent des informations telles que le nombre de
paquets, nombre d'octets, le temps écoulé depuis l'initiation du flux. Et
21
here.
III.4.2 Le protocole OpenFlow
Le protocole OpenFlow est utilisé pour gérer l'interface southbound de l'architecture

SDN. Il s'agit de la première interface standard définie pour faciliter l'interaction entre les
plans de contrôle et de données. OpenFlow fournit un accès logiciel aux tables de flux qui
indiquent aux commutateurs et aux routeurs les règles de diriger le trafic réseau (ajouter,
mettre à jour et supprimer de nouvelles entrées dans les tableaux de flux) de façon réactive
(en réponse aux paquets) et proactive.
Ce protocole fournit un ensemble d'outils de gestion de base qui peuvent être utilisés
pour contrôler des fonctions telles que les changements de topologie et le filtrage de
paquets…
Le protocole OpenFlow prend en charge trois types de messages, qui sont tous
envoyés sur un canal sécurisé. Ces messages peuvent être catégorisés comme suit :
 Les messages de contrôleur à commutateur : sont Initiés par le contrôleur et

utilisés pour gérer ou dériver des informations directement sur l'état du
commutateur.
 Les messages asynchrones : sont lancés par le commutateur et sont utilisés
pour mettre à jour le contrôleur avec des événements de réseau et des
changements à l'état de commutateur.
 Les messages symétriques : sont lancés soit par le commutateur, soit par le
contrôleur, et sont envoyés sans sollicitation.
III.4.3 Commutateur OpenFlow
Le commutateur OpenFlow est basé sur la structure du commutateur Ethernet

traditionnel. Il consiste en une table de groupe et un ou plusieurs tables de flux comme il est
représenté au niveau de la figure ci-dessous. Il effectue les recherches de paquets et
l'expédition.
Le commutateur doit être en mesure d'établir une communication avec un contrôleur à

une adresse IP configurable par l'utilisateur (mais autrement fixe) à l'aide d'un port spécifié
par l'utilisateur.
22
here.
Figure 10: Flow Table, source
Au niveau d’une table de flux on distingue trois colonnes: règles, actions et compteurs.
La colonne rules spécifie les champs d'en-tête qui définissent le flux. Les règles sont mises en
correspondance avec les en-têtes des paquets entrants.
L'ensemble des actions possibles est: transférer le paquet vers un port de sortie,
modifier le paquet d'une certaine manière, ou envoyer le paquet à la table suivante ou à la
table de groupe.
Un commutateur OpenFlow prend en charge trois types de ports OpenFlow: ports

physiques, ports logiques et ports réservés
 Les ports physiques OpenFlow : correspondent à une interface matérielle du

commutateur (c'est-à-dire sur un Ethernet, les ports physiques mappent un à un
aux interfaces Ethernet).
 Les ports logiques OpenFlow : sont des ports définis par commutateur qui ne
correspondent pas directement à une interface matérielle du commutateur.
 Les ports réservés : sont définis dans la spécification de commutateur
OpenFlow.
III.4.4 Le contrôleur OpenFlow
Le contrôleur est responsable de la maintenance de tous les protocoles et politiques

réseau et de la distribution des instructions appropriées aux périphériques réseau. En d'autres
termes, le contrôleur OpenFlow est chargé de déterminer comment traiter les paquets sans
23
here.
entrées de flux valides. Il gère la table de flux de commutation en ajoutant et en supprimant
les entrées de flux sur le canal sécurisé en utilisant le protocole OpenFlow.
Le contrôleur centralise essentiellement l'intelligence du réseau. En outre, l’obtention

de plusieurs contrôleurs améliore la fiabilité car le commutateur peut continuer à fonctionner
en mode OpenFlow si l’une des connexions de contrôleurs est échouée. Le transfert entre
contrôleurs est entièrement géré par les contrôleurs eux-mêmes, ce qui permet l'équilibrage de
charge et la récupération rapide de l'échec en synchronisant le transfert entre eux.
III.4.4.1 Le principe de fonctionnement
a. Découverte de topologie
Le plan de commande peut se comporter de manière centralisée et gérer une grande

collection de commutateurs interconnectés qui forment un îlot OpenFlow. Dans un tel
déploiement, le contrôleur peut utiliser le message de sortie de paquet pour ordonner au plan
de données l’envoie des paquets LLDP depuis des ports de commutation vers des liaisons de
réseau (un paquet LLDP entrant à un port de commutateur sera transmis au contrôleur sous
forme de paquet dans un message). Sur la base de ces paquets LLDP, le plan de contrôle peut
déduire la connectivité à l'intérieur de l'îlot et construire la topologie du réseau. C'est
l'approche populaire où aucun support supplémentaire n'est nécessaire aux commutateurs pour
déduire la topologie du réseau.
b. Le traitement de flux
Lorsqu'un paquet arrive à un commutateur, celui-ci vérifie s'il existe une entrée de flux
(également appelée règle) dans sa table qui correspond aux champs d'en-tête du paquet. S'il y
a une correspondance, l'entrée de la table de flux spécifie comment transmettre le paquet. S'il
n'y a pas de correspondance, le commutateur génère un paquet dans le message qui est envoyé
au contrôleur en utilisant le protocole OpenFlow. Le contrôleur passe le paquet sous forme
d’un événement aux applications de contrôle appropriées basées sur les politiques
programmées (quelles applications voient quels événements). Les applications traitent
l'événement en utilisant l'état du réseau et leur logique d'application et peuvent renvoyer un
message avec des actions à entreprendre.
24
here.
III.5 Flow Visor
Flow Visor est l’une des premières approches SDN dans la virtualisation du réseau. Il
permet à la virtualisation de commutateur de partager la même infrastructure de réseau avec
plusieurs locataires. Il est basé sur le concept de virtualisation informatique, c'est-à-dire que
FlowVisor place une couche entre le plan de données et le plan de contrôle. De cette façon le
réseau est divisé en tranches et chacun peut effectuer différents tests sans interférence entre
eux.
FlowVisor utilise le concept SDN pour contrôler chaque tranche afin de tester de
nouvelles recherches avec du trafic de production. Le processus de tranchage tient compte de
quatre dimensions: La topologie, la bande passante, l'unité centrale de traitement du dispositif
(CPU) et les tables de transfert. Chaque tranche a un fichier texte composé d'une liste de
commandes, qui ont à leur tour des actions spécifiques (allow, read-only et deny).
FlowVisor réécrit les messages du commutateur au contrôleur et vice versa pour

assurer la transparence entre les tranches. La figure suivante montre l'architecture FlowVisor.
Controller Controller Controller
FlowVisor
Openflow
Openflow switches
Figure 11 : architecture flow Visor
III.6 Conclusion
En conclusion, Ces dernières années on a assisté à un changement spectaculaire dans

les réseaux en raison de la croissance exponentielle du trafic de données réseau et de
25
here.
l'introduction de nouvelles technologies telles que le cloud computing et la virtualisation sur
lesquelles se focalise le chapitre suivant.
26
Chapitre IV: Network
Function Virtualization
(NFV)
here.
III.1 Introduction
Les réseaux de télécommunications contiennent une variété croissante des

équipements matériels propriétaires. Pour lancer un nouveau service réseau, il faut encore un
autre équipement et il est de plus en plus difficile de trouver l'espace et l'alimentation
nécessaires pour tenir ces boîtiers, en plus de la complexité de l'intégration et du déploiement
de ces équipements au sein d’un réseau. D’où l’émergence de NFV qui vise à résoudre ces
problèmes.
III.2 Network Function Virtualisation
III.2.1 Définition
NFV (Network Function Virtualization) Est un concept fastidieux d'architecture de

réseau qui propose d'utiliser les technologies de la virtualisation informatique pour introduire
et déployer de nouvelles fonctions de réseau dont l’objectif est de créer des services de
communication dans un environnement informatique ouvert et standardisé.
NFV redéfinit la façon dont les fonctions réseau typiques sont livrées et exploitées. À
l'aide de technologies de virtualisation et de cloud computing standardisées, NFV définit une
architecture où les fonctions et les applications du réseau sont implémentées en tant qu'entités
logicielles et conçues pour être indépendantes du matériel. Ces entités logicielles utilisent des
éléments de calcul et de stockage standard disponibles en tant que plate-forme matérielle. La
gestion de NFV doit prendre en compte les considérations suivantes:
 implémentations multifournisseurs de VNF.

 gérer les cycles de vie et les interactions de ces fonctions.
 gérer les allocations de ressources matérielles.
 surveiller l'utilisation.
 configuration des VNF.
 interconnexion des fonctions virtualisées pour implémenter le service.
III.2.2 Architecture
L'architecture [5] qui définit les périphériques réseau traditionnels est assez basique
puisque le matériel et le logiciel sont personnalisés et bien intégrés. En revanche, NFV permet
27
here.
au logiciel développé par les fournisseurs de s'exécuter sur du matériel générique partagé en
créant plusieurs points de contact pour la gestion. La figure ci-dessous représente
l’architecture NFV :
Figure 12 : Architecture NFV

Il existe trois composantes principales d'une structure NFV qui sont décrites par la
suite:
III.2.2.1 VNF (Virtual Network Function)
La mise en œuvre virtuelle des fonctions réseau est appelée fonction de réseau
virtualisé (VNF). Un VNF est le bloc de base dans l'architecture NFV. Il s'agit de l'élément
virtualisé de réseau. Par exemple, lorsqu'un routeur est virtualisé, on l'appelle routeur VNF.
Même lorsqu'une sous-fonction d'un élément de réseau est virtualisée, elle est appelée VNF.
Tel que, dans le cas du routeur, diverses sous-fonctions peuvent être des VNFs séparés
fonctionnant ensemble comme routeur virtuel. D'autres exemples de VNF comprennent les
pare-feu, IPS, GGSN, SGSN, RNC, EPC…
 EM (Elément Management)
28
here.
Il s'agit d’un système de gestion des éléments du VNF. Il est responsable de leur
gestion fonctionnelle, c'est-à-dire FCAPS (Fault, Configuration, Accounting,
Perfomance and Security Management). Cela peut gérer les VNFs par des interfaces
propriétaires. On peut y avoir un EM par un ou plusieurs VNF ainsi qu’EM lui-même peut
être un VNF.
III.2.2.2 NFVI (Network Function Virtualization Infrastructure)
NFVI est l'environnement dans lequel les VNF fonctionnent. Cela comprend les
ressources physiques, les ressources virtuelles et la couche de virtualisation.
III.2.2.3 Gestion et orchestration (MANO)
MANO est un sous-système de NFV qui comprend le Network Functions

Virtualization Orchestrator (NFVO), le gestionnaire d'infrastructure virtualisé (VIM), et le
Virtual Network Functions Manager (VNFM).
 VNFM (VNF Manager)
Un gestionnaire VNF gère un ou plusieurs VNF, c'est-à-dire qu'il effectue la gestion

du cycle de vie des instances VNF. Cette tâche de gestion implique la mise en place, le
maintien et la destruction des VNF. En outre VNFM fait le FCAPS pour la partie virtuelle du
VNF.
 La différence entre EM et VNFM doit être notée. EM fait la gestion des

composants fonctionnels. Alors que le VNFM effectue la gestion des composants
virtuels. Un exemple serait clair. Dans le cas où le noyau mobile (Core mobile) est
virtualisé, l'EM effectuera la gestion de la partie fonctionnelle (par exemple, les
problèmes liés à la signalisation mobile), tandis que VNFM effectuera la gestion
de la partie virtuelle (par exemple les problèmes liés à l'établissement d'un VNF
lui-même).
 VIM (Virtualized Infrastructure Manager)
Il s'agit d’un système de gestion du NFVI. Il est responsable de contrôle et de gestion

du calcul, du réseautage et des ressources de stockage dans le domaine d'infrastructure d'un
opérateur. Il est également responsable de la collecte des mesures de performance et des
événements.
29
here.
Ressources de calcul, de mémoire et de réseautage
C'est la partie physique dans NFVI. Les ressources virtuelles sont instanciées sur ces
ressources physiques. Tout commutateur de production, serveur physique et serveur de
stockage font partie de cette catégorie.
Ressources de calcul, de mémoire et de réseautage virtuel
C'est la partie virtuelle dans NFVI. Les ressources physiques sont extraites en
ressources virtuelles qui sont finalement utilisées par les VNF.
Couche de virtualisation
Cette couche est responsable de l'abstraction des ressources physiques dans des
ressources virtuelles. Le terme courant de l'industrie pour cette couche est "Hypervisor".
 NFVO (NFV Orchestrator)
NFV Orchestrator génère, maintient et détruit les services réseau de VNF. S'il existe
plusieurs VNF, l'orchestrateur permet la création d'un service de bout en bout sur plusieurs
VNF. Il est également responsable de la gestion globale des ressources NFVI.
Afin d’exécuter ses fonctions l'Orchestrateur ne parle pas directement aux VNF mais
via VNFM et VIM.
III.2.3 OSS/BSS (Operation Support System/Business Support System)
OSS / BSS fait référence à OSS / BSS d'un opérateur. OSS traite la gestion du réseau,
de la configuration des services. BSS traite la gestion des clients, des produits et des
commandes.
III.2.4 Fonctionnement de bout en bout
On explique ici, comment ce modèle fonctionne de bout en bout, en examinant

comment les blocs fonctionnels définis dans le cadre ETSI interagissent collectivement pour
implémenter le service. La figure 13 montre une version simplifiée des étapes impliquées.
30
here.
Figure 13 : Interaction des blocs fonctionnels (ETSI)
 Étape 1 : le NFVO dispose d’une vue complète de la topologie de bout en bout.

 Étape 2 : Le NFVO instancie les VNF requis et les envois au VNFM.
 Étape 3 : VNFM détermine le nombre de machines virtuelles nécessaires ainsi que les
ressources dont chacune d'entre elles aura besoin et renvoi cette exigence à NFVO
pour pouvoir réaliser la création de VNF.
 Étape 4 : NFVO valide s'il existe suffisamment de ressources disponibles pour que les
VM soient créées.
 Étape 5 : NFVO envoie une demande à VIM pour créer les machines virtuelles et
allouer les ressources nécessaires à ces machines virtuelles.
 Étape 6 : VIM demande à la couche de virtualisation de créer ces machines virtuelles.
 Étape 7 : Une fois que les machines virtuelles ont été créées avec succès, VIM
reconnaît cela à NFVO.
 Étape 8 : NFVO notifie à VNFM que les machines virtuelles dont elle a besoin sont
disponibles pour faire apparaître les VNF.
 Étape 9 : VNF configure maintenant les VNFs avec des paramètres spécifiques.
 Étape 10 : Lors de la configuration réussie des VNF, VNFM informe le NFVO que
les VNF sont prêts, configurés et disponibles à utiliser.
31
here.
III.2.5 Les avantages de NFV
L'un des développements les plus importants dans l'industrie du réseau est l'adoption
de la virtualisation des fonctions réseau (NFV), qui remplace les équipements réseau par un
logiciel fonctionnant dans le cloud. Il s'agit d'un changement de paradigme complet dans les
services réseau et l'architecture.
La virtualisation des fonctions réseau offre un cadre pour transformer complètement la

façon dont les réseaux sont conçus, déployés, gérés et exploités, tout en offrant de nombreuses
amélioration et efficacité. Quelques-uns des avantages offerts par NFV sont discutés ci-
dessous.
III.2.4.1 Rapidité du délai de mise sur le marché
Ça consiste à introduire rapidement de nouveaux services en réduisant le temps de

déploiement et de validation des nouvelles applications logicielles (de mois à minutes).
III.2.4.2 Optimisation OPEX
Le soutient et le maintien de matériel de télécommunication dédié nécessite des

compétences spécialisées. La virtualisation sur des plates-formes standard qui sont plus
facilement supportées par les administrateurs contribue à réduire les dépenses d'exploitation.
L'automatisation de haut niveau activé par NFV réduit également l'effort manuel requis dans
la configuration et la création de services et réduit par conséquent les dépenses.
III.2.4.3 Réduction CAPEX
Le passage d'appliance de télécommunications dédiées à la virtualisation sur une

infrastructure informatique standard permet une meilleure utilisation de la capacité et une
évolutivité énorme qui permet d'éliminer ou de retarder les investissements dans des
infrastructures coûteuses et spécialisées.
III.2.4.4 Nouvelles opportunités et plus d'innovation
De nouvelles opportunités d'affaires innovantes sont possibles avec les technologies

de virtualisation et une plate-forme qui est capable d'accueillir des applications développées
32
here.
dans un écosystème collaboratif. Étant donné que le coût et l'effort d'introduction et de
déploiement de nouveaux services sont beaucoup plus faibles et que de nouveaux services
jugés trop risqués pour être testés peuvent maintenant être expérimentés de manière contrôlée.
III.3 NFV et SDN
On tient à souligner qu’on considère la virtualisation des fonctions de réseau comme

étant très complémentaire de Software Defined Networking (SDN). Ces sujets sont
mutuellement bénéfiques mais ne dépendent pas l'un de l'autre. Les fonctions réseau peuvent
être virtualisées et déployées sans qu'un SDN soit requis et vice versa.
Figure 14 : La synergie de NFV et SDN

Mais entre autre, La synergie des technologies SDN et NFV offre une meilleure
programmation de réseau et un maintien de service plus rapide. SDN est la clé de la mise en
œuvre des déploiements NFV. Voici quelques exemples du rôle complémentaire de SDN et
de NFV:
III.3.1 La distribution du trafic
Afin de s'assurer que la capacité VNF est optimisée, il est important que seuls les bons
flux de trafic soient dirigés vers les VNF appropriés. Les techniques SDN comme Service
Function Chaining (la capacité de définir une liste ordonnée de services réseau pour un
ensemble de paquets) sont essentielles pour diriger dynamiquement les flux de trafic vers les
VNF correspondants. SDN active VNF Graphs qui sont les cas d'utilisation les plus courants
permettant de combiner SDN et NFV.
33
here.
III.3.2 Le contrôle de connectivité
L'un des principaux avantages du NFV est la capacité des VNF à instancier dans les
datacenters. SDN est essentiels pour s'assurer que les paramètres de connectivité réseau et les
accords de niveau de service (SLA) sont bien appliqués et sécurisés lors de la migration des
VNF à travers les datacenters,
III.3.3 L’orchestration des services
Les contrôleurs SDN jouent également un rôle important dans l'orchestration de

services à travers une infrastructure hybride (virtualisée et non virtualisée). L'orchestration
des services est l'aspect d’un réseau qui gère la création et la prestation des services. SDN
fournit un point central de configuration et de gestion pour les éléments de réseau hétérogènes
sous-jacents.
III.3.4 La différence entre NFV et SDN
Le principal objectif du NFV est de réduire le coût des équipements et de réduire le

délai de mise sur le marché en offrant une évolutivité, une élasticité et un écosystème solide.
Le SDN OpenFlow-enabled proposé par la Open Networking Foundation (ONF) vise à
obtenir les mêmes avantages. Alors que NFV est destiné à optimiser le déploiement des
fonctions réseau (comme les pare-feu, le DNS, les équilibreurs de charge, etc.) et la solution
SDN basée sur OpenFlow est axée sur le routage et sur l'optimisation des réseaux.
III.4 Conclusion
On conclue que La virtualisation des fonctions réseau (NFV) offre une nouvelle façon
de concevoir, de déployer et de gérer les services réseau. Il est conçu pour consolider et
fournir les composants réseau nécessaires pour prendre en charge une infrastructure
entièrement virtualisée y compris les serveurs virtuels, le stockage et même d'autres réseaux
en utilisant des technologies de virtualisation standard qui fonctionnent sur des services à haut
volume, des commutateurs et du matériel de stockage pour virtualiser les fonctions réseau.
34
Chapitre IV : Etude de la
solution
here.
IV.1. Introduction
Ce chapitre consiste à décrire les détails de la solution proposée pour les futurs réseaux
qui propose une nouvelle approche pour redessiner les procédures principales des plans de
contrôle et de données en s'appuyant sur de nouvelles techniques telles que Software Defined
Networking (SDN) et Network Functions Virtualization (NFV) au niveau de réseau mobile
tout en expliquant la migration vers une nouvelle architecture et la mise en œuvre des
nouveaux outils à cet effet.
IV.2. La virtualisation
La virtualisation est le processus de création de versions virtuelles de ressources

physiques qui imitent les mêmes caractéristiques physiques. Il est souvent utilisé dans le
contexte informatique, pour partitionner une ressource physique en plusieurs virtuels. Dans
les cinq futures années, ce processus sera utilisé dans le contexte les réseaux de
télécommunications.
IV.2.1. La virtualisation de réseau
Les réseaux mobiles sont l'une des technologies à croissance rapide qui influencent les
aspects majeurs de la façon dont nous communiquons et accédons à l'information. La
virtualisation réseau permet à plusieurs opérateurs de réseau de partager une infrastructure
commune (y compris le réseau de base, le réseau de transport et le réseau d'accès) afin de
réduire le capital d'investissement tout en améliorant la performance globale en même temps.
En outre, la virtualisation du réseau peut réduire le montant nécessaire de l'équipement de la
station de base et ainsi réduire l'énergie requise pour gérer les réseaux sans fil, aussi que
réduire le capital d'investissement global requis par les opérateurs de téléphonie mobile pour
configurer leur propre infrastructure. La virtualisation du réseau jouera un rôle essentiel dans
la diversification de futur Internet.
IV.2.2. La virtualisation de réseau LTE
La virtualisation de réseau peut être considérée comme l'une des motivations pour la
recherche et le développement de la virtualisation des réseaux mobiles LTE. Cependant, le
processus de commercialisation de la virtualisation du réseau mobile LTE a un effet ambigu
sur le futur marché mobile LTE.
35
here.
Les principaux défis techniques rencontrés sont la façon de virtualiser l'infrastructure
physique pour supporter de tels scénarios et les changements d'architecture nécessaires dans le
système LTE actuel, deux différentes catégories des processus de virtualisation sont
principalement prévues:
 La virtualisation de l'infrastructure physique : l'infrastructure du réseau LTE

(nœuds et liens) doit être virtualisée afin que les différents opérateurs mobiles
virtuels puissent créer leur propre réseau ;
 La virtualisation de l'interface aérienne: la virtualisation du spectre LTE, tel
que les ressources du spectre physique peuvent être partagées par différents
opérateurs mobiles virtuels.
IV.3. La Problématiques
De nos jours, l'architecture Long-Term Evolution (LTE) connaît une période de

changements rapides et massifs. Il sera soumis à une utilisation à grande échelle car il
connecte plus d'appareils, plus d’applications et plus de trafic réseau. Par conséquent,
l'architecture de réseau actuel ne fournit aucune élasticité. Le réseau est généralement
dimensionné sur la base de la charge prévue dans les heures de pointe. Par exemple, les
entités de réseau mobile d’E-UTRAN et d’EPC : les eNodeBs (eNB), Mobility Management
Equipement (MME), Serving Gateway (S-GW), Packet Data Network Gateway (P-GW) et
Home Subscriber Server (HSS) sont basées sur du matériel personnalisé et doivent être
statiquement approvisionnées et configurées. Par conséquent, pour augmenter la capacité du
réseau, il est nécessaire de déployer de nouvelles entités. Le fonctionnement d'un tel réseau
statique est donc un processus coûteux, encombrant et long.
IV.4. La solution proposée
Les technologies Network Functions Virtualization (NFV) et Software Defined

Networks (SDN) visent à résoudre ces problèmes, et une bonne intégration de ces
technologies dans le réseau LTE (E-UTRAN et EPC) doit être soigneusement analysée. L'un
des buts de ce projet est de faire une analyse de la façon dont ces concepts orienteront la
transformation en un réseau porteur SDN / NFV et de proposer une nouvelle architecture LTE
SDN / NFV. Afin d'être en mesure d'adopter de telles stratégies, l’opérateur de réseau cherche
à comprendre pleinement SDN et NFV : leurs avantages avec leurs obstacles. La première
étape consiste à déterminer où ces deux technologies s'intègrent le mieux dans le réseau
36
here.
(allant de l'accès, du backhaul mobile, du Core Network) et d'ajuster leurs avantages là où les
solutions 3GPP sont très complexes et moins rentables. Les principaux enjeux du déploiement
de LTE actuel sont les coûts élevés, l'équilibrage de charge en temps réel et la qualité de
service (QoS) de différents flux. Dans ce contexte, les questions suivantes se posent:
 Comment les exploitants peuvent-ils optimiser leurs avantages en combinant NFV

avec SDN et dans quelles parties du réseau ces technologies peuvent-elles être
déployées?
 Comment SDN / NFV peut-il être intégré dans l'architecture 3GPP actuelle, quelles
sont les interfaces essentielles à préserver et où la flexibilité supplémentaire peut-elle
être ajoutée?
 Outre que l'abaissement des coûts, ces technologies pourraient-elles fournir une
gestion du trafic plus fiable et une meilleure QoS?
 Quels outils peuvent être utilisés et comment ces outils affecteront les performances
du réseau?
Afin de construire une solution entièrement conforme, il est très important de

comprendre l’architecture de ces technologies, ainsi que la relation: Cloud Computing / NFV,
ou entre NFV et SDN.
IV.5. L'informatique en nuage (Cloud Computing)
L'informatique en nuage est considérée comme un nouveau modèle basé sur Internet
qui fournit des ressources partagées à des ordinateurs et à d'autres périphériques à la demande.
Le stockage, le traitement, la mémoire, la bande passante du réseau et les machines virtuelles
sont considérés comme des ressources. L'un des principaux avantages du cloud est que les
utilisateurs ne se préoccupent pas à la consommation de ressources. Par conséquent, il est
appelé auto-service à la demande.
Le regroupement de ressources est une autre caractéristique du cloud : le client n’a pas
besoin de connaître l'emplacement exact de la ressource, on ne peut que spécifier
l'emplacement à un niveau supérieur (pays, état ou centre de données). L'élasticité rapide
signifie que le temps et l'espace ne sont pas des contraintes et les requêtes semblent à être
illimitées. Le service peut être mesuré et les ressources peuvent être surveillées, contrôlées,
ainsi que déclarées dans une transparence complète entre le consommateur et le fournisseur de
service.
37
here.
IV.5.1. Modèles de service et avantages
Les services Cloud Computing sont généralement offerts aux clients dans l'un des trois
modèles de service définis par l'Institut national des normes et de la technologie (NIST).
Infrastructure as a service (IaaS)
IaaS reflète la capacité d'offrir aux consommateurs le traitement, le stockage et les

ressources informatiques fondamentales. L'infrastructure NFV fournira des capacités de calcul
comparables à celles d'un service IaaS de cloud computing.
Plate-forme as a service (PaaS)
PaaS ajoute une couche supplémentaire d'intégration avec des plateformes de

développement d'applications et des fonctions telles que la base de données, la messagerie et
la file d'attente. Le consommateur contrôle uniquement les applications déployées et certains
hébergeurs d'applications et n'a aucun droit de gérer l'infrastructure sous-jacente du cloud: les
réseaux, les serveurs, les systèmes d'exploitation ou le stockage.
Service as a service (SaaS)
SaaS est mentionné comme un «logiciel à la demande» dans lequel les données et les
ressources logicielles sont généralement accessibles par les utilisateurs via un navigateur Web
sur Internet. Cela comprend le contenu, sa présentation, les capacités d'application et de
gestion intégrées dans un environnement d'exploitation autonome.
Le succès du cloud et de SDN / OpenFlow dans les centres de données est attribué au
Core Network tout IP. En comparaison avec la multi-technologie et la complexité de transport
coûteux des fournisseurs de services de communications (CSP), les solutions fournies par le
cloud sont très flexibles et demandent un ajustement approprié aux besoins du CSP.
IV.5.2. Cloud et NFV
NFV est la virtualisation des fonctions de réseau spécifiques aux télécoms dans des
applications qui fonctionneront au moins jusqu'à 99,999% de la disponibilité sur des matériels
et des logiciels adaptés aux opérateurs. Les modèles de services de cloud PaaS et SaaS
fournissent des fonctionnalités basées sur des logiciels qui peuvent fonctionner sur
l'infrastructure fournie (la même infrastructure qui peut offrir le service IaaS ou Network as a
Service (NaaS)).
38
here.
Figure 15 : NFVIaaS
Les principaux CSP sont maintenant convaincus que le NFV a suffisamment mûri
pour virtualiser la majorité des fonctions du réseau.
IV.6. Corrélation SDN/NFV
SDN et NFV sont deux technologies innovantes indépendantes. Cependant, de

nombreux objectifs de SDN sont partagés par NFV, de sorte que les deux bénéficient
fortement l'un de l'autre et soutiennent leur adoption mutuelle. Les périphériques réseau
traditionnels prennent en compte le plan de contrôle et celle de données qui sont intégrés sur
le même matériel.
Figure 16 : Domaines d'intervention SDN et NFV
39
here.
L'architecture n'offre pas de flexibilité pour implémenter de nouveaux services ou
d'agilité pour absorber les changements. Comme le montre la figure ci-dessous, SDN et NFV
jouent un rôle dans la rupture de cette liaison dans deux dimensions différentes. L'objectif de
SDN est la séparation du plan de contrôle et de données, et il utilise l'abstraction du réseau
pour un plan de contrôle indépendant pour gérer, manipuler et surveiller le plan de données.
D'autre part, NFV met l'accent sur le découplage de la fonction réseau à partir du matériel
dédié, et il facilite l'utilisation de matériel générique pour exécuter le logiciel implémentant
des fonctions de réseau.
SDN et NFV proposent différentes approches pour le déploiement d’un réseau

flexible, évolutif, élastique et agile. Bien que ces deux technologies puissent être mis en
œuvre indépendamment, les principes de SDN peuvent être appliqués à NFV en virtualisant la
fonction réseau et en séparant la fonction de plan de contrôle du plan de transfert. La figure 17
reflète cette relation, où NFV utilise du matériel de base et implémente le plan de donnée de
la fonction réseau, tandis que la fonction du plan de contrôle est extraite au contrôleur SDN.
Figure 17 : Corrélation de SDN, NFV et Application
40
here.
IV.7. Architecture SDN/NFV
Le défi le plus important est de préserver la fonctionnalité LTE dans une nouvelle
architecture VEPC/SDN flexible et centralisée. L'architecture proposée vise à modifier
légèrement l'architecture existante afin d'intégrer les composants de base dans le réseau
OpenFlow.
Figure 18 : Architecture combinée NFV et SDN
41
here.
Dans la figure ci-dessus, on présente l'architecture combinée NFV et SDN qui est
conforme à celui défini par l'ETSI NFV, tandis que quelques modifications sont introduites
pour recevoir le concept SDN.
Aujourd’hui NFV et SDN sont les orientations technologiques ayant un impact

perturbateur de l'industrie des télécommunications. On mentionne dans la figure ci-dessous
l’impact de ces techniques sur les réseaux mobiles.
Figure 19 : Architecture d'un réseau mobile basé sur la virtualisation et SDN

Horizontalement, on suit le modèle de référence du 3GPP en cours, qui se compose de
trois parties principales:
 Radio access network (RAN).

 Mobile backhaul.
 Mobile packet core network.
Verticalement, on montre quatre couches d'architectures SDN :
 Le plan de données.
 Le plan de contrôle.
 Le plan d'application.
 Le plan de gestion.
L'un de principaux objectifs est de trouver un modèle architectural générique pour

SDVMN (Software Defined Virtual Mobile Network) et la compatibilité avec l'architecture de
42
here.
référence SDN. En utilisant ce modèle générique, on peut facilement comprendre comment la
technologie SDN et NFV sont utilisés dans les réseaux.
IV.8. eNB à base SDN
La virtualisation de l'eNB est similaire à toute autre virtualisation de nœud, où une

entité appelée «Hypervisor» est ajoutée au-dessus des ressources physiques et est responsable
de l'allocation de ces ressources entre les différentes instances virtuelles exécutées.
Cette proposition tente d'utiliser les avantages de la mise en réseau définie par logiciel
(SDN) et OpenFlow, en introduisant la virtualisation du réseau dans les réseaux LTE de
manière adaptable, hautement extensible et moins invasive. La solution proposée consiste en
une nouvelle architecture de réseau et un mécanisme qui permet la virtualisation des stations
de base LTE en fonction de l'état du réseau.
La nouveauté de notre cadre est basée sur la flexibilité offerte par l'utilisation de l'OF,
qui permet la virtualisation dynamique des eNB physiques existants. En fait, dans OF le plan
de contrôle est déplacé dans un contrôleur centralisé, la politique de réseau pour NV peut être
facilement modifiée ou adaptée dynamiquement aux nouvelles exigences en se concentrant
uniquement sur le Contrôleur.
IV.8.1. Architecture
Deux types d'entités logicielles sont également définis, qui sont le contrôleur principal
(MC) et le contrôleur local (LC). Ces entités sont responsables de la gestion des éléments
physiques comme suit:
Le contrôleur principal : Le MC agit comme un contrôleur SDN et gère de multiples

eNB. C'est l'endroit où réside l'intelligence du réseau et la responsabilité d'activer la procédure
NV pour permettre le partage des eNBs entre plusieurs opérateurs. Le MC programme
également les OFS (OpenFlow switch), en envoyant des instructions / règles pour gérer le
lien entre les UE et les opérateurs hébergés dans les eNB.
43
here.
Figure 20 : OpeNB Framework

La nouvelle eNB exécute la fonctionnalité de la couche PHY et MAC comme une
station de base traditionnelle de LTE. Le changement est que les paquets de / vers la couche
MAC traversent l'OFS, qui gère les paquets par rapport aux instructions fournies par le MC.
En particulier, les ports de sortie de l'OFS sont connectés à l'entité LC qui implémente la pile
de protocole eNB pour chaque opérateur. Le LC fournit essentiellement l'abstraction de
l'infrastructure physique eNB et implémente les fonctions de partage des ressources physiques
entre les différents VeNB. Le LC donne aux VeNB toutes les fonctionnalités nécessaires pour
gérer les ressources physiques allouées et implémente le plan de données / contrôle vers les
UE. En outre, le LC coordonne l'allocation (équitable) des ressources entre plusieurs
opérateurs (en tant que Hyperviseur) en ce qui concerne les accords de propriété entre les
opérateurs, alors que c'est aussi le moyen par lequel le MC met à jour les entrées de l'OFS.
Le MC utilise un protocole basé sur UDP, pour communiquer avec l’eNB qui est situé
dans sa zone et obtenir des informations à jour sur l’état actuel (trafic, condition de canal,
bande passante, etc.). Il utilise également le protocole OF pour communiquer avec les OFS
dans eNB. Remarque : on choisit le protocole UDP pour l'échange de messages, car il est un
protocole sans connexion, ne nécessite pas un établissement de connexion entre les entités.
44
here.
Cette fonctionnalité est très utile pour notre cadre qui échange des données sporadiques et à
faible volume.
IV.8.2. Les avantages de la virtualisation d’eNB
La virtualisation des stations de base à long terme (LTE) sera nécessaire pour les
futurs réseaux. Parmi les avantages majeurs de cette approche :
 Amélioration des performances de l'utilisateur ;

 Réduction des interférences de liaison descendante ;
 Partage des bandes de fréquence entre opérateurs ;
 Réduction d’énergie.
IV.9. EPC à base de SDN
L'intégration du SDN dans l'EPC actuelle est une tâche complexe qui implique une
évaluation minutieuse des protocoles standardisés du (3GPP).
Figure 21 : LTE virtualisé à base SDN

Cette intégration agit sur les principales procédures des plans de contrôle et de
données en s'appuyant sur de nouvelles techniques telles que SDN et Network Function
Virtualisation (NFV).
45
here.
Il est primordial de modifier légèrement l'architecture existante afin d'intégrer les
composants de base dans le réseau OpenFlow. Les interfaces principales: S1-MME, S1-U,
S6a et Gx sont maintenues, ainsi que l'authentification, l'autorisation et la gestion de mobilité
(MME). Le mécanisme de sélection de (SGW) / (PGW) actuel qui est basé sur les poids DNS
(Domain Name System) a été modifié. Le MME interroge le contrôleur OpenFlow via
l'interface NorthBound (interface de programmation d'application REST) qui est capable
d'installer des règles de transfert dans les commutateurs OpenFlow comme il est indiqué dans
la figure 11. La fonctionnalité des principaux composants est présentée comme suit:
Le contrôleur SDN
Le contrôleur SDN est l'entité centrale chargée de la gestion des plans d’utilisateur et
les décisions de routage entre (eNB-U) et (S / PGW-U) de ce plan. L'une des responsabilités
du contrôleur SDN est de tenir à jour des statistiques portuaires, d'équilibrer le trafic et
d'effectuer la planification des débits.
Le contrôleur interroge périodiquement les octets transmis sur chaque commutateur et

sur la base des informations rapportées, il distribuera également la charge. Pour un porteur par
défaut, le mécanisme d'ordonnancement de flux calcule un chemin de la source à la
destination en fonction de la limitation de la bande passante, le profil de l'UE qui exige et
installe des entrées de flux dans les commutateurs eNB-Us et S / PGW-U. Le contrôleur peut
installer des règles dans les commutateurs OpenFlow (OF) en mode réactif et proactif:
Mode proactif : lors de l'établissement du porteur par défaut, il fonctionne en mode

proactif (il remplit les entrées de flux à l'avance)
Mode réactif : pour les porteurs dédiés il prend des décisions basées sur Les
informations contenues dans l'en-tête du paquet.
Le MME
Le MME n'est plus responsable de la sélection S / PGW-U. Il interroge le contrôleur

via l'interface de Nord à l'aide de l'API ouverte. L'un des principaux avantages de cette
solution est la grande élasticité, qui permet aux opérateurs mobiles de conserver MME
autonome ou de l'intégrer dans le nuage. Par exemple, l'application MME, l'application S /
PGW de plan de contrôle (S / PGW-C) et Policy and Charging Rules function (PCRF)
peuvent être exécutées en tant que Virtual Machine (VM) (OpenStack Neutron) au-dessus du
46
here.
contrôleur. Les interfaces standard telles que S1-MME (entre eNB et MME), S6a (entre MME
et HSS) et Gx (entre PGW et PCRF) pourraient être maintenues.
S / PGW-C
Les fonctions de contrôle de SGW et de PGW, telles que l'attribution de

l'identificateur de point final du tunnel (TEID), sont en charge du contrôleur. Une base de
données est requise à fin de stocker l'adresse du protocole Internet (IP) de l'UE après la
requête MME et de conserver une correspondance entre les paramètres du Quality of Service
(QoS) et le porteur. Dans cette architecture, le plan de contrôle et GPRS Tunneling Protocol
Control Plane (GTP-C) sont maintenus dans le sens où ils ajoutent des fonctionnalités
transparentes aux interfaces de contrôle standard 3GPP.
ENB-SDN / SGW-U / PGW-U
Ces composants sont des commutateurs OF permettant de traiter les entrées de flux
reçues du contrôleur dans leurs tables de flux. Ces commutateurs sont responsables de
l'acheminement du trafic d’utilisateur entre (eNodeB) et IP (Internet).
Le contrôleur local
Le contrôleur local (LC) est responsable de la classification des paquets aux

commutateurs d'accès en fonction de l'adresse IP (LocIP) (l'adresse IP de l'UE et le préfixe de
l’eNB). Il communique au contrôleur central via une API ouverte.
eNodeB
L’eNB est l’entité de réseau qui conserve les fonctions de radio spécifiées dans les
normes 3GPP pour l'interface radio.
IV.10. Plan de contrôle
IV.10.1. Le contrôleur local (LC)
Le LC est responsable de classer les paquets en fonction de Plusieurs attributs,

d’appliquer les règles génériques et de former l'adresse dépendant de la localisation (LocIP).
Cela se fait principalement pour identifier les utilisateurs connectés à la même station de base
et pour gérer la mobilité lorsque les utilisateurs migrent vers un autre eNB.
47
here.
Le LocIP se compose de l'identifiant UE et du préfixe de la station de base. Même si
les commutateurs d'accès peuvent maintenir l'état par flux, il n'est pas évolutif que le
contrôleur gère le réseau au niveau du flux, par conséquent, l'objectif principal de l'agrégation
des flux est de minimiser les ressources de traitement dans le contrôleur. Les flux provenant
du même utilisateur (source IP) et le port de destination peuvent être agrégés dans un seul lot
et routés de la même manière. Après l'agrégation, le contrôleur local envoie les paquets
classés au contrôleur central. Une fonction majeure de la LC consiste à répartir les flux de
manière égale et à éviter les encombrements dans le réseau aux commutateurs de bord. Le LC
communique avec le contrôleur SDN principal via le protocole OpenFlow.
IV.10.2. Le contrôleur central (MC)
Le rôle du contrôleur principal est de catégoriser le trafic en différentes classes en

fonction de plusieurs paramètres. Les paquets entrant dans un domaine des services peuvent
être classés sur plusieurs paramètres: les adresses IP source et de destination, le protocole
Layer 4 et les numéros de port, la valeur d'octet Type de service (ToS) ou les informations
Layer 2. Dès que ces paquets sont classés au moins sur la base de l'un des paramètres
mentionnés ci-dessus, ils peuvent être traités, conditionnés et marqués. Le rôle du contrôleur
central est de classer le trafic dans différentes classes et d'appliquer les paramètres QoS à ces
classes.
IV.11. Plan d’utilisateur
IV.11.1. PDN Gateway User (PGW-U)
Le commutateur PGW-U met en cache l'état des paquets envoyés à Internet et effectue
la traduction d'adresse réseau (NAT) sans interroger le contrôleur central pour traduire
l'adresse de l'UE. Afin de mettre en cache l'état utilisateur associé, le commutateur PGW-U
nécessitera une table plus grande qui n'impliquera pas nécessairement une capacité de
traitement accélérée de contenu Tarnary (TCAM) plus coûteuse avec des capacités de
traitement optimisées. En raison de la vulnérabilité face aux attaques malveillantes provenant
d'Internet, ces menaces peuvent être évitées en configurant des listes d'accès ou des pare-feu.
IV.11.2. SGW user
48
here.
IV.12. Midleboxes
Midleboxes [9] représente les boîtes intermédiaires qui sont nécessaires entre le
commutateur PGW-U et Internet pour ajouter des règles supplémentaires à différents trafics.
Ces boîtiers peuvent être soit déployés en matériel autonome dans plusieurs emplacements
(par exemple : pare-feu, transcodeurs, optimiseurs de réseau étendu, caches proxy Web,
systèmes de détection d'intrusion…) ou exécutés sur des machines virtuelles à partir d'un seul
emplacement. Ils sont nécessaires pour assurer la flexibilité et l'application des politiques dans
le noyau mobile via SDN.
Figure 22 : Classification et direction de trafic
IV.13. Les défis d’EPC/SDN
L'architecture EPC SDN proposée apporte des défis supplémentaires tels que
l'agrégation de flux dynamique, les chemins politiques et la solution de routage centralisée.
IV.13.1. Pile protocolaire
IV.13.1.1. Encapsulation GTP
Problème : Le GTP est le protocole clé dans EPC. Dans le plan utilisateur, le tunnel
GTP est identifié de manière unique par une paire de TEID (nœuds sources et destination)
ainsi que les adresses de source et de destination IP et les numéros de port UDP. Dans
49
here.
l'architecture EPC traditionnelle, chaque porteur est identifié par un tunnel et un UE peut
avoir plusieurs sessions correspondant à plusieurs porteurs. Étant donné que l'architecture
employée est basée sur OpenFlow, un commutateur OF est la plate-forme utilisée pour traiter
tout le trafic. Cependant, la version la plus récente du Open-Flow (OpenFlow 1.4.0) ne
supporte pas la correspondance GTP, ni TEID dans l'en-tête GTP.
Solution : Il existe deux solutions possibles à ce problème. Une option consiste à

étendre le protocole OpenFlow afin de supporter la terminaison du tunnel GTP et les TEID.
La deuxième solution consiste à garder Open Flow intacte et à ajouter une entité
distincte (une carte de ligne) responsable de la terminaison du tunnel de GTP. Cela devrait
fonctionner comme un «décapsuleur» et il peut être placé entre eNodeB et le commutateur
eNB-U. La fonction principale de cette entité est de supprimer les TEID. De cette manière, le
réseau entre eNB et Internet est un noyau IP qui peut être facilement géré par le contrôleur.
Figure 23 : Pile protocolaire de LTE-SDN
IV.13.1.2. Décapsulation GTP
Problème : Après l'en-tête UDP de la pile GTP il n'y a pas d'en-tête Ethernet. Après la
décapsulation de GTP, le paquet n'a pas d'information de couche 2, donc pour implémenter le
protocole GTP dans l'Open vSwitch, les informations de couche 2 doivent être ajoutées.
50
here.
Solution 1 : Une solution possible à ce problème, c’est de créer un en-tête Ethernet
simple et les paquets seront transmis en fonction des informations de couche 3, car les
informations de couche 2 n'existent pas réellement.
Solution 2 : Une autre solution consiste à acheminer les paquets en fonction des
informations disponibles. De cette façon, nous profitons pleinement des fonctionnalités Open
vSwitch en spécifiant uniquement les ports d'entrée et de sortie. La performance de cette
solution devrait être meilleure en termes de débit que la solution dans laquelle nous pouvons
activer le mappage de couche 3 et modifier l'en-tête Ethernet. En fait, le mappage de couche
3 et le changement d'en-tête Ethernet augmentent les frais généraux du tunnel GPRS
Tunneling Protocol (GTP-U).
IV.13.2. Routage centralisée
Problème : Dans le réseau LTE normalisé, la QoS est mise en œuvre entre UE et
PGW sur un ensemble de porteurs qui assurent un traitement spécial à un ensemble de trafic.
Ces porteurs peuvent être des porteurs par défaut (service "Best-effort") lorsque l'UE se
connecte au réseau pour la première fois, ou des porteurs dédiés qui agit comme un porteur
supplémentaire au porteur par défaut. Le porteur dédié fournit un traitement différencié pour
différentes sessions (VoIP, vidéo…). Dans l'architecture basée sur EPC/SDN, les concepts de
porteurs par défaut et de porteurs dédiés doivent également être définis.
Solution : Porteur par défaut: Le contrôleur central renvoie les TEID pour les adresses
de contrôle et les adresses IP des eNB-U et S / PGW-U. Par exemple, sur la base d'un
mécanisme d'équilibrage de charge et de réception de statistiques de charge périodiques, le
contrôleur obtiendra les informations sur les commutateurs moins surchargés et installera des
entrées de flux dans tout le chemin de données. L'établissement de porteur par défaut ne
nécessite pas l'intervention du contrôleur principal (instanciation réactive), puisque les
commutateurs ont déjà une entrée de flux installée.
Porteurs dédiés : Le LC regroupe les flux en paquets en fonction de la LocIP, qui

comprend l'UE et l'ID eNB. En utilisant cette méthode, on réduit le nombre d'entrées de flux
dans le plan de données SGW (SGW-U) et le temps de traitement. A ce stade, le nombre de
faisceaux est proportionnel au nombre d'utilisateurs puisque toutes les sessions utilisateur sont
regroupées dans un flux avec un ID unique (ID de lot ou code de stratégie). Dans l'étape
suivante, le commutateur SGW-U envoie un message PACKET_IN au contrôleur principal
51
here.
qui recherchera dans sa table de base de données la valeur QCI pour cette session
(correspondant au port de destination) et le bit ToS et établira une politique de chemin.
Figure 24 : Table de contrôle et de flux dans eNB SDN
Le contrôleur SDN principal est responsable de choisir le chemin le plus court,

d'installer des stratégies sur le chemin et de configurer les entrées de flux dans les
commutateurs. Dès que l'UE est authentifiée, le MME envoie le message Attach Request au
contrôleur. La table de base de données est remplie avec UE IP, les valeurs QCI
correspondant aux sessions utilisateur et le type d'abonnement. Le contrôleur SDN conserve
un enregistrement de mis à jour des statistiques de port en interrogeant le contrôleur local et le
S / PGW-U en une période de millisecondes.
IV.13.3. Agrégation de flux dynamique
Problème: Généralement, dans un scénario de réseau mobile, des millions

d'utilisateurs sont connectés à des milliers des eNB, qui sont connectés à plusieurs passerelles.
En fait qu'un réseau cellulaire doit servir des millions de clients avec des diverses demandes,
cela implique des politiques sophistiquées sur la chaîne de service. Par rapport à un centre de
données où le trafic reste à l'intérieur, dans un réseau cellulaire, le trafic mobile va et vient de
l'utilisateur à l'Internet. Une autre caractéristique du réseau mobile réside dans le fait qu'elle
présente un bord asymétrique (c'est-à-dire que le bord d'accès présente une bande passante
plus faible que le bord de la passerelle). La plupart des trafics sont lancés à partir de bord
d’accès.
Solution: Si on utilise l'architecture LTE/SDN proposée, afin d'économiser des

ressources et une puissance de l'unité centrale de traitement (CPU), la granularité de flux peut
être utilisée comme un moyen d'agrégation des flux. Au lieu d'avoir des millions de flux avec
dix entrées OpenFlow, on peut les regrouper plutôt que d'acheminer chaque flux
individuellement. Par conséquent, l'une des options est de faire l'agrégation de flux au niveau
52
here.
du bord d'accès (eNB) puis d'appliquer des règles aux passerelles pour implémenter des
chemins d'accès vers Internet. La classification des paquets est effectuée lorsque le trafic entre
dans le réseau au niveau du bord d'accès et encode les résultats de classification dans l'en-tête
du paquet. Ensuite, lorsque le trafic revient d'Internet, le bord de la passerelle n'a besoin que
d'effectuer le renvoi, car les résultats de la classification sont implicitement liés dans l'en-tête
du paquet
IV.13.4. Politique de chemins
Problème: A cause de l'évolution des applications en temps réel, la QoS dans les
réseaux mobiles est devenue une exigence importante. Un mécanisme de QoS de bout en bout
devrait assurer un traitement de trafic spécial pour différents profils d'utilisateur et différentes
sessions. Cela peut être réalisé en installant des politiques sur le chemin avec la mise en forme
du trafic.
Solution: Ces politiques peuvent être appliquées non seulement aux flux individuels,
mais également aux faisceaux spécifiques aux applications / services, de manière à adapter le
circuit pour avoir des caractéristiques bénéfiques pour l'application ou le service (c'est-à-dire
le chemin sur lequel le faisceau est acheminé). Par exemple, le trafic VoIP doit bénéficier de
trajets à faible latence. Dans le cas d'un paquet VoIP, un circuit peut être créé dynamiquement
entre les commutateurs de paquets source et destination, où le chemin du circuit est celui qui
présente le plus petit délai de propagation. De la même manière, tout le trafic HTTP peut être
redirigé via un pare-feu sur le chemin d'accès à Internet. Un autre exemple est le trafic vidéo,
où la faible latence pour la vidéo n'est pas aussi importante que faible gigue. De plus, la
session vidéo peut être acheminée sur le chemin de propagation la plus courte dans la
topologie utilisée.
IV.14. Mobilité de l'utilisateur
On doit prendre en considération plusieurs aspects pour que la conception du système

proposé soit pleinement conforme au contexte de la mobilité. Tout d'abord, les transitions de
l'état inactif / connecté doivent être discutées correctement. L'appel est établi selon deux
procédures importantes: la demande déclenchée par l'UE et la demande déclenchée par le
réseau.
53
here.
IV.14.1. États inactifs / connectés
L'une des principales caractéristiques de Evolved Packet System (EPS) est la

fonctionnalité "always-on": tant que l’appareil de l’utilisateur est allumé, il a un porteur par
défaut en permanence. Le cœur de réseau mobile fait partie du porteur EPS par défaut et de
l'adresse IP affectée à l'UE qui restent avec l'UE tant qu’il est sous tension. Le porteur EPS
par défaut est le premier support établi et le dernier porteur libéré. Cela permet à l'UE
d’échanger des informations avec le serveur à tout moment. Cet état UE est appelé l'état UE
REGISTERED.
Contrairement au cœur de réseau, le réseau radio adopte une approche différente. Il

alloue et libère dynamiquement les ressources du réseau radio pour supporter le porteur EPS
par défaut avec des transitions entre les deux modes des modes REGISTERED,
CONNECTED et IDLE. Ces transitions durent environ 100 millisecondes. Dans l'état ECM-
CONNECTED, il existe une connexion de signalisation entre l'UE et le MME. Cette
connexion de signalisation se compose de deux parties: une connexion RRC (Radio Resource
Control) entre UE et eNB et une connexion S1-MME entre eNB et MME. Lorsque l'UE a un
nouveau trafic à envoyer, il envoie le message de demande de service MME, en transmettant à
l'état ECM (EPS Contrôl Management) / RRC-CONNECTED. Lorsqu'un UE est toujours
enregistré sur un réseau, mais sa connexion S1 est libéré à cause de l'inactivité, l'UE n'a pas de
ressources radio disponible. Par conséquent, l'UE est en cas EPS Mobility Management
(EMM)-REGISTERED, tout en étant dans l'état ECM-IDLE. [12]
Figure 25 : Transition inactive / connectée
Les demandes de service peuvent être déclenchées soit par l'UE, soit par le réseau.
Elles sont classées comme suit :
 La demande de service déclenchée par l'UE : des données de liaison montante

doivent être envoyées depuis l'UE vers le réseau.
 La demande de service déclenchée par le réseau : des données de liaison
descendante doivent être envoyées du réseau à l'UE
54
here.
IV.15. Flux d'appel
IV.15.1. Demande déclenchée par l'utilisateur
Une demande de service déclenché par l’utilisateur est une procédure que l'UE exécute
quand il est en mode veille et il doit établir les porteurs pour envoyer des données ou un trafic
de signalisation au MME.
 L'UE lance la Procédure de connexion en envoyant à eNB le message de

demande de connexion (Identité d'abonné mobile internationale (IMSI), dernier
identifiant de zone de suivi (TAI) Le message de demande de connexion est
envoyé dans le message initial d’UE au MME sur l'interface S1AP. Le
message inclut également le message de demande de connectivité des paquets
de données (PDN). L’eNB utilise l'ID eNB-UE-S1AP pour identifier de
manière unique l'UE.
Figure 26 : Demande de connexion (UE)
 Le MME récupère les informations utiles pour authentifier et interroger le

profil de l'UE à partir de HSS, tels que: IMSI (l'identifiant unique d'une carte
SIM (Subscriber Identity Module), QoS et Nom de point d'accès (APN) de
l’abonné ;
 Pour authentifier un UE, le MME envoie « Create Session Request » au
contrôleur SDN via l'interface Nord ;
55
here.
 Dans cette étape, l'application S / PGW-C interrogent le PCRF afin d'obtenir la
QoS pour la session initiée, ainsi que les taux de téléchargement maximum
pour les liens ascendants et descendants.
 Les applications S / PGW-C renvoient au contrôleur SDN le TEID pour le
contrôle et les adresses IP des commutateurs OpenFlow qui sont moins
surchargés avec les taux maximum de liaison descendante et de liaison
montante. Un message « Create Session Response » est établi entre le
contrôleur SDN et le MME.
 le contrôleur central communique avec le contrôleur local pour configurer les
entrées de flux dans le commutateur eNB-SDN et établit les règles de politique
dans les commutateurs S / PGW-U.
 Une réponse OpenFlow (PACKET_IN) est envoyée des commutateurs au
contrôleur local qui communique avec le contrôleur central. Le message
PACKET_IN inclut les statistiques du port: les paquets reçus et transmis ainsi
que le nombre de paquets abandonnés.
 Un message d’acceptation est envoyé par MME à eNB contenant l'adresse IP
de S / PGW-U, et les taux maximum de liaison montante et descendante.
Néanmoins, les messages Non Access Stratum (NAS) sont transparents à
l’eNB qui les transmet à l'UE. Le message de reconfiguration de connexion
RRC est envoyé pour activer le support de radio par défaut.
 Une fois que le MME a reçu le message Attach Complete, l'eNB-SDN envoie
le premier paquet de données UE.
 Lorsque le paquet arrive, le LC vérifie les adresses IP source et destination,
aussi l'adresse de contrôle d'accès à l’eNB et modifie l'en-tête de paquet avec
l'adresse LocIP. Pour un établissement porteur par défaut, l'agrégation et les
règles de politique sur le chemin ne sont plus nécessaires car dans LTE, le
support par défaut fournit un débit non garanti (GBR). Lorsque l'utilisateur a
plusieurs sessions, un porteur dédié doit être établi. Le LC agrégera les flux en
fonction de LocIP et il les envois aux commutateurs S / PGW-U dans un
message de demande PACKET_IN.
 Le contrôleur SDN central analyse le Port de destination du paquet utilisateur
et effectue la correspondance entre le QCI de cette session, le profil utilisateur
56
here.
et ToS. Selon le type de session, il installera un chemin d'accès aux règles et
configure les entrées de flux dans les commutateurs S / PGW-U.
IV.15.2. Demande déclenchée par le réseau
La demande de service déclenché par le réseau est une procédure exécutée lorsque
l’UE est en veille et le réseau doit établir les porteurs pour lui envoyer des données ou une
signalisation.
 Lorsque le SGW-U reçoit un paquet de données de liaison descendante pour un

UE qui est dans ECM-Idle, il exécute une correspondance d'en-tête dans sa
table de flux. Puis il envoie un message de notification de données de liaison
descendante au contrôleur SDN principal dans un message PACKET_IN. Le
contrôleur interroge MME, qui répond avec un accusé de réception de
notification de données descendante. Cette confirmation sera envoyée au
commutateur S / PGW-U dans un message PACKET_OUT.
 Si l'UE est enregistrée dans le MME, celui-ci envoie un message de pagination
à chaque eNB appartenant à la zone « Tracking Area » (TA) dans laquelle l'UE
est enregistrée. Lorsque l’eNB reçoit le message Paging du MME, elle la
transmet vers l'UE.
Figure 27 : Demande de connexion (réseau)
57
here.
 Si l'UE est en veille, le MME connaît son dernier emplacement. Ainsi, si MME
veut trouver un UE en mode inactif, il envoie le message Paging à l'eNB et
l'eNB sera la page pour l'UE. Mais si UE est dans une nouvelle (TA) et qu’il
n'est pas dans la liste reçue lors de la connexion initiale, le MME lance une
mise à jour Tracking Area Update (TAU).
 Lorsque l’UE reçoit une indication Paging, il lance la procédure de demande
de service déclenchée par l'UE qui a déjà été discutée ci-dessus. Pour lancer un
TAU, l'UE doit avoir une connexion RRC. Tout d'abord, il s'attache à l'eNB la
plus proche Dès que la connexion RRC est établie, l'UE envoie un TAU au
réseau.
 Une fois que le réseau reçoit TAU, le LC stocke les informations de
localisation de l'UE et il installe les entrées de flux dans le commutateur eNB-
SDN. Le SGW-U transmet les données de liaison descendante vers l'UE.
IV.16. Analyse de la conception et les améliorations possibles
IV.16.1. Flexibilité
 Plan de contrôle :
La souplesse introduite par les fonctions virtualisées élimine la sur provision de l’EPC
traditionnelle, vise à apporter une automatisation et une intelligence supplémentaires dans un
environnement standardisé. La couche de gestion d'orchestration permet l'allocation
dynamique de capacité pour les machines virtuelles en fonction des exigences (horizontal and
vertical scalability). Ceci est renforcé par la gestion du trafic et le routage optimisé dans
l'application S / PGW-C. Par exemple, les mises à niveau logicielles peuvent être maintenues
par l'opérateur sans qu'il soit nécessaire d'en faire une implication des fournisseurs. Un autre
avantage que la virtualisation pourrait apporter aux opérateurs, est le déploiement des
environnements de production et de test sur la même plate-forme.
 Plan d’utilisateur
L'élasticité de plan d’utilisateur est principalement offerte par les capacités Open vSwitch. Par
conséquent, en envoyant au contrôleur des mises à jour périodiques des paquets reçus /
transmis et abandonnés, la redondance globale dans le réseau augmente, de sorte que le
contrôleur sera conscient des liens encombrés. Cette caractéristique est fortement liée au
58
here.
mécanisme d'équilibrage de charge qui est destiné à distribuer également des flux vers des
commutateurs moins surchargés. Le mécanisme de priorité de flux et l'agrégation peuvent
établir la qualité de service pour un type particulier de service (VoIP, vidéo, etc.).
L'un des principaux inconvénients de l'architecture LTE existante est l'établissement de

tunnels entre eNB et PGW, même lorsqu'il n'y a pas de trafic de données à envoyer. Cette
anomalie peut être évitée si Open vSwitch déclenche l'effacement de tunnel après une période
prédéterminée de plusieurs secondes ou si la période de connexion expire. De plus, sur la voie
de chaînage de service, la gestion du trafic peut être facilement résolue par la gestion du trafic
du contrôleur.
IV.16.2. Complexité de déploiement
 Plan de contrôle
La complexité de la solution actuelle peut être analysée en termes d'outils de mise en

œuvre, d'évolutivité et de coûts. Même si la solution proposée préserve la fonctionnalité du
plan de contrôle, du point de vue de l'implémentation, elle nécessite des changements de
matériel et de logiciel. Par exemple, les fonctions MME, S / PGW-C et PCRF peuvent
s'exécuter en VM dans OpenStack Neutron (dans les centres de données) et peuvent être
communiquées avec le contrôleur central via l'API REST. De plus, le contrôleur et OpenStack
peuvent être implémentés sur une plate-forme de serveur virtualisée, cela diminue
considérablement la complexité du matériel dans un réseau d'opérateurs. Le coût des dépenses
en immobilisations (CAPEX) et des dépenses d'exploitation (OPEX) est l'un des principaux
avantages du déploiement de SDN dans le réseau des télécommunications.
 Plan de données
Le plan de donnée innovant consiste en plusieurs switch OpenFlow avec Open

VSwitch (OVS) intégré. Open vSwitch [47] est un commutateur virtuel qui prend en charge
les flux, les VLANs, le tranking, la QoS, l'agrégation des ports et la couche 3. La solution
utilisée simplifie l'encapsulation GTP du plan de donnée dans l’EPC traditionnelle en
impliquant le transfert à la couche 2 et le flux Agrégation basée sur ToS. L'adresse LocIP
regroupe les flux provenant du même UE et eNB dans une seule balise et différencie les
sessions utilisateur en fonction des ports de destination. Néanmoins, dans un grand
environnement de production, il pourrait garantir l'évolutivité du réseau. L'un des avantages
de cette solution repose sur la mise en œuvre à faible coût, puisque le prix d'un OpenSwitch
59
here.
est de milliers de dinars par rapport à Des millions que les opérateurs paient pour le
déploiement et la configuration de chaque passerelle.
IV.16.3. La performance
 Plan de contrôle
La performance du plan de contrôle dans l'architecture EPC SDN devrait augmenter en

termes de fiabilité de routage par rapport au déploiement EPC existant. Par exemple, le
mécanisme d'équilibrage de charge actuel est proactif et ne prend pas en compte la charge ou
la capacité instantanée en raison du manque de communication entre les éléments GTP-C, ce
qui peut conduire à une surcharge dans un ou plusieurs nœuds d'un SGW ou PGW.
Maintenant, un nouveau mécanisme d'équilibrage de charge basé sur des mises à jour
périodiques de statistiques de flux peut être utilisé dans l'application S / PGW-C. En raison du
fait que dans l'architecture proposée, le contrôleur SDN principal peut gérer des milliers de
commutateurs et de LC, il introduit implicitement un seul point d'échec dans le réseau. La
redondance du réseau peut être augmentée en déployant deux contrôleurs centraux qui
peuvent communiquer entre eux via l'application HyperFlow. Le second contrôleur sert à la
sauvegarde en cas de défaillance du contrôleur primaire.
 Plan de données
Le protocole OpenFlow permet au contrôleur de configurer les tables de transfert de

matériel dans un réseau de commutateurs. Chaque fois que le commutateur reçoit un paquet, il
recherche d'abord dans sa table de flux pour l'alignement des en-têtes L2-L4, puis effectue
l'une des actions: transférer le paquet vers un port spécifique, encapsuler le paquet ou le
déposer. Si aucune correspondance n'est trouvée, le paquet sera envoyé au contrôleur. Dans le
déploiement proposé, la latence du contrôleur est diminuée en installant des règles prédéfinies
dans le commutateur, ainsi, pour un établissement porteur par défaut, le commutateur pourra
prendre une action basée sur les informations contenues dans le tableau de flux. Dans chaque
message PACKET_IN envoyé au contrôleur, le commutateur inclut des statistiques de port
avec le nombre de paquets reçus / transmis et abandonnés. Par conséquent, dans le cas de
liaisons congestionnées, les anomalies de trafic peuvent être facilement déterminées par le
contrôleur SDN.
60
here.
IV.17. Sécurité de la virtualisation de réseau
NFV pose également un défi de mise en œuvre et d'assurer la sécurité du réseau à

plusieurs niveaux. Avec les multiples couches indépendantes d'entités opérationnelles et de
gestion, comme le matériel, les hyperviseurs, les conteneurs et les VNF, les paramètres de
sécurité doivent être pris en considération pour chacun d'eux. Il peut être nécessaire de
conserver les autorisations et les informations d'identification des utilisateurs pour chacune
des couches. Un point faible dans l'une des couches peut entraîner une violation qui pourrait
avoir un impact sur les autres. Chaque couche doit être sécurisée.
Pour sécuriser le réseau NFV contre les intrusions et bloquer l'accès et le trafic
indésirables, des pare-feu séparés peuvent être nécessaires à plusieurs niveaux :
 La première couche : concerne les VNF individuels, qui doivent être protégés, tout
comme les appareils traditionnels. Les pare-feu virtuels (fonctionnant dans un VNF
séparé) peuvent être utilisés à cette fin.
 La deuxième couche : utilise un pare-feu dans l'hyperviseur, protégeant le chemin
parcouru par les données pour chaque machine virtuelle. Ce type de pare-feu, appelé
un pare-feu introspectif, protège les machines virtuelles de l'hôte contre l'accès qui
peuvent exploiter les ports ouverts accessibles via l'hyperviseur indépendamment de
son état opérationnel.
 La troisième couche : consiste à implémenter un pare-feu pour protéger le système
d'exploitation hôte lui-même. La protection des composants de l'infrastructure et
l'assurance que le trafic indésirable est bloqué à leur égard nécessiteraient encore une
autre couche de pare-feu. Les pare-feu protégeant le système d'exploitation et
l'infrastructure hôte peuvent faire partie du NFVI lui-même et seraient probablement
approvisionnés et maintenus pour fonctionner indépendamment des pare-feu
introspectifs et des pare-feu VNF.
Un autre défi à relever pour la mise en œuvre de sécurité NFV provient de l'utilisation
de logiciels multi fournisseurs dans le réseau NFV et en particulier les VNF. Étant donné que
le VNF, ainsi que toutes les autres couches, peuvent être composés d'implémentations de
plusieurs fournisseurs différents, chacun d'entre eux devra être évalué et validé séparément
pour s'assurer qu'il est sécurisé et robuste. Une réévaluation peut être requise si le VNF est
commuté d'un fournisseur à l'autre, créant ainsi des frais généraux supplémentaires pour le
processus de sélection du VNF.
61
here.
IV.18. Conclusion
62
here.
Chapitre V : Simulation
63
here.
V.1 Introduction
V.2 Virtualisation de l’interface aérienne LTE
Afin de virtualiser l'interface aérienne LTE, il est nécessaire de virtualiser eNodeB [1]
dans E-UTRAN du réseau mobile LTE. Comme le montre la figure ci-dessous, un
«Hypervisor» est ajouté aux ressources physiques du réseau mobile LTE pour virtualiser les
eNodeBs. En outre, l'hyperviseur peut collecter des informations telles que l'état de la chaîne
et les charges de trafic des utilisateurs, les exigences et le contrat des MVNO. Ensuite, il est
chargé de planifier les ressources de l'interface aérienne parmi les MVNO.
Figure 28 : Pile protocolaire d'eNB virtuel
V.2.1. Modèle de simulation
Le modèle de simulation LTE utilisé dans ce chapitre a été développé à l'aide de l'outil
de simulation OPNET [2]. Le modèle est conçu et mis en œuvre selon les spécifications
3GPP. L'objectif de ce travail n'était pas sur la virtualisation des nœuds ou des liens, mais
plutôt sur la virtualisation de l'interface aérienne et sur la façon de programmer les ressources
de l'interface aérienne entre les différents opérateurs virtuels.
La figure ci-dessous montre un scénario d'exemple, on peut voir que l’hyperviseur est
ajouté entre les eNodeBs virtuels. Cette entité est responsable de la planification des
ressources de l'interface aérienne (spectre de fréquence ou PRB) parmi les différents eNodeBs
virtuels. L'Hyperviseur a également un accès direct aux couches MAC de chacun des ENodeB
64
here.
virtuels LTE pour collecter les informations pertinentes requises à utiliser pour la
planification comme: les conditions de canal des utilisateurs de l'opérateur et la charge de
trafic de l'opérateur.
V.2.2. Scénario 1 : Multiplexage
Ce scénario exploite le gain de multiplexage qui se réalise grâce à la virtualisation

LTE et au partage du spectre. L'idée derrière ce scénario est de montrer ce qui se passe si
différents opérateurs partagent leurs bandes de fréquences les uns avec les autres.
Normalement, le réseau d'accès radio est dimensionné avec une bande de fréquences
surchargée pour gérer les scénarios les plus défavorisés lorsque les opérateurs connaissent
leurs charges de trafic maximales. Une hypothèse générale qui peut être supposée est que les
différents opérateurs mobiles connaissent leurs pics de charges à différents moments, ce qui
signifie que le potentiel de multiplexage peut être atteint grâce au partage du spectre. Cela
entraînera une meilleure utilisation globale des ressources. Ce scénario de simulation étudie
ceci en comparant deux configurations différentes:
- Configuration traditionnel: qui est la configuration du réseau mobile d'aujourd'hui,

où chaque opérateur possède une bande de fréquences et ne partage pas cette bande avec un
autre opérateur.
- Configuration virtualisée: où les opérateurs partagent la même infrastructure via la

virtualisation et la combinaison de spectre qui est partagé entre les différents opérateurs.
65
Abréviations
LTE Long Term Evolution
EPC Evolved Packet Core
MME Mobility Management Entity
HSS Home Subscriber Server
SGW Serving Gateway
PGW Packet Data Network Gateway
RAN Radio Access Network
UE User Equipment
NFV Network Function Virtualization
SDN Software Defined Networking
VNF Virtual Network Function
IMSI International Mobile Subscriber Identity
EPS Evolved Packet System
GTP GPRS Tunneling Protocol
OF OpenFlow
LC Local Controller
MC Main Controller
RRM Radio Resource Management
PCEF Policy Control Enforcement Function
RIB Routing Information Base
FIB Forwarding Information Base
EM Element Management
here.
NFVO NFV Orchestrator
TEID Tunnel Endpoint Identifier
VNFM VNF Manager
NFVI Network Function Virtualization Infrastructure
OSS/BSS Operation Support System/Business Support System
VIM Virtualized Infrastructure Manager
IaaS Infrastructure as a Service
NaaS Network as a Service
PaaS Platform as a Service
OVS Open vSwitch
ToS Type of service
QoS Quality of Service
TAI Tracking Area Identifier
ECM EPS Control Management
SDVMN Software Defined Virtual Mobile Network
VM Virtual Machine
TAU Tracking Area Update
CSP communications service provider
API Application Programming Interface
35
Bibliographies
[1] Cisco, “Cisco visual networking index: Global mobile data traffic forecast update,
2015-2020.” [Online]. Available: http://www.cisco.com/c/en/us/solutions/collateral/service-
provider/visual-networking-index-vni/mobile-white-paper-c11-520862.html
[1] “A Comparison of SDN and NFV for Re-designing the LTE Packet Core” Aman
Jain, Sadagopan N S, Sunny Kumar Lohani, Mythili Vutukuru: Department of Computer
Science and Engineering, Indian Institute of Technology, Bombay
[2] “LTE mobile network virtualization: Exploiting multiplexing and multi-user

diversity gain” Yasir Zaki · Liang Zhao Carmelita Goerg · Andreas Timm-Giel.
[3] “A Virtual SDN-enabled LTE EPC Architecture: a case study for S-/P-Gateways
functions”
[5] “Network Function Virtualization (NFV) with a touch of SDN”
[6] https://portal.etsi.org/NFV/NFV_White_Paper.pdf
[47] Open vSwitch, “Open Virtual Switch,” http://openvswitch.org/
[9] Xin Jin, Li Erran Li, Laurent Vanbever, and Jennifer Rexford. SoftCell: scalable
and flexible cellular core network architecture. ACM CoNEXT, 2013.

Rapport Sarra

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Rapport Sarra

Uploaded by

Copyright:

Available Formats

+MINISTERE DE L’ENSEIGNEMENT SUPERIEUR

‫المعهد العالي لإلعالمية وتقنيات االتصال بحمام سوسة‬

INSTITUT SUPERIEUR D’INFORMATIQUE

Présenté en vue de l’obtention du diplôme d’ingénieur

Technologies des Communications

Analyseur de trafic en tant que

‫المعهد العالي لإلعالمية وتقنيات االتصال بحمام سوسة‬

INSTITUT SUPERIEUR D’INFORMATIQUE

ET DES TECHNIQUES DE COMMUNICATION – HAMMAM SOUSSE

MEMOIRE DE STAGE FIN D’ETUDES

Présenté en vue de l’obtention du diplôme d’ingénieur

Technologies des Communications

Encadrant :…………………….. ……Date :………………………Signature

Superviseur :………………….. ……Date :………………………Signature

Année Universitaire 2016 – 2017

Affable, honorable, aimable : Vous représentez pour moi le symbole de la bonté

A mon cher Oncle Sghir Ezzedine

A tous les membres de ma famille, petits et grands

Tout d'abord, j'adresse mes remerciements à mon professeur, Mr Khaled

Je tiens à remercier vivement mon maitre de stage, Mr Anouar Aleya,

TABLE DE MATIERE ................................................................................................................................................ II

LISTE DES FIGURES ................................................................................................................................................ 1

CHAPITRE I : CADRE DE STAGE ET PRESENTATION DE L’ENTREPRISE .................................................................. 2

I.1 INTRODUCTION ..................................................................................................................................................3

CHAPITRE II : LTE ET LE RESEAU 4G ...................................................................................................................... 7

II.1 INTRODUCTION ..................................................................................................................................................8

CHAPITRE III: SOFTWARE DEFINED NETWORKING (SDN) .................................................................................... 7

III.1 INTRODUCTION ...........................................................................................................................................15

CHAPITRE IV: NETWORK FUNCTION VIRTUALIZATION (NFV) ........................................................................... 26

III.1 INTRODUCTION ...........................................................................................................................................27

CHAPITRE IV : ETUDE DE LA SOLUTION .............................................................................................................. 34

IV.1. INTRODUCTION ...........................................................................................................................................35

IV.8.1. Architecture .............................................................................................................................. 43

V.1 INTRODUCTION ...........................................................................................................................................64

Liste des figures

Figure 1: Puget de temps ............................................................................................... 4

Le rapport de ce projet est structuré en quatre chapitres :

 Le premier est dédié à la présentation de l’entreprise d’accueil ainsi que le cahier

La progression spectaculaire d’internet dans tout le monde, la prolifération des

Ce projet consiste à mettre en place la solution d’étude de virtualisation des

La conception sera suivie d’implantation de service d’analyse de trafic sur ces

I.5 Planification de projet

Figure 1: Puget de temps

I.6 Organisation du rapport

Tunisie Telecom est un opérateur de télécommunications qui focalise ces travaux à

Tunisie Telecom dispose de 24 directions régionales, 80 agences commerciales et point de

Tunisie Telecom atteint près de 7 millions d’abonnés de téléphonie fixe et mobile.

I.7.1 Les missions du groupe

 La contribution et la participation au développement de recherches

I.7.2 Organisation Fonctionnelle

La figure ci-dessous représente l’organigramme général de Tunisie Télécom :

Figure 2: organigramme Tunisie Télécom

L’objectif de LTE est de permettre à l’opérateur de fournir à ces clients plus de

Cette révolution d’amélioration de vitesse amène à une évolution énorme de données.

Ce chapitre a été consacré pour présenter l'entreprise d'accueil (Groupe Tunisie

II.2 LTE (4G)

 D’augmenter la capacité des réseaux ;

LTE optimise la technologie d’accès radio, soutient les déploiements de bande

II.2.1 Les buts de LTE

La 4ème génération a pour ambition d’améliorer l’efficacité spectrale 50 fois plus

II.2.2 Architecture de LTE

L'architecture totale de LTE est divisée en quatre domaines principaux: l'équipement

 L'équipement utilisateur (UE): est le dispositif mobile de l'utilisateur qui

Figure 3 : Architecture d'EPC traditionnel