La construction de la dorsale est réalisée avant la construction des clusters pour les raisons suivantes :
• optimiser le nombre de noeuds participant à l'élection des chefs de zones. • forcer un chef de zone à être membre de la dorsale.
• tirer prot de la dorsale pour le trac de contrôle de construction des zones. • xer une distance limite entre un noeud et son chef de zone via la dorsale.
Il est toutefois important de noter que la construction de la dorsale et celle des clusters ne se déroulent pas de façon parfaitement séquentielle. Il est par contre nécessaire de coordonner les deux parties de la structure virtuelle, un clusterhead n'étant par exemple élu que parmi les membres de la dorsale. En conséquence, un n÷ud initie l'élection de chefs de cluster dés que ses voisins ont déterminé leur rôle dans la dorsale. En agissant de façon localisée, la construction présente une convergence plus rapide, et une plus grande robustesse aux fautes. Il est par exemple non acceptable d'attendre que chaque n÷ud reporte la n de la construction pour initier le clustering. La construction, tant pour la dorsale que pour les clusters s'appuie sur la connaissance du voisinage, nous allons donc ici détailler ce processus commun.
3.3.1 Découverte de voisinage
Pour découvrir ses voisins, un n÷ud envoie périodiquement un paquet hello. Puisque le médium radio est de type diusion (broadcast), tous ses voisins le recevront. Cependant, il peut se trouver que deux n÷uds possèdent une portée radio diérente, pouvant mener à la création de liens asymétriques. Par ailleurs, un protocole MAC, bien souvent, utilise des acquittements pour abiliser l'envoi de ses trames unicast, et donc limiter l'impact des collisions ou le manque de abilité des liens radio. Or, par dénition, un lien asymétrique ne permet pas de prendre en charge une telle fonction. Nous avons donc choisi de n'utiliser que les liens bidirectionnels. Un n÷ud doit donc envoyer dans ses paquets hellos la liste des n÷uds qu'il entend au niveau radio. En conclusion, les liens unidirectionnels peuvent être éliminés.
Algorithmes distribués de construction 33 Pour construire la dorsale, la connaissance du kcds-voisinage, i.e. l'ensemble des n÷uds à kcds
sauts ou moins, est requise. Pour remplir un tel but, deux choix sont possibles :
• Approche de type vecteur de distance : chaque n÷ud envoie dans ses paquets hellos la liste des n÷uds à kcds-1 sauts ou moins. Chaque n÷ud peut en agrégeant les informations de ses voisins connaître son kcds-voisinage.
• Approche de type état de liens : un paquet hello est relayé sur kcds-1 sauts. Comme un paquet hello contient la liste des voisins de la source, la reconstruction du kcds-voisinage est possible.
La première approche permet de réduire le trac de contrôle : les paquets sont plus importants en taille mais moins nombreux. Or, le nombre de paquets possède en radio un impact beaucoup plus important que la taille des paquets. Cependant, la deuxième approche converge beaucoup plus rapidement. Nous avons donc employé cette méthode dans notre implémentation.
An que les changements de topologie soient détectés par les n÷uds, l'envoi de paquets hellos est périodique.
3.3.2 Construction de la dorsale
Nous avons choisi de construire une dorsale sous la forme d'un kcds-CDS : la distance entre un noeud et la dorsale est un paramètre de notre solution. Dans un réseau statique, kcds peut être élevé an de limiter la cardinalité de la dorsale. Dans un réseau fortement mobile, kcdsdevra être faible pour limiter les déconnexions. Un noeud peut prendre l'un des états suivants :
• isolé : en état d'initialisation, le noeud attend le signal déclencheur pour la détermination de son état
• actif : en processus d'élection pour devenir dominant • dominant : membre de la dorsale
• dominé : client de la dorsale, possédant un dominant à moins de kcds sauts
Nous avons fait le choix de ne pas nous focaliser uniquement sur la minimisation de la cardinalité de la dorsale. Nous pensons au contraire que la robustesse d'une dorsale représente une propriété beaucoup plus importante. Par exemple, il est inutile de minimiser le nombre de n÷uds relais lorsqu'un paquet inondé n'est reçu que par un faible nombre des terminaux auxquels il aurait du être délivré. Pour nous, une dorsale doit avant tout remplir la tâche pour laquelle elle a été conçue, plutôt que de minimiser par exemple le trac de contrôle, qui est une propriété subsidiaire.
Par ailleurs, la construction se déroule en deux phases : dans un premier temps, un ensemble dominant est construit. Puis il est interconnecté. Nous utilisons dans nos algorithmes la présence d'un leader. Dans un réseau hybride, le point d'accès (AP) peut jouer le rôle de leader naturel. Si au contraire aucun AP n'existe, il est nécessaire d'en élire un en utilisant par exemple l'algorithme décrit dans [12].
3.3.2.1 Création d'un ensemble dominant
La première étape permet de construire un ensemble dominant, i.e. tout n÷ud dominé est à au plus kcdssauts d'un dominant. Lorsqu'un n÷ud change d'état, il envoie un hello immédiatement, sans attendre la n de son temporisateur. Sur réception d'un tel paquet, un n÷ud applique les règles suivantes :
• un noeud isolé ou actif recevant un message d'un dominant à moins de kcds sauts devient dominé et xe la source comme père
• un noeud isolé recevant un message d'un dominé à moins de kcds+1 sauts devient actif et arme un temporisateur pour l'élection
• un noeud actif pour lequel le temporisateur est écoulé, qui possède le poids le plus élevé parmi tous ses kcds-voisins actifs devient dominant.
Le leader devient le premier dominant du réseau. Il va donc déclencher le changement en dominé de ses kcds-voisins. De même, les dominés entraînent le changement en actif des kcds+1-voisins. Parmi ces n÷uds actifs seront élus les dominants qui possèdent le plus fort poids. Finalement, ces dominants vont engendrer de nouveaux changements. Ainsi, l'algorithme de construction procède par vagues de changements d'états. Ces changements sont illustrés sur la gure3.2(ils correspondent aux transitions préxées par DS (Dominating Set)).
La deuxième règle fait intervenir le (kcds+1)-voisinage d'un n÷ud. Cependant, une telle connaissance n'est requise que pour limiter la redondance dans l'élection des dominants. Ainsi, lorsqu'un n÷ud change d'état, il envoie un paquet hello avec son nouvel état avec un TTL d'exactement kcds+ 1, et seulement dans ce cas.
Par ailleurs, nous pouvons remarquer que durant la première phase de la construction, seul un dominé possède un père dans la dorsale. Le dominant xera son père dans la deuxième étape de la construction.
Un exemple de cette construction est donné gure 3.3page suivante (étapes 1 à 4). Dans la première étape, le leader devient le premier dominant. Puis les voisins du dominant deviennent dominés, et les 2 voisins des dominés deviennent actifs. Durant l'étape 3, 2 noeuds actifs ont été élus dominants car ils possédaient le poids le plus élevé parmi leurs voisins actifs. Finalement, le processus réitérant, un ensemble dominant est bien construit.
Fig. 3.2 Diagramme des changements d'états pour la construction de la dorsale 3.3.2.2 Interconnexion de l'ensemble dominant
Il reste maintenant à connecter l'ensemble dominant pour former une dorsale. Nous avons choisi de maximiser la robustesse et la rapidité de convergence. La redondance éventuelle dans la dorsale sera supprimée au cours de la maintenance.
Nous proposons ici un mécanisme d'interconnexion inspiré de [3]. Le leader constitue initiale-ment le seul dominant connecté. Il envoie un paquet d'invitation à la connexion, un cds-invite, en broadcast avec un TTL égal à 2kcds+1. Un dominé recevant une invitation avec un TTL t la relaie s'il a relayé au plus maxinvitations avec un TTL supérieur ou égal à t. Si aucune col-lision ne se produit, il est conseillé de xer maxinvitations à 1. Sinon, maxinvitations constitue un compromis entre le trac de contrôle généré et la robustesse aux collisions. Si toutefois les cds-invite subissent de nombreuses collisions, la dorsale peut ne pas être connexe à la n de la construction. Cependant, les algorithmes de maintenance étant auto-stabilisants 1, une dorsale connectée et fonctionnelle sera tout de même obtenue en cours de maintenance.
Lorsqu'un dominant non connecté reçoit un cds-invite, il y répond par un cds-accept. Ce paquet est envoyé sur la route inverse, vers la source de l'invitation. Les dominés
Algorithmes distribués de construction 35
diaires relayant un cds-accept deviennent dominants et xent le prochain saut comme nouveau père. Ainsi, le dominant source du cds-accept devient connecté et peut lui même envoyer un cds-invite pour autoriser les autres dominants à se connecter par son intermédiaire.
Un dominant ne répond pas immédiatement à un cds-invite. Il arme au préalable un temporisateur. Si au bout de ce temps, il a reçu plusieurs cds-invite, il choisit de répondre à celui maximisant le poids minimum des n÷uds intermédiaires du chemin. En eet, si un n÷ud de faible poids fait partie du chemin suivi par le cds-invite, ce dominé sera coloré en dominant, et constituera un point faible dans la dorsale.
Fig. 3.4 Espacement de deux dominants dont les zones de dominances sont voisines (kcds=1) Nous allons expliquer ici intuitivement la raison pour laquelle xer la valeur du TTL des invitations à 2kcds+1. Nous appelons zone de dominance un groupe de n÷uds dominés possédant le même père, plus le dominant en question. Nous pouvons remarquer que deux dominants appartenant à deux zones de dominance voisines sont espacés d'au plus 2kcds+1 sauts : les deux dominés à la frontière des deux zones sont à au plus kcds sauts de leur propre dominant respectif (g. 3.4). Ainsi, les invitations permettront une interconnexion totale de la dorsale, comme démontré de façon rigoureuse dans le chapitre suivant.
Finalement, à la n de la deuxième phase, la dorsale forme un semble connexe de dominants. de plus, chaque dominant possède un père dans la dorsale, constituant le prochain saut vers le leader. Enn, chaque dominé possède un père dominant et à au plus kcds sauts. Il existe un chemin qui l'unit à ce père et qui ne contient que des dominés ayant choisi le même père. Ainsi la dorsale forme un arbre dirigé, dont le leader est la racine.
Reprenons l'exemple de la gure 3.3page précédente. Les étapes 5 et 6 représentent la phase d'interconnexion. Dans l'étape 5, les 2 dominants à 2 sauts du leader ont reçu l'invitation du leader et ont forcé les dominés intermédiaires à devenir dominants. L'étape 6 connecte les 2 derniers dominants. Nous pouvons là encore remarquer que le processus de connexion se déroule en vagues.
3.3.3 Construction des clusters
An de minimiser le trac de contrôle induit par la construction des clusters, seuls les do-minants participent à la construction des zones. Un dominé rallie automatiquement le même cluster que son père. En conséquence, un dominant doit inscrire l'adresse de son clusterhead dans ses hellos an que ses dominés sachent dans quel cluster ils se trouvent.
Les clusters sont construits en utilisant la topologie de la dorsale : la construction doit donc être terminée. Cependant, un algorithme de construction séquentiel (dorsale puis clusters) pourrait augmenter le temps de convergence. De plus, il n'est par exemple pas nécessaire que les voisins du leader attendent que le réseau entier ait ni de construire la dorsale. Ainsi, tout dominant connecté et qui ne possède aucun voisin soit dominé soit isolé considère que sa zone locale a terminé la phase de construction de la dorsale. Il initie donc la construction des clusters. Nous souhaitons limiter la distance via la dorsale entre un n÷ud et son chef de cluster. Ainsi, seule la topologie de la dorsale doit être empruntée : les dominants initient une découverte de leur
Algorithmes distribués de maintenance événementielle 37 voisinage virtuel. Un voisin virtuel est soit un ls1 soit un père dans la dorsale. Un voisin virtuel est un sous-ensemble des voisins radio réels. Chaque dominant envoie donc périodiquement un cluster-hello avec un TTL de kcluster-kcds. Un dominant relaie un cluster-hello seulement s'il provient d'un voisin virtuel. Un dominant stoppe l'émission de cluster-hellos lorsqu'il ne possède plus aucun dominant sans clusterhead dans sa table de voisinage.
Un dominant qui possède le plus fort poids parmi tous ses kcluster-kcds-voisins virtuels sans clusterhead s'élit clusterhead. Conséquemment, il envoie immédiatement un cluster-hello an d'avertir de sa décision. Un dominant D relayant un cluster-hello choisit la source du paquet comme clusterhead si :
• D ne possède pas de clusterhead
• La source du paquet est à au plus kcluster-kcds sauts • Le précédent dominant a choisi le même clusterhead
Ainsi, des clusters connexes sont formés : un n÷ud peut joindre son clusterhead via un chemin de n÷uds de son propre cluster.
Un dominant possède un clusterhead à au plus kcluster-kcds sauts. De plus, un dominé est à au plus kcds sauts de son père dominant. Ainsi, les clusters formés présentent bien un rayon maximum de kcluster.
Les cluster-hello étant envoyés seulement par les n÷uds de la dorsale, leur impact sur le trac de contrôle est faible. D'autre part, ces paquets ne sont utilisés que lors de la construction, la maintenance extrayant les informations dont elle a besoin directement des paquets hellos.