Cette partie adresse la probl´ematique des communications multicast internes `a un cluster. On suppose que la taille des clusters r´esultants du fonctionnement du protocole de clustering permet de consid´erer que les protocoles “non hi´erarchique” d´efini pour les r´eseaux MANET commerciaux peuvent r´epondre `a la probl´ematique de l’intra-cluster. Ainsi, un ´etat de l’art des solutions de multicast propos´ees au cours des dix derni`eres ann´ees doit ˆetre effectu´e afin de d´eterminer si une des solutions existantes permet de r´epondre aux exigences ´enonc´ees pr´ec´edemment.
Afin de classer la multitude de solutions propos´ees dans la litt´erature, plusieurs taxonomies se fondant sur une des caract´eristiques du protocole ont ´et´e envisag´ees, dont la topologie de la structure, le sch´ema d’acquisition des routes, l’initialisation de la session multicast, la d´ependance vis-`a-vis du protocole de routage unicast, le m´ecanisme de maintenance de la topologie ou la connectivit´e de la structure.
Le tableau A.1 donne une classification de quelques protocoles en fonction de ces diff´erentes taxonomies. Malheureusement, ces taxonomies qui se concentrent sur une caract´eristique pr´ecise du protocole ne perme- ttent pas de conclure quant `a l’existence d’un protocole pouvant r´epondre `a nos exigences de robustesse, efficacit´e et ´economie d’´energie. Seule la taxonomie bas´ee sur la structure pr´esente un plus grand int´erˆet car c’est celle qui permet d’avoir la vue la plus globale sur le protocole. Cependant, cette taxonomie ne permet pas de prendre en compte les derni`eres approches ´emergeantes dans le domaine du multicast pour les r´eseaux MANET. Ces approches sont diff´erentes dans le sens o`u soit elles exploitent une des caract´eristiques du r´eseau MANET, soit elles se concentrent sur un objectif de design comme l’´economie d’´energie par exemple. Afin d’avoir une meilleure comparaison des solutions existantes en ayant comme point de mire notre objectif, nous proposons une nouvelle taxonomie qui sera plus globale et plus “pratique” dans le sens o`u les protocoles seront class´es en fonction de l’objectif de design (ou de l’exigence) qu’ils privil´egient. On distingue les protocoles qui privil´egient la robustesse, ceux qui privil´egient l’efficacit´e et ceux qui privil´egient l’´economie d’´energie. Il ressort de cette ´etude qu’il n’existe pas de protocole qui permet de satisfaire en mˆeme temps les exigences de robustesse, d’efficacit´e et d’´economie d’´energie. Ainsi nous avons choisi de d´efinir un nouveau protocole qui combine les avantages des protocoles robustes et ceux des protocoles efficace. Concernant l’´economie d’´energie, nous consid´erons qu’un protocole efficace, i.e. un protocole qui r´eduira au maximum les overheads de contrˆole et de donn´ee, r´epondra aussi `a l’exigence d’´economie d’´energie dans le sens o`u la transmission et la r´eception sont deux des op´erations les plus consommatrice en ´energie.
Le protocole “Shared Tree ad Hoc Multicast Protocol” (STAMP) a ´et´e d´efini avec l’objectif d’ˆetre `a la fois robuste et efficace. Ainsi, il repose sur une structure d’arbre partag´e qui permet de r´eduire au minimum la surcharge d’information de contrˆole ainsi que la duplication des donn´ees. De plus, il utilise une approche “hard state” pour la maintenance, i.e. les ´etats de la structure multicast ne sont remis `a jour que sur d´etection d’une rupture de liens et non p´eriodiquement, de fa¸con, ici encore, `a r´eduire la surcharge d’information de contrˆole. d’autre part, il tire parti de la capacit´e de diffusion du m´edium sans fil pour distribuer les donn´ees sur l’arbre comme sur un mesh de fa¸con `a cr´eer de la redondance et ainsi augmenter la robustesse du protocole. Pour cela, il suffit de modifier la r`egle d’acceptation d’un paquet de donn´ees. Ainsi, au lieu de n’accepter un paquet de donn´ee en r´eception que s’il provient d’un noeud appartenant `a la mˆeme branche de l’arbre (noeud
Table A.1Tableau comparatif des diff´erents protocoles de routage multicast
Topology Route Initialization Unicast Topology Structure Acquisition Dependency Maintenance Connectivity ABAM [122] Source Tree Reactive Traffic Independent Hard State Source
ADMR [63] Source Tree Reactive Traffic Independent Soft State Source AMRIS [130] Shared Tree Reactive Elected Source Independent Soft State Group AMRoute [12] Shared Tree Proactive Both Partially Soft State Group
Dependent
ASTM [24] Shared/Source Proactive Both Partially Soft State Source
Tree Dependent and Group
BEMR [96] Mesh Proactive Both Independent Hard State Group CAMP [47] Mesh Proactive Both Partially Soft State Group
Dependent
CQMP [37] Mesh Reactive Source Independent Soft State Group DCMP [32] Mesh Reactive Source Independent Soft State Group DDM [65] Source Tree Reactive Source Dependent None Source DPUMA, PUMA [123] Mesh Proactive Group Independent Soft State Group FGMP-SA [25] Mesh Proactive Source Partially Soft State Source
Dependent
FGMP-RA [25] Mesh Proactive Group Partially Soft State Group Dependent
GBMP [134] Shared Tree Reactive Source Independent Soft State Group LAM [64] Shared Tree Proactive Both Partially Hard State Group
Dependent
MANSI [117] Mesh Reactive Source Independent Soft State Group MAODV [108] Shared Tree Proactive Both Independent Soft State Group MOLSR [72] Source Tree Reactive Source Independent Soft State Source MRDC [131] Shared Tree Reactive First Source Independent Soft/Hard Group
State
MSTP [98] Shared Tree Hybrid Source Independent Hybrid Group MZRP [133] Source Tree Hybrid Source Independent Soft State Source NSMP [76] Mesh Reactive Source Independent Soft State Group ODMRP [77] Mesh Reactive Source Independent Soft State Group ODMRP-MPR [138] Mesh Reactive Source Independent Soft State Group ODMRP-PDA [14] Mesh Reactive Source Independent Soft State Group ROMANT [124] Shared Tree Proactive Group Independent Soft State Group SMMRP [55] Mesh Reactive Source Independent Soft/Hard Group
State
Figure A.4Taux de d´elivrance des paquets en % en fonction de la mobilit´e.
Figure A.5Overhead de paquets total (donn´ees + contrˆole) en fonction de la mobilit´e
identifi´e comme ´etant p`ere ou fils sur la structure), un noeud de l’arbre acceptera en r´eception un paquet de donn´ee quelque soit le voisin qui l’a envoy´e (`a condition qu’il ne l’a pas d´ej`a re¸cu bien ´evidemment). Le noeud qui sera le coeur de l’arbre sera le premier noeud `a joindre le groupe multicast. Ce noeud envoie p´eriodiquement un message d’annonce du coeur pour informer les autres noeuds du r´eseau. Dans l’utilisation du protocole en tant que protocole intra-cluster ces derni`eres r`egles ne s’appliquent pas, car le noeud coeur de l’arbre est d´ej`a identifi´e et connu de tous les noeuds, c’est le clusterhead.
Nous avons effectu´e une ´etude d’´evaluation de performance grˆace au simulateur `a ´ev`enement discret OPNET Modeler 11.5. L’objectif de cette ´etude ´etait de v´erifier que le protocole STAMP r´epondait bien aux exigences que nous nous ´etions fix´ees en d´ebut de conception. Ainsi, nous avons pris comme r´ef´erence le protocole ODMRP, le plus repr´esentatif des protocoles multicast bas´es sur un mesh, qui sont les protocoles reconnus pour ˆetre les plus robustes. Nous avons consid´er´e diff´erents types de sc´enarios pour ´evaluer le protocole en fonction de diff´erentes configurations r´eseau. Ainsi, nous avons ´etudi´e l’influence de la mobilit´e des noeuds, du nombre de sources, du nombre de membres multicast par groupe, de la charge de trafic et de la densit´e du r´eseau. Nous avons pu montrer que STAMP atteint des taux de d´elivrance des donn´ees comparable `a ceux d’ODMRP (cf. figure A.4), ce qui t´emoigne de sa robustesse. De plus, nous avons aussi montr´e que ces r´esultats ´etaient obtenus avec une efficacit´e beaucoup plus importante que celle d’ODMRP (cf. fig A.5). Les courbes ci-dessous donnent des exemples de r´esultats obtenus sur les scenarios de mobilit´e. La figure A.6 pr´esente une comparaison diff´erentielle en pourcentage des overhead de donn´ees (bleu), de contrˆole (vert) et du taux de d´elivrance des paquets (rouge) en fonction de la mobilit´e. Elle illustre la faible perte en termes de robustesse et l’important gain en termes d’efficacit´e. Consid´erons par exemple les r´esultats obtenus pour la vitesse de 2m/s, on peut voir que STAMP produit 98% d’overhead de contrˆole de moins qu’ODMRP, 36% d’overhead de donn´ees de moins et que son taux de d´elivrance des paquets est seulement de 3% inf´erieur.