Dans cette partie, nous présentons rapidement quelques contributions qui n’ont pas été présentées dans le cœur de ce document. Nous avons choisi de présenter trois aspects1 : la démarche de simulation réaliste, le routage tolérant au délai, et la réduction de la congestion.
5.2.1 Démarche de simulation réaliste
La démarche de simulation, même si elle n’est pas présentée en détail dans ce document, est centrale dans l’évaluation des solutions proposées par l’ensemble de l’équipe « réseaux et protocoles ». Même s’il a été montré que différents simula-teurs donnaient généralement des résultats différents [CSS02], nous pensons qu’il est possible d’affiner les simulateurs pour que les résultats qu’ils produisent soient réalistes.
1. Trois autres aspects de nos travaux, plus mineurs, ne sont ni présentés dans le cœur de ce document, ni dans cette conclusion : il s’agit de l’optimisation de requêtes multiples dans un réseau de capteurs sans fil, la compression de séries temporelles représentant les données issues d’un réseau de capteurs sans fil, et l’évaluation et l’optimisation de la sous-couche MAC de IEEE 802.15.4.
Notre démarche de simulation réaliste peut être décrite en trois étapes : l’implé-mentation d’un simulateur réaliste, la mise en place d’un environnement complet de simulation, et le retour d’informations des résultats de prototypes pour la simulation. L’implémentation d’un simulateur réaliste est le point de départ de notre dé-marche de simulation. Nous nous sommes basés sur le simulateur réseau NS2 (ver-sion 2.31), très utilisé dans la communauté scientifique internationale. Nous avons réécrit l’essentiel des couches basses de NS2, afin de prendre en compte des aspects qui étaient négligés dans la version originale. Nous pouvons citer l’implémentation du modèle de propagation ITU en intérieur [ITU 1238], la prise en considération des variations des conditions de propagation d’un lien donné (qui permet d’avoir, pour une distance donnée, des liens de bonne qualité et des liens de mauvaise qualité, ce qui est le cas en pratique [BARD13]), la prise en compte de la dérive temporelle des nœuds, l’amélioration de la modélisation de la couche physique (avec la prise en compte de la probabilité d’erreurs par bit due à la modulation, l’utilisation de huit tests différés de médium pour réaliser un CCA (comme le standard IEEE 802.15.4 l’impose) plutôt qu’un test unique et immédiat, ou encore la prise en compte de l’ef-fet de capture temporel), et l’introduction d’un temps de traitement pour certaines tâches.
La mise en place d’un environnement complet de simulation permet d’utiliser efficacement notre simulateur. Cet environnement comprend deux types d’outils lo-giciels : des scripts de préparation des simulations, et des scripts de collecte des résultats. Les scripts de préparation des simulations gèrent tous les paramètres des protocoles testés et génèrent les topologies (qu’il s’agisse de topologies en lignes, en grilles, en arbres, aléatoires uniformes, ou aléatoires non uniformes). Ces scripts s’occupent aussi du lancement du simulateur pour chacune des répétitions prévues, et sauvegardent les résultats (à la fois les fichiers de trace et la sortie du simulateur). Ces scripts permettent de garantir que les résultats produits correspondent bien à la dernière version des paramètres. Les scripts de collecte des résultats, quant à eux, extraient les valeurs des métriques utiles à partir de tous les fichiers de résultats pro-duits, et produisent des fichiers contenant des valeurs numériques ou des courbes. Ces scripts réalisent eux-mêmes les calculs de moyennes et d’intervalles de confiance. L’utilisation de ces scripts permet de minimiser les erreurs d’extraction, et accélère significativement la mise en page des résultats produits.
Le retour d’informations des résultats des prototypes pour l’intégration dans notre simulateur permet d’affiner régulièrement le réalisme de notre simulateur. D’ailleurs, ces retours d’informations sont nécessaires dans une démarche de simula-tion visant le réalisme [PTBD10]. Ils ont conduit de manière directe aux publicasimula-tions suivantes [GTH08*, CLG+09*, ABD+13*], et de manière indirecte à une bonne par-tie des publications de l’équipe.
Cette démarche de simulation, créée autour d’outils logiciels, s’appuie aussi sur des contributions scientifiques permettant de réaliser certains points spécifiques. Par exemple, nous avons proposé des algorithmes pour accélérer l’association des nœuds au réseau (qui est souvent une phase obligatoire mais annexe lorsque l’on teste des protocoles MAC ou réseau) [ERGM09*, ERGM12c*], ou pour simplifier les pro-blèmes d’adressage sur certaines topologies aléatoires [ERGBM10*].
5.2.2 Routage tolérant au délai
Le routage tolérant au délai consiste à proposer des mécanismes de routage ap-plicables sur des réseaux où les liens sont intermittents. Dans de tels réseaux, la connectivité n’est pas garantie à un instant donné.
L’une des contributions de la thèse de Nassima Hadid [Had11] a été de pro-poser un protocole de routage tolérant au délai pour une application de robotique mobile. Pour gérer les différents capteurs et actionneurs des robots autonomes et mobiles, nous avons remarqué qu’il est possible d’utiliser un réseau de capteurs sans fil fonctionnant selon la norme IEEE 802.15.4. Dans le cas où les robots doivent interagir, il est nécessaire d’introduire de nouveaux protocoles. Pour ne pas perdre la compatibilité avec la norme IEEE 802.15.4, nous avons proposé une architecture dans laquelle les nœuds du réseau qui sont riches en énergie profitent de l’inactivité des autres nœuds (qui sont pauvres en énergie) pour communiquer entre eux. Ces nœuds riches en énergie se placent alors sur un canal commun à tous les mobiles, appelé canal d’aparté, et interagissent, sans que la compatibilité avec la norme IEEE 802.15.4 ne soit remise en cause [HGM11a*, HGM11b*]. Plusieurs aspects de cette architecture correspondent à un réseau tolérant au délai. En effet, les robots sont mobiles et ne sont en contact radio que rarement. De plus, même lorsque les robots sont à portée radio, ils ne peuvent communiquer entre eux que lorsque le réseau de capteurs de chacun des robots est dans la phase d’activité sur le canal d’aparté, c’est-à-dire que les nœuds pauvres en énergie sont dans leur phase d’inactivité. Pour gérer les communications dans un tel réseau, nous avons mis en place un protocole de routage basé sur une structure appelée bundle, servant à temporiser les paquets et permettant un routage opportuniste.
L’une des études à mener pendant la thèse d’Affoua Thérèse Aby concerne aussi la proposition d’un protocole de routage tolérant au délai pour une application de surveillance environnementale. Le très faible taux d’activité des nœuds rend les liens intermittents, et rend par conséquent la topologie dynamique, même en l’absence de mobilité des nœuds. La conception de protocoles de routage supportant ces inter-mittences font partie des problématiques étudiées actuellement par Thérèse.
Il est probable que des protocoles tolérants au délai soient étudiés par de futurs étudiants en thèse ou en master. En effet, l’intermittence des liens apparaît de ma-nière naturelle dans de nombreuses applications, dès lors que les nœuds ne sont pas synchronisés et que le taux d’activité de chaque nœud est faible.
5.2.3 Réduction de la congestion
Il est important de réduire la congestion afin d’améliorer les performances du réseau en termes de délai et de taux de pertes. Pendant la thèse de Nancy El Ra-chkidy, nous avons abordé ce point en remarquant que la congestion était souvent importante au niveau des sources dans un réseau de capteurs sans fil, notamment quand des situations critiques étaient détectées. En effet, il est probable que plu-sieurs nœuds capteurs dans une même zone détectent la même situation critique, dans un intervalle de temps court. Ces nœuds vont alors tous envoyer leurs don-nées au puits, ce qui va provoquer de la congestion sur le chemin de la source au puits. Nous avons donc proposé un protocole basé sur des pivots afin d’écarter les
chemins des sources au puits [ERGBM09*, ERGM12b*, ERGB13*]. Une approche complémentaire pourrait être de chercher à réduire les interférences quand la posi-tion des nœuds est connue et que les interférences peuvent être estimées à partir de la distance entre les nœuds [HLP11].
Ensuite, et toujours avec Nancy El Rachkidy, nous avons cherché à réduire la congestion au niveau du puits. Cette congestion est inévitable lorsqu’un seul puits est dans le réseau. Nous avons donc étudié le cas où de nombreux puits sont déployés, ce qui nous a conduit à proposer un protocole supportant les communications
any-cast, c’est-à-dire les communications pour lesquelles un ensemble de destinations
équivalentes est fourni [ERGM10*, ERGM12a*]. Ce protocole combine la sélection d’un puits adapté et la construction d’une route écartée des autres routes afin de réduire la congestion.