Routage géographique
5.5 Auto-configuration du paramètre k
Nous avons vu dans la section 5.4 que le paramètre k, correspondant à la pro-fondeur de recherche de routes de l’algorithme HGA, pouvait influencer le taux de livraison. Le nombre de messages de contrôle et par conséquence l’énergie consom-mée par les nœuds est aussi affectée par ce paramètre. Le paramètre k n’est pas le seul responsable des performances du réseau, en effet les propriétés du réseau déterminent elles aussi les performances finales. Il n’est pas toujours facile, ou pos-sible, de connaître les propriétés du réseau avant son déploiement. De même, on peut souhaiter utiliser la même application sur des réseaux de nature différentes, comme des villes denses d’une part et d’autres moins denses d’autre part, dans le cadre des villes intelligentes par exemple. Dans ce contexte on pourra s’intéresser à l’auto-configuration du paramètre k afin d’obtenir l’auto-organisation du réseau.
On peut noter que si la valeur du paramètre k est supérieure à la distance entre la source et la destination, le paquet sera assurément délivré (hors pertes dues au lien physique). La mesure du diamètre du réseau pourrait permettre de déduire la distance moyenne entre source et destination, ou la distance maximale entre source et destination avec un indice de confiance. L’indice de confiance permettrait de déduire un taux de livraison théorique pour le réseau. Grâce à des techniques similaires à celles utilisées par Vcap [113] décrit en section 5.2 il est possible de déterminer le diamètre du réseau. De cette manière il serait possible de déduire une valeur pour le paramètre k adaptée au réseau. Toutefois cette méthode nécessite d’inonder plusieurs fois le réseau au démarrage or, comme décrit en section 5.2, nous souhaitons l’éviter pour garantir le passage à l’échelle.
Une autre possibilité serait de corréler le degré moyen en nombre de nœuds positionnés au taux de livraison. Grâce à un jeu de simulation plus ciblé sur cette mesure il serait possible de définir le degré moyen des nœuds positionnés pour un taux de livraison donné. Par exemple, si on vise un taux de livraison supérieur à 90% et qu’un nœud souhaitant envoyer un paquet de données connaît 2 voisins positionnés, on pourra déduire de la figure 5.5 que la variante HGA-1 est suffisante. La figure 5.6 permet de déduire les mêmes conclusions. En effet dans un réseau dont 5%des nœuds sont positionnés, si le degré moyen est 40, un nœud aura en moyenne 2voisins positionnés. De même dans un réseau dont 10% de nœuds sont positionnés, avec un degré moyen de 20, un nœud aura aussi en moyenne 2 voisins positionnés. Or on observe sur la figure 5.5 (resp. 5.6) que le taux de livraison de HGA-1 est supérieur à 90% pour un degré de 40 (resp. 20) et plus.
5.6. Conclusion 101
Lorsque le nombre de nœuds positionnés dans le voisinage du nœuds source est faible, voire nul, il peut être difficile de déduire la profondeur la plus adaptée. Pour cela il peut être intéressant de prendre la décision de transmettre ou non le paquet RREQ sur les nœuds intermédiaires. Le paquet RREQ contiendrait alors quelques informations supplémentaires permettant de calculer les degré moyen en nombre de nœuds positionnés. Grâce à cette information la retransmission de la RREQ serait réévaluée sur chaque nœuds en fonction du taux de livraison souhaité.
5.6 Conclusion
Nous proposons dans ce chapitre une solution de routage géographique inédite, permettant d’utiliser la position des nœuds du réseau quand elle est disponible et de s’en passer lorsqu’elle ne l’est pas. À notre connaissance, il n’existe pas de solution dans la littérature reposant sur les mêmes hypothèses. En effet, on retrouve des solutions de routage géographique dans lesquelles l’ensemble des nœuds connaissent leur position et des solutions utilisant des coordonnées virtuelles où aucun nœud ne connaît sa position. Nous proposons une solution intermédiaire, tirant parti de la position réelle des nœuds lorsqu’elle est disponible.
La solution que nous proposons, HGA, offre des performances nettement supé-rieures à la solution de routage géographique Greedy si une partie des nœuds n’a pas connaissance de sa position. Nous comparons aussi HGA avec une solution de routage utilisant des coordonnées virtuelles, Vcap, et montrons que pour différents scénarios d’utilisation, notre solution offre de meilleures performances, avec un sur-coût limité.
Pour les travaux futurs, la validation de nos résultats avec des couches physiques et MAC réalistes est envisagée. L’utilisation de plates-formes réalistes comme FIT ou SmartSantander permettrait de tester ces aspects en plus d’offrir un environnement réaliste. Par ailleurs la validation des résultats sur des topologies ciblant l’application telle que définie dans BinThatThinks est aussi prévue.
L’étude de la mobilité des nœuds est aussi un aspect intéressant, elle permettrait de caractériser notamment le délai nécessaire avant expiration des routes en fonc-tion de la vitesse de déplacement des nœuds. La comparaison avec les algorithmes de routage utilisant des coordonnées virtuelles devrait aussi apporter de nouveaux arguments en faveur de HGA puisque ces algorithmes nécessiteraient une recons-truction fréquente du système de coordonnées virtuelles, et donc, une augmentation du nombre de messages échangés dans le réseau.
Nous pourrions étendre notre proposition en supprimant l’usage des messages HELLO, comme proposé dans l’algorithme GDBF [122], ce qui permettrait de ré-duire le nombre de messages échangés dans le réseau et donc d’augmenter sa durée de vie notamment lorsque le trafic est faible.
Nous avons proposé une approche réactive, permettant de faire face à des chan-gements dans la topologie du réseau. Ainsi notre proposition est applicable lorsque
certains nœuds du réseau sont mobiles. Il serait intéressant de comparer notre propo-sition avec une variante proactive dans laquelle chaque nœud maintient une connais-sance de son voisinage à k-sauts en lieu et place de l’utilisation de RREQ à k-sauts. Nous pourrions étudier le nombre de messages de contrôle de l’une et l’autre des solutions et trouver le seuil pour lequel il est plus intéressant d’utiliser l’une ou l’autre variante. Nous pourrions aussi mesurer le temps de réactions des différentes variantes et son impact sur le taux de livraison.
L’algorithme que nous proposons offre une solution intéressante dans le projet BinThatThinks et plus généralement dans les villes intelligentes. L’utilisation d’un réseau de capteurs fixes connaissant leur position, sur les poubelles publiques et les points de collecte par exemple, pourrait offrir les informations de position nécessaires aux capteurs disposés sur les poubelles. Cela permettrait de réduite les coûts (aucun récepteur GPS nécessaire) tout en offrant de bonnes performances pour le routage des données.