DEPARTEMENT D'INFORMATIQUE MEMOIREd ˇacheminement de paquet, et sa non-dépendance sur un protocole spécifique d'unicast. Cette thèse propose un protocole sans fil de multicast

DEPARTEMENT D'INFORMATIQUE

MEMOIRE

Présenté par

F EL L AH So u ma ya

Pour obtenir

LE DIPLOME DE MAGISTER

Spécialité Informatique

Option : Ingénierie des Données et des Connaissances

Intitulé : Soutenu le : / / à la salle de conférences de la faculté des sciences

Devant les membres du jury : Président du jury Professeur KHELFI Mohamed Fayçal, Département

Informatique université d’Oran Directeur de thèse Professeur LEBBAH Yahia, Département Informatique université

d’Oran Co-directeur de thèse Maître de conférences B KADDOUR Mejdi, Département

Informatique université d’Oran Examinateur Professeur HAFFAF Hafid, Département Informatique université

d’Oran Examinateur Maître de conférences A GEZZOURI Mustapha, Département

Informatique université d’Oran

OPTIMISATION DU ROUTAGE MULTICAST DANS LES RESEAUX SANS FIL MAILLES

http://www.pdfcomplete.com/cms/hppl/tabid/108/Default.aspx?r=q8b3uige22

À mes parents

À mes frères et sœurs

À ceux qui m’ont encouragé et soutenu

À tous mes amies


Remerciements ii

Remerciements

Je voudrais avant tout remercier Allah pour tous ses bienfaits.

Il est important ensuite de remercier ardemment toutes les personnes ayant contribué de près

ou de loin à la réalisation de cette thèse. Mes sincères remerciements s’adressent à monsieur

Y. LEBBAH. Je souhaite remercier mon co-directeur de recherche monsieur M. KADDOUR

pour sa patience et ses encouragements, ses compétences scientifiques et qui a toujours su me

guider et me conseiller.

Je remercie tout particulièrement les membres de mon jury de thèse monsieur M. KHELFI,

monsieur H. HAFFAF et monsieur M. GEZZOURI pour avoir bien voulu consacrer une partie

de leurs temps à examiner et à évaluer ce travail.


Résumé iii

Résumé

ODMRP (On-Demand Multicast Routing Protocol) est un protocole de multicast très répandu pour les réseaux ad hoc sans fil. Les forces d'ODMRP sont sa simplicité, son taux élevé d’acheminement de paquet, et sa non-dépendance sur un protocole spécifique d'unicast. Cette thèse propose un protocole sans fil de multicast basé sur ODMRP nommé OODMRP (Optimized On-Demand Multicast Routing Protocol) qui minimise le nombre des nœuds relayeurs et optimise la consommation des ressources radio et des ressources énergétique dans le réseau. Avant de choisir un nœud relayeur, chaque nœud cherche dans son voisinage l'existence préalable d'un nœud relayeur. Dans le cas où ce nœud relayeur existe il selecte ce nœud comme un ascendant. Nos résultats de simulation montrent qu'OODMRP réduit considérablement le nombre de nœuds relayeurs et de paquets expédiés, comparé à l'ODMRP original. Mots clé: Multicast, Routage, Réseau Maillé Sans fil, ODMRP, OODMRP


Abstract iv

Abstract

ODMRP (On-Demand Multicast Routing Protocol) is a popular multicast protocol for wireless ad hoc networks. The strengths of ODMRP are simplicity, high packet delivery ratio, and non-dependency on a specific unicast protocol.

This thesis proposes an ODMRP-based wireless multicast protocol named OODMRP (Optimized On-Demand Multicast Routing Protocol) that relies on less forwarding nodes and optimizes resource consumption in the network.

Indeed, before selecting a forwarding node, each node searches in its neighborhood the existence of a forwarding node. In this case, it selects this node as an ascending one.

Our simulation results show that OODMRP reduces dramatically the number of forwarding nodes and forwarded packets, compared to original ODMRP.

Key words: Multicast, Routing, Wireless Mesh Network, ODMRP, OODMRP


Table des matières v

Table des matières

Remerciements………………………………………………………………. ii

Résumé……………………………………………………………………….. iii

Abstract……………………………………………………………………….. iv

Table des matières……………………………………………………………. v

Liste des figures……………………………………………………………… viii

Liste des tableaux…………………………………………………………….. x

Liste des abréviations………………………………………………………… xi

Introduction générale………………………………………………………… 14

Chapitre I : Les réseaux sans fil………………………………………….…

16

I.1 Introduction…………………………………………………………………….......... 16 I.2 Les réseaux sans fil ……….…………………………………………………........... 17 I.2.1 La fiabilité de la communication sans fil ………………….…….…….…… 18 I.2.2 Les classes des réseaux mobiles……………….…………………………….. 18 I.2.2.1 Les réseaux avec infrastructure (cellulaires)……….........................

I.2.2.2 Les réseaux sans infrastructure (AD HOC)………….…………….…18 19

I.2.3 Les réseaux maillés sans fil (Wireless Mesh Network -WMN)……………. 22 I.2.3.1 Architecture des réseaux maillés sans fil………….………………….

I.2.3.2 Topologies des réseaux maillés sans fil……………………….………I.2.3.3 Caractéristiques des réseaux maillés sans fil…………………..…….I.2.3.4 Les Scénarios d'application………………………...…………………I.2.3.5 Problématique et défis dans WMN………………………………..…..

24 25 26 27 30

I.3 Conclusion……………………………………………………………………………

32

Chapitre II : Le Routage Multicast………………………………………… 33

II.1 Introduction………………………………………………………………………….

33 II.2 Le multicast ………………………………………………………………………… 34 II.2.1 Groupes de Multicast………………………….……………………………. 35 II.2.2 Adressage multicast ……………….………………………………………. 35 II.3 Protocole de gestion de groupe d'Internet (IGMP)…………………………………. 36 II.4 Protocoles de routage multicast…………………………………………………..… 38 II.4.1 Définition du routage…………………………………................................ 38 II.4.2 Classification des protocoles de routage …………………………………... 38


Table des matières vi

II.4.2.1 Les Protocoles de Routage Proactifs………………………………… 39 II.4.2.2 Les Protocoles de Routage Réactifs (à la demande)……………….. 40 II.4.2.3 Les protocoles de routages Hybrides……………………………..… 41 II.4.2.4 Avantages et inconvénients des protocoles de routages proactifs et

réactifs………………………………………………………………

41 II.4.3 Concepts de base pour le routage multicast……………………………..…. 41 II.4.4 Etude protocoles de routage multicast en général..………………………… 42 II.4.4.1 Le protocole PIM (Protocol Independent Multicast)…………..…... 43 II.4.4.2 Le protocole DVMRP………………………….……….………….. 46 II.4.5 Synthèse……………………………………………….……………….…… 48 II.5 Conclusion……………………………………………………………………….….

49

Chapitre III : Protocoles de routage multicast dans les réseaux...……….. 50

III.1 Introduction ………………………………………………………….……. .……… 50 III.2 Étude comparative des architectures de routage multicast dans les sans fil..…….. 51 III.2.1 Caractéristiques des architectures de type arbre…………….…………….. 51 III.2.2 Caractéristiques des architectures de type maille……………..…….……... 52 III.3 Les protocoles de routage multicast dans les réseaux sans fil…………................. 53 III.3.1 Présentation du protocole MOLSR……………………………….……….. 53 III.3.2 Présentation du protocole MAODV…………………………..................... 56 III.3.3 Présentation du protocole CAMP…...…………………………………….. 59 III.3.4 Synthèse…………………………………………………………………… 60 III.4 Des nouveaux protocoles de routage multicast pour les réseaux maillés sans fil… 61 III.4.1 Le protocole GAMP (gateway associated multicast protocol)……………. 61 III.4.2 Algorithmes de routage multicast pour les WMNs multi canal…………….. 63 III.4.2.1 LCA (Level Channel Assignment).……………………………..…. 63 III.4.2.2 MCM (Multi-Channel Multicast)...……………………………..… 64 III.5 Conclusion…………………………………………………………………………..

66

Chapitre IV : Conception…………………………………………………..... 67

IV.1 Introduction……………………………………………..………………………….

67 IV.2 Problématique du routage dans les réseaux sans fil ………………………………. 68 IV.3 Présentation du protocole ODMRP………………………………………………… 69 IV.3.1 Principe de fonctionnement………………………………………………… 69 IV.3.2 Format des paquets ODMRP…………………………………………..….. 70 IV.3.3 Structures de données du protocole………….……………………………. 71 IV.3.4 Inconvénient majeure d'ODMRP……………..…………………………… 72 IV.4 Principe de fonctionnement d’OODMRP………………………………………….. 72 IV.5 Différence entre ODMRP et OODMRP………………………………………….... 76 IV.5.1 Fonctionnement d’ODMRP……………………………………………….. 76 IV.5.2 Fonctionnement d’OODMRP…………………….……………………….. 77 IV.6 Consommation d’énergie ……….………………...……………….......................... 78 IV.7 Conclusion………………………………………………..…………………………

80

Chapitre V : Simulations et résultats………………………………………... 81

V.1 Introduction…………………………………………………………………………..

81 V.2 Description de la simulation……………………………………….……………….. 82


Table des matières vii

V.3 Description du simulateur NS2……………………………………………………… 82 V.4 Implémentation d’ODMRP sous ns2………………………………………………. 83 V.4.1 L’agent ODMRP ………………………………………………….……….. 84 V.4.2 L'en-tête du paquet ODMRP ……………………………………….……… 84 V.5 Résultats de la simulation…………………………………………………….……. 85 V.5.1 Un seul récepteur…………………………………………….……………. 86 V.5.2 Plusieurs récepteurs……………………………………………………….. 86 V.6 Conclusion…………………………………………………………………………. 92 Conclusion générale et perspectives…………………………………………

93

Bibliographie…………………………………………………………………. 95

Annexe A : Exemple de script TCL………………………………………… 97

Annexe B : Exemple de script AWK………………………………………… 107


Liste des figures viii

Liste des figures I.1 : Réseau cellulaire (GSM)…………………………………………………………... 19 I.2 : Réseau Ad Hoc ………………………………………………………………….… 20 I.3 : Le changement de la topologie des réseaux Ad Hoc ……………………………… 20 I.4 : Applications des réseaux mobiles Ad Hoc ………………………………………… 21 I.5 : Le nœud caché……………………………………………………………………... 22 I.6 : Réseau maillé sans fil..…………………………………………………………...... 23 I.7 : WMN Infrastructure/backbone ………………………............................................ 24 I.8 : WMN Client ……………………………..………………………………………... 25 I.9 : WMN Hybride ……………………………………………………………..….….. 25 I.10 : Topologies des WMNs ……………………………………………..……….…….. 26 I.11 : WMN pour un réseau domestique…………………………………………….…... 28 I.12 : WMNs pour les réseaux communautaires………………………………………….. 28 I.13 : WMN pour un réseau d’entreprise…………………………………….…………… 29 I.14 : WMN pout les réseaux de zone métropolitaine……………………………………. 29 I.15 : WMN pour un système de transport …………………………………..…………… 30

II.1 : Avantage du multicast ………………………………………………….………….. 35 II.2 : La classe D……………………………………………………………………….... 35 II.3 : Classes des protocoles de routage……………………………………….………… 39 II.4 : Le mécanisme d'inondation…………………………………………………….….. 42 II.5 : Construction d’arbre de diffusion………………………………………………..... 43 II.6 : Le message d’enregistrement ……………………………………………………... 44 II.7 : Join message……………………………………………………………………..... 44 II.8 : Arbre partagée par plusieurs sources …………………………………………..…. 44 II.9 : Construction d’un meilleur chemin ……………………………………...………… 45 II.10 : Principe du protocole PIM-DM………………………………………………….... 46 II.11 : Reverse Path Forwarding (RPF)…………………………………………….…..… 47 II.12 : Echange des tables de routage …………………………………………………..... 47 II.13 : Poison Reverse ………………………………………………………………….… 48

III.1 : Architecture du réseau Ad hoc mobile en mode arbre……………………............ 51 III.2 : Architecture de réseau Ad hoc mobile en mode maille…………………………… 52 III.3 : Mécanisme de construction de l’arbre multicast……………………………….… 55 III.4 : Arbre partagé..…………………………………………………………………….. 57 III.5 : Ruptures de lien ………………………………………………………………….… 59 III.6 : Enregistrement des clients ……………………………………………………….… 62 III.7 : Équilibrage de charge …………............................................................................... 62 III.8 : Construction de l’arbre multicast …………………………………………………. 63 III.9 : Allocation des canaux …………………………………………………………….. 64 III.10 : Allocation ascendante du canal …………………………..……………………….. 65

IV.1 : Fonctionnement d’ODMRP……………………………………………………...... 70 IV.2 : Format du paquet ODMRP Join Query ……………………………………………… 70 IV.3 : Format du paquet ODMRP Join Reply ……………………………………………… 70 IV.4 : Format du paquet OODMRP Join Query ……………………………………………. 76


Liste des figures ix

IV.5 : Format du paquet OODMRP Session Exist ………………………………………. 76 IV.6 : Le fonctionnement d’ODMRP (R1)………………………………………………. 77 IV.7 : Le fonctionnement d’ODMRP (R2)………………………………………………… 77 IV.8 : Le fonctionnement d’OODMRP (R1)…………………………………………….. 77 IV.9 : Le fonctionnement d’OODMRP (R2)…………………………………………….. 78

V.1 : Vue simplifier de l’interaction entre les classes………………………………….. 84 V.2 : Le nombre de nœuds relayeurs pour un seul récepteur………………………... 86 V.3 : Le nombre de paquets transmis pour un seul récepteur………………………….. 86 V.4 : Le nombre de nœud relayeurs dans le cas de plusieurs récepteurs……………. 87 V.5 : Le nombre de paquets transmis dans le cas plusieurs récepteurs……………..…. 87 V.6 : Le délai moyen……………………………………………………………………. 88 V.7 : Le délai moyen avec 2 sources……………………………………………………. 88 V.8 : Le délai moyen avec 2 sources (intervalle de transmission = 0.25)……………… 89 V.9 : Le délai moyen avec 2 sources (intervalle de transmission = 0.05)………………… 89 V.10 : Energie totale ……………………………………………………………………… 90 V.11 : Energie moyenne…………………………………………………………………….. 90 V.12 : Écart type……………………………………….………………………………….. 91 V.13 : La perte moyenne des paquets…………………………………………………….. 91 V.14 : Le débit moyen………………………………………………………………….…. 91

A.1 : Exemple1 de script TCL…………………………………………………………. 97 A.2 : Exemple2 de script AWK………………………………………………………… 107


Liste des tableaux x

Liste des tableaux

I.1 : Caractéristiques des normes principales …………………………………….…... 17

II.1 : Caractéristiques des protocoles…………………………………………...……... 48

III.1 : Tableau comparatif des architectures de réseaux (Arbre, Maille)………...…….. 53 III.2 : Comparaison de différents protocoles de multicast……………………………... 60

V.1 : Un sommaire des paramètres de simulation ………………………………......... 85


Liste des abréviations xi

Liste des abréviations

ODMRP On-Demand Multicast Routing Protocol OODMRP Optimized On-Demand Multicast Routing Protocol

IEEE Institute of Electric and Electronic Engineers WMN Wireless Mesh Network WLAN Wireless Local Area Network

PDA Personal Digital Assistant WIFI Wireless Fidelity

SB Stations de Base UM Unité Mobile

GSM Global System Mobil MANET Mobile Ad hoc Network

QoS Qualité de Service WMR Wireless Mesh Router P2P Peer to Peer DSL Digital Subscriber Line MAN Metropolitan area network MAC Medium Access control

IP Internet Protocol LAN Local Area Network

DVMRP Distance Vector Multicast Routing Protocol PIM Protocol Independent Multicast

IGMP Internet group management Protocol MQ Membership Query MR Membership Report LG Leave Group

OSPF Open Shoretest Path First DBF Distributed. Bellman-Ford RPF Reverse Path Forwarding RP Rendez-vous Point DM Dense Mode SM Sparse Mode

MAODV Multicast Ad hoc On-Demand Distance-Vector Routing Pro AMRIS Ad hoc Multicast Routing protocol Increasing id-numberS CAMP Core Assisted Mesh Protocol

MOLSR Multicast Optimized Link State


Liste des abréviations xii

OLSR Optimized Link State MPR Multi-Points Relays

MC-Claim Multicast_Claim AODV Ad hoc On-Demand Distance-Vector Routing Protocol REQ Request

MACT Multicast Activation REP Reply TTL Time To Live ACK Acknowledgment

GAMP Gateway Associated Multicast Protocol GRDR Gateway Route Discovery Request GRDP Gateway Route Discovery Reply GRR Gateway Register Request GRP Gateway Reply reply GHR Eway Handover Request MRQ Multicast Route request MRP Multicast Route reply MSQ Multicast Source Request MSP Multicast Source reply LCA Level Channel Assignment MCM Multi-Channel Multicast

FG_FLAG Forwarding Group Flag LRU Least Recently Used FIFO First In First Out http Hyprtext Transfer Protocol TCP Transport Control Protocol TCL Tool Command Language AWK Alfred V. Aho Peter J. Weinberger Brian W. Kernighan.


Introduction générale

14


L’évolution rapide des technologies de télécommunication sans fil, a permis le traitement de l’information à l’aide de terminaux mobiles. Ces terminaux ont des caractéristiques particulières (puissance de calcul, mémoire, énergie…) et accèdent au réseau à travers une interface de communication sans fil. Malgré l’émergence de plusieurs applications dans les réseaux sans fil qui nécessitent des communications multicast, tel que la visioconférence, le travail de collaboration, et les jeux distribués, le multicast dans les réseaux sans fil demeure toujours un sujet de recherche où de nombreuses problématiques restent à résoudre. Le multicast est une technologie clé qui fournit une communication efficace entre les nœuds d’un réseau et dont le but est d’acheminer le même flux de données à plusieurs récepteurs. Ce type de communication est largement utilisé pour les applications temps réel. Actuellement, les protocoles de routage des réseaux fixes ne sont pas appropriés aux réseaux sans fil et de nouveaux protocoles pouvant s’adapter aux caractéristiques particulières (la bande passante, l’énergie, temps de traitement) et aux diverses contraintes des réseaux sans fil sont nécessaires. De nombreuses approches ont été explorées et analysées dans le cadre du routage unicast. En revanche, peu de travaux se sont attelés à la problématique du routage multicast et plus particulièrement dans la nouvelle génération des réseaux sans fil : les réseaux maillés sans fil. Une nouvelle génération de réseaux sans fil a vue le jour, appelés les réseaux maillés sans fil (Wireless Mesh Network -WMN). Le succès des WMNs réside en leur capacité à couvrir de larges zones géographiques à moindre coût avec de meilleures performances que les réseaux ad hoc traditionnels. Un réseau maillé sans fil fournit un accès aux différents réseaux tel que Internet, capteur, cellulaire, IEEE 802.11, IEEE 802.15et IEEE 802.16, et prend en charge une large variété d’applications temps réel (ex. visioconférence, voix sur IP, vidéo à la demande…). Les nœuds routeurs sont généralement stationnaires ou avec un minimum de mobilité. La gestion d'acheminement de données ou le routage, consiste à assurer une stratégie qui garantit, à n'importe quel moment, la connexion entre n'importe quelle paire de nœuds appartenant au réseau. La stratégie de routage doit prendre en considération les caractéristiques du réseau sans fil (bande passante, nombre de liens, ressources du réseau…etc.). En outre, la méthode adoptée dans le routage, doit offrir le meilleur acheminement des données en respect des différentes contraintes des réseaux sans fil.



15

En conséquence, une nouvelle approche de routage s’avère nécessaire à travers une nouvelle architecture décentralisée qui aura comme but de réduire la charge du réseau et faciliter la gestion du routage en diminuant la consommation de ressources du réseau. Ce travail entre dans le cadre de l'étude du problème de routage multicast dans les réseaux maillés sans fil. Notre étude fournit principalement une étude synthétique des travaux de recherche qui ont été fait, et qui se font à l'heure actuelle, dans le but de résoudre le problème d'acheminement de données entre les nœuds du réseau. En particulier, nous exposons les défis que pose le multicast dans les réseaux sans fil. Notre contribution principale dans ce travail est l’extension et l’enrichissement d’un des protocoles de communication multicast dédié aux réseaux sans fil les plus utilisé actuellement. Nous répondons aux exigences de ce mode de réseaux en assurant un routage de données avec une intervention d’un nombre minimal de nœuds intermédiaires. Le présent mémoire est organisé en cinq chapitres : Le premier chapitre présente les réseaux sans fil en générale et ses deux catégories “avec et sans infrastructure”, afin d’en comprendre le principe de fonctionnement, les caractéristiques et les facteurs qui influencent la conception de ces réseaux. La deuxième partie du chapitre est consacrée à la description du réseau maillé sans fil (WMN), sa topologie, ses propres caractéristiques et avantages par rapport aux autres réseaux sans fil. Le deuxième chapitre se focalise sur le routage multicast en général : les concepts de base, la notion de groupe de multicast, adressage multicast, le protocole de gestion des adhésions ainsi que les protocoles de routage multicast en générale. Le troisième chapitre est consacré à la description des protocoles de routage multicast dans les réseaux sans fil et leur principe de fonctionnement. La deuxième partie du chapitre, se focalise sur le routage multicast dans les réseaux maillés sans fil, nous allons présenter certains travaux de recherche réalisés dans ce domaine. Le quatrième chapitre présente le cœur de notre contribution en détaillant dans un premier temps le principe de fonctionnement du protocole de routage multicast ODMRP. Nous décrivons par la suite le principe de notre protocole OODMRP qui représente une version optimisée d’ODMRP. Le cinquième chapitre présente le processus d’expérimentation à travers des simulations (sous le simulateur NS2) et des résultats qui démontrent les performances de notre nouveau protocole par rapport à la version originale. Finalement, nous terminons se mémoire par une brève conclusion qui résume notre travail de recherche et quelques perspectives.


Chapitre I: Les réseaux sans fil

16

Chapitre I

Les réseaux sans fil

I.1 Introduction

Les environnements mobiles offrent aujourd'hui une grande flexibilité d'emploi. En particulier, ils permettent la mise en réseau des sites dont le câblage serait trop onéreux à réaliser dans sa totalité, voire même impossible.

Pratiquement inconnu, il y a encore quelques années, les réseaux sans fil (Wireless LAN ou WLAN ou IEEE 802.11), sont, aujourd’hui, omniprésents dans notre société. Utilisant des ondes radio, les WLAN existent pourtant depuis des années, mais l’augmentation de la bande passante et la baisse des coûts a fait exploser leur croissance [1].

Les réseaux sans fil offrent aujourd'hui de nouvelles perspectives dans le domaine des télécommunications. C’est des systèmes de transmission des données, conçus pour assurer une liaison indépendante de l'emplacement des périphériques informatiques qui composent le réseau. Les réseaux sans fil sont principalement employés lorsqu'il s'agit d'interconnecter des utilisateurs nomades, munis de terminaux mobiles, entre eux. Ce système ne pose aucune restriction sur la localisation des usagers. Il utilise des ondes radio plutôt qu'une infrastructure câblée pour communiquer. Ce nouveau mode de communication engendre des nouvelles caractéristiques, propres à l’environnement mobile : des déconnexions fréquentes, un débit de communication et des ressources modestes, et des sources d’énergie limitées.



17

I.2 Les réseaux sans fil

Qu'est-ce qu'un réseau sans fil ?

Un réseau sans fil (wireless network) est, comme son nom l'indique, un réseau dans lequel au moins deux terminaux (ordinateur portable, PDA, etc.) peuvent communiquer sans liaison filaire [2]. Un réseau sans fil est un ensemble d’appareils connectés entre eux et qui peuvent s’envoyer et recevoir des données sans qu’aucune connexion « filaire » physique reliant ces différents composants entre eux ne soit nécessaire.

Grâce aux réseaux sans fil, un utilisateur a la possibilité de rester connecté tout en se déplaçant dans un périmètre géographique plus ou moins étendu, c'est la raison pour laquelle on entend parfois parler de mobilité.

Un environnement mobile est un système composé de sites mobiles et qui permet à ses utilisateurs d'accéder à l'information indépendamment de leur position géographique.

Les réseaux sans fil permettent de relier très facilement des équipements distants d'une dizaine de mètres à quelques kilomètres. De plus l'installation de tels réseaux ne demande pas de lourds aménagements des infrastructures existantes comme c'est le cas avec les réseaux filaires (creusement de tranchées pour acheminer les câbles, équipements des bâtiments en câblage, goulottes et connecteurs), ce qui a valu un développement rapide de ce type de technologies.

La norme la plus utilisée actuellement pour les réseaux sans fil est la norme IEEE 802.11, mieux connue sous le nom de Wi-Fi. Les caractéristiques des normes principales sont résumées dans le tableau I.1:

La norme Fréquence Débit maximal IEEE 802.11a Bande 5 GHz 54 Mbits/s IEEE 802.11b Bande 2,4 GHz 11 Mbits/s IEEE 802.11g Bande 2.4 GHz 54 Mbits/s

Tab. I.1 Caractéristiques des normes principales

Un réseau local sans fil véhicule les informations soit par infrarouge, soit par onde radio (utilisant généralement la bande de fréquence 2.4 GHz). La transmission par onde radio est la méthode la plus répandue en raison de sa plus large couverture géographique et de son débit plus important.



18

Les réseaux sans fils constituent avant tout une alternative aux réseaux câblés. Leur compatibilité avec les réseaux câblés permet également de les y ajouter comme extensions.

I.2.1 La fiabilité de la communication sans fil La communication sans fil est moins fiable que la communication dans les réseaux filaires. La propagation du signal subit des perturbations (erreurs de transfert, microcoupure, timeout…) dues à l'environnement, qui altèrent l'information transférée et engendrent un accroissement du délai de transit de messages à cause de l'augmentation du nombre de retransmissions. La connexion peut aussi être rompue ou altérée par la mobilité des sites. Un usager peut sortir de la zone de réception ou entrer dans une zone de haute interférence. Le nombre d'unités mobiles dans une même cellule, par exemple dans le cas des réseaux cellulaires lors d'un rassemblement populaire, peut entraîner une surcharge du réseau.

L'une des limites aussi de la communication sans fil vient de la relative faiblesse de la bande passante des technologies utilisées [3].

I.2.2 Les classes des réseaux mobiles

Les réseaux mobiles ou sans fil, peuvent être classés en deux grandes classes : • Réseau sans fil avec infrastructure de communication (modèle cellulaire). • Réseau sans fil sans infrastructure (modèle ad hoc). I.2.2.1 Les réseaux avec infrastructure (cellulaires) Dans ce mode, le réseau sans fil est composé de deux ensembles d'entités distinctes : 1- Les sites fixes d'un réseau de communication filaire classique (wired network). 2- Les sites mobiles (wireless network) [3]. Certains sites fixes, appelés stations de base (SB), sont munis d'une interface de communication sans fil pour la communication directe avec les sites ou les unités mobiles (UM) localisés dans une zone géographique limitée, appelée cellule. Comme le montre la figure suivante I.1:



19

Fig. I.1 Réseau cellulaire (GSM)

A chaque station de base correspond une cellule à partir de laquelle des unités mobiles peuvent émettre et recevoir des messages. Alors que les sites fixes sont interconnectés entre eux à travers un réseau de communication filaire. Une unité mobile ne peut être, à un instant donné, directement connectée qu'à une seule station de base. Elle peut communiquer avec les autres sites à travers la station à laquelle elle est directement rattachée. I.2.2.2 Les réseaux sans infrastructure (AD HOC) a) Définition d’un réseau ad hoc Dans le modèle de réseau sans infrastructure préexistante l'entité site fixe n’existe pas, tous les sites du réseau sont mobiles et communiquent entre eux d'une manière directe en utilisant leurs interfaces de communication sans fil [3]. Un réseau mobile Ad Hoc (fig. I.2), appelé généralement MANET (Mobile Ad hoc Network), consiste en une grande population, relativement dense, d'unités mobiles qui se déplacent dans un territoire quelconque. Le seul moyen de communication est l'utilisation «des ondes radio» qui se propagent entre les différents nœuds mobiles, sans l'aide d'une infrastructure préexistante ou d’une administration centralisée.



20

Fig. I.2 Réseau Ad Hoc L'absence de l'infrastructure ou du réseau filaire composé des stations de base, oblige les unités mobiles à se comporter comme des routeurs qui participent à la découverte et la maintenance des chemins pour les autres hôtes du réseau. Le concept des réseaux mobiles ad hoc a pour objectif d'étendre les notions de la mobilité à toutes les composantes de l'environnement. Ici, contrairement aux réseaux basés sur la communication cellulaire, aucune administration centralisée n'est disponible, ce sont les hôtes mobiles eux-mêmes qui forment, d'une manière ad hoc, une infrastructure du réseau. La topologie du réseau peut changer à tout moment, elle est donc dynamique et imprévisible ce qui fait que la déconnexion des unités soit très fréquente (fig. I.3).

Fig. I.3 Le changement de la topologie des réseaux Ad Hoc Aucune supposition ou limitation n'est faite sur la taille du réseau ad hoc, le réseau peut contenir des centaines ou des milliers d'unités mobiles.



21

b) Les applications des réseaux mobiles Ad Hoc Les applications ayant recours aux réseaux ad hoc couvrent un très large spectre, telles que : • les applications militaires ; • l’enseignement à distance ; • le web rapide ; • les autres applications stratégiques comme les opérations de secours (incendies, tremblement

de terre...). Ces applications sont utilisés dans plusieurs contextes spécifiques et permettent de : • réaliser des réseaux temporaires, ou à mettre en place très rapidement (conférence, réunion) ; • permettre d'éviter de gros travaux de câblages dans des endroits où c'est difficile ou même

prohibé ; • donner la possibilité de transmettre des données dans le cas d'applications mobiles (capteurs

d'entreprises...). D'une façon générale, les réseaux ad hoc sont utilisés dans toute application où le déploiement d'une infrastructure réseau filaire est trop contraignant, soit parce qu’il est difficile le mettre en place, soit parce que la durée d'exploitation du réseau ne justifie pas de câblage à demeure.

Fig. I.4 Applications des réseaux mobiles Ad Hoc c) Les caractéristiques des réseaux Ad Hoc Les réseaux sans fil ad hoc se caractérisent principalement par [3]: • bande passante limitée : une des caractéristiques primordiales des réseaux basés sur la communication sans fil est l'utilisation d'un médium de communication partagé (ondes radio). Ce partage fait que la bande passante réservée à un hôte soit modeste. • contraintes d'énergie : les hôtes mobiles sont alimentés par des sources d'énergie autonomes comme les batteries. • sécurité physique limitée : les réseaux mobiles ad hoc sont plus touchés par le paramètre de sécurité que les réseaux filaires classiques.



22

• erreur de transmission : les erreurs de transmission radio sont plus fréquentes que dans les réseaux filaires. • interférences : les liens radios ne sont pas isolés, deux transmissions simultanées sur une même fréquence ou utilisant des fréquences proches peuvent interférer. • absence d'infrastructure : les réseaux ad hoc se distinguent des autres réseaux mobiles par la propriété d'absence d'infrastructure préexistante et de tout type d'administration centralisée. Les hôtes mobiles sont responsables d'établir et de maintenir la connectivité du réseau d'une manière continue. • topologie dynamique : les unités mobiles du réseau se déplacent d'une façon libre et arbitraire. Par conséquent, la topologie du réseau peut changer à des instants imprévisibles, d'une manière rapide et aléatoire. • nœuds cachés : ce phénomène est très particulier à l’environnement sans fil. Un exemple est illustré par fig. I.5. Dans cet exemple, les nœuds B et C ne s’entendent pas, à cause d’un obstacle qui empêche la propagation des ondes. Les mécanismes d’accès au canal vont permettre alors à ces nœuds de commencer leurs émissions simultanément provoquant ainsi des collisions au niveau du nœud A.

Fig. I.5 Le nœud caché

Les atouts de l’ad hoc

La robustesse d’un réseau de ce type est en théorie beaucoup plus grande, puisque pour que le réseau s’effondre, il faudrait qu’un très grand nombre d’éléments qui le compose cessent de fonctionner. Et si l’un des éléments du réseau ne fonctionne plus, ceci ne change rien ou presque pour les autres éléments : de nouvelles routes sont empruntées par les informations, comme si l’élément manquant n’avait jamais existé.

I.2.3 Les réseaux maillés sans fil (Wireless Mesh Network -WMN)

La technologie mesh (terme anglais signifiant ‘maille’ ou ‘filet’), permet aux équipements sans fil de se connecter de proche en proche, d’une façon instantanée, sans hiérarchie centrale, formant ainsi une structure en forme de filet d’où son nom mesh. Cela permet



23

d’éviter d’avoir des points sensibles, qui en cas de panne, coupent la connexion d’une partie du réseau. Si un hôte est hors service, ses voisins passeront par une autre route. L’implémentation d’une telle topologie est appelée réseau maillé.

Les réseaux maillés sans fil (WMN : Wireless Mesh Networks) constituent une technologie émergente, principalement présentée comme un moyen de construire des réseaux de communauté (campus, entreprises, villes) à bas coût. Ce type de réseaux présente plusieurs défis notamment le routage des données avec qualité de service (QoS). La technologie mesh permet aussi la connexion et la déconnexion de nouveaux relais sans recourir à la configuration manuelle et fastidieuse du réseau. Un WMN est capable de s’organiser et de s’auto-configurer dynamiquement. Les réseaux maillés sans fil définissent deux types de nœuds, les routeurs sans fil maillés et les clients maillés [4].

Les routeurs sont statiques ou avec un minimum de mobilité et forme le WMN ‘backbone/infrastructure’ et fournirent l’accès aux clients. Les communications entre deux nœuds peuvent être supportées par plusieurs nœuds intermédiaires (appelés Wireless Mesh Router - WMR) dont le rôle est de retransmettre les informations.

Fig. I.6 Réseau maillé sans fil

Les atouts des réseaux maillés

La topologie maillée réduit le câblage, tout en fournissant de manière inhérente une forte tolérance aux pannes et une grande évolutivité. Les réseaux maillés sans fil promettent de repousser les limites physiques des réseaux Wifi, tout en apportant une souplesse inégalée.

L’architecture mesh a ainsi pu montrer qu’elle apportait des améliorations notables au WiFi (fiabilité, couverture). A l'inverse des réseaux Wifi classiques, nul besoin d'un réseau filaire reliant les points d'accès, il suffira de relier un ou deux nœuds du réseau sans fil maillé à l'accès Internet. Avec, à la clé, deux avantages immédiats : des coûts de déploiement réduits et une architecture plus flexible. Mais, surtout, de cette architecture résulte une forte tolérance aux pannes, en raison de la redondance inhérente à la topologie maillée : les communications peuvent être déroutées vers un autre chemin si l'un des éléments du réseau tombe en panne.



24

I.2.3.1 Architecture des réseaux maillés sans fil

Les réseaux WMN adoptent le principe d’un réseau sans fil basé sur la transmission multi-sauts. Leur architecture à deux niveaux concentre le routage sur une partie sans fil stable (le premier niveau - backbone), composée de WMRs qui offrent une connectivité à des clients mobiles (le deuxième niveau).

L’architecture peut être classifiée en 3 groupes selon la fonctionnalité des nœuds [5]:

a) WMN Infrastructure/Backbone

Ce type d’architecture inclut des routeurs maillés qui forment une infrastructure pour les clients connectés à eux (fig. I.7), où les liens discontinus représentent les liens sans fil et les liens pleins représentent les liens filaires. Avec la fonction ‘gateway’ les routeurs maillés peuvent se connecter à Internet.

L’intégration de WMN avec les autres réseaux tels que Internet, cellulaire, IEEE 802.11, IEEE 802.15, IEEE 802.16, réseau de capteurs, etc., peut être accompli à travers les fonctions de gateway et bridging dans les routeurs. Des clients conventionnels avec une interface Ethernet peuvent être connectés aux routeurs maillés via des liens Ethernet. Pour des clients conventionnels avec les mêmes technologies radio que les routeurs maillés, ils peuvent communiquer directement avec les routeurs maillés.

Fig. I.7 WMN Infrastructure/backbone



25

b) WMN Client

Ce type d’architecture est composé des nœuds clients et fournit un réseau P2P. Dans ce type, un paquet recherche la destination par de multiples sauts entre les nœuds.

Fig. I.8 WMN Client

c) WMN Hybride

Ce type d’architecture est une combinaison des deux types précédents (fig. I.9).

Fig. I.9 WMN Hybride

I.2.3.2 Topologies des réseaux maillés sans fil

L’architecture de réseau dite mesh est connue depuis longtemps : il s’agit d’une topologie où chaque nœud du réseau est relié à tous les autres (mesh total) ou à certains de ses voisins (mesh partiel), comme le montre la figure I.10.



26

Fig. I.10 Topologies des WMNs

I.2.3.3 Caractéristiques des réseaux maillés sans fil

Dans les réseaux maillés, l’administrateur déploie un grand nombre de points d’accès dont seulement une sous‐partie est connectée à Internet et constitue les passerelles du réseau. Ainsi, les autres points d’accès doivent relayer les paquets de leurs clients via leurs liaisons radio afin qu’ils atteignent une passerelle Internet. Les réseaux maillés apparaissent comme une approche prometteuse dans la réduction du coût où seuls quelques points d’accès sont reliés à une interface filaire, les autres servant à étendre la couverture à moindre coût. La gestion du réseau maillé est une manière de router les données, la voix et des instructions entre les nœuds. Elle tient compte des connections et de la reconfiguration continues autour des chemins coupés par “saut” du nœud au nœud jusqu'à ce que la destination soit atteinte. Un réseau maillé dont tous les nœuds sont connectés entre eux est un réseau entièrement connecté. Les réseaux maillés diffèrent d'autres réseaux parce que tous les éléments peuvent se connecter entre eux par l'intermédiaire des sauts multiples. Les réseaux maillés sont auto-curatif: le réseau peut toujours fonctionner même lorsqu'un nœud tombe en panne ou une mauvaise connexion. En conséquence, un réseau très fiable est formé. Les caractéristiques principales des WMNs sont expliquées comme suit [5]:

• réseau sans fil à saut multiple

L’objectif de développer les WMNs est de prolonger la couverture des réseaux sans fil courants. Un autre objectif des WMNs est d’assurer la connectivité entre les utilisateurs qui n’ont pas un lien directe à travers des sauts multiples.



27

• capacité d’auto-organisation et auto-formation Les WMNs augmentent la performance du réseau, grâce à l'architecture flexible du réseau, la facilité de déploiement et de configuration, la tolérance aux fautes, et la connectivité maillée (communication multipoint-à-multipoint). • compatibilité et interopérabilité avec les réseaux sans fil existants Un WMN est compatible avec les standards IEEE 802,11 dans le sens de supporter les clients maillés et les clients conventionnels Wi-Fi. De tels WMNs sont également interopérables avec d'autres réseaux sans fil tels que le WiMAX ou les réseaux cellulaires. • infrastructure/backbone sans fil Comme discuté avant, les WMNs se composent d'un ‘backbone’ sans fil avec des routeurs maillés. Un ‘backbone’ sans fil fournit une large couverture, connectivité, et robustesse dans le domaine sans fil. Cependant, la connectivité dans les réseaux ad hoc dépend des contributions individuelles des utilisateurs qui ne peuvent pas être fiables. • intégration Un WMN supporte les clients conventionnels qui utilisent les mêmes technologies radio que les routeurs maillés. Les WMNs permettent également l'intégration de divers réseaux existants tels que le WiFi, l’Internet, les réseaux cellulaires et les réseaux de capteurs par des fonctionnalités de gateway/bridge dans les routeurs maillés. Par conséquent, les utilisateurs dans un réseau accèdent à des services fournis dans les autres réseaux, à travers l'utilisation de l'infrastructure sans fil.

• interfaces radio multiples

Un routeur peut être équipé par de multiples radios pour améliorer les fonctionnalités d’accès et de routage, qui améliorent la capacité du réseau.

Les avantages des WMNs

Les avantages des réseaux maillés sans fil sont nombreux, tels que le faible coût, facilité d’installation, élimination du câblage, modèle économique simple, robustesse d’infrastructure.

I.2.3.4 Les Scénarios d'application

La recherche et développement des WMNs est impulsée par plusieurs applications qui démontrent clairement le marché prometteur alors qu'en même temps ces applications ne peuvent pas être directement supportées par d'autres réseaux sans fil tels que les réseaux



28

cellulaires, les réseaux ad hoc, les réseaux de capteurs sans fil, etc. Dans cette section, nous présentons certaines de ces applications [5]. Réseau domestique: la communication dans les réseaux à la maison peut être réalisée par la gestion de réseau maillé. Par conséquent, la communication entre ces nœuds devient beaucoup plus flexible et plus robuste aux défauts du réseau et aux coupures des liens, comme c’est illustré dans fig. I.11.

Fig. I.11 WMN pour un réseau domestique

Réseau communautaire : dans une communauté, l'architecture commune pour l'accès réseau est basée sur le câble relié à l'Interne. Ce type d'accès réseau a plusieurs inconvénients: • Même si l'information doit être partagée dans une communauté ou un voisinage, tout le

trafic doit traverser l’Internet. Ceci réduit de manière significative l'utilisation de ressource du réseau. WMNs atténuent les inconvénients ci-dessus par des connectivités flexibles maillés entre les maisons, comme montré dans fig. I.12.

Fig. I.12 WMNs pour les réseaux communautaires

Réseau d'entreprise : le modèle du réseau d'entreprise peut être appliqué à beaucoup d'autres scénarios des services publics et commerciaux tels que des aéroports, hôtels, centres commerciaux, etc.



29

Fig. I.13 WMN pour un réseau d’entreprise

Réseaux de zone métropolitaine: le déploiement des WMNs dans les zones métropolitaines apporte plusieurs avantages :

• la communication entre les nœuds dans WMN ne se base pas sur une infrastructure câblée. Comparé aux réseaux câblés, un MAN (Metropolitan Area Network) maillé sans fil est une alternative économique pour les réseaux à grande échelle, particulièrement dans des régions sous-développées.

• un MAN maillé sans fil couvre une zone potentiellement beaucoup plus grande qu'une maison, entreprise, bâtiment, ou les réseaux communautaires, comme représenté dans fig. I.14.

Fig. I.14 WMN pout les réseaux de zone métropolitaine



30

Systèmes de transport : la technologie du réseau maillé peut offrir un accès Internet dans des autobus et des trains.

Fig. I.15 WMN pour un système de transport

Systèmes de surveillance : comme la sécurité s'avère être un très grand souci, les systèmes de surveillance de sécurité deviennent une nécessité pour des bâtiments d'entreprise, des centres commerciaux, des grand magasins, etc. Afin de déployer de tels systèmes aux endroits nécessaires, les WMNs sont une solution beaucoup plus viable que les réseaux câblés pour relier tous les dispositifs.

I.2.3.5 Problématique et défis dans WMN La couche croisée (Cross-layer) Un réseau WMN a plusieurs caractéristiques différentes des autres réseaux sans fil. Pour améliorer les performances de tel réseau, il faut chercher à tirer profit de ses spécificités. Il existe plusieurs pistes de recherche dans les WMNs. La conception Cross-layer entre le routage et les protocoles de la couche MAC (2) est une piste intéressante de recherche. Auparavant, la recherche sur le protocole de routage a été concentrée seulement sur la fonctionnalité de la couche réseau (3). Cependant, il a été démontré que les performances d'un protocole de routage ne sont pas satisfaisantes dans ce cas. L’adoption de multiple métrique de performances de la couche 2 dans des protocoles de routage est un exemple. Cependant, l'interaction entre la couche MAC et le routage est étroite. Le fusionnement de certaines fonctions MAC et le routage est une approche prometteuse. Quand les nœuds sans fil maillés multi-radio ou multicanaux sont considérés, des nouveaux protocoles de routage sont nécessaires pour deux raisons. D'abord, le protocole de routage n'a pas besoin seulement de choisir un chemin intermédiaire entre les différents nœuds, il a besoins également de choisir le canal ou l’interface radio la plus approprié sur le chemin. En second lieu, la conception de Cross-layer devient une nécessité parce que le changement d'un chemin de routage implique le changement de canal ou de radio dans un nœud maillé. Sans considérer la conception de Cross-layer, le processus de changement peut être trop lent pour dégrader la performance de WMN.



31

Comment appliquer une solution innovatrice de canal unique à un système multi radio ou multi canal est un autre problème de recherche. La qualité de service La plupart des efforts existants de recherches dans la couche MAC se focalisent sur la capacité, le débit, et l'équité. Cependant, beaucoup d'applications ont besoin de prendre en charge la communication multimédia dans les WMNs. Ainsi, le développement des protocoles MAC avec de multiples métriques de QoS comme le délai, la perte de paquet est important pour les WMNs. Les métriques existantes incorporées aux protocoles de routage doivent être augmentées. D'ailleurs, comment intégrer de multiples métriques de performance dans un protocole de routage de sorte que la performance globale optimale soit réalisée est un défi. Le routage pour des applications multicast est une autre piste importante de recherche. Beaucoup d'applications de WMNs ont besoin des possibilités du multicast. Par exemple, dans une communauté, vidéo distribuée, etc. Les protocoles de routage existants traitent tous les nœuds du réseau de la même manière. Cependant, de telles solutions peuvent ne pas être efficaces pour les WMNs, parce que les routeurs maillés dans un backbone WMN et les clients maillés ont des différences significatives dans la contrainte d'énergie et la mobilité. Des protocoles de routage plus efficaces qui tiennent compte de ces différences sont désirés pour les WMNs. Allocation des canaux Dans les WMNs un routeur peut avoir plus d’une interface, qui peuvent être tuner aux différents canaux. Un processus d’allocation de canal est une piste de recherche intéressante pour améliorer les performances des WMNs.



32

I.3 Conclusion Ce chapitre a été axé sur le concept des environnements mobiles et l'utilisation de la technologie de communication sans fil. L'évolution rapide qu'a connu la technologie sans fil récemment, a permet l'apparition de nouveaux systèmes de communication qui offrent plus d'avantages par rapport aux systèmes classiques. Les nouveaux systèmes n'astreignent plus l'usager à une localisation fixe, mais lui permet une libre mobilité comme les réseaux ad hoc. Différent types de réseaux ont vu le jour, parmi eux, nous avons présenté les réseaux maillés sans fil qui ont un avenir prometteur grâce à leurs divers atouts tel que la connectivité, la couverture et par leur maillage, une forte tolérance aux pannes est garantie. La facilité d’installation et de configuration des réseaux WMNs a favorisé leur utilisation dans plusieurs domaines d’applications pour assurer une connectivité robuste à moindre coût. Le but de ce chapitre a été de donner un aperçu général sur cette technologie de communication sans fil qui ne cesse pas de croître.

Les environnements sans fil sont caractérisés par les déconnexions et les restrictions sur les ressources utilisées. Ces limitations transforment certains problèmes, ayant des solutions évidentes dans l'environnement classique, en des problèmes complexes et difficiles à résoudre. Parmi ces problèmes figure le problème de routage et particulièrement le routage multicast que nous allons discuter dans le chapitre suivant.


Chapitre II: Le Routage Multicast

33

Chapitre II

Le Routage Multicast

II.1 Introduction

Dans le réseau Internet actuel, des services tels que la télévision sur IP ou certains jeux nécessitent de transmettre simultanément une quantité importante de données à de nombreux récepteurs. Les méthodes de diffusion classiques des réseaux IP, le broadcast et l’unicast, ne sont pas efficaces du fait qu’elles imposent un flux par récepteur et donc une multiplication des données. C’est en 1991 que Steve Deering propose une technique appelée routage multicast. Cette technique consiste à confier au réseau la tâche de duplication des données.

Dans ce modèle de communication une source envoie un paquet de données en un seul exemplaire et c’est le réseau qui se charge de le dupliquer en autant de copies que de récepteurs déclarés [6].

Après une introduction globale plus approfondie du concept de routage multicast, nous étudions les techniques nécessaires à mettre en œuvre l’adressage multicast, le protocole de gestion des adhésions et ainsi que les protocoles de routage.



34

II.2 Le multicast Comme le terme indique, le multicast IP a été développé pour prendre en charge une communication efficace entre une source et de multiples destinations à distance [9]. Dans le multicast, un système communique avec un groupe d'autres systèmes. L’information est transmise à une seule adresse multicast et reçue par tout dispositif qui souhaite l’obtenir. Pourquoi le multicast est voulu/nécessaire ? Il y a trois types de communication entre les systèmes dans un réseau IP: • unicast : un système communique directement avec un autre système. • broadcast : un système communique avec tous les autres systèmes. • multicast : un système ici communique avec un groupe sélectionné d'autres systèmes. Les communications multicast désignent les communications un-à-plusieurs ou plusieurs-à-plusieurs. Dans les réseaux IP traditionnels, un paquet est typiquement envoyé par une source à une seule destination (unicast). Alternativement, le paquet peut être envoyé à tous les dispositifs sur le réseau (broadcast). De nombreuses applications professionnelles ou multimédia exigent un mécanisme de transmission multicast qui permet la communication entre les membres d’un groupe de nœuds. L'information est transmise à une seule adresse multicast et reçue par n'importe quel nœud qui souhaite obtenir une telle information. Le multicast est pilotée par les récepteurs, c’est eux qui indiquent leur intérêt pour certaines données. Les applications avec de multiples récepteurs Beaucoup d’applications transmettent les mêmes données en simultanée à plusieurs récepteurs, telles que : • distribution des données financières en temps réel ; • télévision numérique sur un réseau IP (IPTV) ; • radio d'Internet ; • visioconférence. Avantages du multicast Comme le montre la figure II.1, sans la prise en charge du multicast au niveau de la couche réseau, de multiples copies d’un même message sont envoyées sur un même lien [7]. Avec la prise en charge du multicast au niveau de la couche réseau on constate les avantage suivants :



35

• meilleur utilisation de la bande passante ; • moins de traitement sur les hôtes et les routeurs ; • les adresses des récepteurs ne sont pas nécessairement connues.

Fig. II.1 Avantage du multicast II.2.1 Groupes de Multicast L’ensemble des récepteurs d’une transmission multicast est appelé Groupe Multicast, chaque groupe multicast est identifié par une adresse multicast. Un utilisateur qui souhaite recevoir des transmissions multicast doit rejoindre le groupe multicast correspondant, et devenir ainsi un membre de ce groupe. Chaque nœud peut rejoindre et quitter un groupe multicast de manière dynamique. Quand un utilisateur rejoint un groupe, le réseau met en place les chemins de routage nécessaires pour que cet utilisateur puisse recevoir les données envoyées au groupe multicast. II.2.2 Adressage multicast Chaque groupe de récepteurs est identifié par une adresse multicast, la classe D des adresses IPv4 est utilisée pour le multicast, comme le montre la figure II.2. Ø Toutes les adresses des groupes multicast IP appartiennent à l’intervalle :

224.0.0.0 – 239.255.255.255

Fig. II.2 La classe D



36

Adresses réservées Parmi les adresses de le classe D, certaines sont réservées pour des fonctionnalités de routage multicast telles que : 224.0.0.1: toutes les machines du LAN 224.0.0.2: tous les routeurs du LAN 224.0.0.4: tous les routeurs DVMRP 224.0.0.13: tous les routeurs PIM Translation de l’adresse Multicast Pour passer de la couche réseau à la couche MAC, il faut traduire l’adresse multicast IP en adresse MAC. Les 3 octets de l’adresse multicast de niveau MAC sont en hexadécimal 01 00 5E auxquels on ajoute les 23 bits de l’adresse multicast. Résolution directe d’adresse La résolution d’adresse est réalisée comme suit [8] : • adresse multicast IP => adresse MAC de groupe

Par exemple : 224.1.2.3 ⇒ 01 00 5Ε 01 02 03 II.3 Protocole de gestion de groupe d'Internet (IGMP) / Enregistrement dynamique d’hôte IGMP (Internet group management Protocol) [7] est un protocole simple pour la prise en charge du multicast IP. Le protocole IGMP est un mécanisme qui informe le réseau qu’un récepteur est membre d'un groupe particulier. Dans un environnement multicast, l'information d'adhésion de groupe est échangée entre un récepteur et le routeur multicast le plus proche. IGMP est utilisé par des récepteurs pour joindre ou quitter un groupe multicast. Un hôte rejoint un groupe par l'envoi des messages IGMP à son routeur multicast local. Les routeurs multicast envoient périodiquement des requêtes pour découvrir quels groupes sont actifs ou inactifs sur un sous-réseau.



37

Les messages IGMP Plusieurs versions du protocole IGMP ont vu le jour, chaque version a ses propres messages : a) La version 1 : cette version comprend deux types de messages IGMP MQ (Membership Query) et MR (Membership Report). Un récepteur intéressé pour joindre un groupe multicast particulier génère un MR qui contient la référence à cette adresse multicast (groupe). Le routeur construit une entrée dans la table de transition et transmit les paquets multicast aux interfaces qui supportent des sous réseaux où résident les hôtes enregistrés. Le routeur envoie périodiquement un MQ IGMP pour vérifier qu’au moins un hôte sur le sous réseau est toujours intéressé à recevoir le trafic dirigé vers ce groupe. Quand il n'y a aucune réponse à trois MQs IGMP consécutifs, le routeur arrête le transfert du trafic destiné à ce groupe. b) La version 2 : cette version comprend les messages suivants: • MQ : il est générique (general MQ) ou spécifique (group-specific MQ). General MQ est envoyé par un routeur multicast pour apprendre l'état de réception, concernant tous les adresses multicast. Group-specific MQ est envoyé par un routeur multicast pour apprendre l'état de réception, concernant une seule adresse multicast. • LG (Leave Group) : envoyé par le récepteur au routeur local pour quitter un groupe. L'utilisation des LGs réduit le trafic sur les sous-réseaux, lors de la réception d’un message LG, le routeur génère une requête spécifique au groupe pour déterminer s'il reste des récepteurs sur ce sous-réseau. Un routeur peut également envoyer un MQ pour s’informer des groupes possédant des membres sur le réseau attaché (également connu comme general MQ) ou pour apprendre si un groupe particulier a encore des membres sur un réseau (group-specific MQ). c) La version 3 : elle ajoute un nouveau concept appelé le source filtering qui permet au récepteur de sélectionner ou d’exclure un ensemble spécifique de sources dans un groupe multicast.

Le source filtering permet à un récepteur de signaler au routeur les groupes qu’il veut joindre et de quel source(s) ce trafic est exclu. Cette information peut être utilisée par le protocole de routage multicast pour éviter de livrer des paquets multicast provenant de sources spécifiques à des sous-réseaux où il n'y a aucun récepteur intéressé. Les récepteurs signalent l'adhérence à un groupe multicast en deux modes:

• Le mode INCLURE: le récepteur annonce l'adhésion à un groupe et fournit une liste d'adresses IP (la liste INCLURE) dont il souhaite recevoir le trafic ;



38

• Le mode EXCLURE: le récepteur annonce l'adhésion à un groupe et fournit une liste d'adresses IP (la liste EXCLURE) desquelles il ne souhaite pas recevoir le trafic.

Les messages IGMP V3

• general query: pour apprendre l'état complet de réception multicast des interfaces voisines.

• group-specific query: est envoyé par un routeur multicast pour apprendre l'état de

réception, concernant une seule adresse multicast, des interfaces voisines.

• group-and-source-specific query: pour apprendre si n'importe quelle interface voisine désire la réception des paquets envoyés à une adresse multicast spécifique par la liste des sources indiquée.

En raison de sa complexité plus élevée, IGMPv3 n'est pas pris en charge universellement par tous les hôtes récepteurs. II.4 Protocoles de routage multicast II.4.1 Définition du routage Le routage est une méthode à travers laquelle on fait transiter une information donnée depuis un certain émetteur vers un destinataire bien précis. Le problème du routage ne se résume pas seulement à trouver un chemin entre les deux nœuds du réseau, mais encore à trouver un acheminement optimal et de qualité. Il s'agit de trouver l'investissement au moindre coût en capacité et réserve. L’objectif d’un protocole de routage multicast est de construire un arbre recouvrant entre tous les membres d’un groupe multicast. Autrement dit, il doit insérer un arbre de manière à ce que tous les membres du groupe soient traversés par l’arbre. II.4.2 Classification des protocoles de routage Le principal but de toute stratégie de routage est de mettre en œuvre une bonne gestion d’acheminement qui est robuste et efficace. Suivant la manière de création et de maintenance de routes lors de l'acheminement des données, les protocoles de routage peuvent être séparés en trois grandes classes (fig. II.3) [3]: les protocoles de routage proactifs, les protocoles de routage réactifs et les protocoles de routage hybrides. Les protocoles proactifs établissent les routes à l'avance en se basant sur l'échange périodique des tables de routage, alors que les protocoles réactifs cherchent les routes à la demande.



39

Fig. II.3 Classes des protocoles de routage

II.4.2.1 Les protocoles de routage proactifs Un protocole de routage est dit proactif si les procédures de création et de maintenance des routes, durant la transmission des paquets de données, sont contrôlées périodiquement. Cette maintenance reste toujours active même s’il n’y a pas de trafic circulant dans le réseau. Deux principales méthodes sont utilisées dans cette classe de protocoles proactifs : la méthode “Etat des Liens” (Link State) et la méthode “Vecteur de Distance” (Distance Vector). Les deux méthodes exigent une mise à jour périodique des données de routage qui doit être diffusée par les différents nœuds de routage du réseau. Les algorithmes de routage basés sur ces deux méthodes [3], utilisent la même technique qui est la technique des plus courts chemins, et permettent à un nœud donné, de trouver le prochain nœud pour atteindre la destination en utilisant le trajet le plus court existant dans le réseau. Généralement le calcul du plus court chemin entre deux stations est basé sur le nombre de nœuds (on dit aussi le nombre de sauts) que comportent les différents chemins qui existent entre les deux stations. a) Etat des liens (Link Stat) Dans cette méthode, chaque nœud garde une vision de toute la topologie du réseau et ce par l’intermédiaire des requêtes périodiques portant sur l’état des liaisons avec les nœuds voisins. Pour que cette vision soit à jour, chaque nœud diffuse (par inondation) périodiquement l'état des liens de ses voisins à tous les nœuds du réseau. Cela est fait aussi quand il y a un changement d'état de liens. Un nœud qui reçoit les informations concernant l'état des liens, met à jour sa vision de la topologie du réseau et applique un algorithme de calcul des chemins optimaux afin de choisir le nœud suivant pour une destination donnée. Un exemple des algorithmes les plus connus appliqué dans le calcul des plus courts chemins, est celui de Dijkstra. Notons que le nœud de routage calcule la plus courte distance qui le sépare d'une destination donnée, en se basant sur l'image complète du réseau formée des liens les plus récents de tous les nœuds de routage.



40

Le protocole OSPF (Open Shoretest Path First), est l'un des protocoles les plus populaires basé sur le principe d’Etat des liens. b) Vecteur de distance (Distance Vector) Dans cette méthode par contre, chaque nœud diffuse à ses nœuds voisins sa vision des distances qui le séparent de tous les hôtes du réseau. En se basant sur les informations reçues par tous ses voisins, chaque nœud de routage cherche le chemin le plus court vers n'importe quelle destination. Le processus de calcul se répète, s'il y a un changement de la distance minimale séparant deux nœuds, et cela jusqu'à ce que le réseau atteigne un état stable. Cette technique est basée sur l'algorithme distribué de Bellman Ford (DBF). L'algorithme DBF est basé sur l'utilisation des messages de mise à jour. Un message de mise à jour contient un vecteur d'une ou plusieurs entrées dont chaque entrée contient, au minimum, la distance vers une destination donnée. Le principe du DBF est utilisé par une grande partie des protocoles de routage des réseaux filaires. Dans les algorithmes de routage basés sur le principe d’état des liens, la convergence d'un nœud de routage, est moins lente par rapport au DBF, ce qui a fait que état des liens est plus préféré et utilisé dans beaucoup de réseaux modernes, tel que Internet. Cependant, l'approche de l’état des liens exige que chaque nœud doit maintenir une version mise à jour de la topologie complète du réseau, ce qui nécessite un grand espace de stockage et implique une surcharge d'échange de paquets de contrôle dans le cas des réseaux dynamiques. II.4.2.2 Les protocoles de routage réactifs (à la demande) Comme décrit précédemment, les protocoles de routage proactifs tâchent de maintenir les meilleurs chemins existants vers toutes les destinations possibles (qui peuvent représenter l'ensemble de tous les nœuds du réseau) au niveau de chaque nœud du réseau. Les routes sont sauvegardées mêmes si elles ne sont pas utilisées. La sauvegarde permanente des chemins de routage est assurée par un échange continu des messages de mise à jour des chemins, ce qui induit un contrôle excessif surtout dans le cas des réseaux de grande taille. Les protocoles de routage réactifs (dits aussi : protocoles de routage à la demande), représentes les protocoles les plus récents proposés dans le but d'assurer le service du routage dans les réseaux sans fil. Les protocoles de routage appartenant à cette catégorie, ce sont des protocoles dans lesquels la mise à jour ou le contrôle des routes se fait à la demande, c'est-à-dire lorsqu’une source veut transmettre des paquets de données vers une destination. Les protocoles de routage réactifs, créent et maintiennent les routes selon les besoins. Lorsque le réseau à besoin d'une route, une procédure de découverte globale de routes est lancée, et cela dans le but d'obtenir une information spécifique, inconnue au préalable.



41

II.4.2.3 Les protocoles de routages hybrides Les protocoles hybrides combinent les deux idées : celle des protocoles proactifs et celle des protocoles réactifs. Ils utilisent un protocole proactif pour avoir des informations sur les voisins les plus proches (au maximum les voisins à deux sauts). Au-delà de cette zone prédéfinie, le protocole hybride fait appel aux techniques des protocoles réactifs pour chercher des routes. Ce type de protocoles s’adapte bien aux grands réseaux, cependant, il cumule aussi les inconvénients des protocoles réactifs et proactifs en même temps (messages de contrôle périodique, le coût d’ouverture d’une nouvelle route). II.4.2.4 Avantages et inconvénients des protocoles de routages proactifs et réactifs Comme expliqué précédemment les protocoles de routages proactifs ont des avantages et des inconvénients nous citons : • l’échange de paquets de contrôle ; • la mise à jour continue des tables de routage ; • les routes sont immédiatement disponibles à la demande ; • le trafic de contrôle et de mise à jour peut être important et partiellement inutile. De même pour les protocoles de routages réactifs qui ont aussi des avantages et des inconvénients : • pas de tables de routage maintenues en continu ; • réaction à la demande en diffusion de requêtes ; • pas de trafic de contrôle continu pour les routes non utilisées ; • coût important pour la mise en place des routes (inondation) ; • délais importants avant l’ouverture de chaque route. II.4.3 Concepts de base pour le routage multicast Avant d’entamer les protocoles de routage en général pour Internet, nous commençons d’abord par quelques définitions des concepts de base utilisés dans le routage multicast. 1. La notion d'inondation L'inondation ou la diffusion pure, consiste à faire propager un paquet (de données ou de contrôle) dans le réseau tout entier. Un nœud qui initie l'inondation envoie le paquet à tous ses voisins directs. De même, si un nœud quelconque du réseau reçoit le paquet, il le rediffuse à tous ses voisins.



42

Ce comportement se répète jusqu'à ce que le paquet atteigne tous les nœuds du réseau (voir fig. II.4). Notons que les nœuds peuvent être amenés à appliquer durant l'inondation certains traitements de contrôle dans le but d'éviter certains problèmes, tel que le bouclage et la duplication des messages. Le mécanisme d'inondation est utilisé généralement dans la première phase du routage, plus exactement dans la procédure de découverte des routes, et cela dans le cas où le nœud source ne connaît pas la localisation exacte de la destination. Un paquet de requête de route est inondé par la source afin qu'il atteigne la station destination. Il faut noter que l'inondation est très coûteuse surtout dans le cas ou le réseau est étendu (latence, surcharge des messages…etc.) [3]. C'est pour cette raison que les protocoles de routage essayent de minimiser au maximum la propagation des paquets inondés en rajoutant d'autres paramètres de diffusion.

Fig. II.4 Le mécanisme d'inondation 2. Chemin inverse (RPF: Reverse Path Forwarding) Etant donnée l’adresse de la racine de l’arbre (ex : source), un routeur sélectionne comme son ascendant (appelé voisin RPF) le routeur qui représente lui-même le prochain saut lors de l’envoi de paquets unicast vers la racine. Le concept RPF permet d’éviter les boucles. 3. Un point de rendez-vous Un RP (Rendez-vous Point) est un point dans le réseau où les sources multicast se relient aux récepteurs multicast. Quand un relayeur souhaite envoyer des données, il les envoie d'abord au RP, et quand un récepteur souhaite recevoir des données, il s'inscrit au RP. II.4.4 Etude des protocoles de routage multicast en général Dans cette partie nous allons présenter quelques protocoles de routage multicast en général, tel que les protocoles PIM et DVMRP. Il existe deux modes de fonctionnement pour les protocoles de routage multicast :



43

Ø Mode dense DM (Dense-Mode) : implique la construction d‘arbres de distribution par inondation du réseau et puis l’élagage des chemins sans récepteurs. Il utilise les arbres de distribution source et crée un état pour chaque source sur tous les routeurs. Il est donc opté pour les groupes à forte densité de membre (ex : PIM-DM et DVMRP).

Ø Mode épars SM (Sparse-Mode) : il commence par un arbre de distribution vide et ajoutent

des branches seulement sur demandes explicites des récepteurs désirant joindre la distribution. Il utilise des arbres de distribution source et partagés, il est opté pour les groupes à faible densité de membre (ex : PIM-SM).

II.4.4.1 Le protocole PIM (Protocol Independent Multicast) Le protocole PIM a deux modes de fonctionnement: PIM-DM, spécifié dans le RFC 3973, et PIM-SM spécifié dans le RFC 2362. PIM-DM construit des arbres basés sur la source en utilisant l’inondation et l’élagage. PIM-SM construit des arbres basés sur le noyau et également des arbres basés sur la source avec des join explicites. 1. Le protocole de routage multicast PIM-SM Dans le contexte de PIM-SM, cet arbre de diffusion est enraciné en un point particulier appelé point de rendez-vous ou RP (Rendez-vous Point). Principe de fonctionnement de PIM-SM Un routeur est choisi comme le RP du groupe. Un routeur terminal ayant au moins un récepteur pour un groupe, envoie périodiquement un message d’inscription au groupe join message vers le RP du groupe, en utilisant le chemin unicast le plus court, le chemin suivi deviendra la branche de l’arbre de diffusion des paquets de données multicast [9].

Fig. II.5 Construction d’arbre de diffusion



44

Lorsqu’une source veut diffuser un paquet de données vers un groupe, le routeur d’extrémité, responsable de la source, envoie en unicast un message d’enregistrement register message dans lequel il encapsule le paquet de données.

Fig. II.6 Le message d’enregistrement

Le RP, après décapsulation, retransmet le paquet de données en le diffusant sur l’arbre et envoie un join message (S,G) à la source où S est la source et G le groupe multicast .

Fig. II.7 Join message

Lorsqu’il y a plusieurs sources, leur flux de données convergent vers le RP.

Fig. II.8 Arbre partagée par plusieurs sources



45

Construction d’un meilleur chemin Le chemin suivi par les données n’est pas le plus court, donc, le routeur terminal peut décider d’utiliser le meilleur chemin pour recevoir les paquets multicast d’un groupe. Le routeur terminal prévient l’émetteur en envoyant un join message directement à l’émetteur. L’émetteur émet les paquets de données à la fois vers le RP et le routeur terminal. Le routeur terminal dès qu’il reçoit des données provenant du meilleur chemin, envoie un message d’élagage (*, G) vers le RP. Les paquets multicast utilisent alors uniquement le chemin le plus court entre l’émetteur et le routeur terminal.

Fig. II.9 Construction d’un meilleur chemin

Le désabonnement d’un groupe Un routeur terminal ayant plus de membre actif se désabonne d’un groupe G : • soit explicitement par l’envoi d’un message prune (message envoyé pour élaguer un chemin) ; • soit implicitement en ne réémettant plus de message join. 2. Le protocole de routage multicast PIM-DM Ce protocole est basé sur les mécanismes d’inondation, élagage et de greffage. La source commence par inonder le réseau et chaque nœud élagage ses voisins non RPF. Elagage et greffe sur l’arbre de diffusion Elagage : Un routeur multicast qui n’a plus de récepteurs locaux ni de routeurs multicast en aval envoie un message prune à la (aux) source(s) émettrice(s) pour ce groupe multicast via les interfaces RPF et arme un timeout.



46

Greffe : A la réception d’une nouvelle demande d’un récepteur local ou d’un routeur en aval pour un nouveau groupe (ou un groupe précédemment élagué), il envoie un message graft (message envoyé pour se greffé directement un arbre multicast) vers le routeur RPF pour éviter d’attendre l’expiration du timeout d’élagage. Exemple :

Fig. II.10 Principe de fonctionnement du protocole PIM-DM II.4.4.2 Le protocole DVMRP Le protocole DVMRP (Distance vector multicast routing protocol) décrit dans le RFC 1075, agit en mode dense : basé sur les mécanismes d’inondation et d’élagage, on inonde tout le réseau et ceux qui ne sont pas intéressés ils sont élagués de l’arbre. Principe de fonctionnement Un routeur transmet un paquet multicast si le datagramme est reçu sur l’interface utilisée pour envoyer un paquet unicast vers la source (reverse path). Un paquet est retransmis vers toutes les interfaces non élaguées du routeur sauf l’interface RPF.



47

Fig. II.11 Reverse Path Forwarding (RPF) Routage DVMRP DVMRP utilise son propre routage unicast. Les routeurs échangent avec leurs voisins des messages de mise à jour du vecteur de distance (liste de couples <destination, distance> où destination désigne l’adresse unicast de l’émetteur multicast, et distance désigne le nombre de routeurs intermédiaires entre la destination et le routeur local). A l’issue de l’algorithme, chaque routeur connait pour chaque destination l’interface qui donne accès au plus court chemin vers cette destination (c’est à dire l’émetteur multicast).

Fig. II.12 Echange des tables de routage

Poison Reverse Le routeur B va décider que le routeur voisin A est en amont vers la source S, il envoie à A une information de routage vers S dont la métrique est dite empoisonnée (fig. II.13). Par conséquent, B attend le flux multicast de A pour la source S et A ne doit pas compter sur B pour ce même flux.



48

Fig. II.13 Poison Reverse

II.4.5 Synthèse Le tableau II.1 résume les caractéristiques principales des trois protocoles de routage multicast: Les protocoles PIM-DM et DVMRP fonctionnent en mode dense et constituent des arbres d’expédition basés source qui sont mieux adaptés pour ce mode. Contrairement au protocole PIM-SM qui fonctionne en mode épars et constitue un arbre de distribution basé sur un point de rendez vous. Le mode épars est adapté au réseau de taille importante par rapport au mode dense. Chacun de ces trois protocoles de routage, appartient à la classe des protocoles proactifs, il produit la table de routage au préalable et rafraichit son contenu périodiquement. Protocole Mode Arbre basé Type d’arbre Mécanisme Classe du

protocole PIM-SM Epars PR/source arbre partagé

join explicite Proactif

PIM-DM Dense source arbre par source

inondation/ élagage Proactif

DVMRP Dense source arbre par source

inondation/ élagage Proactif

Tab. II.1 Caractéristiques des protocoles



49

II.5 Conclusion Actuellement, une demande croissante provient des applications faisant appel à des protocoles de communication multipoints (Multicast) au sein desquelles un flot de données doit être distribué vers diverses destinations de façon efficace. Ce type de communication met en jeu plus de deux participants qui désirent échanger des informations. Afin de prendre en charge ce genre d'applications, les réseaux offrent généralement le concept de groupe de multidiffusion, de sorte qu'un émetteur puisse considérer l'ensemble de ses destinations comme une seule entité (groupe multicast identifié par une seule adresse). Il incombe alors au protocole multicast de distribuer les données à tous les membres du groupe considéré. Dans l’étude des protocoles de routage, nous avons commencé par présenter les trois classes de protocoles de routages : proactifs, réactifs et hybrides, ainsi que les politiques et les méthodes d’acheminement sur lesquelles ils reposent. Nous montrons comment fonctionne le protocole de gestion d’hôtes IGMP et nous avons expliqué les fondements des protocoles de routage PIM-SM, PIM-DM et le protocole DVMRP et nous avons montré leur fonctionnement de base. Dans le chapitre suivant nous détaillons le fonctionnement des protocoles de routage multicast dans les réseaux sans fil en général et les réseaux maillés en particulier.


Chapitre III: Protocoles de routage multicast dans les réseaux sans fil

50

Chapitre III

Protocoles de routage mul ticast dans les réseaux sans fil

III.1 Introduction

La plupart des applications utilisent du routage unicast, mais le multicast est en train d’évoluer régulièrement, son utilité ne cesse de se justifier, par exemple dans des applications de téléconférence ou de jeux en réseaux.

La difficulté dans la conception d’un protocole de routage multicast est le choix de la structure à mettre en place soit (i) un arbre de diffusion, qui peut être centralisé et partagé ou qui peut être définie pour chaque source, ou soit (ii) une grille reliant tous les membres d’un groupe.

Les choix des structures dans les réseaux sans fil sont différents des choix effectués dans le cadre des réseaux filaires dû aux difficultés propres aux réseaux sans fil.

Dans ce chapitre nous étudions des protocoles de routage multicast dans les réseaux sans fil en générales, puis dans les réseaux maillés sans fil.



51

III.2 Étude comparative des architectures de routage multicast dans les réseaux sans fil III.2.1 Caractéristiques des architectures de type arbre Un réseau multicast peut être représenté par un arbre, où le nœud source sera la racine et l’ensemble des nœuds mobiles du réseau représente les feuilles et les nœuds de chaque branche de cet arbre (fig. III.1). L’utilité de cette schématisation et que chaque nœud du réseau aura un lien unique vers son nœud voisin. MAODV [10] et AMRIS [11] sont deux protocoles de routage multicast de type arbre [12].

Fig. III.1 Architecture de type arbre 1. Avantages des architectures de type arbre - Minimiser le nombre de paquets à transmettre ainsi que le nombre de paquets de contrôle. - Une meilleure façon d’exploiter la bande passante. - Une implication d’un nombre restreint de nœuds intermédiaires. - Une économie d’énergie pour les nœuds du groupe. 2. Inconvénients des architectures de type arbre - Le problème de mobilité des nœuds avec une variation de vitesse. - Une rupture d’un lien implique une re-génération de l’arbre tout entier. - Quand il y a des sources multiples, les arbres partagés ou les arbres séparés de multicast sont nécessaires. - Dans les arbres partagés, l'optimalité de chemin est perdue. - Dans un groupe multicast séparé, chaque nœud doit maintenir des entrées pour chaque source.



52

III.2.2 Caractéristiques des architectures de type maille Contrairement à une architecture de type arbre, l’architecture maillée est un graphe fortement connexe où pour chaque source il doit exister plus qu’un chemin vers une destination (fig. III.2). Cette approche bénéficie de l’avantage de la connectivité du réseau pour procurer plusieurs chemins entre les nœuds, il existe plusieurs protocole de routage adoptant ce schéma de représentation comme : CAMP [13], ODMRP [14] qui est la base de notre projet, nous allons l’étudier en détaille dans le prochain chapitre.

Fig. III.2 Architecture de type maille 1. Avantages des architectures de type maille - Fournir une multitude de chemins entre une source et une destination afin de diminuer le risque d’échecs des liens et, en conséquence, faire face aux problèmes de la mobilité. - Dans les scénarios de multicast en multiples sources, les structures maillées fournissent des chemins plus optimaux que des architectures en arbres. 2. Inconvénients des architectures de type maille - Employez plusieurs copies par paquet (une prodigalité relative à la consommation de bande passante). - Risque de congestion du réseau pour chaque paquet transmis. - Très forte consommation énergétique au niveau des nœuds mobiles (exigeante en terme de calcul). Le tableau III.1 résume les avantages et les inconvénients de chaque architecture :



53

Schéma Avantages Inconvénients

Arbre

Un nombre minimal de copies par paquet

=> utilisation efficace de la bande passante

Nombre de nœuds minimal dans le routage

=> utilisation efficace de l’énergie

Un lien cassé => régénération de tout l’arbre

Maillée

Multiple chemins de routage => faire face

aux cassures de liens et à la mobilité des

nœuds

Utilisation de plusieurs copies du même

paquet durant la transmission

=> congestion de la bande passante

Tab. III.1 Tableau comparatif des architectures de réseaux (Arbre, Maille)

III.3 Les protocoles de routage multicast dans les réseaux sans fil L'étude des protocoles de communication multicast est intéressante tant du point de vue théorique que pratique. Plusieurs travaux se sont penchés sur divers aspects et approches pour le multicast dans les réseaux filaires en général, et dans les réseaux ad hoc en particulier. Dans cette section nous décrivons les protocoles multicast de niveau IP comme MOLSR, MAODV et CAMP. Ils exploitent une des propriétés fondamentales des réseaux ad hoc, en l’occurrence le fait que les nœuds agissent en routeurs. III.3.1 Présentation du protocole MOLSR Le protocole (Multicast Optimized Link State) appartient à la famille des protocoles de routage multicast qui maintiennent un arbre de diffusion par source dans un groupe de diffusion. MOLSR est l’extension multicast pour le protocole de routage unicast OLSR. MOLSR est conçu de façon à tirer profit de ce qui est fait dans le protocole OLSR. Il utilise les différentes tables de voisinage, de topologie et de routage, afin de minimiser le trafic de contrôle et d’économiser la bande passante en utilisant les relais multipoint (Multi-Points Relays, MPR) [15]. Le principe de MOLSR consiste à construire et maintenir un arbre multicast pour chaque tuple (source, groupe) d’une façon distribuée sans aucune entité centrale tout en offrant les plus courts chemins de la source aux membres du groupe. OLSR réagit à chaque modification dans le voisinage ou la topologie en recalculant l’ensemble des relais multipoint et la table de routage. MOLSR profite de ces mises à jour pour optimiser les arbres multicast et détruire les branches obsolètes.



54

1. Informations locales Un nœud conserve localement l’identifiant des groupes multicast dont il fait parti. La table des arbres multicast maintient en chaque nœud les informations sur les différents groupes multicast auxquels ce nœud participe. Chaque entrée de la table contient des renseignements sur l’arbre défini par (source, groupe) : l’adresse de la source, l’adresse du groupe multicast, l’adresse du père du nœud dans l’arbre, et la liste des fils de ce nœud. A chaque nœud dans la table, on associe également une durée de vie. Un nœud peut ne pas être membre d’un groupe, mais faire parti de l’arbre pour router les messages vers les abonnés. La table de routage multicast indique les plus court chemins vers tous les nœuds multicast (identique à la table de routage unicast, mais n’utilise que les nœuds gérant le multicast, ces nœuds étant connus sur le réseau car l’information est diffusée). Cette table est recalculée à chaque fois que la table de routage OLSR est mise à jour, ou bien lorsqu’un nouveau nœud multicast est découvert. 2. Construction de l’arbre multicast Les routeurs multicast diffusent dans le réseau le message MC-Claim (en utilisant la diffusion optimisée d’OLSR par l’intermédiaire des MPR). Chaque nœud effectuant des opérations multicast connait ainsi les autres membres du réseau multicast. Lorsqu’une source désire émettre des données multicast vers un groupe spécifique G, elle diffuse un message Source-Claim pour que les membres du groupe détectent sa présence et se rattachent à l’arbre associé à cette source. L’invitation de la source est diffusée par MPR. Les branches de l’arbre sont construites en partant des feuilles. Lorsqu’un membre du groupe reçoit le message Source-Claim, et s’il ne fait pas partie de l’arbre définit par (source, G), alors il se rattache automatiquement à l’arbre : - Il regarde dans sa table de routage multicast pour choisir le prochain saut qui lui permet d’atteindre la source en un nombre minimal de sauts. Ce nœud devient son parent dans cet arbre multicast. - Il envoie un message pour confirmer à son parent qu’il devient son fils. - Le nœud parent qui reçoit un tel message se rattache à son tour à l’arbre (source, G) s’il n’appartient pas à ce dernier, en suivant la même procédure. De plus, il actualise sa liste de fils. La construction et l’activation de la branche se fait donc de façon récursive jusqu’à ce que la source ou un participant de l’arbre soit atteint.



55

Fig. III.3 Mécanisme de construction de l’arbre multicast

3. Maintenance des arbres Les arbres sont rafraichis périodiquement par l’intermédiaire des messages de confirmation de parents et par les Source-Claim. Lorsqu’un nœud reçoit un Source-Claim et qu’il appartient déjà à l’arbre multicast, il se contente de mettre à jour les informations de durée de vie. Les modifications de topologie sont détectées par l’échange de messages de contrôle d’OLSR. Chaque nœud répercute alors ces modifications également sur les structures multicast qu’il gère. Lors d’un changement dans le voisinage ou dans la topologie du réseau, la table de routage multicast doit être recalculée. Ces changements dans la table de routage peuvent amener à devoir changer un parent dans l’arbre (route vers la source). Pour cela, les tables sont mises à jour. Les relations de parenté sont également mises à jour régulièrement grâce aux messages que chaque participant à l’arbre envoie régulièrement à son père. 4. Destruction des arbres Un nœud peut quitter un groupe multicast, ou bien seulement une branche d’un arbre. Dans tous les cas, il est amené à détruire différentes branches de l’arbre et des liaisons entre les nœuds appartenant à l’arbre. Un nœud quitte une branche spécifique s’il découvre une meilleure route vers la source, comme indiqué dans la maintenance de tables. Lorsqu’un nœud quitte un groupe, il doit quitter tous les arbres multicast concernant ce groupe. Pour cela, il doit détruire toutes les branches de ces arbres. Un nœud qui est une feuille peut quitter l’arbre multicast par un simple message à son père (message Leave). Si le

Client group

Source group

Multicast tree participant

Source_claim flooding Tree building with Confirm_parent message

Source Multicast data



56

père devient une feuille et s’il n’est pas abonné au groupe, il effectue la même opération de destruction de branche. Sinon, s’il est sur la route pour atteindre d’autres membres du groupe pour certaines sources, il doit rester dans l’arbre pour effectuer le routage. Lorsqu’il quitte un groupe, un nœud peut envoyer un message Leave à tous ses parents pour tous les arbres auxquels il appartient, en une seule diffusion. 5. Fiabilité des arbres multicast Pour rendre plus fiable OLSR, on peut introduire de la redondance et de la diffusion multiple. On peut rendre les chemins multicast plus robustes et plus fiables en dédoublant les branches de l’arbre. On possède ainsi un chemin de secours en cas d’erreur sur un lien. Ainsi, en plus de choisir son père, un nœud choisit également un oncle dans l’arbre, voisin de son père si possible. L’oncle est également à portée de communication du grand père (le nœud connait son voisinage à deux sauts), et ainsi le grand père peut transmettre les données au nœud en passant soit par le père soit par l’oncle. III.3.2 Présentation du protocole MAODV MAODV, Multicast AODV (Ad hoc On-Demand Distance-Vector Routing Protocol) est basé sur AODV, et fonctionne de manière réactive également, à la demande. Il utilise le même principe qu’AODV, et les mêmes formats de requêtes de recherche de routes [15]. Dans AODV, les tables de routage de chaque nœud sont mises à jour lorsque ceux-ci désirent connaitre le chemin vers une destination non répertoriée (ou pour laquelle l’information correspondante est périmée) ou lorsqu’ils participent à une recherche de route lancée par un autre nœud. Le protocole MAODV construit un arbre partagé centré sur un noyau (le leader du groupe) pour chaque groupe multicast du réseau. Le nœud leader est le premier participant au groupe, il est chargé de le gérer et de le maintenir en place. L’arbre peut contenir des nœuds qui ne font pas partie du groupe. Un numéro de séquence est associé à chaque groupe.



57

Fig. III.4 Arbre partagé

Un nœud MAODV maintient une table de routage comme dans AODV pour le routage unicast (l’algorithme AODV maintient une table sur chaque nœud, indexée par destination et notamment le voisin auquel envoyer le paquet pour atteindre cette destination. Si la destination recherchée n’est pas dans la table, on doit donc découvrir une route jusqu’au destinataire. L’algorithme agit à la demande : recherche d’une route uniquement lorsque c’est nécessaire), mais aussi une table de routage pour la structure en arbre du groupe. Cette table contient l’adresse du groupe multicast (identifiant du groupe), le numéro de séquence, l’adresse du leader du groupe, le nombre de sauts jusqu’au leader, et les informations sur le saut suivant, qui correspondent aux voisins qui sont dans l’arbre. Les voisins peuvent être fils ou père, chaque nœud possède au plus un père, et le leader ne peut posséder des fils que s’il y a d’autres membres dans le groupe. 1. Message de requête Les messages de demande de routes et de réponse sont ceux de AODV, adaptés pour le multicast. Une requête est envoyée lorsqu’un nœud source désire envoyer un message multicast. Le même type de message de requête REQ est utilisé lorsqu’un nœud désire joindre un groupe multicast. Dans les deux cas, il s’agit donc de trouver une route vers l’arbre multicast. Si le nœud source connait le leader du groupe, il peut envoyer son message directement au leader en mode unicast. Sinon, le message REQ est relayé saut par saut jusqu’à trouver un nœud qui appartient déjà à l’arbre multicast. Le nœud récepteur de la requête répond alors en mode unicast au nœud demandeur, par un message de réponse REP. Les requêtes sont envoyées avec des TTLs de plus en plus grands, et si le nœud n’obtient pas de réponse après plusieurs tentatives de connexion à un arbre multicast, il se considère comme étant le premier membre de ce groupe, et il initialise le numéro de séquence du groupe.

Multicast Group Member

Multicast Tree Member

Non-Tree Node

Multicast Tree Link Arrow pointing to Downstream Node

Group Leader



58

2. Réponse et activation de branches Dans AODV, le message de réponse à une demande de route active directement la route, alors que dans MAODV, la réponse indique seulement une route possible jusqu’à l’arbre, sans l’activer. Le nœud qui a émis la requête attend une certaine période, puis choisit la meilleure route à utiliser pour atteindre l’arbre parmi les réponses qu’il a reçues. Il envoie alors un message MACT (Multicast Activation) pour activer la route jusqu’à l’arbre, ou activer une nouvelle branche de l’arbre multicast. La meilleure route est la plus récente (en regardant le numéro de séquence), et la plus courte parmi ces dernières (en terme de nombre de sauts jusqu’à l’arbre). 3. Opérations de maintenance Les opérations de maintenance lors de départ de nœuds sont plus complexes en multicast que pour le protocole AODV unicast. Le leader du groupe envoie périodiquement un message Hello de groupe. Ce message est broadcasté dans tout le réseau, pour indiquer l’adresse du leader du groupe et le numéro de séquence courant du groupe. Le numéro de séquence de groupe est incrémenté avant chaque envoi de ce message Hello. Pour un départ d’un membre du groupe, si le nœud n’est pas une feuille de l’arbre, il doit rester dans l’arbre et faire office de routeur pour le groupe multicast. Sinon, il faut enlever la branche de l’arbre désormais inutilisée, cela se fait par l’envoi d’un message MACT avec un flag spécial. Les nœuds servant de routeur pour le nœud qui quitte le groupe sont également supprimés de l’arbre, et ce jusqu’à ce qu’un membre du groupe soit rencontré. Les problèmes propres à l’ad hoc sont bien sur les ruptures de lien dues à la mobilité, et cela peut entrainer des envois à une partie seulement du groupe multicast. Les ruptures de lien peuvent être détectées de la même façon que dans AODV, mais AODV se contente d’effacer la route des tables de routage et de rechercher une nouvelle route, alors que dans MAODV la procédure à lieu localement, seul le nœud fils du lien cassé peut initier la procédure de réparation. Le nœud fils envoie en mode broadcast un message de requête REQ en demandant à joindre l’arbre, indiquant également son nombre de sauts jusqu’au leader (pour éviter qu’un de ses descendants renvoie une réponse). Lorsqu’une réponse est obtenue, le nœud envoie un MACT pour raccorder sa branche à l’arbre, et il envoie également un MACT avec un flag de mise à jour à ses descendants pour qu’ils puissent changer leur compteur de sauts jusqu’au leader du groupe.



59

Exemple :

Fig. III.5 Ruptures de lien Si aucune réponse n’est reçue après une tentative de reconnexion de la branche (après plusieurs essais), la source suppose alors que l’arbre est partitionné, et il faut sélectionner un nouveau leader pour l’arbre partitionné. Si le nœud source est un membre du groupe, il devient le leader. Sinon, il oblige un de ses descendants à devenir le leader. III.3.3 Présentation du protocole CAMP Le protocole CAMP (Core-Assisted Mesh Protocol) utilise les nœuds noyaux dans le maillage pour éliminer l'approche d’inondation utilisée dans d’autre protocole pendant la création et la maintenance du maillage. Ainsi, elle est plus efficace dans l'utilisation de la bande passante. Le protocole CAMP assume l'existence d'un protocole de routage unicast sous-jacent dans l'environnement du réseau, qui fournit l’identificateur du prochain nœud [16]. 1. Phase d'initialisation du maillage CAMP est un protocole de routage multicast receiver-initiated. Initialement, pour joindre le maillage, un récepteur extrait l'identification du nœud noyau à partir de sa table d'adresse de core-to-group et envoie en unicast un paquet JoinReq vers ce nœud noyau. Dans la transmission du JoinReq, le prochain nœud est obtenu en utilisant le protocole de routage unicast sous-jacent. Quand un nœud membre du maillage reçoit ce JoinReq, il envoie un ACK au récepteur, et ainsi, il devient un membre du groupe multicast. Le paquet JoinReq ne peut être envoyé si le récepteur souhaitant joindre un maillage et il a un nœud voisin déjà présent dans le maillage. Dans ce cas-ci, le récepteur joint le groupe multicast en annonçant son adhésion en utilisant le message Multicast Routing Update et modifie la table de routage multicast.

Group Leader Group Leader Group Leader Multicast Group Member Multicast Tree Member Non-Tree Node Multicast Tree Link RREQ/RREP

Link Break RREQ sent out

RREP sent back Repaired Multicast Tree



60

2. Phase de maintenance du maillage Les pannes de lien ne sont pas très critiques dans le CAMP. Chaque récepteur perdant un chemin sur le maillage utilise le message Push Join pour établir un nouveau chemin. Nous notons que, en évitant l'approche d’inondation, le protocole CAMP laisse une charge de contrôle inférieur. Toujours, les pannes du nœud noyau causent des pertes significatives de paquet. Un autre inconvénient de ce protocole est qu'il n'est pas autonome, car il a besoin de l'appui d'un protocole existant de routage unicast qui devrait fonctionner correctement en présence des pannes du noyau. De ce fait, non pas tous les protocoles de routage peuvent être compatibles avec le CAMP. III.3.4 Synthèse Le tableau ci-dessous présente un comparatif entre les trois protocoles de routage multicast étudiés précédemment. MOLSR est un protocole qui construit un arbre multicast par source et MAODV réalise un arbre partagé. Or Le protocole CAMP utilise un maillage pour l’acheminement des données multicast. Le protocole MOLSR est dépendant d’un protocole de routage unicast proactif. Les routes sont immédiatement disponibles à la demande. Les deux protocoles MAODV et CAMP calculent les routes à la demande. Par conséquent, Les routes ne sont pas immédiatement disponibles à la demande ce qui élimine le trafic de contrôle continu pour les routes non utilisées.

Protocole MOLSR MAODV CAMP

Topologie du multicast arbre par source arbre partagé maillée

Approche de routage proactif Réactif réactif Dépendance au routage

unicast oui Non Oui

Messages de contrôle périodiques

oui Oui Non

Initialisation de la session multicast

initié-source initié-récepteur initié-récepteur

Métrique de construction de route

le plus court chemin

le plus frais et le plus court chemin

dépend du protocole unicast

Tab. III.2 Comparaison de différents protocoles de multicast



61

III.4 Des nouveaux protocoles de routage multicast pour les réseaux maillés sans fil Les réseaux maillés sans fil sont une technologie émergente, principalement présentée comme un moyen de construire des réseaux de communautés (campus, entreprises, villes) à bas coût. Ce type de réseaux présente plusieurs défis notamment le routage des données. De ce fait, plusieurs travaux de recherche se focalisent sur la réalisation des protocoles de routage performant et adéquat aux particularités de ce type de réseau. Dans ce qui suit, nous nous intéressons au routage multicast dans les réseaux maillés sans fil, et nous présentons certains travaux réalisés dans ce domaine. III.4.1 Le protocole GAMP (gateway associated multicast protocol) Dans les WMNs, les clients sont reliés à Internet par l'intermédiaire des passerelles qui agit en tant qu’un nœud de relais dans l'arbre multicast ce qui rend la charge du trafic lourde pendant des périodes particulières (paquets multicast et unicast) qui peut générer des conséquences désastreuses sur la performance globale du réseau. La solution est de réaliser un algorithme qui contrôle l’enregistrement des clients auprès des passerelles et l’équilibrage de la charge des passerelles. Le protocole GAMP (gateway associated multicast protocol) a investi le problème d'équilibrage de charge multicast dans les WMNs [17]. Cet algorithme réalise l'enregistrement des clients aux passerelles et la construction d'arbre multicast.

Une session multicast est divisée en trois étapes : 1. Enregistrement des clients Un client doit d'abord s'inscrire à une passerelle qui est connectée à Internet. Il envoie la requête GRDR (gateway route discovery request) aux passerelles. Chaque passerelle répond par GRDP (gateway route discovery Reply) qui contient l’index de sa charge et après un certain temps, il envoie la requête GRR (gateway register request) à la passerelle avec la meilleure bande passante disponible qui répond a son tour par GRP (gateway reply) si l’utilisation courante de sa bande passante est inférieure à un certain seuil, sinon elle répond par (GRP-E) pour choisir une autre. La figure. III.6 dépeint les procédures d'enregistrement de la façon dont un nœud client maillé s'enregistre au prés d’une passerelle. G est un nœud de passage (passerelle) et C1, C2 et C3 sont les clients enregistrés au prés de G. C4 est un nœud souhaitant s'inscrire à G. 1, 2, 3, 4 sont GRDR, GRDP, GRR, GRP respectivement. C4 envoie d'abord GRDR à la passerelle G. Après réception de GRDP, C4 envoie alors GRR encore. La passerelle G reçoit finalement GRR, met à jour sa table de routage et envoie un GRP à C4. Cependant, la passerelle G crée



62

une table de routage de passage et enregistre C4 dans la première entrée si C4 est son premier nœud.

Fig. III.6 Enregistrement des clients

Équilibrage de charge de la passerelle Quand une passerelle trouve sa largeur de bande passante inférieure à un certain seuil ou que la charge d’une passerelle voisine est meilleure que son seuil, elle envoie une (GRP-B) à la passerelle voisine avec le meilleur index de charge, qui prendra sa charge en main après un échange de requête/réponse. Lors de recevoir GHR (gateway handover request), GA transfère toute la responsabilité de routage du nœud client pris en main au GB. GA vérifie sa charge si sa bande passante est importante, il aura un déclanchement du processus d’équilibrage pour récupérer ses responsabilités préalables.

Fig. III.7 Équilibrage de charge 2. Construction de l’arbre multicast Chaque passerelle enregistre l’adresse de la source dans sa table de routage multicast suite aux messages Hello multicast. Quand un nœud client voudrait joindre un groupe multicast, il envoie la requête (MRQ) (multicast route request) à la passerelle enregistrée, si cette dernière a un lien avec la source, donc elle envoie une (MRP) a la source sinon, elle envoie une (MSQ) (multicast source request) vers les autre passerelles pour chercher la source. La passerelle qui a un lien avec la source répond par (MSP).



63

Internet

G1 G1

C2 C1 C0 C3

C4

2

1

1 1 3

2

3

3

Fig. III.8 Construction de l’arbre multicast

3. GAMP maintient les routes dans WMN Plusieurs travaux de recherche se focalisent sur l’amélioration de cette technologie soit en adaptant les techniques existantes ou en créant des nouvelles techniques. Le maintient des routes est assuré par l’envoi des messages Hello périodiques entre chaque nœud et ses voisins. Si un lien et coupé, il refait le processus de découverte d’une nouvelle route par (GRDR). Le protocole GAMP permet d’alléger la charge des passerelles et réalise une coopération entre elles.

III.4.2 Algorithmes de routage multicast pour les WMNs multi canal Deux algorithmes ont été proposés pour optimiser le débit dans les WMNs multi-canal et multi-interface: LCA (Level Channel Assignment) et MCM (Multi-Channel Multicast) [18]. Les deux algorithmes utilisent l’arbre comme une structure multicast puisque les routeurs dans les WMNs ont un minimum de mobilité ou statiques (pas de changement de topologie). III.4.2.1 LCA (Level Channel Assignment) Avant la construction de l’arbre multicast, les nœuds du réseau sont partitionnés en plusieurs niveaux.



64

1. Construction de l’arbre multicast Pour chaque récepteur, si un de ses parents est un nœud d'arbre, alors il se connecte à ce parent, sinon il choisie aléatoirement un de ses parents et l’intégrer à l’arbre et ainsi de suite jusqu’à atteindre la source. 2. Allocation des canaux L’allocation des canaux ce fait par niveau, comme suit : Le niveau 0 : réservé à la source qui utilise une interface sur le canal 0 pour envoyer les paquets aux nœuds du niveau 1. Le niveau i : utilise deux interfaces, une sur le canal i-1 pour la réception des paquets (a partir du niveau i-1) et l’autre sur le canal i pour les transférés au niveau i+1ou au récepteur (client).

Fig. III.9 Allocation des canaux

III.4.2.2 MCM (Multi-Channel Multicast) Ce protocole vise deux buts, le premier est de réduire au minimum le nombre de nœuds relais a chaque niveau et le second, réduire les interférences (utiliser les canaux partiellement chevauchés) [18]. 1. Construction de l’arbre multicast Commence par la division des nœuds du réseau en plusieurs niveaux. En suite élimine les liens entre les nœuds du même niveau (si 2 nœuds ne sont pas dans le même niveau ni dans des niveaux adjacent, ils peuvent avoir le même canal). Après ces étapes, il faut identifier le nombre min de nœud relais dans chaque niveau i qui couvre le maximum des nœuds dans le niveau i+1 (assurer que chaque nœud a un seul parent). L’identification est d’une façon ascendante (du récepteur ver la source).



65

2. Allocation des canaux Il y’a deux algorithmes d’allocation proposés, allocation ascendante du canal et allocation heuristique du canal : a. Allocation ascendante du canal Chaque interface de réception d’un nœud est associée à l’interface d’envoi de son nœud de relais (utilisent le même canal). Chaque nœud relais dans un niveau a un canal différent des autres nœuds.

Fig. III.10 Allocation ascendante du canal Avantage de l’allocation ascendante du canal Ce type d’allocation est sollicité vu qu’il est simple et évite d’allouer le même canal à deux liens voisins. Inconvénient de l’allocation ascendante du canal L’allocation ascendante du canal utilise un nombre limité de canal (juste les canaux orthogonaux). b. Allocation heuristique de canal Utilise tous les canaux. Choisir le canal qui minimise la somme des interférences avec les nœuds voisins.



66

III.5 Conclusion Dans ce chapitre nous avons présenté plusieurs protocoles de routage qui ont été proposé pour assurer le service de routage multicast dans les réseaux sans fil. Nous avons décri leurs principales caractéristiques et fonctionnalités afin de comprendre les stratégies utilisées dans l'acheminement des données entre les différentes unités. Nous avons vu ensuite quelque proposition de routage multicast pour les réseaux maillés qui traitent des problèmes propre aux réseaux maillés tel que l’équilibrage de la charge des passerelles sur lesquelles passe tout le trafic d’Internet et l’allocation des canaux pour les réseaux multi-canal. Parmi les caractéristiques principales des réseaux sans fil, nous citons les ressources et la bande passante limités et la contrainte d’énergie. Pour la réalisation d’un protocole de routage optimale, il faut prendre en considération ses contraintes. Dans le prochain chapitre nous détaillons ce problème et nous proposons un protocole qui optimise l’utilisation des ressources.


Chapitre IV: Conception

Chapitre IV

Conception

IV.1 Introduction

Dans les réseaux sans fil, les ressources sont très importantes d’où la nécessité de les préserver. Donc, un protocole de routage qui minimise le nombre de ressources réseau employées est un besoin critique.

Notre projet consiste à proposer une version optimisée OODMRP (Optimized On-Demand Multicast Routing Protocol) du protocole de routage multicast le plus réputé ODMRP de telle sorte qu’il minimise le nombre de nœud transférant les paquets multicast afin d’optimiser l’utilisation des ressources et de réduire le trafic sur le réseau.

Nous commençons par une description détaillée du protocole de routage multicast ODMRP (On-Demand Multicast Routing Protocol) et ses caractéristiques. Ensuite, nous présentons notre protocole OODMRP.



68

IV.2 Problématique du routage dans les réseaux sans fil

Usuellement, un réseau est représenté dans sa forme la plus générale par un graphe. Les sommets représentent les nœuds du réseau et les arcs modélisent la possibilité d’établir une communication directe entre deux sommets. S’il existe un arc du sommet u vers le sommet v, on dit que le sommet u est un voisin de v tandis que v est accessible depuis u. Le médium radio étant diffusant par nature, lorsqu’un nœud u diffuse un paquet (on emploie aussi le terme de broadcast ou de broadcast local), tous les nœuds qui sont accessibles depuis u reçoivent une copie de ce message. Les transmissions radio interférant fortement, un nœud v ne peut recevoir un message que si exactement un seul de ses voisins émet. S’il s’avère que plusieurs voisins émettent en même temps, il y a une collision et les messages arrivent brouillés et sont inexploitables par le nœud v (1-port en réception et ∆-port en émission) [19].

La grande majorité des algorithmes de multicast au sein des réseaux filaires met en œuvre une structure d’arbre (partagé ou non). L’arbre est le moyen le plus efficace en termes de ressources pour connecter n nœuds et garantit la non duplication des données. De plus, les décisions de routage sont très simples et se limitent à retransmettre les données sur les autres interfaces, exceptée celle par laquelle le message est arrivé. Vouloir transposer directement ces principes aux réseaux sans fil peut se révéler très inefficace.

Il ne faut pas perdre de vue que l’emploi d’un protocole de multicast pour envoyer une donnée à un ensemble de destinataires doit permettre de réduire le nombre de ressources réseau employées. De plus, la mise en œuvre d’un protocole de multicast peut s’avérer utile car elle offre aussi un moyen robuste pour joindre des destinataires dont l’adresse n’est pas connue a priori ou qui change régulièrement. Comme nous l’avons souligné plus haut, il est important de réduire le nombre de transmissions (et la consommation d’énergie au sein des mobiles) dans un réseau sans fil car la bande passante est limitée. Le multicast doit permettre d’optimiser la gestion du médium radio en évitant les retransmissions superflues de messages et en tirant parti de la caractéristique de diffusion inhérente au médium radio [12].

En appliquant l'avantage du broadcast sans fil où la transmission d'un paquet de données multicast d'un nœud donné à tout nombre de ses voisins peut être réalisée avec une seule transmission de données. Ainsi, dans un réseau multi-saut sans fil dans lequel les nœuds sont statiques, l'arbre de coût minimum reliant des sources et des récepteurs en impliquant un nombre minimum des transmissions. En d'autres termes, l'arbre contenant un nombre minimum de nœuds relayeurs de multicast.

Pour quoi ODMRP?

Récemment, plusieurs protocoles de multicast dans les réseaux sans fil ont été proposés telle que MAODV [20], ODMRP [21] [22] [23] [14], ADMR [24] et CAMP [25]. ODMRP, est l’un des protocoles de routage multicast les plus utilisés actuellement. En outre, des caractéristiques d'exécution d'ODMRP ont été intensivement étudiées. Les raisons pour lesquelles nous avons choisi le protocole ODMRP sont nombreuses:



69

• simplicité ; • utilisation des mises à jour des routes ; • maintenance et exploitation des multiples chemins redondants ; • exploitation de la nature broadcast des environnements des réseaux sans fil ; • capacité de routage unicast.

IV.3 Présentation du protocole ODMRP

ODMRP (On-Demand Multicast Routing Protocol) est un protocole de routage multicast très réputé pour les réseaux sans fil. La force d’ODMRP provient de sa simplicité, et sa non-dépendance sur un protocole unicast spécifique.

ODMRP est basé sur une structure maillée (mesh-based), plutôt que le conventionnel basé-arbre, il utilise le concept du groupe d’expédition ‘forwarding group’ (seulement le sous-ensemble de nœuds qui transmettent les parquets multicast). Il applique les procédures à la demande pour construire les routes dynamiquement et maintenir les membres du groupe multicast.

Définitions

• Join Query : est un paquet de contrôle envoyé par l'émetteur du multicast pour lancer une session multicast. En outre, la source multicast envoie des paquets Join Query périodiquement pour rafraichir le chemin d'expédition.

• Join Reply : est un paquet de contrôle envoyé par les abonnés du multicast. Les paquets Join Reply sont expédiés en amont vers la source multicast pour renforcer le chemin d'expédition pour les données de multicast.

• Nœuds relayeurs (Forwarding nodes) : ce sont des nœuds intermédiaires, qui transmettent des données multicast au nom de la source multicast. Les nœuds intermédiaires indiquent leur volonté de participer à la transmission des données multicast par l'expédition des paquets Join Query, qui permettent aux nœuds descendants de choisir ces nœuds comme des nœuds relayeurs. A travers l'expédition des paquets Join Reply les nœuds intermédiaires s'autoproclament comme des nœuds relayeurs et forment ainsi le chemin d'expédition. L'état d'expédition est maintenu par le rafraichissement périodique des chemins de routage par les paquets Join Query, qui permettent à des abonnés de multicast de découvrir de meilleurs chemins d'expédition.

IV.3.1 Principe de fonctionnement

Dans ODMRP, les membres du groupe et les routes multicast sont établis et mis à jour par la source à la demande. Quand une source multicast à des parquets à émettre, elle inonde le réseau par des paquets Join Query, ces paquets sont diffusés périodiquement sur tout le réseau pour rafraichir les informations sur les membres du groupe et mettre à jour les routes.



70

Chaque nœud intermédiaire qui reçoit le paquet Join Query, enregistre l’adresse de son ascendant ainsi que le numéro de séquence et retransmet le paquet. Les paquets Join Query dupliqués sont détectés par l'intermédiaire du numéro de séquence.

Quand un récepteur multicast reçoit le paquet Join Query, il choisit le meilleur chemin, crée et broadcaste un paquet Join Reply à ses voisins. Ce Join Reply contient la source et le dernier saut de la source à lui-même.

Quand un nœud reçoit un Join Reply, il vérifie si son adresse figure dans le paquet. Si c’est le cas, il réalise qu’il est sur le chemin ver la source et met son flag FG_FLAG (Forwarding Group Flag) et broadcaste son propre Join Reply. De cette façon le Join Reply est propagé par chaque membre du group d’expédition jusqu'à ce qu'il atteigne la source de multicast via le chemin choisi [26].

Fig. IV.1 Fonctionnement d’ODMRP

IV.3.2 Format des paquets ODMRP

Le format des parquets ODMRP est comme suit :

Fig. IV.2 Format du paquet ODMRP Join Query

Fig. IV.3. Format du paquet ODMRP Join Reply

Type Reserved Time to live Hop Count

Multicast Group IP Address

Sequence Number

Source IP Address

Previous Hop IP Address

Type Reserved Time to live Hop Count Multicast Group IP Address

Sequence Number

Source IP Address

Next Hop IP Address



71

IV.3.3 Structures de données du protocole

La section suivante documente les différentes structures de données utilisées dans ODMRP.

a) Format des paquets du protocole :

• Le paquet Join Query se compose des champs suivants :

- Type: type du paquet ODMRP (Join Query)

- Reserved: non utilisé

- Time to Live: nombre de sauts maximum

- Hop Count: le nombre de sauts traversés jusqu'ici

- Multicast Group IP Address: adresse IP du groupe multicast

- Sequence Number: identificateur unique assigné par la source multicast

- Source IP Address: adresse IP de la source de multicast

- Previous Hop IP Address: adresse IP du saut précédent

• Le paquet Join Reply se compose des champs suivants :

- Type: type du paquet ODMRP (Join Reply)

- Reserved: non utilisé

- Time to Live: nombre de sauts maximum

- Hop Count: le nombre de sauts observé par l'abonné de multicast

- Multicast Group IP Address: adresse IP du groupe multicast

- Sequence Number: identificateur unique

- Source IP Address: adresse IP de l’émetteur du Join Reply

- Next Hop IP Address: adresse IP du prochain saut parent vers la source multicast



72

b) Le contenu des Tables

Les nœuds exécutants ODMRP doivent maintenir les tables suivantes [14] :

1. Table de routage

La table de routage est créée à la demande et maintenue par chaque nœud. Une entrée est insérée ou mise à jour quand un Join Query non-dupliqué est reçue. Le nœud stocke la destination (c.-à-d., la source de Join Query) et le prochain saut à la destination (c.-à-d., le dernier nœud qui a propagé le Join Query). La table de routage fournit les informations concernant les prochains sauts en transmettant les réponses Join Replies.

2. Table du groupe d’expédition (Forwarding Group)

Quand un nœud est un nœud de groupe d’expédition du groupe de multicast, il maintient l'information du groupe dans la table de groupe d’expédition. L’identificateur du group multicast et le temps où le nœud a été rafraichi pour la dernière fois sont enregistrés.

3. Cache du message

Le cache du message est maintenu par chaque nœud pour détecter les duplications. Quand un nœud reçoit un nouveau Join Query ou une donnée, il stocke l'adresse de source et l’identificateur unique du paquet. Notez que les entrées dans le cache de message n'ont pas besoin d'être maintenues de manière permanente. Des arrangements tels que LRU (Least Recently Used) ou FIFO (First In First Out) peuvent être utilisés pour expirer et enlever les anciennes entrées et pour empêcher la taille du cache de message d’être étendue.

IV.3.4 Inconvénient majeure d'ODMRP

L'émetteur de multicast doit périodiquement rafraichir le chemin d’expédition.

Afin de maintenir l'arbre de transmission, l'émetteur de multicast doit fréquemment rafraichir le chemin de transmission par l'envoi des paquets Join Query. Bien que ceci permette aux récepteurs multicast de découvrir de meilleurs chemins de transmission mais, il génère beaucoup de nouveaux nœuds intermédiaires donc, plus de ressources utilisées. En outre, un seul nœud se trouve avec plusieurs nœuds relayeurs pour le même trafic, ce qui augmente le nombre des paquets transmis et ainsi épuise les ressources des réseaux. L’augmentation du nombre de paquets transmis augmente la charge du réseau par des paquets redondants inutiles qui génèrent une congestion dans le réseau.

IV.4 Principe de fonctionnement d’OODMRP

Parmi les caractéristiques principales des réseaux maillés sans fil, nous citons la stabilité de la topologie du réseau puisque les nœuds intermédiaires sont généralement statiques. Dans ce contexte un meilleur protocole de routage est celui qui utilise un nombre minimum de nœuds relayeurs.



73

ODMRP forme des chemins multiples de transmission avec énormément de nœuds relayeurs, ce qui inonde le réseau par du trafic constitué de paquets redondants.

Notre démarche, concrétisée par le protocole OODMRP, consiste à réduire ce trafic inutile qui épuise les ressources du réseau par l’optimisation du nombre de nœuds relayeurs. Notre contribution se situe à deux niveaux :

1. Eliminer l’utilisation de plusieurs nœuds relayeurs pour le même trafic :

Si un nœud a déjà un nœud relayeur en amont il ne choisira pas un autre nœud qui n’est pas relayeur. En outre, il ne change pas un nœud relayeur par un autre non relayeur à la réception de nouveau Join Query.

2. Si un nœud veut joindre le groupe pour la première fois et que l’un de ses voisins est déjà un nœud relayeur, il s’attache directement à ce nœud.

A la réception d’un paquet Join Query, chaque nœud vérifie si le nœud transmetteur de ce paquet est un relayeur. Si c’est le cas il le choisit comme ascendant ver la source.

Si un nœud reçoit un Join Query d’un relayeur, il vérifie si l’ascendant enregistré dans sa table de routage n’est pas un relayeur. Si c’est le cas, il le remplace avec celui qui a transité ce Join Query.

Cette vérification permet de minimiser le nombre des nœuds relayeurs de flux et ainsi réduire la consommation des ressources et le nombre de paquets transmis sur le réseau.

Si un nœud devient relayeur pour la première fois, il envoie un paquet Session Exist aux voisins pour les informer qu’il est devenu un relayeur.

Pour expliquer les démarches du protocole nous présentons les deux algorithmes principaux ci-dessous :

Algorithme 1 : montre le traitement réalisé à la réception d’un paquet Join Query ainsi que les vérifications à faire et à quel moment il faux modifier le contenu de la table de routage.

A la réception du premier Join Query, le nœud rafraichit la table de routage, modifie le champ Session et retransmet le paquet. Si le nœud est un membre du groupe multicast et il envoie un JoinReply.

Si le nœud reçoit un autre Join Query d’un nœud relayeur, il vérifie si son ascendant n’est pas un nœud relayeur, si c’est le cas, il rafraichit sa table de routage. Si le nœud est un membre du groupe multicast, il envoie un JoinReply.



74

Algorithme1 handleJoinQueryReceipt

1: si (premier JoinQuery) alors

2: jq_table.enterInTable;

3: jr_table.lookupsession;

4: mettre à jour le champ session;

5: retransmettre le JoinQuery;

6: si (mcast_membership_table.lookup) alors

7: sendJoinReply;

8: fin si

9: sinon

10: si (1er JoinQuery provient d'un descendant) alors

11: si (ce nouveau JoinQuery ne provient pas d'un descendant) alors

12: jq_table.enterInTable;


14: sendJoinReply;

15: fin si

16: fin si

17: fin si

18: si (session = 1 de ce JoinQuery) alors

19: si (ce JoinQuery ne provient pas d'un descendant) alors

20: si (n’existe pas un ascendant avec session = 1) alors

21: jq_table.enterInTable ;


23: sendJoinReply;

24: fin si

25: fin si

26: fin si



75

29: fin si

Avec : jq_table.enterInTable : mettre l’adresse du nœud transmettant ce JoinQuery dans la table de routage.

jr_table.lookupsession : vérifier si le nœud est un nœud relayeur.

mcast_membership_table.lookup: vérifier si le nœud est un membre du groupe.

sendJoinReply: envoyer un JoinReply.

Algorithme 2 : montre le traitement réalisé à la réception d’un paquet SessionExist. Le but de cet algorithme est d’informer les nœuds voisins qu’un nœud est devenu relayeur. A la réception d’un paquet SessionExist, le nœud voisin qui n’a pas un ascendant relayeur, alors il met dans sa table de routage l’adresse de l’émetteur de ce SessionExist s’il ne provient pas d’un nœud descendant.

Algorithme2 handleSessionExist Receipt

1: si (le paquet SessionExist ne provient pas d'un descendant) alors

2: si (n’existe pas un ascendant avec session = 1) alors


5: jq_table.enterInTable2;

6: sendJoinReply;

7: fin si

8: fin si

9: fin si

Avec: jq_table.enterInTable2: mettre l’adresse du nœud relayeur de ce SessionExist dans la table

de routage.



76

Format des paquets OODMRP

Le protocole OODMRP comprend les trois messages suivant :

1. Le paquet Join Reply est identique à celui d’ODMRP.

2. Le paquet Join Query est modifié par l’insertion d’un nouveau champ Session. La valeur de Session est égale à 1 si le nœud transmetteur de ce paquet est déjà un nœud relayeur et à 0 dans le cas contraire.

Fig. IV.4 Format du paquet OODMRP Join Query

3. Le paquet Session Exist, c’est le paquet que nous avons ajouté, ce paquet est envoyé par un nœud dés qu’il devient un relayeur, il comprend les champs suivants :

Fig. IV.5 Format du paquet OODMRP Session Exist

IV.5 Différence entre ODMRP et OODMRP

Dans cette section, nous illustrons à travers un exemple la différence entre le protocole ODMRP et OODMRP.

IV.5.1 Fonctionnement d’ODMRP

Soient : S la source, N1, N2, N3 N4 et N5 des nœuds intermédiaires, R1 et R2 des récepteurs.

Le récepteur R1 joint le groupe et choisit N4 comme un nœud relayeur et le nœud N4 choisit a son tour N1 comme relayeur (fig. IV.6). Après la réception d’un nouveau Join Query, le récepteur R1 choisit N5 et ce dernier choisit N2 comme nœud relayeur.


Sequence Number Source IP Address

Previous Hop IP Address Session


Sequence Number Source IP Address

Previous Hop IP Address



77

Fig. IV.6 Le fonctionnement d’ODMRP (R1)

Après un certain temps, Le récepteur R2 joint le groupe et choisit N3 comme un nœud relayeur vers la source. Cet exemple montre que pour le même flux de donnée, on a plusieurs relayeurs pour un seul descendant. Dans la totalité on a 5 nœuds relayeurs générés par le protocole ODMRP transmettant le flux de données.

Fig. IV.7 Le fonctionnement d’ODMRP (R2)

IV.5.2 Fonctionnement d’OODMRP

Comme illustré dans fig. IV.8, le récepteur R1 joint le groupe et choisit N4 comme un nœud relayeur, le nœud N4 choisit N1 comme relayeur. Après la réception d’un nouveau Join Query, le récepteur R1 vérifie le champ Session de chaque Join Query. Le nœud R1 choisit N4 car le Join Query reçu de cet ascendant possède un champ Session égal à 1, contrairement à celui reçu de N5 qui vaut 0. Le nœud R1 choisit N4 comme ascendant puisqu’il est un nœud relayeur et la même chose pour N4 qui choisit à son tour N1.

Fig. IV.8 Le fonctionnement d’OODMRP (R1)

Après un certain temps, Le récepteur R2 joint le groupe et choisit N4 comme un nœud suivant vers la source puisqu’il est déjà un relayeur pour ce flux (fig. IV.9). Dans la totalité on a 2 nœuds intermédiaires transmettant le flux, donc on a une différence de 3 nœuds entre



78

OODMRP et ODMRP. Cet exemple montre la manière dont OODMRP optimise le nombre de nœuds relayeurs.

Fig. IV.9 Le fonctionnement d’OODMRP (R2)

Dans la section suivante nous abordons le critère de la consommation d’énergie dans les réseaux sans fil munies des sources d’énergie autonomes. Dans ce type d’alimentation limitée, la consommation d’énergie doit être prise en compte au niveau du routage afin de préserver les ressources énergétiques et augmenter la durée de vie du réseau.

IV.6 Consommation d’énergie

La consommation d’énergie représente une contrainte très importante dans les réseaux sans fil utilisant des sources d’énergie autonome (batterie).

La fonction d’énergie

Elle calcule l’énergie consommée en réception et en transmission pour chaque nœud et retourne le résultat de la consommation d’énergie.

Le calcule de l’énergie se fait selon l’équation de la consommation d’énergie suivante :

Avec Tx : Transmission, Rx : réception. L’énergie consommée pour émettre un message de k bits sur une distance d est donnée par la formule suivante :

( ) ),()(, dkEkEdkE ampTxTxTx += [27](I.1)

L’énergie consommée pour recevoir un message de k bits est donnée par la formule suivante :

elecRx EkkE ×=)( [27](I.2) Avec :

elecE énergie électrique de transmission/réception

K taille d’un message D distance entre l’émetteur et le récepteur

ampTxE énergie d’amplification



79

Par conséquent, l’énergie consommée pour la transmission d’un message de k bits entre deux nœuds avec une distance d est égale à :

( ) ( ) ( )kEdkEkEE

kEdkEkEEkEdkEE

elecampTxelecTotal

RxampTxTxTotal

RxTxTotal

×+××+×=

++=+=

2

)(),()()(),(

[27](I.3)

On remarque que la transmission est l’opération qui consomme le plus d’énergie à cause du facteur d’amplification.



80

IV.7 Conclusion

La communication multicast est un domaine de recherche très actif, où l’objectif principal demeure la réalisation des mécanismes de routage tout en préservant les ressources limitées du réseau joue un rôle important dans les prochains réseaux de communication.

Notre étude repose essentiellement sur ce problème où le but de notre travail est de réduire les ressources utilisées ainsi que le trafic total sur le réseau.

La conclusion générale que nous pouvons tirer de l'étude des différentes stratégies, est que la conception d'un protocole de routage pour les réseaux sans fil doit tenir compte de tous les facteurs et limitations physiques imposés par l'environnement afin que la stratégie de routage ne dégrade pas les performances du système.

Le protocole que nous avons proposé OODMRP est implémenté dans le simulateur réseaux NS2, connu par son efficacité et ses résultats proches de ceux obtenus dans un environnement réel.


Chapitre V: Simulations et résultats

81

Chapitre V

Simulations et résultats

V.1 Introduction

Les protocoles de routage doivent être évalués afin de mesurer les performances de la stratégie utilisée et de tester sa fiabilité. L'utilisation d'un réseau sans fil réel dans une évaluation est difficile et coûteuse, en outre de telles évaluations ne donnent généralement pas des résultats significatifs. Le réseau réel n'offre pas la souplesse de varier les différents paramètres de l'environnement et pose en plus le problème d'extraction de résultats, c'est pour cela que la majorité des travaux d'évaluation de performances utilisent le principe de simulation vu les avantages qu'il offre.

En effet, la simulation permet de tester les protocoles sous une variété de conditions. Durant ces simulations on doit varier les différents facteurs de l'environnement tels que le nombre d'unités, le nombre de nœuds récepteurs, le territoire du réseau et la distribution des unités dans ce territoire.

Après l’implémentation d’OODMRP sous le simulateur NS2, nous avons modélisé quelques scénarios pour évaluer le fonctionnement de notre protocole OODMRP par rapport au protocole d’origine ODMRP.



82

V.2 Description de la simulation

La simulation est l’un des moyens qui permettent de maîtriser la complexité des systèmes, et les motivations qui poussent à y recourir peuvent être multiples :

- On peut simuler pour comprendre le fonctionnement d'un système afin d'en formuler et d'en mettre au point les lois d'évolutions, c'est toute la problématique de la simulation des phénomènes physiques, le simulateur dans ce cas à pour rôle de permettre la mise au point d'un modèle.

- On peut simuler pour évaluer de manière prédictive le comportement d'un système, ou l'impact sur ce comportement d'une modification d'une partie d'un système existant. Le simulateur devient dans ce cas un outil de conception et de validation.

L'approche simulation trouve toute sa justification dans l'ingénierie des systèmes complexes pour lesquels il est difficile d'avoir une vision globale, même si l'on est capable d'appréhender chacun des composants pris individuellement [12].

V.3 Description du simulateur NS2

a) Présentation

NS [28], [29] est un outil logiciel de simulation de réseaux informatiques. Il est principalement bâti avec les idées de la conception par objets, de réutilisabilité du code et de modularité. Il est devenu aujourd'hui un standard de référence en ce domaine. C'est un logiciel dans le domaine public disponible sur l'Internet. Son utilisation est gratuite. Le logiciel est exécutable tant sous Unix que sous Windows.

Le simulateur NS actuel est particulièrement bien adapté aux réseaux à commutation de paquets et à la réalisation de simulations de petite taille. Il contient les fonctionnalités nécessaires à l'étude des algorithmes de routage unipoint ou multipoint, des protocoles de transport, de session, de réservation, des services intégrés, des protocoles d'application comme HTTP. De plus le simulateur possède déjà une palette de systèmes de transmission (l'architecture TCP/IP), d'ordonnanceurs et de politiques de gestion de files d'attente pour effectuer des études de contrôle de congestion [30].

Prises ensembles, ces capacités ouvrent le champ à l'étude de nouveaux mécanismes au niveau des différentes couches de l'architecture réseau. NS est devenu l'outil de référence pour les chercheurs du domaine. Ils peuvent ainsi partager leurs efforts et échanger leurs résultats de simulations. Cette façon de faire se concrétise aujourd'hui par l'envoi dans certaines listes de diffusion électronique de scripts de simulations [31] NS pour illustrer les points de vue.

NS2 utilise des scriptes en TCL pour simuler des scénarios. TCL est un langage de commande comme le shell UNIX. Son nom signifie Tool Command Language. TCL offre des structures de programmation telles que les boucles, les procédures ou les notions de variables.



83

b) Format des résultats

Après avoir exécuté une simulation à partir d’un fichier TCL décrivant le scénario, NS génère un fichier texte (appelé fichier trace) décrivant précisément l’avancement des paquets au sein du réseau de la simulation. En effet, chaque ligne représente un paquet envoyé, éliminé, retransmit ou reçu par un nœud du réseau.

Le plus important dans une étude telle que la notre est l’analyse des résultats recueillis. Nous avons utilisé le langage awk1 pour extraire les résultats à partir du fichier trace [32].

V.4 Implémentation d’ODMRP sous ns2

L’outil choisi pour la simulation est Network Simulator (NS2) un simulateur open source très réputé dans les recherches concernant les réseaux filaires et sans fil.

Le groupe de recherche “Carnegie Mellon University’s Monarch Research Group” [23] a développé plusieurs protocoles de routage pour les réseaux sans fil, incluant le protocole ODMRP pour ns2. L’implémentation d’OODMRP est basée sur cette implémentation de référence d’ODMRP.

Les fichiers suivants définissent les classes correspondantes pour l'exécution d'ODMRP (figure V.1).

• defs.h - Définit les différents paramètres du protocole

• hdr odmrp.h/cc - Définit l’en-tête du paquet ODMRP (hdr odmrp class)

• odmrpagent.h/cc - Définit le nœud ODMRP (ODMRPAgent class)

• msg cache.h/cc - Définit le cache du paquet (MSGCache class)

• mem table.h/cc - Définit la table du membre ODMRP (McastMemberTable class)

• packet buffer.h/cc - Définit le buffer du paquet (PacketBuffer class)

• jq table.h/cc - Définit la table de la recherche du Join Query (JQTable class)

• jr table.h/cc - Définit la table de la recherche du JoinReply (JRTable class)

• join query timer.h/cc - Définit le temporisateur du Join query (JoinQueryTimer class)

• join reply timer.h/cc - Définit le temporisateur du JoinReply (JoinReplyTimer class)

1 http://www.gnu.org/software/gawk/manuel/gawk.html



84

Fig. V.1 Vue simplifier de l’interaction entre les classes

V.4.1 L’agent ODMRP Dans le simulateur ns2, les points finaux où des paquets du réseau sont consommés ou construits s'appellent agents. Par conséquent la classe ODMRPAgent définit les points finaux du réseau pour le protocole ODMRP. La classe ODMRPAgent hérite de la classe générique d'agent et ODMRPAgent maintient sa table de routage comme un ensemble de tables (hash tables), qui sont définies dans les classes JQTable et JRTable. Les classes JoinQueryTimer et JoinReplyTimer définissent les temporisateurs du rafraichissement des routes et les temporisateurs d'expiration des routes. Dans ns2, chaque nœud est lié à un agent. L'agent peut manipuler des événements et envoyez/recevez des paquets [33]. V.4.2 L'en-tête du paquet ODMRP L'en-tête du paquet ODMRP est défini comme un emballage pour les deux paquets Join Query et Join Reply. Ce concept suit la convention de programmation de ns2, où chaque protocole est défini avec un en-tête simple du paquet. L'en-tête du paquet ODMRP est défini dans la classe hdr odmrp. class hdr_odmrp {

private:

int valid_ack_;

odmrpaddr_t mcastgroup_addr_;

odmrpaddr_t prev_hop_addr_;

struct odmrp_join_query join_query_;

struct odmrp_join_reply join_reply_;}



85

Métriques de performance

Les paramètres mesurés dans une évaluation dépendent de la stratégie de routage appliquée, notre simulation doit être en mesure d'évaluer :

- Le nombre de nœuds relayeurs: le nombre total des nœuds relayeurs dans le réseau.

- Le nombre de paquets expédiés: le nombre de paquets de données retransmis est le nombre total des paquets de données retransmis par les nœuds relayeurs.

- Le délai moyen du transfert d’un paquet de données: c’est le délai moyen pris par un paquet de donnée pour transiter d’une application à une autre. Il permet de nous renseigner sur la durée moyenne nécessaire pour transmettre un paquet de donnée de bout en bout.

- L’énergie consommée: l’énergie consommée en réception et en transmission par tous les nœuds du réseau.

- La perte des paquets: le nombre des paquets émis par la source et non reçus par le destinataire.

- Le débit moyen: quantité d'information empruntant un canal de communication pendant un intervalle de temps.

Paramètre Valeur Temps de simulation 100 s Taille de la topologie 1200x800 m

Nombre de nœuds 7,15, 20,50,70 et 100 Nombre de sources 1 et 2

Taille du paquet 64 et 512 octet Type du trafic CBR

Intervalle de transmission 0.25 et 0.05

Tab. V.1 Un sommaire des paramètres de simulation

Avec : CBR : Le trafic UDP est de type CBR (Constant Bit Rate).

Intervalle de transmission : l'intervalle entre chaque transmission de paquets.

V.5 Résultats de la simulation

Nous avons simulé 6 réseaux avec 7, 15, 20, 50,70 et 100 nœuds, dans le cas ou chaque réseau contient un seul récepteur et dans le cas de plusieurs récepteurs. Pour chaque scénario nous avons deux résultats, un pour le protocole OODMRP et un pour le protocole d’origine ODMRP.



86

V.5.1 Un seul récepteur

1. Le nombre de nœuds relayeurs

La figure V.2 montre le nombre des nœuds relayeurs générés par le protocole ODMRP et OODMRP, nous observons qu’OODMRP a réduit significativement le nombre des nœuds relayeurs de 66% pour un réseau de 7 nœuds jusqu’à 78% pour un réseau de 100 nœuds par rapport à ODMRP. Nous remarquons que la réduction augmente avec la croissance de la taille du réseau.

Fig. V.2 Le nombre de nœuds relayeurs pour un seul récepteur

2. Le nombre de paquets expédiés

Nous avons vu précédemment qu’OODMRP réduit le nombre des nœuds relayeurs. Par conséquent, il génère moins de paquets retransmis sur le réseau et moins de traitement au niveau des nœuds (fig. V.3).

Fig. V.3 Le nombre de paquets expédiés pour un seul récepteur

V.5.2 Plusieurs récepteurs

Dans cette section nous allons évaluer la performance des protocoles dans le cas de plusieurs récepteurs.

0102030405060

0 20 40 60 80 100 120

Le n

ombr

e de

nœ

uds

rela

yeur

s

Taille du réseau

ODMRP

OODMRP

0

1000

2000

3000

4000

0 20 40 60 80 100 120

Le n

ombr

e de

paq

uets

ex

pédi

és

Taille du réseau

ODMRP

OODMRP



87

1. Le nombre de nœuds relayeurs

La figure V.4 montre les résultats des simulations dans le cas de plusieurs récepteurs, nous observons qu’OODMRP a réduit également le nombre des nœuds relayeurs de 66% pour un réseau de 7 nœuds jusqu’à 76% pour un réseau de 100 nœuds par rapport à ODMRP. Dans le cas de plusieurs récepteurs le nombre de nœuds relayeurs augmente légèrement par rapport à un seul récepteur, par exemple pour un réseau de 20 nœuds avec un seul récepteur nous avons 9 nœuds relayeurs pour ODMRP et 4 pour OODMRP, dans le cas de plusieurs récepteurs nous avons 13 nœuds relayeurs pour ODMRP et 6 pour OODMRP, cette augmentation est relative au nombre croissant des récepteurs sur le réseau.

Fig. V.4 Le nombre de nœud relayeurs dans le cas de plusieurs récepteurs

2. Le nombre de paquets expédiés

La figure V.5 montre qu’OODMRP réduit le nombre de paquets transmis sur le réseau dans le cas de plusieurs récepteurs suite à la réduction du nombre de nœuds relayeurs.

Fig. V.5 Le nombre de paquets expédiés dans le cas plusieurs récepteurs

3. Le délai moyen

La figure V.6, montre qu’il n’y a pas une grande différence entre le délai du protocole ODMRP et OODMRP, malgré que le but principal d’ODMRP est de réduire le délai par tous les moyens, ce qui génère un grand nombre de nœuds relayeurs.

0

20

40

60

80

100

0 20 40 60 80 100 120Le n

ombr

e de

nœ

uds

rela

yeur

s

Taille du réseau

ODMRP

OODMRP

0

2000

4000

6000

8000

0 20 40 60 80 100 120Le n

ombr

e de

paq

uets

ex

pédi

és

Taille du réseau

ODMRP

OODMRP



88

Fig. V.6 Le délai moyen

Le cas de deux sources

Dans cette section nous allons présenter le comportement du délai dans le cas de deux sources émettrices sous différents scénarios.

a) avec des paquets de 64 octets

La figure suivante illustre le délai moyen généré dans le cas de deux sources transmettant des paquets de 64 octets. Nous constatons qu’il y a une légère différance entre le délai moyen généré par le protocole ODMRP et celui généré par OODMRP.

Fig. V.7 Le délai moyen avec 2 sources

b) avec des paquets de 512 octets

Dans cette section nous allons présenter le comportement du délai dans le cas de deux sources émettrices et en augmentant la charge du trafic, avec un intervalle de transmission de 0.25 et de 0.05.

• avec un intervalle de transmission de 0.25

La figure V.8, montre que le délai moyen généré par notre protocole OODMRP réalise une diminution de 14% par rapport au délai généré par ODMRP en transmettant des paquets de 512 octets.

0,000000

0,005000

0,010000

0,015000

0 20 40 60 80 100 120Le d

élai

moy

en (s

ec)

Taille du réseau

ODMRP

OODMRP

0,000000

0,005000

0,010000

0,015000

Le d

élai

moy

en (s

ec)

ODMRP

OODMRP



89

Fig. V.8 Le délai moyen avec 2 sources (intervalle de transmission = 0.25)

• avec un intervalle de transmission de 0.05

La figure suivante illustre le délai moyen généré en diminuant l’intervalle de transmission à 0.05. Nous remarquons que notre protocole OODMRP génère un délai moyen moins de 57% du délai moyen généré par le protocole d’origine ODMRP.

Fig. V.9 Le délai moyen avec 2 sources (intervalle de transmission = 0.05)

Les résultats de la simulation montrent que l’augmentation de la charge du réseau dégrade rapidement le délai moyen généré par le protocole ODMRP, contrairement à notre protocole qui a résisté à cette augmentation. Cela peut être expliqué par le fait qu’ODMRP utilise plusieurs nœuds relayeurs pour le même flux. Un nœud relayeur est chargé de la transmission de deux flux en même temps ce qui épuise la bande passante. Or notre protocole génère un minimum de nœuds relayeurs et laisse les autres nœuds libres pour d’autres trafics.

La charge du réseau est donc partagée sur les nœuds ce qui préserve la bande passante et réduit la congestion du réseau et ainsi la perte des paquets.

4. Calcule de l’énergie consommée

Dans cette section nous allons calculer l’énergie totale consommée sur le réseau, l’énergie moyenne et l’écart type.

0

0,005

0,01

0,015

0,02

0,025

Le d

élai

moy

en (s

ec)

ODMRP

OODMRP

0

0,02

0,04

0,06

0,08

Le d

élai

moy

en (s

ec)

ODMRP

OODMRP



90

a) Energie totale

Nous remarquons dans la figure suivante la diminution des la consommation d’énergie sur le réseau pour le protocole OODMRP. Cela peut être expliqué par la réduction du nombre de nœuds relayeurs et ainsi le nombre de paquets expédiés. OODMRP réalise une réduction de 24% à 32% par rapport à ODMRP.

Fig. V.10 Energie totale

b) Énergie moyenne

La figure suivante illustre la différence d’énergie moyenne entre OODMRP et ODMRP, nous remarquons que l’énergie moyenne d’OODMRP est inférieure à celle d’ODMRP dans les 6 cas.

Fig. V.11 Energie moyenne

c) Ecart type

Comme c’est montré dans (fig. V.12), l’écart type de l’énergie consommée d’OODMRP est supérieur à celui d’ODMRP. OODMRP sollicite les mêmes nœuds plus souvent, ODMRP répartit plus la charge du trafic sur plus de nœuds.

0

1E+10

2E+10

3E+10

4E+10

0 20 40 60 80 100 120

Éner

gie

tota

le( n

j/bi

t)

Taille du réseau

ODMRP

OODMRP

0,00E+00

2,00E+08

4,00E+08

6,00E+08

8,00E+08

0 20 40 60 80 100 120Éner

gie

moy

enne

(nj/

bit)

Taille du réseau

ODMRP

OODMRP



91

Fig. V.12 Écart type

5. La perte moyenne des paquets

La perte moyenne des paquets avec OODMRP est inférieure à celle d’ODMRP. OODMRP réalise une réduction de 4% jusqu' à 14% qu'ODMRP. Cette réduction de perte des paquets augmente avec l’accroissement de la charge du trafic. Ce la peut être expliqué par le fait qu’OODMRP minimise le nombre des paquets expédiés ce qui réduit la congestion du réseau et ainsi la perte des paquets.

Fig. V.13 La perte moyenne des paquets

6. Le débit moyen

Nous remarquons qu’il n’y a pas une différence importante entre le débit moyen d’OODMRP et celui d’ODMRP (fig. V.14). L’amélioration des performances vue précédemment n’a pas dégradé le débit moyen.

Fig. V.14 Le débit moyen

0,00E+00

2,00E+08

4,00E+08

6,00E+08

8,00E+08

0 20 40 60 80 100 120

Ecar

t ty

pe

Taille du réseau

ODMRP

OODMRP

0

200

400

600

800

4096 32768 163840

La p

erte

moy

enne

des

pa

quet

s

La charge du trafic (bits/sec)

ODMRP

OODMRP

0500

1000150020002500

0 20 40 60 80 100 120

Le d

ébit

moy

en(b

it/s

ec)

Taille du réseau

ODMRP

OODMRP



92

V.6 Conclusion

Nous avons présenté dans un premier lieu la conception et le développement du protocole ODMRP, un protocole multicast pour les réseaux sans fil. Dans un second lieu, nous avons présenté notre protocole proposé OODMRP, vise à préserver les ressources limitées du réseau en réduisant le nombre des nœuds relayeurs et ainsi la charge du réseau.

Les résultats de simulation indiquent que notre protocole OODMRP réduit d’une façon considérable le nombre des nœuds relayeurs, ainsi que le nombre des paquets expédiés sur le réseau tout en construisant un arbre efficace de multicast. Nous avons constaté aussi que le délai moyen d’OODMRP résiste à l’augmentation de la charge du réseau contrairement à ODMRP.


Conclusion générale et perspectives

93


Le routage multicast dans les réseaux sans fil est une thématique complexe étant donné les propriétés particulières de ce type de réseaux et ses ressources limitées. Les protocoles de routage proactifs ou réactifs essaient de s'adapter aux contraintes imposées par ce type de réseaux, et cela en proposant une méthode qui soit de moindre coût en capacités et ressources.

Le multicast constitue une application parmi le spectre d’applications que peut prendre en charge un réseau sans fil. Par conséquent, la stratégie de conception d’un nouveau protocole de routage doit tenir compte de tous les facteurs et limitations physiques imposés par l'environnement afin que la fonctionnalité «routage» ne dégrade pas les performances du système.

La conception d’un protocole de routage, qui fait l’objet de ce présent travail, a été guidée par une nécessité d’économiser le nombre de nœuds relayeurs et par conséquent le nombre de paquets expédiés afin de garantir une meilleure utilisation des ressources.

La solution proposée a été entièrement simulée sous NS2 afin d’évaluer les performances de notre protocole par une confrontation des résultats obtenus avec celles du protocole d’origine sous les mêmes conditions de simulation.

Les résultats obtenus démontrent globalement que notre protocole parvient à faire diminuer de manière considérable le nombre de nœuds relayeurs et le nombre de paquets transférés, ce qui permet de réduire la charge du réseau et contribue à la diminution du délai de bout en bout.

Notre travail offre plusieurs vois d’exploration pour des travaux futurs. En ce qui concerne l’amélioration de notre protocole, nous proposons :

En premier la gestion de la qualité de service dans le cadre des applications multimédia communicantes devra être pris en charge par des mécanismes tels que le contrôle d’admission, la réservation de la bande passante sur un chemin réseau, ou encore le polissage et la régulation des flux de trafic.

Un deuxième aspect qui peut être amélioré consiste à prendre en considération l’interaction entre la couche MAC et la couche réseau et son effet sur la performance du protocole de routage. En effet, une connaissance précise et actualisée de l’environnement contexte dans lequel évoluent les terminaux mobiles permet d’utiliser de manière plus rationnelle les ressources disponibles. Nous pouvons proposer également comme perspective, l’équilibrage de la charge sur les différents chemins que peut emprunter un paquet de multicast dans un réseau sans fil.



94

Enfin, le présent travail peut être enrichi par l’ajout de la fonctionnalité de sécurité. Cet aspect très important représente la méthode employée pour la gestion des clés de cryptage de données entre la source et les nœuds du groupe multicast. Sa mise en place devrait se faire en parallèle du processus de gestion de routage au sein du réseau. L’idée est donc, d’implémenter un algorithme de calcul de ces clés dans la table de routage multicast de chaque nœud de façon a attribué pour chacun une clé unique de cryptage de données transmis par la source.


Bibliographie

95

Bibliographie

[1] J. Anzevui. Les réseaux sans fil. Projet de semestre. Université de Genève, 2006-2007.

[2] F. Di Gallo. Wifi l’essentiel qu’il faut savoir…. Extraits de source diverses récoltées en 2003.

[3] T. Lemlouma. Le Routage dans les Réseaux Mobiles Ad Hoc. Thèse de magister, Université des Sciences et de la Technologie Houari Boumèdiene, Institut d'Informatique, 2000.

[4] M. Bezahaf, P. E. Le Roux, M. Dias de Amorim, S. Fdida, L. Iannone. Open Issues in Wireless Mesh Networks. Université Pierre et Marie Curie, Laboratoire LIP6 /CNRS – France, IP Networking Lab (INL) – Belgium.

[5] I. F. Akyildiz, X. Wang, W. Wang. Wireless mesh networks: a survey. Broadband and Wireless Networking (BWN) Lab, School of Electrical and Computer Engineering, Georgia Institute of Technology, Atlanta, GA 30332, USA, Kiyon, Inc, 4225 Executive Square, Suite 290, La Jolla, CA 92037, USA, 2005.

[6] B. Hilt, A. Kaiser. Le routage multicast. Rapport de recherche. Université de Haute Alsace, Département R&T et MIPS Colmar, France.

[7] D. Minoli. Ip multicast with applications to IPTV and mobile dvb-h. Copyright 2008 John Wiley & Sons, Inc. Pages 26–60.

[8] B. Cousin. Le multicast. IFSIC - Université Rennes I, 2007.

[9] B. Cousin. Les protocoles de routage multicast. IFSIC - Université de Rennes I, 2007.

[10] E. Royer, C. E. Perkins. Multicast operation of the ad-hoc on-demand distance Vector routing protocol. Proc. Of the 5th ACM/IEEE Annual Conf. On Mobile Computing and Networking, 1999.

[11] E. Cheng. On-demand multicast routing in mobile ad hoc networks, M.Eng. Thèse, Carleton University, Département des systèmes informatiques, 2001.

[12] A. Zebdi. DZ-MAODV : nouveau protocole de routage multicast pour les réseaux ad hoc mobiles basé sur les zones denses. L’université du Québec à Trois- Rivières, 2006.

[13] J. Garcia-Luna-Aceves, E. Madruga. The core assisted mesh protocol. IEEE Journal on Selected Areas in Communications, 1999.

[14] S. J. Lee, W. Su, and M. Gerla. On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc Network. IETF Internet Draft. July 2000.

[15] Anne Benoit. Réseaux sans fil. Notes de cours (ENS Lyon, M1), 2006.

[16] H. Moustafa. Routage unicast et multicast dans les réseaux mobiles ad hoc. Thèse de doctorat de l’Ecole Nationale Supérieure des Télécommunications, Informatique et Réseaux, 2004.

[17] L. Zhao, A. Al-Dubai , X. Liu. A new multicast routing algorithm for the Wireless Mesh Networks. School of Computing, Napier University10 Clinton Road, Edinburgh EH10 5DT, UK, 2008.


Bibliographie

96

[18] G. Zeng, B. Wang, Y. Ding, L. Xiao, M. Mutka. Multicast Algorithms for Multi-Channel Wireless Mesh Networks. Department of Computer Science and Engineering Michigan State University, in Network Protocols, ICNP 2007, pp. 1-10.

[19] G. Chelius, E. Fleury. Critères d’évaluation d’arbres multicast ad hoc. Rapport de recherche. CITI INSA de Lyon – ARES INRIA Rhône-Alpes.

[20] E. M. Royer, C. E. Perkins. Multicast Operation of the Ad-hoc On-Demand Distance Vector Routing Protocol. Proceeding of ACM MOBICOM 1999, pp. 207-218, August, 1999.

[21] S. Ho Bae, S. Lee, W. Su, M. Gerla. The Design, Implementation, and Performance Evaluation of the On-Demand Multicast Routing Protocol in Multihop Wireless Networks. In IEEE Network Magazine, volume 14, pages 70–77, January 2000.

[22] S. Lee, M. Gerla, and C. Chain. On-Demand Multicast Routing Protocol - (ODMRP). In Proc. Of the IEEE Wireless Communication and Networking Conference (WCNC), September 1999.

[23] Monarch Research Group. Rice Monarch Project Software Distributions. Retrieved March 01, 2006, from http://www.monarch.cs.cmu.edu/software.html.

[24] J.G. Jetcheva, D. B. Johnson. Adaptive Demand-Driven Multicast Routing in Multi- hop Wireless Ad Hoc Networks. ACM mobihoc 2001, Long Beach, CA, USA, 2001.

[25] J. J. Garcia-Luna-Aceve, E. L. Madruga. The Core Assisted Mesh Protocol. IEEE Journal on Selected Areas in Communications, Special Issue on Ad-Hoc Networks,vol. 17, no. 8, pages 1380 - 1394, August 1999.

[26] S. Roy, D. Koutsonikolas, S. Das, Y. C. Hu. High- throughput multicast routing metrics in wireless mesh networks. School of Electrical and Computer Engineering, Purdue University, West Lafayette, IN 47907, United States, 22 July 2007.

[27] K. Fellah. Techniques d’optimisation pour l’économie d’énergie dans les réseaux de capteurs sans fil, thèse de magister, Université d’Oran, 2008.

[28] K. Fall, K. Vradhan, Oct. 1998. Http://www-mash.cs.berkeley.edu/ns/nsdoc.ps.gz. NS Notes and Documentation.

[29] M. Greis. Oct. 1998. Http://titan.cs.uni-bonn.de/~greis/ns/ns.html NS Tutorial.

[30] P. Anelli et E. Horlait. NS-2: Principes de conception et d'utilisation. UPMC - LIP6, 15 Septembre 1999.

[31] K. Fall, K. Varadhan. The ns Manual (formerly ns Notes and Documentation). The VINT Project A Collaboration between researchers at UC Berkeley, LBL, USC/ISI, and Xerox PARC, January 6, 2009.

[32] The VINT project. The network simulator (ns-2). Retrieved December 12, 2005, from Http://www.isi.edu/nsnam/ns.

[33] L. Cheng. Lightweight Service Advertisement and Discovery in Mobile Ad hoc Networks. Director, Laboratory Of Networking Group, Department of Computer Science and Engineering, P.C. Rossin College of Engineering & Applied Science, Lehigh University,April 22, 2005.


Annexe A : Exemple de scripte TCL

97

Annexe A Exemple de scripte TCL

# ====================================================================== # Default Script Options # ====================================================================== set opt(chan) Channel/WirelessChannel set opt(prop) Propagation/TwoRayGround set opt(netif) Phy/WirelessPhy set opt(mac) Mac/802_11 set opt(ifq) Queue/DropTail/PriQueue set opt(ll) LL set opt(ant) Antenna/OmniAntenna set opt(x) 670 ;# X dimension of the topography set opt(y) 670 ;# Y dimension of the topography set opt(cp) "" ;# "../mobility/scene/cbr-3-test" set opt(sc) "" ;# "../mobility/scene/scen-3-test" set opt(ifqlen) 50 ;# max packet in ifq set opt(nn) 3 ;# number of nodes set opt(nia) 0 ;# number of interference nodes set opt(seed) 0.0 set opt(stop) 300.0 ;# simulation time set opt(tr) out.tr ;# trace file set opt(rp) "" ;# routing protocol script set opt(is) "" ;# interference scenario set opt(lm) "off" ;# log movement set opt(uni) "" # ported: start set opt(mg) "" ;# multicast group scenario set opt(noclobber) 0 ;# clobber existing trace files? set opt(slaver) "" ;# remote drive an ad-hockey at this ip addr set opt(cmd) "" ;# shell cmd to run before ns start set opt(progress) 4 ;# how many progress markers to show set opt(imep) "OFF" set opt(debug) "OFF" set opt(errmodel) "" ;# for errmodel set opt(em) "" ;# set to name of errmodel file # ported: end # ====================================================================== set AgentTrace ON Simulator set AgentTrace_ ON set RouterTrace ON Simulator set RouterTrace_ ON set MacTrace OFF



98

Simulator set MacTrace_ OFF set IFTrace OFF ;# ported: for incoming packets only Simulator set IFTrace_ OFF ;# ported: for incoming packets only # ported: start #LL set mindelay_ 25us #LL set maxdelay_ 50us # ported: end LL set mindelay_ 25us LL set maxdelay_ 50us LL set bandwidth_ 0 ;# not used Agent/Null set sport_ 0 Agent/Null set dport_ 0 Application/Traffic/CBR set sport_ 0 Application/Traffic/CBR set dport_ 0 Agent/TCPSink set sport_ 0 Agent/TCPSink set dport_ 0 Agent/TCP set sport_ 0 Agent/TCP set dport_ 0 Agent/TCP set packetSize_ 1460 Queue/DropTail/PriQueue set Prefer_Routing_Protocols 1 # ported: start # These binary variables indicate whether or not DROP CMU Trace # objects will log all 'drop' events or not. If they are configured # not to log all drops, then the only events that are logged are # DROP_END_OF_SIMULATION events. This option is provide so that, # for example, when "MacTrace" is turned OFF (see above), end # of simluation drops still get written to the trace file. # CMUTrace set agt_log_all_drops_ 1 ;# agent CMUTrace set arp_log_all_drops_ 1 ;# ARP layer CMUTrace set ifp_log_all_drops_ 1 ;# Network Interface CMUTrace set ifq_log_all_drops_ 1 ;# Interface Queue CMUTrace set mac_log_all_drops_ 1 ;# MAC layer CMUTrace set rtr_log_all_drops_ 1 ;# Routing layer CMUTrace set sch_log_all_drops_ 1 ;# NS Scheduler CMUTrace set trp_log_all_drops_ 1 ;# ??? # ====================================================================== # Parameters for the "Managers" to determine what gets logged when... # ====================================================================== #PriQueue set qlen_logthresh_ 10 ;# min queue size to log #PriQueue set fw_logthresh_ 25 ;# min forwards to log



99

#Manager/Mac set intvl_ 10 ;# invoke handle every "n" seconds #Manager/Mac set log_macair_ 0 ;# enable/disable airtime logging #Manager/Mac set log_macmib_ 1 ;# enable/disable mib logging #Manager/PriQueue set intvl_ 1 ;# invoke handle every "n" seconds #Manager/Channel set intvl_ 1 ;# invoke handle every "n" seconds #Manager/NetIf set intvl_ 1 ;# invoke handle every "n" seconds #Manager/Node set intvl_ 10 ;# invoke handle every "n" seconds #Manager/Node set log_movement_ 0 ;# enable/disable movement logging # ====================================================================== # ====================================================================== # this is probably just for the emulation if [TclObject is-class Scheduler/RealTime] { Scheduler/RealTime set maxslop_ 10 } # ported: end # unity gain, omni-directional antennas # set up the antennas to be centered in the node and 1.5 meters above it Antenna/OmniAntenna set X_ 0 Antenna/OmniAntenna set Y_ 0 Antenna/OmniAntenna set Z_ 1.5 Antenna/OmniAntenna set Gt_ 1.0 Antenna/OmniAntenna set Gr_ 1.0 # jj: not sure how this physical model compares to the one used in the original # monarch extensions -- need to check the code... # Initialize the SharedMedia interface with parameters to make # it work like the 914MHz Lucent WaveLAN DSSS radio interface Phy/WirelessPhy set CPThresh_ 10.0 Phy/WirelessPhy set CSThresh_ 1.559e-11 Phy/WirelessPhy set RXThresh_ 3.652e-10 Phy/WirelessPhy set Rb_ 2*1e6 Phy/WirelessPhy set Pt_ 0.2818 Phy/WirelessPhy set freq_ 914e+6 Phy/WirelessPhy set L_ 1.0 set channel_(0) [new $opt(chan)] # ====================================================================== proc usage { argv0 } { puts "Usage: $argv0" puts "\tmandatory arguments:"



100

puts "\t\t\[-x MAXX\] \[-y MAXY\]" puts "\toptional arguments:" puts "\t\[-mg mcast scenario\]"; puts "\t\[-is interference scenario\]"; puts "\t\t\[-cp conn pattern\] \[-sc scenario\] \[-nn nodes\]"; puts "\[-nia number of interference agents\]\n"; puts "\t\t\[-seed seed\] \[-stop sec\] \[-tr tracefile\]\n" } proc getopt {argc argv} { global opt lappend optlist cp nn seed sc stop tr x y for {set i 0} {$i < $argc} {incr i} { set arg [lindex $argv $i] if {[string range $arg 0 0] != "-"} continue set name [string range $arg 1 end] set opt($name) [lindex $argv [expr $i+1]] } } proc cmu-trace { ttype atype node } { global ns_ tracefd if { $tracefd == "" } { return "" } set T [new CMUTrace/$ttype $atype] $T target [$ns_ set nullAgent_] $T attach $tracefd $T set src_ [$node id] $T node $node return $T } proc stop {} { global ns_ f nf $ns_ flush-trace close $f close $nf } proc create-god { nodes } { global ns_ god_ tracefd set god_ [new God] $god_ num_nodes $nodes }



101

proc log-movement {} { global logtimer ns_ ns set ns $ns_ source ../mobility/timer.tcl Class LogTimer -superclass Timer LogTimer instproc timeout {} { global opt node_; for {set i 0} {$i < $opt(nn)} {incr i} { $node_($i) log-movement } $self sched 0.1 } set logtimer [new LogTimer] $logtimer sched 0.1 } # ====================================================================== # Main Program # ====================================================================== getopt $argc $argv # ported: start if { $opt(em) == "" } { puts "*** no errormodel specified." set opt(errmodel) "none" } else { source $opt(em) } # ported: end # # Source External TCL Scripts # source tcl/lib/ns-mobilenode.tcl # ported: start if { $opt(rp) != "" } { source $opt(rp)/$opt(rp).tcl } elseif { [catch { set env(NS_PROTO_SCRIPT) } ] == 1 } { puts "\nenvironment variable NS_PROTO_SCRIPT not set AND" puts "no -rp option provided!\n" usage $argv0 exit 1 } else { puts "\n*** using script $env(NS_PROTO_SCRIPT)\n\n"; source $env(NS_PROTO_SCRIPT) } # ported: end (they only had the source $opt(rp) line



102

source tcl/lib/ns-cmutrace.tcl if { $opt(is) != "" } { source interference_agent/interference.tcl } # ported: start (not sure what this is for # set configured_bitrate -1.0 # set configured_range -1.0 # if { $configured_bitrate > 0 } { # puts "*** adjusting configured bitrate ==> $configured_bitrate" # puts "THIS WILL ONLY WORK FOR NetIf/SharedMedia!!!\n\n" # NetIf/SharedMedia set Rb_ $configured_bitrate # } # if { $configured_range > 0 } { # puts "*** adjusting configured range ==> $configured_range" # puts "THIS WILL ONLY WORK FOR NetIf/SharedMedia!!!\n\n" # NetIf/SharedMedia set range_rx_ $configured_range # NetIf/SharedMedia set range_cs_ [expr 2 * $configured_range + 10] # } # ported: end # do the get opt again incase the routing protocol file added some more # options to look for getopt $argc $argv if { $opt(x) == 0 || $opt(y) == 0 } { usage $argv0 exit 1 } if {$opt(seed) > 0} { puts "Seeding Random number generator with $opt(seed)\n" ns-random $opt(seed) } # ported: start # # Don't overwrite existing trace files # if { $opt(noclobber) != 0 && [file exists $opt(tr)] == 1 } { puts "Trace file $opt(tr) already exists. EXITING...\n" exit 1 } # ported: end # # Initialize Global Variables # set ns_ [new Simulator]



103

set chan [new $opt(chan)] set prop [new $opt(prop)] set topo [new Topography] set tracefd [open $opt(tr) w] # ported: start #set macmgr_ [new Manager/Mac] #set prqmgr_ [new Manager/PriQueue] #set chnlmgr_ [new Manager/Channel] #set netifmgr_ [new Manager/NetIf] #set nodemgr_ [new Manager/Node] # ported: end set nf [open nam-out-test.nam w] set f [open trace-out-test.tr w] $ns_ namtrace-all-wireless $nf $opt(x) $opt(y) $ns_ trace-all $f $topo load_flatgrid $opt(x) $opt(y) $prop topography $topo # # Create God # create-god $opt(nn) # # log the mobile nodes movements if desired # if { $opt(lm) == "on" } { log-movement } # # Create the specified number of nodes $opt(nn) and "attach" them # the channel. # Each routing protocol script is expected to have defined a proc # create-mobile-node that builds a mobile node and inserts it into the # array global $node_($i) # # 1 or 0??? if { [string compare $opt(rp) "admr"] == 0 || [string compare $opt(rp) "odmrp"] == 0} { for {set i 0} {$i < $opt(nn) } {incr i} { create-mcast-mobile-node $i 0 } } if { $opt(uni) == "" } { puts "*** NOTE: no power scaling scenario specified."



104

set opt(uni) "none" } else { puts "Loading power scaling scenario..." source $opt(uni) } # nodes for the interference agents set i_node [expr $opt(nn) + 1] for {set i 0} {$i < $opt(nia) } {incr i} { puts "$i_node *** \n"; create-interference-mobile-node $i_node 0 set i_node [expr $i_node + 1] } #enable node trace in nam for {set i 0} {$i < $opt(nn)} {incr i} { $node_($i) namattach $nf # 20 defines the node size in nam, must adjust it according to your scenario $ns_ initial_node_pos $node_($i) 20 } # # Source the Connection and Movement scripts # if { $opt(cp) == "" } { puts "*** NOTE: no connection pattern specified." set opt(cp) "none" } else { puts "Loading connection pattern..." source $opt(cp) } # # Tell all the nodes when the simulation ends # for {set i 0} {$i < $opt(nn) } {incr i} { $ns_ at $opt(stop).000000001 "$node_($i) reset"; } $ns_ at $opt(stop).1 "puts \"NS EXITING...\" ; $ns_ halt" $ns_ at $opt(stop) "stop" if { $opt(sc) == "" } { puts "*** NOTE: no scenario file specified." set opt(sc) "none" } else { puts "Loading scenario file..." source $opt(sc) puts "Load complete..." }



105

# ported: start # ====================================================================== # Start the Managers # ====================================================================== #$ns_ at 0.001 "$macmgr_ start" #$ns_ at $opt(stop).000000001 "$macmgr_ reset" #$ns_ at 0.001 "$prqmgr_ start" #$ns_ at $opt(stop).000000001 "$prqmgr_ reset" #$ns_ at 0.001 "$nodemgr_ start" #$ns_ at $opt(stop).000000001 "$nodemgr_ reset" if { $opt(mg) == "" } { puts "*** NOTE: no multicast group scenario specified" set opt(mg) "none" } else { puts "Loading multicast info file..." source $opt(mg) puts "Loading multicast info file... done." } if { $opt(is) == "" } { puts "*** NOTE: no interference scenario specified" set opt(is) "none" } else { puts "Loading interference info file..." source $opt(is) puts "Loading interference info file...done" } # # Create Scheduler Drop Target: what is this? jj # #set drpT_ [cmu-trace Drop "SCH" $node_(1)] #[$ns_ set scheduler_] drop-target $drpT_ # ====================================================================== # Schedule status/information events # ====================================================================== # # Have the simulator display periodic progress messages # for {set i 1} {$i <= $opt(progress)} {incr i} { set t [expr $i * $opt(stop) / ($opt(progress) + 1)] $ns_ at $t "puts \"completed through $t secs...\"" } # ported: end



106

puts $tracefd "M 0.0 nn $opt(nn)q x $opt(x) y $opt(y) rp $opt(rp)" puts $tracefd "M 0.0 sc $opt(sc) cp $opt(cp) seed $opt(seed)" puts $tracefd "M 0.0 prop $opt(prop) ant $opt(ant)" puts "Starting Simulation..." $ns_ run


Annexe B : Exemple de scripte AWK

107

Annexe B Exemple de script AWK

Le langage AWK Awk2 est un langage de programmation qui tire son nom des trois programmeurs qui l'ont développé : Alfred V. Aho, Peter J. Weinberger et Brian W. Kernighan. Le langage awk est très efficace dans la gestion de fichiers avec récupération d'informations et transformation des données. Il permet : - la manipulation de fichiers texte en tous genres - le support de petites bases de données au format personnel - la génération de rapports - la validation/les tests de données - la production d'index et la conversion de documents Le script suivant permet de calculer le délai moyen :

#! /bin/awk -f BEGIN { idHighestPacket = 0 ; idLowestPacket = 10000 ; nSentPackets = 0 ; nReceivedPackets36 = 0 ; nReceivedPackets11 = 0 ; nReceivedPackets37 = 0 ; nReceivedPackets21 = 0 ; nReceivedBytes36 = 0 ; rTotalDelay36 = 0.0 ; nReceivedBytes11 = 0 ; rTotalDelay11 = 0.0 ; nReceivedBytes37 = 0 ; rTotalDelay37 = 0.0 ; nReceivedBytes21 = 0 ; rTotalDelay21 = 0.0 ; join36 = 0; join11 = 0; join37 = 0; join21 = 0; } { strEvent = $1 ; rTime = $2 ; node = $3; strAgt = $4 ; idPacket = $6 ; strType = $7 ; nBytes = $8 ;

2 http://www.faqs.org/faqs/computer-lang/awk/faq /index.html



108

if(strEvent == "s" && node == "_36_" && strType == "ODMRP") join36 = 1; if(strEvent == "s" && node == "_11_" && strType == "ODMRP") join11 = 1; if(strEvent == "s" && node == "_37_" && strType == "ODMRP") join37 = 1; if(strEvent == "s" && node == "_21_" && strType == "ODMRP") join21 = 1; if(join36 == 1 || join11 == 1 || join37 == 1 || join21 == 1){ if (strType == "cbr" && strAgt == "AGT") { if (strEvent == "s" && node == "_0_") { nSentPackets += 1 ; rSentTime[ idPacket ] = rTime ; if ( idPacket > idHighestPacket ) idHighestPacket = idPacket ; if ( idPacket < idLowestPacket ) idLowestPacket = idPacket ; } if (strEvent == "r" && node == "_36_") { nReceivedPackets36 += 1 ; nReceivedBytes36 += nBytes ; rReceivedTime36[ idPacket ] = rTime ; if(rSentTime[ idPacket ]!=0){ rDelay36[ idPacket ] = rReceivedTime36[ idPacket ] - rSentTime[ idPacket ] ;} } if (strEvent == "r" && node == "_11_") { nReceivedPackets11 += 1 ; nReceivedBytes11 += nBytes ; rReceivedTime11[ idPacket ] = rTime ; if(rSentTime[ idPacket ]!=0){ rDelay11[ idPacket ] = rReceivedTime11[ idPacket ] - rSentTime[ idPacket ] ;} } if (strEvent == "r" && node == "_37_") { nReceivedPackets37 += 1 ; nReceivedBytes37 += nBytes ; rReceivedTime37[ idPacket ] = rTime ; if(rSentTime[ idPacket ]!=0){ rDelay37[ idPacket ] = rReceivedTime37[ idPacket ] - rSentTime[ idPacket ] ;} } if (strEvent == "r" && node == "_21_") { nReceivedPackets21 += 1 ; nReceivedBytes21 += nBytes ; rReceivedTime21[ idPacket ] = rTime ;



109

if(rSentTime[ idPacket ]!=0){ rDelay21[ idPacket ] = rReceivedTime21[ idPacket ] - rSentTime[ idPacket ] ;} } } } } END { for ( i=idLowestPacket; ( i<idHighestPacket ); i+=1 ){ rTotalDelay36 += rDelay36[ i ] ; rAverageDelay36 = rTotalDelay36 / nReceivedPackets36 ;} for ( i=idLowestPacket; ( i<idHighestPacket ); i+=1 ){ rTotalDelay11 += rDelay11[ i ] ; rAverageDelay11 = rTotalDelay11 / nReceivedPackets11 ;} for ( i=idLowestPacket; ( i<idHighestPacket ); i+=1 ){ rTotalDelay37 += rDelay37[ i ] ; rAverageDelay37 = rTotalDelay37 / nReceivedPackets37 ;} for ( i=idLowestPacket; ( i<idHighestPacket ); i+=1 ){ rTotalDelay21 += rDelay21[ i ] ; rAverageDelay21 = rTotalDelay21 / nReceivedPackets21 ;} rAverageDelay = (rAverageDelay36 + rAverageDelay11 + rAverageDelay37 + rAverageDelay21)/4; printf( "%f délai moyen\n",rAverageDelay) ; }


Résumé : ODMRP (On-Demand Multicast Routing Protocol) est un protocole de multicast très répandu pour les réseaux ad hoc sans fil. Les forces d'ODMRP sont sa simplicité, son taux élevé d’acheminement réussi de paquet, et sa non-dépendance sur un protocole spécifique d'unicast.

Cette thèse propose un protocole sans fil de multicast basé sur ODMRP nommé OODMRP (Optimized On-Demand Multicast Routing Protocol) qui minimise le nombre des nœuds relayeurs et optimise la consommation des ressources radio et des ressources énergétique dans le réseau.

Avant de choisir un nœud relayeurs, chaque nœud cherche dans son voisinage l'existence préalable d'un nœud relayeur. Dans le cas où ce nœud relayeur existe il selecte ce nœud comme un ascendant.

Nos résultats de simulation montrent qu'OODMRP réduit considérablement le nombre de nœuds relayeurs et de paquets expédiés, comparé à l'ODMRP original.

Mots clé : Multicast, Routage, Réseau Maillé Sans fil, ODMRP, OODMRP

Abstract: ODMRP (On-Demand Multicast Routing Protocol) is a popular multicast protocol for wireless ad hoc networks. The strengths of ODMRP are simplicity, high packet delivery ratio, and non-dependency on a specific unicast protocol.

This thesis proposes an ODMRP-based wireless multicast protocol named OODMRP (Optimized On-Demand Multicast Routing Protocol) that relies on less forwarding nodes and optimizes resource consumption in the network.

Indeed, before selecting a forwarding node, each node searches in its neighborhood the existence of a forwarding node. In this case, it selects this node as an ascending one.

Our simulation results show that OODMRP reduces dramatically the number of forwarding nodes and forwarded packets, compared to original ODMRP.

Key words: Multicast, Routing, Wireless Mesh Network, ODMRP, OODMRP



Documents

DEPARTEMENT D'INFORMATIQUE MEMOIREd ˇacheminement de paquet, et sa non-dépendance sur un protocole spécifique d'unicast. Cette thèse propose un protocole sans fil de multicast