Les autres fonctionnalités du système LiveFile

En l’associant avec d’autres composants logiciels, le système LiveFile offre d’autres fonctionnalités. La première est la sauvegarde de données sur plusieurs capteurs. Celle-ci a été introduite dans le paragraphe 3.2.2.3 portant sur l’utilisation de la primitive In() pour accéder aux données. La seconde concerne de potentielles applications au niveau de la gestion de la communication au sein du RCSF. Cette partie présente donc ces différentes fonctionnalités en indiquant quel type de composants logiciels sont nécessaires pour permettre leurs utilisations.

3.5.1 La sauvegarde de données d’un capteur

Le stockage des données dans la mémoire Flash évite de perdre l’ensemble des données collectées après une panne du système. Les données ainsi sauvegardées peuvent être restaurées après récupération du capteur et résolution de la panne. Les deux grandes causes de pannes rencontrées dans un capteur sans fil sont soit un blocage au niveau du système d’exploitation soit un problème d’alimentation en énergie. Des mécanismes de type « chien de garde » limitent l’impact du premier type de panne. Au niveau du second type de panne, de nombreux travaux sont menés pour d’une part augmenter le rendement des batteries utilisées et d’autre part diminuer l’énergie consommée par le capteur. A ce titre, le développement des technologies de communication IEEE 802.15.4 ZigBee ont réduit, de manière significative, l’énergie consommée par rapport au Wi-Fi IEEE 802.11b.

Même si les données ne sont pas perdues, elles restent inaccessibles tant que le capteur en panne n’a pas été récupéré. Or, dans certains cas, les capteurs sont utilisés car l’accessibilité au lieu de déploiement est compliquée voire impossible autrement. Par conséquent, le système LiveFile a été muni d’un mécanisme pour permettre la sauvegarde des données d’un capteur sur plusieurs autres. Les informations de type « CHECKPOINT » étant transmises, le procédé employé se situe entre la duplication et la réplication des données.

Supposons que le capteur tombe en panne, les pages qui auraient été libérées après le dernier

« CHECKPOINT » ne seraient d’une part pas prises en compte. D’autre part, la sauvegarde de tout type de données sur un autre capteur se produit si elle est clairement explicitée dans l’argument « key » de la primitive Out(). Seules les données les plus importantes seront a priori sauvegardées plusieurs fois. Par conséquent, il est difficile de parler de réplication sachant que la copie n’est pas totalement fidèle à l’original.

Une sauvegarde par bloc de pages est également envisageable et serait peu coûteuse en ressources si la liste des pages à transmettre est obtenue sans nécessiter de lourds traitements.

La sauvegarde de données sur un autre capteur serait utile pour disposer d’une copie des données stockées dans un buffer de type SRAM et en attente d’une programmation en mémoire Flash. Ce mode de fonctionnement revient à privilégier la mémoire Flash au détriment de l’énergie consommée pour la transmission des données.

Le système LiveFile ne possède pas de mécanisme évolué pour partager les données d’un capteur entre plusieurs autres. L’étape de duplication est réalisée par l’utilisation de la primitive Out(). En revanche, la récupération de données est plus complexe et pose différentes problématiques qui n’ont pas encore été abordées. Les principales sont le choix de la structure de données utilisée pour savoir sur quel capteur sont présentes les différentes informations disséminées. L’emplacement de stockage de cette structure est également important. La première solution est de transmettre celle-ci à la station centrale de collecte de données.

Actuellement, si un capteur en choisit plusieurs autres pour sauvegarder ses données, la méthode définie dans le système LiveFile impose de stocker l’intégralité des données sur chacun d’entre eux pour en faciliter la récupération par la suite.

CemOA : archive ouverte d'Irstea / Cemagref

La zone où les données d’un autre capteur sont stockées doit être clairement délimitée.

Deux solutions sont possibles pour réaliser cette opération. La première est de réserver au niveau de chaque capteur, avant leur déploiement, une zone de mémoire Flash dédiée à cette fonction. La problématique à considérer dans ce cas est le correct dimensionnement de cette zone. La deuxième solution est de réserver une ou plusieurs pages de mémoire Flash où sont indiqués les emplacements des données issues d’un autre capteur. Elle ne pénalise donc pas le capteur qui héberge les données d’un autre mais complexifie grandement le processus de sauvegarde. Dans la version actuelle du système LiveFile, ces problématiques ont été contournées en commençant le stockage des données d’un autre capteur à partir de la fin de la mémoire Flash et en conservant le numéro de la page programmée en dernier (voir Figure 3.34).

Figure 3.34 – Sauvegarde des données sur un autre capteur

Ce fonctionnement a été validé entre deux capteurs mais pas au niveau d’un RCSF.

Pour effectuer une évaluation complète, le système LiveFile doit être associé à un protocole de routage. Au niveau des réseaux sans fil Ad Hoc, différents protocoles ont été élaborés. Ils sont répartis principalement dans les 3 grandes familles suivantes :

• les protocoles proactifs ;

• les protocoles réactifs ;

• les protocoles hybrides.

CemOA : archive ouverte d'Irstea / Cemagref

Le principe de base des protocoles proactifs est que chaque nœud du réseau a, dans sa table de routage, un chemin vers l’ensemble des nœuds du réseau. Ce mode de fonctionnement implique des échanges constants entre les différents nœuds pour prendre en compte les potentiels changements de topologie du réseau. Le principal avantage de ce type de protocole est que chaque nœud dispose immédiatement d’un chemin vers n’importe quel autre nœud du réseau. Les protocoles DSDV [Perkins 1994] et OLSR [Clausen 2003]

appartiennent à cette famille.

Dans un protocole réactif, les chemins sont construits au fur et à mesure des communications entre les nœuds. Au départ, la table de routage d’un nœud est vide. Quand un nœud va vouloir communiquer avec un autre, la première étape est la recherche d’un chemin valide par l’envoi de messages à travers le réseau. Si un tel chemin est découvert, la communication pourra débuter. Par rapport à un protocole proactif, le nombre de messages pour établir les routes est moindre. Des exemples de protocoles réactifs sont AODV [Perkins 2003] et DSR [Johnson 2007].

Les protocoles de routage hybrides combinent les aspects proactif et réactif de différentes manières [Abolhasan 2004]. Par exemple, dans [Ramasubramanian 2003] et [Haas 1997], une zone au fonctionnement proactif est définie autour de chaque nœud. Au-delà de cette zone, un protocole réactif est utilisé. D’autres protocoles comme FZRP [Yang 2007]

utilisent des méthodes différentes à base de constructions d’arbres de routage.

Par rapport à leurs caractéristiques, les protocoles de routage proactifs voire hybrides semblent être les mieux adaptés pour réaliser la sauvegarde de données sur plusieurs nœuds ou capteurs. La table de routage pourra être ainsi utilisée pour trouver un capteur dans lequel les données pourront être stockées.

Pour certaines applications, un intérêt existe pour qu’un capteur n’effectue pas une copie de ses données dans un nœud voisin. Si l’on reprend l’exemple d’une application de surveillance d’incendie de forêt, les capteurs doivent être très proches les uns des autres pour obtenir un quadrillage assez fin de la zone observée et permettre une localisation la plus précise possible. Lorsqu’un incendie se déclare, suivant la vitesse d’intervention des pompiers, un capteur et le voisin sur lequel il a choisi de dupliquer ses données pourraient être tous les deux endommagés et entraineraient la perte des données sur le départ du feu.

3.5.2 La gestion de la communication

Le système LiveFile peut également intervenir au niveau de la communication. Dans la fonctionnalité précédente, les liens qui peuvent exister entre le système LiveFile et le protocole de routage utilisé ont été introduits. Dans cette section, les rôles que peut jouer le système LiveFile en ce qui concerne la gestion de la communication vont être présentés.

3.5.2.1 La gestion des données de routage

L’une des premières utilisations pressentie pour le système LiveFile était la gestion des données liées au routage. Au-delà du stockage non volatile de la table de routage pour cause de redémarrage du système, d’autres applications existent.

La première est née à partir du protocole de routage OLAR (Obstacle Location-Aided Routing) [De Sousa 2005]. Ce dernier a été élaboré à partir du protocole LAR version 2 [Ko 2000]. Pour être plus complet, les familles de protocoles suivantes peuvent être ajoutées à celle présentées dans la section précédente :

• les protocoles géographiques ;

• les protocoles multicast ;

• les protocoles geocast.

CemOA : archive ouverte d'Irstea / Cemagref

Le protocole OLAR fait partie des protocoles géographiques. Ces protocoles partent du principe que les capteurs sont munis de dispositifs de localisation. Avec la démocratisation des systèmes GPS, cette hypothèse est de plus en plus valide. A partir de ces informations sur la position des nœuds, différentes méthodes ont été élaborées pour réduire la quantité de messages transmis pour établir une communication [Stojmenovic 2002].

Le protocole OLAR intègre la prise en compte des obstacles à la communication pour améliorer la qualité des chemins créés. Pour envisager une implémentation en réel de ce protocole, différents verrous doivent être levés :

• la détection et l’évaluation des obstacles ;

• le stockage des informations sur les obstacles.

Le système LiveFile apporte en partie une solution au deuxième verrou. Il autorise le stockage des informations sur les obstacles avant même le déploiement à l’aide de la mémoire Flash. Cependant, ce verrou ne se résume pas uniquement à l’aspect gestion des données au niveau du capteur. Il implique également la définition du format de stockage des informations sur les obstacles.

Le protocole CIVIC (Communication Inter Véhicules Intelligente et Coopérative) a été, au départ, élaboré pour répondre aux besoins de la communication entre véhicules civiles ou agricoles [Chanet 2007]. Il subit actuellement des modifications pour pouvoir être utilisé dans d’autres types d’applications [Hou 2007a]. L’intégration de la nouvelle version de différents critères ou grandeurs propres aux réseaux tels que la bande passante disponible, le délai de communication, le nombre de messages perdus. Le contexte des RCSF constitués de nœuds mobiles disposant de ressources limitées complexifie la définition et le respect de la comportement du réseau pourrait être ainsi mieux évalué par rapport à ses réactions passées.

L’historique des RTT avec leur évolution à partir d’une situation donnée pourrait être stocké dans le système LiveFile. Des intervalles de RTT plus ou moins fins pourraient être définis à l’aide des métadonnées contextuelles :

• « RTTint1 » : 0ms < RTT < 1ms ;

• « RTTint2 » : 1ms < RTT < 2ms ;

• « RTTint3 » : 2ms < RTT < 3ms, etc.

La recherche d’une situation rencontrée précédemment serait ainsi accélérée. Chaque intervalle « RTTint » devra comporter un nombre de valeurs en rapport avec la puissance de

CemOA : archive ouverte d'Irstea / Cemagref

calcul du capteur, le processus de décision devant opérer rapidement. L’avantage de cette méthode est d’améliorer l’estimation sans générer plus de trafic.

Le multi-support consiste à utiliser différentes technologies sans fil complémentaires pour répondre à la QoS requise. Les protocoles de communication Wi-Fi et ZigBee peuvent être associés pour bénéficier respectivement du débit de l’un et de la portée de l’autre. Le choix du protocole utilisé s’établit à partir des relevés provenant d’un estimateur de bande passante. A l’aide du système LiveFile, la décision de conserver ou de changer le protocole actuel peut se baser sur les valeurs acquises sur plusieurs cycles de mesure plutôt qu’un seul voire deux.

CemOA : archive ouverte d'Irstea / Cemagref