2.6.1 Développement des réseaux tolérants au délai DTN
Les réseaux tolérants au délai, DTN (Delay Tolerant Networks), désignent les réseaux conçus pour des transmissions sur des distances extrêmement longues telles que les communications spatiales ou inter-planétaires [VZS12]. Dans les environnement de type DTN, de longs délais qui peuvent se mesurer en heures, jours, voir même en années, sont fréquents [VZS12]. Pour ce type d’environne-ment, le modèle classique du protocole Internet ne peut pas être appliquer pour l’interconnexion des réseaux [Jon+08]. Ainsi, les recherches débutèrent sur les moyens de concevoir de nouveaux protocoles pour des communications interpla-nétaires [DFS99 ; Fal03]. A l’issue de ces premiers travaux, le protocole TCP a pu être adapter pour des communication entre Mars et la Terre, qui a permit d’at-teindre des débits de 1600 bits/s à 250 kbits/s [KAF11] même si le taux d’erreur binaire TEB se situait entre 10−9 à 10−7, les conditions atmosphériques sont res-ponsables de 5% des pertes de paquets [VZS12].
2.6.1.1 Architecture des réseaux DTN
Les réseaux DTN constituent des réseaux hétérogènes régionaux [Bur+03] et chaque région représente un type de communication homogène dans laquelle la technologie utilisée est différente de celle d’une autre région [Fal03]. Les don-nées sont transmises de région en région jusqu’à atteindre la destination finale, à travers des passerelles (gateways). Les passerelles stockent les données collectées dans chaque région et les transmettent à une autre passerelle lorsque la connecti-vité est rétablie : c’est le principe de stock-and-forward. Dans les DTN, l’unité d’in-formation échangée est appelée Bundle et une couche spéciale du même nom est ajoutée en dessus du protocole TCP (le plus souvent) pour la gestion de cette unité d’information. La figure 2.14 donne une illustration de l’architecture en couche des réseaux tolérants au délai par rapport à une architecture TCP/IP classique.
La caractéristique essentielle de la couche Bundle est de stocker les données en attendant l’établissement de la connexion. Les bundles reçus peuvent ainsi être stockés durant de longs temps allant de quelques minutes, des jours ou des an-nées [Fal03]. Deux documents servent de base pour la conception des protocoles et le déploiement de l’architecture des réseaux DTN : Ce sont les RFC 5050 et 4838.
(a) Variation de flux dans les liens qui dégénèrent Figure 2.14 –Architecture des réseaux DTN.
2.6.1.2 Mise en oeuvre de protocole des réseaux DTN
Les applications et les protocoles de communications dans les DTN doivent prendre en compte certaines caractéristiques qui conditionnent la communication entre deux régions différentes et différencient les DTN des autres réseaux.
— Une connectivité intermittente. S’il n’y a pas de chemin entre la desti-nation et la source de données ou même entre deux passerelles, le réseau devient ainsi déconnecté.
— délai long et variable. En plus de l’intermittence de la connectivité, des délais de propagation pour les sources très éloignées sont introduits. Par exemple, il y a le délai d’attente des données stockées dans les différentes files d’attente des points de collecte. Ce dernier est plus important que le délai de propagation (entre source et point de collecte) puisqu’il dépend for-tement de la fréquence d’établissement de la connexion.
— Des débits variables. Les données générées par les sources sont envoyées aux points de collecte (passerelles). Ces points de collecte communiquent avec les collecteurs mobiles avec des débits différents.
— La synchronisation : Dans les DTN, les passerelles entre différentes ré-gions doivent être synchronisées à la même horloge [Llo+09] car c’est la condition qu’elles puissent communiquer lorsqu’elles sont dans la portée, les unes des autres.
— La fragmentation : Les passerelles sont aussi comme des points de col-lecte pour une région DTN. Les données stockées sont alors fragmentées en unités d’information avant d’être retransmises à la prochaine passe-relle [WEH09].
2.6.2 Implémentation des DTN dans les zones blanches étendues
2.6.2.1 Cas général des réseaux de capteurs sans fil
Le concept des DTN a évolué depuis ces dernières décennies. Par exemple, depuis le projet IPN (InterPlanetary Network [DFS99]), les protocoles pour les DTN peuvent aussi servir, sur Terre, dans les réseaux à forte intermittence des liens [VZS12]. Avec l’avènement des réseaux de capteurs sans fil, le besoin de dé-ployer des infrastructures de réseaux de collecte de données dans des environ-nements complexe, a poussé à l’utilisation de différents moyens opportunistes de collecte tels que les drones, les ballons, les véhicules terrestres. Ces derniers intro-duisent immanquablement des latences ; même si elles sont largement inférieures à celles observées dans les DTN de communications spatiales, les réseaux de cap-teurs sans fil à puits mobiles fonctionnent selon le même principe.
Certains nœuds du réseau qui sont visités par le puits mobile reçoivent les don-nées de ceux qui ne le sont pas, stockent ces dondon-nées et les retransmettent au puits quand celui-ci rentre dans leur portée. Alors, ces types de réseaux doivent être tolérants au délai dû à l’intermittence de la connectivité [Tov+10 ; HYY13 ; DKN11].
Des exemples de mise en oeuvre sont : le DTNLite [NP04], qui est une archi-tecture DTN pour les réseaux de capteurs sans fil sur TinyOS réalisée sur des nœuds Mica. DTNLite a pour objectif de réduire le taux de perte des données dans des environnements où les nœuds peuvent être mobiles avec des fréquentes pertes de connectivité. ContikiDTN [Lou06] est une autre implémentation de protocole DTN pour les capteurs sans fil. Elle vise à rendre efficace l’échange des messages de gestion et de synchronisation lors de l’établissement de la connectivité entre les capteurs d’un même réseau ou entre un réseau de capteurs sans fil et Internet.
2.6.2.2 Cas particulier des zones blanches étendues
Dans les réseaux pour zones blanches étendues, certaines entités du réseau peuvent être mobiles, c’est le cas de la collecte opportuniste avec des puits mo-biles. Le principe "stock-and-forward" classique hérité des DTN devient alors "stock-carry-and-forward" [Kui08], car les puits mobiles (ballons stratosphériques, drones) ne sont pas la destination finale des données collectées. Ils établissent une connexion avec d’autres nœuds afin de collecter leur données [SBO19].
Dans l’architecture des réseaux DTN de capteurs sans fil avec des puits mo-biles, des nœuds sont désignés dans le réseaux pour jouer le rôle de points de col-lecte ou points de rendez-vous avec les puits mobiles [ZTW17 ; Xin+08 ; Jon+08].
Les points de collecte correspondent aux passerelles dans les DTN classiques car ce sont eux qui collectent, stockent et retransmettent lorsqu’ils sont connectés aux puits mobiles. Ils sont placés sur la trajectoire du puits mobile [GZD11]. Pour amé-liorer la durée de vie des points de collecte, des protocoles proposent de les syn-chroniser au temps d’arrivée des puits mobiles [Gu+13 ; Yun+13].
Ainsi, les DTN ont aidé à déployer des infrastructures réseau dans les zones blanches étendues. On peut citer les exemples d’applications tels que Dak-Net [PFH04], KioskDak-Net [Guo+11], des délais allant de quelques heures à quelques jours sont tolérés dans des réseaux qui fournissent des services Internet à des zones très reculées des centres urbains. ZebraNet [Jua+02] est un projet qui col-lecte des informations sur l’habitat naturel des espèces menacées d’extinction sur une zone plus 100 km2.
SUAAVE [WTJ09] et RESCUECELL [Res13] sont deux projets d’alerte et de se-cours dans des environnements où surviennent des catastrophes. Dans ces appli-cations, des drones sont utilisés pour collecter des données des capteurs déployés au sol. Pour réduire le délai de collecte, des algorithmes de routage qui limitent le nombre de sauts, dans un environnement ad-hoc [Jon+08], sont utilisés [HYM16]. D’autres applications, présentées dans le paragraphe 2.2.2 sont conçues sur le principe des DTN.
Dans toutes ces applications, le problème qu’elles ont en commun est : Com-ment les données sont transmises aux points de collecte avec le minimum possible de relais ? et comment répartir la charge des données entre les différents points de collecte afin de ne pas surcharger certains plus que d’autres.