Vers une plate-forme efficace en énergie pour les

Transcription

No d’ordre : 3480
THÈSE
présentée
DEVANT L’UNIVERSITÉ DE RENNES 1
pour obtenir
le grade de :
DOCTEUR DE L’UNIVERSITÉ DE RENNES 1
Mention :
Traitement du Signal et Télécommunication
par
Mickaël Cartron
Équipe d’accueil : R2D2 - Institut de Recherche en Informatique et Systèmes Aléatoires
École Doctorale :
Composante
Universitaire :
Mathématiques, Télécommunications, Informatique, Signal, Systèmes, Electronique
École Nationale Supérieure de Sciences Appliquées et de Technologie
Vers une plate-forme efficace en énergie pour les réseaux de
capteurs sans fil
Soutenue le 18 décembre 2006 devant la commission d’examen
COMPOSITION DU JURY :
MM.
J.-F. Diouris
M. Auguin
P. Garda
P. Quinton
O. Berder
O. Sentieys
Professeur à l’École Polytechnique de l’Université
de Nantes
Directeur de Recherche CNRS à l’I3S Nice
Professeur à l’Université Pierre et Marie Curie
Professeur à l’Université de Rennes 1
Maı̂tre de Conférences à l’Université de Rennes 1
Professeur à l’Université de Rennes 1
Rapporteur
Rapporteur
Examinateur
Examinateur
Examinateur
Directeur de Thèse
Résumé
Les réseaux de capteurs constituent un thème de recherche très dynamique actuellement,
tiré vers le haut d’une part par l’opportunité de développer des applications novatrices liées
à la position géographique des éléments du réseau, et d’autre part, plus généralement, par le
challenge de la conception d’objets communicants entièrement autonomes. Le but de ce travail
est de parvenir à définir des solutions architecturales opérationnelles capables de maximiser
l’autonomie des nœuds du réseau.
Pour parvenir à ce but, les travaux de recherche qui ont été menés ont pour objectif dans
un premier temps de cerner les besoins de ces réseaux de capteurs en termes de performances,
de complexité de calcul, de mémoire nécessaire, en s’appuyant sur des analyses de scénarios
précis et réalistes.
Dans un second temps, une plate-forme de nœud générique est décrite à partir de l’analyse
préalable des besoins, des couches les plus proches du matériel jusqu’aux couches applicatives
les plus élevées. Cet environnement intégré fortement réglable offre une vision totale des traitements au sein des nœuds et autorise par là-même les optimisations ”cross-layer”. En particulier,
les différents traitements liés à la communication sont identifiés sous forme d’éléments génériques. Des modèles de performances ont été définis pour ces composants déclinés sous forme
de chaı̂ne de communication, dans le but d’en déterminer des points de fonctionnement optimaux du point de vue de l’efficacité énergétique. De même, la technique d’accès au média
MAPLAP/RICER a été optimisée. Ces travaux ont été réalisés sur un logiciel de simulation
développé au sein du laboratoire.
La conception d’architecture et d’algorithmes à faible consommation nécessite des outils
performants et une vision particulière. C’est pourquoi dans un troisième temps, l’évaluation de
la consommation énergétique a été abordée par différentes approches correspondant à différentes
phases de la conception. Des solutions ont été développées pour évaluer des choix logiciels
et matériels d’un point de vue du coût énergétique. Notre approche est basée sur le traçage
d’exécution de code, simple et fondée sur un autre cadre de programmation événementiel général
et portable.
i
ii
Abstract
Sensor networks are a very dynamic domain of research due, on the one hand, to the
opportunity to develop innovative applications that are linked to a specific environment, and
on the other hand to the challenge of designing totally automonous communicating objects. The
aim of this work is to define architectural operational solutions able to maximize the lifetime
of these sensor networks.
In order to reach this goal, the work that has been led aims to define the needs of performance, processing complexity, and memory, solving particular sensor networks applicative
scenarios.
Then, a generic sensor node platform is described according to the application constraints
analysis, from the lower-level hardware processing to the higher-level applicative tasks. This
highly adjustable integrated environment gives a global vision of the processing of the nodes,
which gives the means to study cross-layer optimizations. In particular, wireless communication
processings have been analytically described as generic elements of a communication system in
order to evaluate and optimize the energy efficiency. This work has been realized on a simulation
program that has been developed in our laboratory.
Low power architectural and algorithmic design requires high performance tools and a
particular vision. For this reason, the energy consumption evaluation has been studied, for
all differents steps of the design, and solutions have been given for the evaluation of energy
consumption and performance of hardware and software designs. The approach described is
based on code execution tracing on a general and portable event-driven system.
iii
iv
Remerciements
Cette thèse a été effectuée au sein de l’équipe R2D2 (Reconfigurable and Retargetable Digital
Devices) de l’IRISA (Institut de Recherche en Informatique et Systèmes Aléatoires), et cofinancée la région Bretagne, je souhaite leur adresser mes sincères remerciements.
Je tiens à remercier très vivement mon directeur de thèse Olivier Sentieys pour m’avoir suivi
et soutenu dans ce parcours, pour m’avoir conseillé et encouragé et pour m’avoir fait partager
son expérience et ses connaissances.
Merci également à Olivier Berder pour son soutien sans limite en particulier pendant la phase
de rédaction de cette thèse.
Un très grand merci à tous les gens qui m’ont accompagné et qui ont contribué au développement du prototype de la plate-forme de réseau de capteurs, Vincent Gervaise, Vinciane Bronner,
Fabrice Barriez, Javier Longares, Paali Tandia, Ludovick Lepauloux et Nicolas Mechouk.
Je remercie également nos interlocuteurs de la société Aphycare pour le matériel des plateformes du prototype, mais aussi pour leurs conseils avisés et le partage de leur précieux savoirfaire dans la conception de systèmes de communication radio.
Je remercie tous les membres de l’IRISA, le personnel technique et le personnel administratif
de l’ENSSAT pour avoir contribué, de près ou de loin, à ce travail.
Je remercie également les membres du jury, MM. Patrice Quinton, Jean-François Diouris, Michel Auguin et Patrick Garda.
Enfin, je remercie très chaleureusement tous mes proches, ma famille et mes amis pour leur
soutien et leurs encouragements.
v
Table des matières
Résumé
i
Abstract
iii
Introduction
5
1 Analyse et modélisation du trafic dans les réseaux de capteurs
13
1.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.2
Protocoles de routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.2.1
Stratégie de transmission multi-étapes . . . . . . . . . . . . . . . . . . .
15
1.2.2
Routage pro-actif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
1.2.3
Routage réactif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
1.2.4
Routage géographique . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
1.2.5
Connaissance du positionnement géographique . . . . . . . . . . . . . .
21
1.3
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
1.4
Scénarios typiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
1.4.1
Échantillonnage périodique avec rapatriement automatique . . . . . . .
24
1.4.2
Surveillance à intervalle de temps constant avec rapatriement en cas de
1.5
réalisation d’une condition particulière . . . . . . . . . . . . . . . . . . .
25
1.4.3
Schéma d’interrogation ponctuelle initiée par la station de base . . . . .
26
1.4.4
Applications hybrides . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
1.4.5
Position de la station de base . . . . . . . . . . . . . . . . . . . . . . . .
27
Technique de modélisation du trafic . . . . . . . . . . . . . . . . . . . . . . . .
28
1.5.1
Modélisation de la topologie et échelle du réseau . . . . . . . . . . . . .
28
1.5.2
Modélisation du trafic au niveau application . . . . . . . . . . . . . . . .
28
1.5.3
Modélisation du trafic au niveau réseau . . . . . . . . . . . . . . . . . .
29
1.5.4
Modèles de trafic de référence des principaux schémas applicatifs . . . .
29
1
2
TABLE DES MATIÈRES
1.5.5
Modèle de trafic de l’échantillonnage périodique avec rapatriement automatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.6
Modèle de trafic de la surveillance à intervalle de temps constant avec
rapatriement en cas de réalisation d’une condition particulière
1.5.7
1.6
30
. . . . .
30
Modèle de trafic de l’interrogation ponctuelle initiée par la station de base 30
Modélisation des performances conjointes des niveaux liaison et physique
. . .
32
1.6.1
Expressions de la consommation énergétique . . . . . . . . . . . . . . .
32
1.6.2
Description du système de communication . . . . . . . . . . . . . . . . .
34
1.6.3
Modélisation fonctionnelle et énergétique du problème . . . . . . . . . .
36
1.7
Résultats de performances entre deux capteurs en liaison directe . . . . . . . .
38
1.8
Extension aux niveaux supérieurs et évaluation de performance globale . . . . .
39
1.9
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
2 Architectures et traitements pour des réseaux de capteurs
43
2.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
2.2
Architecture des capteurs communicants . . . . . . . . . . . . . . . . . . . . . .
45
2.2.1
Plate-forme générique . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
2.2.2
Récupération d’énergie . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
2.2.3
Systèmes d’exploitation événementiels . . . . . . . . . . . . . . . . . . .
47
2.2.4
TinyOS et le langage de description nesC . . . . . . . . . . . . . . . . .
51
2.2.5
Modèle en couche d’interconnexions de systèmes . . . . . . . . . . . . .
55
Infrastructure logicielle de la pile de protocole développée . . . . . . . . . . . .
58
2.3.1
Niveau application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
2.3.2
Niveau réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
2.3.3
Niveau liaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
2.3.4
Ordonnancement des tâches . . . . . . . . . . . . . . . . . . . . . . . . .
65
2.3.5
Optimisation des buffers des SAP . . . . . . . . . . . . . . . . . . . . . .
65
Modes de transmission et vecteurs de l’information . . . . . . . . . . . . . . . .
67
2.4.1
Modes de transmission dans un contexte de réseau de capteurs . . . . .
67
2.4.2
Structure des trames . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
2.3
2.4
2.5
Simulateur
2.5.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
Description des éléments spécifiques à l’implémentation virtuelle en simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
2.5.2
Asynchronisme et simulation . . . . . . . . . . . . . . . . . . . . . . . .
74
2.5.3
Avantages et limites de l’implémentation ”simulation” . . . . . . . . . .
75
TABLE DES MATIÈRES
2.6
3
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Évaluation de la consommation et optimisation du prototype
76
79
3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
3.2
Description de la plate-forme R2D2 . . . . . . . . . . . . . . . . . . . . . . . . .
83
3.2.1
Description du matériel . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
3.2.2
Protocoles d’accès au médium . . . . . . . . . . . . . . . . . . . . . . . .
84
3.3
3.4
Evaluation de l’énergie par traçage d’exécution de code
. . . . . . . . . . . . .
88
3.3.1
Traçage d’exécution dans un système événementiel . . . . . . . . . . . .
89
3.3.2
Identification des cycles d’ordonnancement caractéristiques . . . . . . .
92
3.3.3
Caractérisation en consommation des cycles d’ordonnancement . . . . .
97
Evaluation de l’énergie par une approche analytique . . . . . . . . . . . . . . .
98
3.4.1
Estimation analytique de la répartition des cycles d’ordonnancement . .
99
3.4.2
Événements anormaux des communications et coût énergétique . . . . . 101
3.4.3
Résultats d’évaluation de consommation d’énergie . . . . . . . . . . . . 106
3.5
Optimisation énergétique : exemple de l’intervalle de réveil. . . . . . . . . . . . 107
3.6
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Conclusion
111
Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4
Introduction
Introduction
Les évolutions dans le domaine des réseaux sans fils et dans celui des processeurs nous
permettent d’imaginer des réseaux denses, sans fils entre des nœuds hétérogènes et ayant pour
rôles de collecter des données d’un environnement et de les diffuser au sein du réseau. Ce type
de réseaux de capteurs pourrait avoir de très diverses applications. On pourrait prendre pour
exemple un réseau de capteurs de température, de lumière et de présence qui serait installé dans
un bâtiment et qui aurait pour rôle de contrôler les dépenses en énergie pour le chauffage et
l’éclairage. L’utilisateur final peut disposer des informations générées par les capteurs à l’aide
de la ou des stations de base qui sont les interfaces homme-machine du réseau de capteurs.
Les réseaux de capteurs étant constitués de nombreux nœuds, ils sont en mesure de tirer
parti de la densité du réseau et des redondances pour apporter de la tolérance aux pannes et
de la précision. La taille réduite des capteurs favorise en outre le déploiement en nombre de ces
derniers.
Les contraintes qui s’appliquent aux capteurs communicants se distinguent d’autres objets
communicants par de nombreux éléments. Si on compare les réseaux de capteurs avec les réseaux
locaux sans fil WLAN, on constate des différences majeures. Du point de vue du débit de
données, alors qu’il est de l’ordre de la dizaine de mégabits par seconde dans le cas des WLAN,
il est typiquement inférieur au kilobit par seconde dans le cas des réseaux de capteurs. La
taille des paquets de données échangés ne nécessite pas plus d’une centaine de bits dans le
cas des réseaux de capteurs, alors qu’elle dépasse le millier de bits dans le cas des WLAN.
En termes de distance de communication, les réseaux de capteurs communiquent à très courte
distance de l’ordre de la dizaine de mètres, alors que pour d’autres types de réseaux sans fils,
la distance de communication recherchée peut être de l’ordre du kilomètre, par exemple dans
le cas de la téléphonie cellulaire. Les réseaux WLAN privilégient les communications dans le
sens descendant, c’est-à-dire d’un serveur central vers des objets satellites ou ne favorisent pas
de sens particulier de communication. Dans le cas des réseaux de capteurs, la communication
est plutôt majoritairement montante, les nœuds étant les sources d’information et la station de
base le puits de données. En termes de mobilité, les réseaux WLAN doivent impérativement
5
6
Introduction
considérer la mobilité des objets communicants, à la différence des réseaux de capteurs plus
fondamentalement statiques.
Toutes ces différences en termes de besoins en performance peuvent être exploitées à bon
escient pour augmenter l’autonomie des capteurs. Car c’est là le point le plus crucial, alors que
la durée des batteries est de l’ordre de plusieurs heures en WLAN, les réseaux de capteurs visent
des autonomies bien plus élevées, de l’ordre de plusieurs années. Ce point est particulièrement
important si on considère le remplacement des batteries ou leur recharge manuelle comme impossible. Il est en effet difficilement imaginable d’effectuer ce genre de remplacement pour tous
les capteurs d’un réseau qui peut en comporter des milliers, qui plus est dans un environnement
éventuellement difficile d’accès, comme dans les plafonds ou les murs de bâtiments, ou si les
capteurs sont dispersés dans la nature.
Afin d’avoir une idée de la difficulté de conception d’après ces contraintes, on peut mettre
en regard la capacité embarquée typique de nœuds communicants de dimension et de poids
réduits et la consommation des nœuds. Fixons arbitrairement la quantité d’énergie embarquée
à 20000 Joules, ce qui est typique des implémentations les plus courantes. En ce qui concerne
les données de consommation d’un composant de communication commercial assez répandu,
le Chipcon CC1020, la courbe de consommation en fonction de la puissance d’émission fournie
est représentée à la figure 1. En sélectionnant la puissance d’émission minimum, cette consommation d’énergie est donc d’environ 42 mW (14 mA sous une tension d’alimentation de 3 V).
De plus les données constructeur indiquent que la consommation d’énergie en mode de réception est de 17,3 mA, ce qui représente une consommation d’environ 51,9 mW sous une tension
d’alimentation de 3V. En faisant l’approximation d’ignorer les autres systèmes, on trouve alors
les résultats suivants :
– dans le cas d’une réception continue, la durée de vie est bornée à 115 heures au plus,
– dans le cas d’une émission continue, la durée de vie est bornée à 142 heures au plus.
Ces valeurs, calculées simplement, montrent bien que le système d’accès au médium doit
être particulier car on peut dire qu’il est exclu d’employer un système dont la réception est
continuellement active sans quoi les objectifs d’autonomie visés par le cahier des charges ne
pourront pas être atteints.
Compte tenu des caractéristiques particulières des réseaux de capteurs, il est clair que la
conception ne saurait se calquer sur les techniques existantes utilisées pour les WLAN. A des
caractéristiques spécifiques, on doit également associer une méthodologie de conception spécifique. En l’occurence, la durée de vie très élevée visée pour les réseaux de capteurs nécessite
des précautions de conception particulièrement rigoureuses et l’évaluation énergétique est un
Introduction
7
Fig. 1: Consommation d’énergie en émission en fonction de la puissance d’émission.
élément qui doit être très intimement lié à toutes les étapes de la conception. A l’aide de
cet éclairage, le travail consiste ensuite à tenir compte des besoins en performance différents
comparés à des réseaux WLAN ou cellulaires pour trouver des compromis différents entre la
performance ”pure” et la consommation énergétique. Ces recherches de compromis doivent se
faire à tous les niveaux du traitement et en particulier dans les couches de protocole réseau. Par
exemple, on constate que les besoins en termes de débits sont plutôt faibles dans un contexte
de réseau de capteurs et cela doit être pris en compte pour éviter tout surdimensionnement des
émetteurs et des récepteurs.
De nombreuses équipes de recherche mènent depuis quelques années des travaux sur les
réseaux de capteurs, la plupart du temps liés à des réalisations réelles de capteurs communicants.
Dans le secteur industriel, on peut noter les travaux de normalisation autour de la norme IEEE
802.15 dont le champ de compétence vise les réseaux WPAN (Wireless Personal Area Network),
c’est-à-dire les réseaux sans fil à faible portée. Ce groupe de travail est divisé en quatre sousgroupes, et le plus adapté pour les réseaux de capteurs est le groupe IEEE 802.15.4 existant
depuis 2003 seulement et qui se focalise sur les WPAN à bas débit et à durée de vie élevée.
En parallèle de ce groupe, le groupe IEEE 802.15.4a répond aux mêmes besoins mais en se
basant sur la technologie Ultra-Wide Band (UWB), aussi connue sous le nom d’Ultra Large
Bande (ULB) en français. La norme Zigbee également émergente depuis peu de temps, dans le
courant de l’année 2004, a été construite sur la base du IEEE 802.15.4. Elle définit les couches
8
Introduction
supérieures et propose un système transparent de mise en réseau d’objets communicants.
Dans le monde de la recherche académique, il serait difficile de citer tous les acteurs, mais il
est néamoins incontournable de citer les projets suivants :
– µAMPS (MIT) [57],
– PicoRadio (Berkeley) [67],
– WINS (UCLA) [3],
– SmartDust (Berkeley) [83],
– WiseNet (CSEM) [22].
L’objectif général de cette thèse est de proposer une solution alternative aux systèmes cités
précédemment et, dans la mesure du possible, plus performante. Pour parvenir à cet objectif,
une phase préalable d’étude des besoins, des comportements et des caractéristiques spécifiques
des réseaux de capteurs a été réalisée. Puisque l’objectif est l’optimisation de systèmes de
réseaux de capteurs, nous avons cherché à en établir des modèles de performance et de consommation. Dans un premier temps, nous avons étudié les couches basses de communications dans
le but d’optimiser une liaison directe entre capteurs. La seule modélisation de ces couches
basses, qui s’étendent de la couche physique à la couche liaison, correspondant à un nombre
très élevé de paramètres, il a fallu trier ces derniers en plusieurs catégories. Certains paramètres
ne sont pas réellement des paramètres sur lesquels il est possible d’agir, parce qu’ils traduisent
les caractéristiques typiques d’un réseau de capteurs, tels que les distances entre les nœuds,
ou encore le débit de données nécessaire. Ces paramètres traduisant un scénario de réseau de
capteurs sont figés. Certains paramètres traduisant des choix technologiques sont également
considérés comme figés. Enfin, certains paramètres a priori inconnus sont en revanche l’objet
de l’optimisation, et en particulier la puissance d’émission. Dès lors, notre approche a consisté,
sur une base très analytique, à déterminer des points de fonctionnement optimaux pour ces
couches basses.
Ces résultats sont ensuite mis en relief par l’étude de la façon dont l’information transite
au sein du réseau de capteurs. Cette étape a consisté en l’étude d’applications de réseaux
de capteurs, mais également de protocoles de routages et des aspects de topologie, pour en
déduire des modèles de trafic de données. En appliquant les résultats d’optimisation obtenus
pour une communication directe entre deux capteurs à l’ensemble des communications d’un
trafic représentatif d’applications réalistes, nous avons pu étendre des résultats non plus à des
communications point-à-point directes, mais à une modélisation plus réaliste de réseaux de
capteurs.
Cependant, les modèles analytiques de consommation et de performance employés jusqu’alors
Introduction
9
Fig. 2: Organigramme du projet de recherche R2D2 sur les réseaux de capteurs
ont montré leurs limites. En effet, l’absence de réel modèle de technique d’accès au médium ne
permettait pas de rendre compte de certains éléments de performance comme les collisions de
paquets. De plus, les modèles de consommations très théoriques employés jusqu’alors supposaient une implémentation sur un circuit dédié, ce qui ne traduisait pas bien la réalité actuelle
des réseaux de capteurs. Par exemple, typiquement, les algorithmes de correction d’erreur et
de réémission automatique sont plutôt implémentés à l’aide de programmes s’exécutant sur des
microcontrôleurs faible consommation.
En faisant ce constat, nous avons décidé de pousser plus avant la qualité de nos modèles
de performances et de consommation. Certains travaux estiment la consommation d’énergie à
partir du traçage d’exécution de code réel [45] [74] [88]. Cette approche rend mieux compte des
réalités de l’implémentation des traitements sur des microcontrôleurs. Pour réaliser cela, il a
fallu concevoir un logiciel de réseau de capteurs optimisé, à l’aide de l’analyse applicative déjà
réalisée précédemment.
Dès lors nous avons adopté une méthodologie de conception en trois étapes, comme cela est
illustré par l’organigramme de la figure 2.
La première étape consiste en la définition du besoin, pour pouvoir imaginer réaliser des
structures de traitements qui correspondent parfaitement aux contraintes imposées par les
couches supérieures en matière de mémoire, de débits, d’échelle et de densité du réseau et
en tenant compte de la nature des événements issus des capteurs embarqués. Cette étape
10
Introduction
Fig. 3: Photo de la plate-forme du prototype de réseau de capteurs R2D2
réutilise en grande partie l’étude déjà réalisée sur les trafics de données lors des premiers
travaux d’optimisation d’une liaison entre objets en communication directe.
La deuxième étape consiste à définir les traitements mis en évidence à l’étape précédente et
ne dépendant pas du matériel choisi, sous forme d’un logiciel écrit en C à l’aide d’un cadre de
programmation moderne et adapté aux fortes contraintes de mémoire embarquée. Nous nous
sommes orientés vers une définition des traitements à l’aide de la bibliothèque des protothreads,
qui est à la base du système embarqué Contiki [20]. Un grand soin a été porté à distinguer
les traitements dépendant du matériel choisi des traitements indépendants de ces choix. De
même, les traitements dépendant de l’application ont été clairement distingués des traitements
indépendants de l’application. Dès lors, la conception du logiciel a été dictée par un cahier des
charges fondé sur une maximisation de la part des traitements indépendants de l’application et
de la cible matérielle, et sur une minimisation de l’utilisation mémoire. En adaptant le driver
de communication employant des files de messages Unix, nous avons compilé le logiciel vers
des capteurs ”virtuels” sous forme de processus Unix, communicant entre eux par un canal
virtuel constitué de files de messages IPC. Cela a permis de valider le logiciel et en particulier
le protocole de routage employé.
La troisième étape de conception du logiciel consiste à sélectionner une plateforme et décliner
les éléments dépendant du matériel. Lors de cette étape se pose alors le problème de la sélection
du protocole d’accès au médium en fonction des ressources offertes en termes de nombres de
canaux disponibles et de débits atteignables. Notre propre plate-forme a été développée à partir
de composants disponibles, équivalents en termes de consommation à d’autres implémentations,
mais ce fut une étape indispensable pour mettre au point la modélisation et l’optimisation de
la consommation.
Les contributions de ce travail ont consisté en l’analyse conjointe peformance/énergie d’une
liaison entre objets communicant, associé à une analyse des traitements applicatifs pour étendre
les résultats à un réseau complet. Devant les défauts mis en évidence par cette évaluation, une
nouvelle méthode d’évaluation a été réalisée en commençant par la définition d’un logiciel
Introduction
11
portable pour une plateforme générique qui a été identifiée. Ce logiciel a été défini sur un
cadre de programmation événementiel. Les tâches ont été programmées de telle sorte que les
traitements indépendants du matériel et de l’application soient prédominants. Ensuite, nous
avons décliné ce logiciel pour une plate-forme basée sur un microcontrôleur TI MSP 430 et
d’un composant de communication Chipcon CC1020. L’évaluation de la consommation de cette
plateforme en fonctionnement a alors été effectuée par un procédé de traçage d’exécution ce qui
a permis de mettre en évidence les causes majeures de consommation. Enfin, des optimisations
ont été réalisées sur cette plate-forme dans le but d’en augmenter l’autonomie, en partculier par
une étude du paramètre de l’intervalle de réveil, lié à la couche d’accès au médium employée.
Ce document se divise en trois chapitres. Le premier chapitre présente la modélisation et
l’optimisation conjointe performance/énergie d’un réseau de capteurs. Cette étude analytique
comporte deux grandes étapes. Tout d’abord, une analyse de trafic de l’information typique
d’un réseau de capteurs est réalisée. Pour cela, les protocoles de routages employés au sein de
réseaux de capteurs sont présentés. Ensuite, on s’intéresse à la modélisation d’une liaison entre
deux capteurs en liaison directe dans le but de minimiser la communication de données entre
ces deux nœuds. Puis, on réalise l’extension à un réseau entier à l’aide de l’analyse de trafic
préalable.
Le deuxième chapitre présente ensuite la conception d’un logiciel de réseau de capteurs pour
une plateforme générique. La description de ce logiciel est une solution pour pallier au manque
de réalisme relatif au modèle du premier chapitre. Le cahier des charges de ce logiciel impose
une séparation des traitements dépendant du matériel, de ceux indépendants du matériel. De
même, les traitements dépendant de l’application choisie doivent se distinguer des traitements
communs. Enfin, des efforts particuliers sont pris pour minimiser la taille du programme.
Le troisième chapitre présente le portage de l’application vers un prototype de plate-forme
candidate constituée d’un microcontrôleur basse consommation TI MSP430 et du composant
radio ChipCon CC1020. La problématique de l’accès au médium se pose alors et quelques éléments bibliographiques seront apportés, en décrivant plus particulièrement la technique RICER
[53], employée dans le prototype R2D2. L’évaluation énergétique de cette solution est ensuite
réalisée et des conclusions sont données quant à cette implémentation. Puis le problème de
l’optimisation de l’intervalle de réveil, qui est un paramètre très important de la couche d’accès
au médium, est abordé et des solutions sont données pour maximiser la durée de vie du réseau
de capteurs.
Enfin, le chapitre de conclusion et perspectives indiquera la direction à suivre pour la réalisation d’une plateforme aux caractéristiques adaptées dans le but d’un accroissement des
12
performances et de la durée de vie.
Introduction
Chapitre 1
Analyse et modélisation du trafic
dans les réseaux de capteurs
Contents
1.1
Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.2
Protocoles de routage . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.2.1
Stratégie de transmission multi-étapes . . . . . . . . . . . . . . . . . .
15
1.2.2
Routage pro-actif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
1.2.3
Routage réactif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
1.2.4
Routage géographique . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
1.2.5
Connaissance du positionnement géographique . . . . . . . . . . . . .
21
1.3
Applications
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
1.4
Scénarios typiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
1.5
1.4.1
Échantillonnage périodique avec rapatriement automatique . . . . . .
1.4.2
Surveillance à intervalle de temps constant avec rapatriement en cas de
24
réalisation d’une condition particulière . . . . . . . . . . . . . . . . . .
25
1.4.3
Schéma d’interrogation ponctuelle initiée par la station de base . . . .
26
1.4.4
Applications hybrides . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
1.4.5
Position de la station de base . . . . . . . . . . . . . . . . . . . . . . .
27
Technique de modélisation du trafic . . . . . . . . . . . . . . . . . .
28
1.5.1
Modélisation de la topologie et échelle du réseau . . . . . . . . . . . .
28
1.5.2
Modélisation du trafic au niveau application . . . . . . . . . . . . . . .
28
1.5.3
Modélisation du trafic au niveau réseau . . . . . . . . . . . . . . . . .
29
1.5.4
Modèles de trafic de référence des principaux schémas applicatifs . . .
29
1.5.5
Modèle de trafic de l’échantillonnage périodique avec rapatriement automatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
30
14
Analyse et modélisation du trafic dans les réseaux de capteurs
1.5.6
1.5.7
. . . .
30
Modèle de trafic de l’interrogation ponctuelle initiée par la station de
base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6
Modélisation des performances conjointes des niveaux liaison et
physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1
32
1.6.1
Expressions de la consommation énergétique . . . . . . . . . . . . . .
32
1.6.2
Description du système de communication . . . . . . . . . . . . . . . .
34
1.6.3
Modélisation fonctionnelle et énergétique du problème . . . . . . . . .
36
1.7
Résultats de performances entre deux capteurs en liaison directe
1.8
Extension aux niveaux supérieurs et évaluation de performance
1.9
30
38
globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
Conclusion
40
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction
Dans ce premier chapitre, nous allons dans un premier temps analyser les schémas de trafic
de données au sein de réseaux de capteurs. Pour cela, nous évoquerons dans une première
section la problématique du routage au sein d’un réseau ad hoc, qui par définition ne dispose
pas d’infrastructure centrale pour son administration. L’intérêt du routage multi-étapes dans
un but de préservation de l’énergie sera expliqué. Ensuite, seront présentés les routages ad hoc
pro-actif, réactif et les cas un peu particuliers des techniques de routage géographique.
Dans une deuxième section, nous présenterons les applications typiques des réseaux de capteurs et tenterons d’en déduire comment l’information transite dans le réseau de capteurs en
fonction de plusieurs familles d’applications.
Une troisième section aura pour objectif de se focaliser sur la modélisation d’une liaison
de données entre deux capteurs seulement : un émetteur et un récepteur. Nous chercherons à
optimiser une communication entre ces deux capteurs. Pour cela, un modèle conjoint performance/énergie sera employé.
Enfin, nous donnerons des résultats de cette évaluation, étendue à un réseau entier.
1.2
Protocoles de routage
La fonction de routage peut se définir comme la façon d’acheminer de l’information d’une
source à un destinataire à travers un réseau de connexions donné. Un bon routage doit être
capable d’acheminer les informations
1.2 Protocoles de routage
15
– avec une latence faible,
– en utilisant peu d’énergie, donc en utilisant les meilleures liaisons de données,
– en minimisant la charge du réseau, afin de maximiser la quantité totale d’informations
pouvant être transmises sur le réseau dans son ensemble,
– en étant fiable, et en particulier en étant tolérant aux pannes de nœuds du réseau.
Les réseaux de capteurs font partie de la classe des réseaux ad hoc. Ces réseaux ad hoc sont des
réseaux d’objets potentiellement nombreux qui ne nécessitent pas d’infrastructure fixe pour
fonctionner. Les éléments du réseaux doivent donc être en mesure de s’auto-organiser pour
pouvoir communiquer. Tous les éléments du réseau assurent donc la fonction de routage de
l’information au sein du réseau ad hoc. Les protocoles de routage sont au cœur de la recherche
sur les réseaux ad-hoc.
1.2.1
Stratégie de transmission multi-étapes
Dans le cas des réseaux ad hoc sans fil, les éléments du réseau sont autonomes et afin de
sauvegarder de l’énergie, ils emploient des techniques de routage multi-étapes. Ces techniques
de routage consistent à réaliser une transmission de données entre un émetteur et un récepteur
en utilisant éventuellement des capteurs intermédiaires tels des relais si la distance entre la
source et le destinataire du message est trop importante.
Cette technique part du principe qu’une communication sans fil à longue distance est plus
coûteuse énergétiquement parlant que plusieurs communications à courte distance.
Dans le cas d’une onde sphérique traduisant la méthode de propagation radio réalisée au
moyen d’une antenne omnidirectionnelle, un modèle simpliste de canal consiste à considérer
que la puissance totale de l’onde est une constante sur la totalité de la surface. Si on fait abstraction de l’atténuation typique du milieu de propagation, c’est-à-dire de l’énergie absorbée
par le milieu de propagation, on est alors dans le cas idéal. Dans ce cas de propagation omnidirectionnelle, puisque la surface du front d’onde augmente avec la distance parcourue, la
puissance est alors de plus en plus diluée à mesure que la distance augmente et cette dilution
est appelée affaiblissement. Dans le cas d’un milieu idéal et d’une propagation sphérique, en
posant O le point à la source de l’onde, r la distance à laquelle on mesure la puissance de l’onde,
psource la puissance totale observable à une distance nulle (r = 0) de la source, s = 4.πr2 la
surface de la sphère et λ la longueur d’onde du signal transmis, la puissance du signal p(r) peut
16
s’exprimer par la relation suivante
p(r) ≈
λ2
λ2
.psource =
.psource
4.s
16.πr2
(1.1)
cette relation est une approximation correcte pour des faibles distances ou pour une propagation
libre sur un canal idéal sans phénomène d’atténuation [15]. Pour mieux traduire la réalité et en
particulier pour un environnement en intérieur, il faut tenir compte de la présence d’obstacles
sources d’atténuation, et de réflexions multiples. Le modèle précédemment donné ne convient
alors plus du tout. Bien qu’il soit difficile de définir un modèle universel étant donnée la diversité
d’environnements, il est possible de tirer des règles générales à partir de résultats de test sur
des canaux divers [32] [37] [5] [10]. En considérant que l’expression précédente est valide à 1
mètre de distance p(1), on peut alors modéliser la puissance pour des distances plus élevées par
P (r) = p(1).r−α
(1.2)
avec α appelé coefficient d’affaiblissement. En effet, ce modèle est mieux adapté aux distances
plus grandes. On peut noter à ce titre que ce terme de coefficient d’affaiblissement est ici utilisé
un peu abusivement étant donné qu’il exprime la combinaison des deux mécanismes physiques
réduisant la puissance du signal, à savoir l’affaiblissement et l’atténuation par le milieu de propagation. Le coefficient d’affaiblissement α est également sensé représenter des caractéristiques
d’un environnement pouvant éventuellement comporter des obstacles comme les murs des bâtiments. Par exemple, on a l’habitude de considérer que pour un environnement intérieur et
pour des distances inférieures à 10 mètres, α est typiquement compris entre 2 et 4 [32] [17].
Ce qu’on peut dire à partir de cette modélisation, largement employée dans les publications
sur les réseaux de capteurs, est que l’affaiblissement des signaux suivant une loi en r−α , elle
va pénaliser beaucoup les transmissions sur de longues distances. Pour des grandes distances
source-destinataire, on suppose qu’à partir d’une certaine distance r, la somme de l’énergie
dépensée Etot ( Nr ) pour la transmission d’un paquet de données par un ensemble de N transmissions de distance
r
N
est inférieure à l’énergie dépensée au cours d’une seule communication
de distance r ou encore
N.Etot (
r
) < Etot (r)
N
(1.3)
pour un r dépassant un certain seuil. En termes d’énergie, cela peut donc se révéler plus
intéressant de réaliser des transmissions en plusieurs étapes, à partir du moment où l’application
17
est capable de tolérer des latences supplémentaires, étant donné qu’on peut considérer que la
latence est proportionnelle au nombre d’étapes de transmissions. Dans le cas des réseaux de
capteurs, certaines applications peuvent autoriser des latences élevées et c’est la raison pour
laquelle le routage multi-étapes est primordial.
Ce mode de routage a été employé dans le prototype développé au laboratoire.
1.2.2
Routage pro-actif
Les protocoles de routages pro-actifs constituent une catégorie de routage ad hoc dans laquelle
chaque élément du réseau cherche à établir des tables de routages valides en permanence. Pour
ce faire, ces protocoles pro-actifs dialoguent en permanence même si aucun transfert de données
n’est demandé. Pour généraliser, les performances du routage pro-actif se caractérisent par
– les latences les plus faibles, puisque les applications souhaitant émettre peuvent supposer
l’existence de routes à jour et valides,
– une consommation d’énergie importante et une utilisation importante de la bande passante,
dues au fait que le protocole de mise à jour des routes est employé en permanence, même
si les routes ne sont jamais exploitées,
– une utilisation importante de mémoire vive, due à la nécessité de mémoriser sur le long
terme les tables de routages, y compris pour les routes peu ou pas utilisées.
Parmi cette famille de routages ad hoc pro-actifs on retrouve de nombreuses versions, répertoriées ci-après :
– OLSR (Optimized Link State Routing Protocol) [36],
– CGSR (Clusterhead Gateway Switch Routing protocol) [14],
– DBF (Distributed Bellman-Ford Routing Protocol) [6] ,
– DSDV (Highly Dynamic Destination-Sequenced Distance Vector routing protocol) [63] ,
– Guesswork [62] ,
– IARP (Intrazone Routing Protocol) [31],
– LCA (Linked Cluster Architecture)[26],
– STAR (Source Tree Adaptive Routing Protocol) [25],
– TBRPF (Topology Dissemination based on Reverse-Path Forwarding Routing Protocol)
[59],
– WRP (Wireless Routing Protocol) [58].
18
1.2.3
Routage réactif
La famille des routages réactifs réunit les techniques de routages pour lesquelles les routes
sont déterminées uniquement au moment où une transmission de données doit être réalisée. La
transmission se déroule en deux phases ; dans la première phase a lieu la recherche de route et
dans la deuxième phase a lieu le transfert de données. Dans ce cas, ce qu’on entend par le terme
de ”route” est l’intégralité des nœuds intermédiaires qui vont constituer les différentes étapes
des paquets de données. Les principales caractéristiques de performance des routages réactifs
sont
– une latence plus élevée que dans le cas d’un routage pro-actif, due au fait que chaque
transmission est précédée de la phase de recherche de route,
– une consommation d’énergie contrôlée et qui correspond aux routes effectivement utilisées
par les informations échangées,
– une utilisation de la mémoire évoluant avec l’utilisation réelle des informations échangées.
De nombreux protocoles pouvant être qualifiés de réactifs sont listés ci-après :
– Ad-hoc On-demand Distance Vector [64],
– Ant-based Routing Algorithm for Mobile Ad-Hoc Networks [28],
– Admission Control enabled On demand Routing (ACOR) [41],
– Associativity-Based Routing [80],
– Backup Source Routing [76],
– CacHing And MultiPath routing [82],
– Dynamic Source Routing [39],
– Implicit Source Routing [34],
– Dynamic NIx-Vector Routing [46],
– Flow Oriented Routing [24],
– GB (Gafni-Bertsekas) [23],
– IERP (partie réactive du protocole ZRP) [30] ,
– LBR (Link life Based routing) [54],
– LMR (Lightweight Mobile Routing protocol) [16] ,
– MOR - Multipath On-demand Routing Protocol [7] ,
– MPRDV (Multipoint Relay Distance Vector protocol) [2] ,
– RDMAR (Relative-Distance Micro-discovery Ad hoc Routing protocol) [1],
– SSR (Signal Stability Routing protocol) [18],
– TORA (Temporally-Ordered Routing Algorithm routing protocol) [61],
– PLBR (Preferred link based routing) [75].
1.2.4
19
Routage géographique
Le routage géographique est un routage qu’on peut qualifier de ad hoc puisqu’il ne nécessite
pas l’existence d’une quelconque infrastructure fixe. Cependant, le mode de fonctionnement des
techniques de routage géographique est très différent des routages ad hoc présentés précédemment, par le fait qu’une notion supplémentaire est supposée connue : la position géographique
des éléments du réseau. En effet, dans le cas général des routages ad hoc, la disposition géographique n’est pas en tant que telle supposée nécessaire, alors qu’elle est au cœur de la technique
de routage géographique. Le routage géographique est constitué de plusieurs mécanismes :
– l’autopositionnement est une fonctionnalité qui permet à un nœud du réseau de connaı̂tre
sa position géographique,
– l’apprentissage de la topologie du réseau (éventuellement partiel),
– le routage à proprement parler, qui exploite les informations d’autopositionnement et de
topologie précédemment évaluées.
Dans le cas des réseaux de capteurs, le routage géographique est tout particulièrement intéressant étant donné qu’on bénéficie d’un réseau relativement figé, à la mobilité soit nulle, soit
très faible. En effet, dans ce cas la phase d’autopositionnement n’est exécutée que lors de la
mise en place du réseau, et l’apprentissage de la topologie du réseau est réalisé rarement et
uniquement pour envisager les pannes éventuelles des nœuds alentour. On se trouve alors dans
une situation très favorable qui permet de réduire la masse d’informations échangées dans le
but de rendre opérationnel le système de routage.
De plus, la masse de données devant être mémorisée par les nœuds du réseau est également
réduite, puisqu’il est possible de fonctionner avec assez peu d’information traduisant une topologie locale, pour extrapoler les routes éloignées à l’aide d’une direction globale. Cela ne peut
bien sûr fonctionner correctement que si la densité des nœuds est suffisante et si il n’existe pas
de configurations topologiques problématiques comme par exemple celle qui est montrée sur la
figure 1.1.
Les principales caractéristiques de performance des routages géographiques sont :
– une latence comparable à du routage pro-actif, car les informations d’auto-positionnement
et de voisinage sont accessibles à tout moment ;
– une consommation d’énergie limitée grâce au fait que les informations de topologie ne
nécessitent pas des mises à jour constantes dans le cas où la mobilité est très faible ou
nulle. A l’extrême, l’autopositionnement pourrait n’être invoqué qu’à la mise en place
d’un capteur, la mise à jour de la topologie locale restant nécessaire pour intégrer les
nouveaux capteurs et exclure les capteurs connaissant des défaillances ;
20
Fig. 1.1: Exemple de topologie problématique dans le cas du routage géographique. La source
doit router ses messages non pas vers la direction géographique du nœud destination, mais dans
le sens opposé, puisque c’est le seul chemin valide existant.
– une utilisation de la mémoire la plus limitée, puisque seule une connaissance très localisée
du réseau est nécessaire, le routage vers les capteurs les plus éloignés se faisant à l’aide de
la direction globale du nœud destination ;
– une qualité de service qui n’est pas assurée à 100 %, puisque les routes ne sont pas établies
parfaitement par le nœud source ; les routes sont déterminées partiellement au fur et à
mesure de la progression des données.
Ce dernier point concernant la qualité de service est contrebalancé par une forte densité de
nœuds et une repartition homogène des nœuds pour éviter des situations comme celle illustrée
par la figure 1.1.
Quelques exemples de ces routages géographiques dans la littérature sont listés ci-après :
– BGR (Blind Geographic Routing) [85],
– DREAM (Distance Routing Effect Algorithm for Mobility) [4],
– GLS(Grid) (Geographic Location Service) [49],
– LAR (Location-Aided Routing protocol) [43],
– GPSAL (GPS Ant-Like Routing Algorithm) [11],
– ZHLS (Zone-Based Hierarchical Link State Routing) [38],
– GPSR (Greedy Perimeter Stateless Routing) [40],
– Terminode Routing (Terminode local routing and Terminode Remote Routing) [8],
– LBM (Location Based Multicast) [43],
– GeoGRID [50],
21
– GeoTORA [42],
– MBGR [9],
Le routage géographique présente donc des avantages particulièrement intéressants pour les
réseaux de capteurs, d’autant plus que les contraintes importantes nécessaires pour que le
routage géographique puisse être exploitable sont réunies (très faible mobilité et densité élevée).
En pratique, il est difficile de considérer une mobilité nulle de tout le réseau, puisque cela
réduirait de façon radicale les applications envisageables. Cependant, le gain qui pourrait être
obtenu par le fait de pouvoir supposer l’immobilité de tous les nœuds du réseau, ou tout du
moins la majeure partie, pourrait permettre de réaliser des gains significatifs en termes de
consommation d’énergie.
C’est la raison pour laquelle il est souhaitable de pouvoir envisager qu’une partie du réseau
de capteurs puisse être mobile. Dans notre prototype, nous avons opté pour une combinaison
de capteurs fixes et de capteurs mobiles avec une plus grande proportion de capteurs fixes.
1.2.5
Connaissance du positionnement géographique
Comme cela a déjà été évoqué plus haut, la plupart des méthodes de routage utilisent des
informations sur le positionnement géographique des nœuds. De plus, ce positionnement géographique n’est pas seulement utile au routage, mais aussi à la pertinence des messages typiques
au sein de réseaux de capteurs [17, 8]. Par exemple, dans le cas de capteurs de température dans
un bâtiment, si la température n’est pas en correspondance avec le lieu où elle a été mesurée,
l’information est de peu d’intérêt.
Une première façon simple pour chaque nœud de déterminer sa position géographique peut
être le positionnement global à l’aide de la technologie GPS. Cette solution semble intéressante puisque l’infrastructure est déjà déployée. Mais ce système a ses limites et si on peut
effectivement l’envisager en extérieur, il donne de très mauvais résultats en intérieur.
D’autres idées sont évoquées dans divers articles [8, 72](projet Terminode) [81](projet PicoRadio).
Toutes les solutions proposées présupposent l’existence de nœuds dont le positionnement
géographique relatif est préalablement connu et fonctionnent à l’aide de triangulations [72].
Méthodes de mesures relatives et triangulations
Pour déterminer les positions géographiques relatives des différents capteurs, il existe, outre
la technologie GPS, trois familles de mesures [56].
Les méthodes ToA (time of arrival) utilisent les instants d’arrivée de signaux de type radio
22
ou sonore, ainsi que les données sur les vitesses de propagation de ces signaux pour calculer
les distances entre les capteurs. On peut distinguer plusieurs déclinaisons de ces méthodes :
mesure du temps de propagation aller, du temps de propagation aller-retour avec réflexion
active ou passive, ou encore différence de temps de propagation entre groupes de capteurs.
Le GPS peut être considéré comme une méthode ToA, puisqu’elle utilise les différences de
temps de propagation TDoA. Pour une application dans les réseaux de capteurs, les signaux
de type radio semblent plus adaptés, malgré le fait que le temps de propagation à mesurer est
extrêmement court, de l’ordre de 10 ns pour 3 m.
Les méthodes AoA (angle of arrival) sont basées sur les directions des signaux. Ces directions sont mesurées par les capteurs à l’aide de réseaux d’antennes. Les temps d’arrivée d’un
signal aux différentes antennes sont ensuite comparés pour déterminer la provenance de l’onde.
L’inconvénient principal de ces méthodes est la nécessité de disposer de plusieurs antennes de
réception pour un capteur, entraı̂nant des coûts énergétiques supplémentaires. De plus, les récepteurs doivent pouvoir distinguer des déphasages extrêmement faibles dans le cas des ondes
radios, ce qui a un impact direct sur la consommation.
La dernière méthode est basée sur la mesure de l’amplitude des signaux reçus. Cette méthode
nécessite la connaissance des caractéristiques des pertes dues à la propagation des signaux dans
le milieu, ainsi qu’une bonne connaissance des caractéristiques des systèmes d’émission et de
réception. Bien que les mesures de distances faites avec cette méthode soient assez imprécises
(les erreurs peuvent être de l’ordre de 50 %), la méthode est cependant intéressante puisqu’elle
ne nécessite pas autant de rapidité de traitement que les deux autres, et peut être utilisée avec
un matériel simple (une seule antenne suffit), contrairement à la méthode de mesure d’angles.
Pour l’application aux réseaux de capteurs qui ont des contraintes énergétiques fortes, ce choix
semble être le plus intéressant des trois. De plus, le concept de réseau de capteurs implique
une forte densité de capteurs ; on peut donc espérer qu’il y ait de la redondance pour faire les
calculs de triangulations, ce qui pourrait atténuer l’effet des erreurs de mesures de distances.
Les trois méthodes ont toutes des difficultés avec le problème des réflexions multiples des
ondes : des imprécisions sur l’angle d’incidence, le temps de propagation et la puissance mesurée
sont évidentes. De plus, dans le cas de la mesure de la puissance des signaux, la présence
d’obstacles comme des murs ou des meubles peut générer des distorsions importantes dans les
cartes issues de la triangulation. C’est la raison pour laquelle les algorithmes de positionnement
qui vont utiliser ces résultats doivent impérativement avoir une grande tolérance d’erreur.
1.3 Applications
1.3
23
Applications
Un réseau de capteurs sans-fils est constitué de composants autonomes intégrés, connectés
ensemble par liaisons radiofréquences, capables de mesurer des paramètres physiques dans des
environnements variés et de se coordonner en vue de remplir une fonction applicative spécifique. Cette nouvelle approche de contrôle et de suivi trouve de nombreuses applications, dans
des domaines variés. Dans le domaine agricole, on peut imaginer des réseaux de capteurs surveillant des données liées à la météo, à la surveillance des cultures, notamment les maladies,
l’humidité, la pollution, etc.. Dans le domaine de la construction et du bâtiment, on peut penser
à des systèmes de surveillance du vieillissement des édifices. Dans le domaine des transports,
notamment le transport routier, des réseaux de capteurs pourraient diffuser des informations de
portée locale sur les conditions de circulation, les alertes, et permettre d’améliorer la sécurité.
Dans le domaine militaire, des suggestions d’applications ont été données, par exemple pour le
suivi des mouvements de l’ennemi, il peut être intéressant de déployer un réseau de capteurs qui
réaliserait la surveillance en ”arrosant” une zone de capteurs à l’aide d’avions ou d’hélicoptères.
On peut aussi penser à la surveillance chimique et bactériologique. Dans le domaine de la sécurité civile, les réseaux de capteurs pourraient jouer un rôle primordial pendant des catastrophes
naturelles, notamment après des séismes : il pourrait être intéressant de déployer des réseaux
de capteurs pour détecter la présence de vie humaine, de fuites de gaz ou autre pour secourir
ou protéger les populations. Enfin certains ont émis l’idée de déployer des réseaux de capteurs
sur des planètes du système solaire, comme un moyen relativement simple à mettre en oeuvre
pour récupérer diverses données. Le cadre applicatif privilégié est celui des capteurs nécessitant
un déploiement important en nombre d’unités, impliquant une réduction importante des coûts
et de l’énergie électrique consommée.
Ce travail de thèse sur les réseaux de capteurs a été articulé autour de la définition précise des
besoins applicatifs pour mieux adapter les traitements nécessaires. En connaissant mieux les
besoins applicatifs, il serait alors possible d’optimiser le logiciel et le matériel d’un point de vue
de l’efficacité énergétique. Ainsi, il serait intéressant de pouvoir estimer les quantités de données échangées par les applications elles-mêmes, mais également par les protocoles utilisés pour
entretenir les informations de routage ou encore ceux utilisés pour l’évaluation de la position
géographique des capteurs. Les quantités de données échangées doivent permettre de dimensionner au mieux les caractéristiques des systèmes de transmission numérique employés par
la couche physique, notamment les débits minimaux que doivent pouvoir assurer ces éléments,
ainsi que les latences maximales acceptables. De plus, il faut avoir une idée de la complexité des
24
traitements à réaliser pour pouvoir choisir des composants adaptés. Ces performances incluent
des notions de complexité des algorithmes, d’utilisation mémoire. À ce titre, la consommation
de la mémoire est un élément important de la consommation totale d’énergie en particulier à
cause de la consommation liée à l’énergie statique qui est perdue, y compris pendant les phases
d’inactivité, celles-ci pouvant occuper la majeure partie du temps.
1.4
Scénarios typiques
À partir des applications présentées précédemment, l’objectif est d’extraire des mécanismes
réseau de base dans le but de concevoir un système répondant juste à ces besoins. L’approche
est en effet différente de l’utilisation d’une norme réseau préexistante, sans tenir compte des
contraintes aussi spécifiques que celles qui peuvent être trouvées dans le domaine des réseaux
de capteurs.
Avant d’entrer dans les détails d’améliorations des différentes couches de traitements une
par une, l’idée est d’envisager les échanges d’information au niveau applicatif dans un premier
temps, pour cerner les réels besoins et mettre en évidence les traitements strictement nécessaires.
Quelques travaux [79] [35] [33] ont exposé leur analyse des mouvements d’information dans des
réseaux de capteurs. On peut distinguer plusieurs types de réseaux de capteurs. On retrouve
parmi ces schémas génériques de nombreux types de fonctionnements, dont certains d’entre eux
sont développés dans les sections suivantes. Parmi eux seront présentés plus particulièrement :
– le maintien des informations d’autopositionnement,
– le maintien des informations de routage,
– l’échantillonnage à intervalle de temps constant avec rapatriement automatique vers la
station de base,
– la surveillance par échantillonnage à intervalle de temps constant avec rapatriement en cas
de réalisation d’une condition particulière, l’exemple typique est l’alerte consécutive à un
événement particulier,
– la surveillance par interrogation ponctuelle.
1.4.1
Échantillonnage périodique avec rapatriement automatique
Le premier scénario est un réseau fixe de surveillance dans lequel les capteurs communicants
n’ont aucun rôle d’interprétation des données. Les décisions à prendre quant aux valeurs de
mesure des capteurs sont calculées au niveau de la station de base exclusivement. Le schéma
de la figure 1.2 illustre ce type d’application. Chaque capteur a les fonctions suivantes :
1.4 Scénarios typiques
25
Fig. 1.2: Schéma d’un échantillonnage à intervalle de temps constant avec rapatriement automatique vers la station de base.
1. le maintien des informations d’autopositionnement,
2. le maintien des informations de routage,
3. un processus périodique qui effectue des mesures à intervalle constant,
4. une génération de rapport de mesure systématique à destination de la station de base se
diffusant en mode multi-étapes dans l’hypothèse où la station de base est hors de portée
de communication.
1.4.2
Surveillance à intervalle de temps constant avec rapatriement en cas
de réalisation d’une condition particulière
Un second scénario consiste pour le réseau de capteurs à réaliser des mesures en permanence,
associé à un filtrage correspondant à une interprétation des données mesurées localement. Suite
à ce traitement, chaque capteur peut prendre l’initiative de générer un message à destination
de la station de base. Ce message peut être interprété la plupart du temps comme un message
d’alerte. Ce type de fonctionnement applicatif est assez commun et utilisé dans des applications
d’alertes tels que la détection d’incendie ou encore la détection de présence. Chaque capteur
doit réaliser :
1. le maintien des informations d’autopositionnement,
2. le maintien des informations de routage,
3. un processus périodique qui effectue des mesures à intervalle constant,
4. un traitement de filtrage qui interprète les données mesurées,
5. des générations d’alerte le cas échéant en direction de la station de base.
Ce type d’application peut être représenté par la figure 1.3.
26
Fig. 1.3: Schéma de surveillance à intervalle de temps constant avec rapatriement en cas de
réalisation d’une condition particulière.
1.4.3
Schéma d’interrogation ponctuelle initiée par la station de base
Dans un troisième scénario, les mesures ne sont plus effectuées à l’initiative des capteurs,
mais découlent d’un ordre spécifique émis par la station de base. Les événements de mesures
ne sont pas initiés directement par les capteurs, mais déclenchés exclusivement par la réception
d’ordres en provenance de la station de base. Cette situation est celle qui permet de limiter le
plus la consommation d’énergie ainsi que l’utilisation du canal dans le cas où les requêtes sont
suffisamment rares. Chaque capteur doit exécuter :
1. le maintien des informations d’autopositionnement
2. le maintien des informations de routage
3. une tâche de fond capable de recevoir les ordres de mesures de la part de la station de
base,
4. une mesure, ponctuellement, à la réception d’un ordre de mesure,
5. un rapport de mesure, ponctuellement, à destination de la station de base en employant
un schéma de propagation multi-étapes.
La figure 1.4 illustre ce comportement.
1.4.4
Applications hybrides
Ces cas de figures peuvent éventuellement coexister, voire même se combiner. Par exemple,
de nombreux travaux sur les applications mettent en évidence des fonctionnement sous forme de
clusters. Dans ces situations, les capteurs se regroupent par paquets, le critère de regroupement
étant la proximité géographique. Une hiérarchie peut s’établir au sein même de ces clusters pour
1.4 Scénarios typiques
27
Fig. 1.4: Schéma d’une surveillance par interrogation ponctuelle initiée par la station de base.
tenter de cumuler les avantages des différentes stratégies, l’un des capteurs du cluster jouant
en quelque sorte le rôle de station de base locale.
En procédant par des techniques de ce genre, on peut par exemple considérer que les capteurs
emploient une technique d’échantillonnage périodique avec rapatriement automatique vers la
tête de cluster, les têtes de clusters employant à leur échelle une technique de surveillance à
intervalle constant avec rapatriement vers la station de base en cas de réalisation d’une condition
particulière.
1.4.5
Position de la station de base
Toutes ces catégories applicatives peuvent éventuellement être modulées par des critères
supplémentaires liés à la station de base, ou plutôt aux stations de bases, à savoir leur nombre
au sein du réseau et leur position relative par rapport aux capteurs du réseau. La situation
de la station de base à une position centrale dans le réseau est favorable, puisque la distance
moyenne entre les capteurs et la station de base sera minimisée, ce qui permet également de
minimiser le nombre d’étapes moyen pour des transferts entre la station de base et les capteurs
dans les sens ascendant et descendant. De plus, une position centrale de la station de base
permet une meilleure répartition de l’utilisation du canal.
Cependant, dans de nombreux cas, la station de base se retouve plutôt en périphérie du
réseau ce qui a des conséquences sur les performances globales et sur l’énergie globalement
dépensée.
28
1.5
Technique de modélisation du trafic
La modélisation du trafic est nécessaire pour pouvoir simuler des réseaux de capteurs en
fonctionnement. Cela est très important puisque cela permet au concepteur d’évaluer ses choix
de conception avant toute implémentation réelle. Au niveau initial de la conception, il s’agit de
faire varier des éléments tels que :
1. la topologie du réseau, c’est-à-dire la disposition des capteurs les uns par rapport aux
autres ;
2. l’échelle du réseau, c’est-à-dire une valeur qui définit les distances entre les capteurs. Ceci
est important puisque les notions de rayon d’émisison, de densité du réseau et de nombre
moyen de voisins en découlent directement ;
3. les quantités d’informations qui transistent entre chacun des nœuds.
La réalisation de modèle peut être sur mesure, quand par exemple on connaı̂t exactement la
topologie finale du réseau et les mécanismes des applications. Les modèles peuvent également
être génériques, tirés de l’étude des paradigmes applicatifs tels que ceux décrits en section 1.4.
1.5.1
Modélisation de la topologie et échelle du réseau
La modélisation sous forme de matrice de la topologie du réseau et du trafic permet une
programmation simplifiée à l’aide de logiciels de simulation tels que Mathworks Matlab, qui
est le logiciel que nous avons utilisé pour les diverses simulations. La topologie du réseau
est modélisée à l’aide d’un tableau de trois ou quatre colonnes selon que l’on considère un
réseau plan ou tridimensionnel. La première colonne contient les identifiants des nœuds sous
forme d’entiers naturels non nuls. Cet identifiant est très arbitraire et ne sera réellement utile
que dans le cadre d’une simulation, puisqu’un nœud peut complètement être identifié à l’aide
de ses seules coordonnées géographiques. L’introduction d’une notion d’ordre dans l’ensemble
des nœuds est cependant utile pour faire fonctionner un certain nombre d’algorithmes, c’est la
raison pour laquelle cet identifiant est utilisé. Les colonnes suivantes contiennent les coordonnées
cartésiennes x, y, et éventuellement z des capteurs dans un repère orthonormé dont l’unité est
le mètre. Le nombre de nœuds du réseau est noté N .
1.5.2
Modélisation du trafic au niveau application
Le trafic au niveau application s’entend par l’énumération du nombre de paquets d’une
certaine taille taille paquet pour chaque couple émetteur-récepteur du réseau. Les éventuels
1.5 Technique de modélisation du trafic
29
capteurs utilisés comme relais ne sont pas comptabilisés dans cette énumération. On se situe au niveau applicatif uniquement de la pile de protocole, donc la notion de routage y est
transparente, ainsi que les intermédiaires réquisitionnés pour acheminer l’information jusqu’au
destinataire.
Le trafic au niveau application est représenté par une matrice carrée d’entiers à deux dimensions Vi,j de taille N 2 dans laquelle est stocké le nombre de transmissions effectuées entre une
application quelconque de l’émetteur i et une application quelconque du récepteur j.
1.5.3
Modélisation du trafic au niveau réseau
Le trafic au niveau réseau est plus utile que celui au niveau des applications, puisqu’il traduit
mieux les ressources qui sont réquisitionnées lors de la communication entre deux applications
distantes. Cependant, obtenir des modèles réalistes est plus difficile, puisque cela implique de
définir le fonctionnement des protocoles de routage. La classe particulière des protocoles de
routage géographique est une catégorie qui nous intéresse tout particulièrement, comme cela a
été développé dans la section 1.2. Cette étude se limite aux réseaux fixes ou à mobilité très faible,
cohabitant avec un nombre limité de capteurs mobiles. Ces conditions particulières autorisent
donc le routage géographique.
Dans ce cas particulier, il est possible de transformer le trafic au niveau application en trafic
au niveau réseau.
Notons Rcomm le rayon de communication maximum, A le capteur émetteur à une étape
donnée de la propagation du message, Ci le i-ième voisin de A, B le nœud destination. Dans
le cas d’un routage géographique simple, il est possible de considérer que le meilleur choix du
prochain capteur est le capteur Ci qui minimise la distance Ci B.
Par cette analyse relativement simple, il est alors possible de convertir un modèle de trafic
au niveau application en un modèle de trafic au niveau réseau relativement réaliste.
1.5.4
Modèles de trafic de référence des principaux schémas applicatifs
Nous avons travaillé sur des modèles de trafic de référence pour pouvoir estimer la consommation d’énergie du réseau de capteurs. Nous avons employé un réseau constitué arbitrairement
de 26 nœuds disposés comme sur la figure 1.5. Le capteur de coordonnées (0 ;0) est ici une
station de base.
30
Fig. 1.5: Réseau de réference utilisé dans les simulations de consommation énergétique.
1.5.5
Modèle de trafic de l’échantillonnage périodique avec rapatriement
automatique
Pour les simulations, nous utilisons le modèle de trafic réseau, sous forme de la matrice de
volume V de données échangées pendant une durée d’observation longue :
V = Tobs .Fech .
N
X
MSdesc(i)
(1.4)
i=1
avec Tobs , la durée d’observation, Fech , la fréquence d’échantillonnage, et MSdesc(i) la matrice
carrée de dimension N 2 exprimant les messages échangés pour communiquer du nœud i vers
la station de base en mode multi-saut.
1.5.6
En notant MSdesc(i) telle que précédemment, et E(i) le vecteur décrivant le nombre d’événements critiques ayant été observés par le nœud i pendant la durée d’observation Tobs , on a
alors la matrice de volume
V =
N
X
E(i).MSdesc(i)
(1.5)
i=1
cette équation étant valable pour une durée d’observation Tobs suffisamment longue.
1.5.7
Modèle de trafic de l’interrogation ponctuelle initiée par la station de
base
En utilisant la notation MSdesc(i) définie précédemment, on définit de même MSasc(i) la
matrice carrée de dimension N 2 exprimant les messages échangés pour communiquer de la
1.5 Technique de modélisation du trafic
31
station de base vers un nœud i en mode multi-saut, ce qui permet de définir la phase de
requête initiale. On note également F (i), le vecteur de taille N d’interrogation des capteurs,
qui permet d’exprimer combien de fois la mesure du nœud i a été réclamée par la station de
base pendant la durée d’observation Tobs . On a alors la matrice de volume de données
V =
N
X
F (i). MSasc(i) + MSdesc(i)
i=1
et ce pour une durée d’observation Tobs suffisamment longue.
(1.6)
32
1.6
Modélisation des performances conjointes des niveaux liaison et physique
À présent que les aspects du trafic réseau ont été présentés en détail, nous nous intéressons
maintenant exclusivement à une communication entre un émetteur et un récepteur en communication directe. L’objectif étant de déterminer un point optimal par rapport à la consommation
énergétique.
Les objectifs de l’étude sont multiples : il faut exprimer l’énergie consommée par bit transmis
en fonction des paramètres choisis dans le but de mettre en évidence une configuration des
paramètres du système permettant d’obtenir un minimum en termes d’énergie par bit transmis.
Ces résultats pourront être ensuite utilisés pour donner les moyens à une application de définir
ses besoins en termes de qualité de transmission ou de taux de transmission et d’intervenir ainsi
directement sur la puissance d’émission, les tailles de paquets, et d’autres paramètres via une
interface système adéquate. Des travaux similaires on déjà été menés dans [47] et [66]. L’article
[47] combine les corrections d’erreurs et la ré-émission automatique, mais envisage uniquement
une cible processeur, et s’appuie sur des modèles de consommation assez grossiers, sans prendre
en compte l’énergie statique dans le calcul. Mais dans le contexte d’un réseau de capteurs, cette
hypothèse ne peut être maintenue. L’article [66] s’appuie sur la norme IEEE 802.11a, et cherche
à adapter au mieux les paramètres de choix de codage et de puissance d’émission, pour diminuer
l’énergie sous diverses contraintes d’applications. Par contre, l’énergie due aux ré-émissions n’est
pas prise en compte.
1.6.1
Expressions de la consommation énergétique
Pour évaluer la puissance consommée par un traitement, on peut utiliser trois méthodes.
Dans le cas général on peut donner l’expression suivante, en négligeant les pertes statiques :
2
Edyn = Eop .Nopérations = a.Cs .Aop .Vdd
[J]
(1.7)
avec Edyn qui représente l’énergie dynamique de l’algorithme, Eop l’énergie consommée pour
une opération “moyenne”, Nopérations le nombre d’opérations de l’algorithme, a l’activité du
circuit, Aop la surface de l’opérateur “moyen” et Vdd la tension d’alimentation.
Si on souhaite raffiner l’évaluation de la consommation, il faut alors prendre en compte la
puissance statique. La part de la puissance statique est d’ailleurs loin d’être négligeable dans
un contexte comme celui d’un réseau de capteurs où le taux d’activité est très faible. En effet,
des travaux [13] [65] ont mis en évidence le fait que l’énergie statique tend à devenir de plus en
1.6 Modélisation des performances conjointes des niveaux liaison et physique
33
Fig. 1.6: État des circuits d’un nœud en fonction du temps
Fig. 1.7: Comparaison des parts dynamique et statique de la puissance en fonction du taux
d’activité. La puissance dynamique en activité est fixée à 40 mW et la puissance statique est
fixée à 0.1 mW.
plus prédominante dans la consommation énergétique globale avec l’évolution technologique.
De plus, ce phénomène est amplifié dans le cas de système à faible activité comme les réseaux
de capteurs. En effet, en considérant les caractéristiques de fonctionnement on peut considérer
que les circuits sont inactifs pendant la majeure partie du temps. L’activité des réseaux de
capteurs adopte un comportement que l’on pourrait qualifier de sporadique comme l’illustre
la figure 1.6 qui montre l’alternance entre des périodes d’activité et les périodes d’inactivité.
Les temps d’activités apparaissent de façon sporadique en fonction des moments de réveil des
capteurs que ces derniers soient initiés par les capteurs eux-même ou par une cause externe,
comme un événement observé par un capteur ou un réveil dû à la partie radio.
En définissant le taux d’activité par le rapport entre le temps passé en périodes d’activité
et le temps total, on peut faire varier ce paramètre comme sur la figure 1.7 et mettre ainsi en
évidence la prédominance de la part due à la consommation statique sous faible taux d’activité.
Dans ce cas, il faut introduire un terme de puissance statique dans l’expression de l’énergie de
l’algorithme. Ealgo est l’énergie consommée pour exécuter une fois l’algorithme considéré, Pstat
34
et Pdyn sont respectivement la puissance statique totale et la puissance dynamique totale du
circuit réalisant le traitement, Talgo est le temps d’exécution de l’algorithme à l’aide du circuit
considéré, Fclk représente la fréquence de l’horloge, Nopérateurs est le nombre d’opérateurs utilisés
pour le calcul et β est un coefficient de consommation statique par unité de surface.
Ealgo = (Pstat + Pdyn ).Talgo
[J]
Ealgo = (β.Aop .Nopérateurs + Pdyn ).Talgo
Talgo ≥
Nopérations
Nopérateurs .Fclk
(1.8)
[J]
(1.9)
[s]
(1.10)
Ce qui nous permet d’exprimer une borne inférieure pour l’expression de l’énergie de l’algorithme :
Ealgo ≥ Nopérations .
β.Aop
+ Eop
Fclk
[J]
(1.11)
Cette expression qui correspond à une description haut niveau est certes un peu grossière,
mais elle est cependant riche d’enseignements quant aux directions architecturales à prendre
pour réaliser un système réellement basse consommation. De plus ce modèle est bien adapté
pour avoir une idée de la consommation d’un gros système. Cependant, si on souhaite plus de
précision, il faut alors définir exactement le matériel employé pour chaque bloc de traitement.
Dans ce cas, la puissance consommée pendant l’exécution de l’algorithme peut s’exprimer :
Palgo =
X
j∈Df


X
i∈Dsys
nbi,j .Eopi,j .Fj +
X
i∈Dsys

nbi,j .pstati 
[W ]
(1.12)
avec Df l’ensemble des fréquences de fonctionnement, Fj la fréquence de fonctionnement
du domaine j, Dsys l’ensemble des sous-systèmes (e.g. opérateur arithmétique, registre etc.)
fonctionnant à Fj , nbi,j le nombre d’opérateurs de type i fonctionnant à la fréquence du domaine
j, Eopi,j l’énergie dynamique d’une opération du type i et du domaine j et pstati la puissance
statique dépensée par un système de type i sous tension. Nous avons utilisé ce dernier modèle,
plus précis, pour les calculs de consommation des circuits de codage et de décodage de canal.
Quelques valeurs de consommation que nous avons utilisées pour nos calculs sont présentées
dans le tableau 1.1.
1.6.2
Description du système de communication
Canal Le canal choisi pour cette simulation est un canal à bruit blanc gaussien centré additif.
Dans nos simulations, nous avons choisi une puissance de bruit absolue de -90 dBm.
35
Tab. 1.1: Quelques exemples de valeurs de consommation
Modulation
Élément opi,j
Eopi,j [J]
pstati [W]
Bascule D
Et
Inverseur
Ou-exclusif
Compteur 4 bits
Multiplexeur 2 vers
1
Registre 8 bits
Registre 16 bits
1.08.10−12
0.166.10−9
0.066.10−9
0.026.10−9
0.200.10−9
1.430.10−9
0.122.10−9
0.25.10−12
0.12.10−12
0.48.10−12
5.86.10−12
0.32.10−12
8.59.10−12 1.327.10−9
16.75.10−12 2.655.10−9
La modulation utilisée est de type BPSK (Binary Phase Shift Keying). Sous un
bruit blanc gaussien additif (BBGA) le TEB (taux d’erreur binaire) d’un canal BPSK s’exprime
par la formule ci-dessous.
√
1
T EBBP SK,BBGA = .erfc( RSB)
2
(1.13)
La fonction erfc(x) très souvent employée de communication nnumérique est la fonction d’erreur
compémentaire et elle s’exprime de la façon suivante :
2
erfc(x) = √
π
Z
+∞
2
e−t dt
(1.14)
x
Le rapport signal à bruit (RSB) est déterminé en tenant compte de plusieurs facteurs :
– la puissance du bruit Pbruit au récepteur,
– la puissance d’émission Pem (mesurable à côté de l’antenne),
– la distance D entre les deux antennes des capteurs qui communiquent entre eux,
– le coefficient d’atténuation dans l’air γ,
– la fréquence de la porteuse Fp .
Codage de canal / Forward Error Coding (FEC) Le système peut être doté, ou non
d’un système de correction d’erreur. Cela permet de faire baisser le taux d’erreurs binaire
(TEB) et par conséquent le taux d’erreurs par paquet (TEP). Ainsi, ce système diminue le
risque qu’une retransmission soit nécessaire.
Réémission automatique / Automatic Repeat Request (ARQ)
Il existe de nom-
breuses techniques différentes pour gérer les retransmissions automatiques de paquets. Le plus
simple d’entre eux est le ”wait-and-go”, dans lequel l’émetteur envoie un paquet et attend un
36
accusé de réception de la part du récepteur avant d’émettre le paquet suivant. Un paquet est
retransmis si l’accusé n’est pas reçu dans un intervalle de temps, qui correspond à peu près
au temps d’aller-retour (Round Trip Time ou RTT). Un algorithme plus sophistiqué est celui
du ”go-back-N” dans lequel à un instant donné, plusieurs accusés de réception peuvent être
en attente. La taille du pipeline du transmission qui en découle dépend directement du temps
d’aller-retour. Si un accusé de reception n’arrive pas dans l’intervalle de temps voulu, alors
le paquet correspondant et tous ses successeurs sont réémis, ce qui permet de se passer de
buffer au niveau du récepteur. Il existe aussi des variantes plus évoluées du ”go-back-N” qui
sont le CACK (pour Cumulative Acknowledgement) et le SACK (pour Selective Acknowledgement). Avec le CACK, l’accusé de réception comporte le numéro du paquet le plus élevé tel que
tous les paquets précédents ont été correctement reçus. Cette amélioration permet d’obtenir de
meilleures performances dans le sens des retours de paquets, puisque même si quelques accusés
de réceptions sont perdus, les suivants peuvent valider quand même les paquets correspondants.
Le SACK permet, en plus des fonctionnalités du CACK, d’indiquer les paquets récemments
reçus éventuellement non consécutifs. Cela permet à l’émetteur de localiser précisément les
paquets reçus et de ne réémettre que ceux-ci.
L’objectif que nous cherchons à obtenir en utilisant l’ARQ est la transmission la plus fiable
possible, sans contrainte de délais trop stricte. En effet, puisqu’on envisage des transmissions
multi-étapes, une transmission insuffisamment fiable sur une liaison entre deux nœuds induit
rapidement une chute importante de fiabilité après un certain nombre d’étapes.
1.6.3
Modélisation fonctionnelle et énergétique du problème
Une retransmission est nécessaire lorsqu’un paquet transmis comporte au moins une erreur.
Soit lp le nombre d’éléments binaires d’un paquet, TEB le taux d’erreur binaire et nberr le
nombre d’erreurs dans un paquet donné, la probabilité qu’un paquet transmis comporte au
moins une erreur est le taux d’erreur par paquet (TEP) et s’exprime :
TEP = 1 − prob(nberr = 0) = 1 − (1 − TEB)lp
(1.15)
Soit N bP , le nombre de paquets d’information à transmettre et deb le débit binaire de
transmission du système actif, le temps mis pour une transmission réussie du premier coup
d’un paquet d’information s’exprime de la façon suivante :
Tideal =
N bP.lp
deb
[s]
(1.16)
37
Le temps réel de transmission doit donc tenir compte du pourcentage de temps additionnel
nécessaire pour les retransmissions. Lors d’une tentative d’envoi, le paquet a la probabilité
TEP d’être faux, l’expression du temps réel de transmission est donc :
Treel = Tideal + TEP.Tideal + TEP2 .Tideal + ...
Treel = Tideal .
∞
X
TEPi =
i=0
Tideal
1 − TEP
[s]
(1.17)
(1.18)
Afin de réaliser une optimisation énergétique du système de communication, la grandeur à
étudier est l’énergie par bit transmis avec succès. Celle-ci est définie par l’expression :
Ebit =
Ebit =
P.Treel
P
=
N bP.lp
deb.(1 − TEB)lp
P
deb.(1 −
1
2 .erfc(
√
RSB))lp
[J]
(1.19)
[J]
(1.20)
dans laquelle nous avons considéré une modulation de type BPSK, permettant ainsi d’exprimer
TEB en fonction du rapport signal sur bruit RSB. P est la puissance globale du système
en communication incluant les puissances dynamique et statique consommées par les circuits
numériques et analogiques.
Ptot = Palgo + Panalog + Pamp
[W ]
(1.21)
avec Panalog représentant une constante associée à l’ensemble des circuits analogiques et Pamp
représentant la puissance consommée par le système d’amplification de puissance précédant
l’antenne d’émission.
Pamp doit tenir compte de l’efficacité du système d’amplification et dépend de son régime
de fonctionnement. Nous avons utilisé un modèle exponentiel tel que celui proposé dans [66]
pour représenter cette efficacité. Soit ef f l’efficacité du couple amplificateur/antenne et Pdiff
la puissance du signal diffusé par l’antenne, on a alors, avec A = 0.02 et B = 0.140 :
Pamp = Pdiff .ef f = Pdiff .A. exp(B.10 log10 (Pdiff ))
(1.22)
38
1.7
Résultats de performances entre deux capteurs en liaison
directe
L’expression (1.20) permet de tracer l’énergie par bit transmis avec succès en fonction de
paramètres du système de communication. Ces paramètres sont la distance entre les deux
nœuds, le type de canal, la puissance du bruit au niveau du récepteur, la taille des paquets, le
type de système de correction et de réémission automatique et la puissance d’émission.
La figure 1.8 illustre un résultat de simulation de l’énergie par bit utile transmis avec succès
en fonction de la puissance de transmission, sous les conditions expérimentales suivantes :
– distance fixée arbitrairement à 10 mètres
– puissance du bruit de −90 dBm
– taille des paquets de 424 bits (paquets ATM)
L’analyse des courbes nous permet de constater la présence d’un point optimal de fonctionnement. Les trois courbes sont représentées pour différentes techniques de correction d’erreurs.
Aux puissances d’émission faibles, l’énergie par bit utile transmis avec succès décroı̂t. Dans cette
zone, les paquets sont trop souvent erronés et nécessitent des réémissions, ce qui augmente le
temps nécessaire pour la transmission réussie d’une certaine quantité d’information. Sur la
partie droite des courbes, la puissance d’émission est plus élevée ce qui fait chuter le TEP,
et par conséquent la probabilité que des réémissions soient nécessaires. Cependant, l’énergie
par bit utile transmis avec succès augmente avec la puissance d’émission, puisque l’amplificateur d’émission consomme alors plus d’énergie. Le point de fonctionnement optimal se situe
au minimum des courbes. On voit sur l’exemple qu’il est possible de gagner de l’ordre de 30
% d’énergie en choisissant un codage de canal de type Viterbi et en se positionnant au point
optimal comparé à une absence de codage de canal. Ce travail a été validé par une publication
[12].
Sur la figure 1.9, on observe le même type de courbes. Ce qui change par rapport à la version
précédente, c’est que le modèle de consommation a été extrait des données constructeur du
composant commercial ChipCon CC1020. On peut remarquer un palier d’énergie relativement
élevé qui fait que le point optimal de l’énergie par bit transmis avec succès est assez élevé. Ce
composant n’est donc probablement pas un excellent choix pour la couche physique.
1.8 Extension aux niveaux supérieurs et évaluation de performance globale
39
Fig. 1.8: Énergie par bit transmis avec succès en fonction de la puissance d’émission, pour trois
types de FEC et des paquets de taille 424 bits.
Fig. 1.9: Énergie par bit transmis avec succès en fonction de la puissance d’émission, pour
trois types de FEC, des paquets de taille 424 bits et en utilisant un modèle de consommation
correspondant à un composant commercial (Chipcon CC1020).
1.8
Extension aux niveaux supérieurs et évaluation de performance globale
À présent, il s’agit d’étendre les résultats obtenus pour deux nœuds en communication directe
à un réseau entier, à l’aide de l’analyse préalable qui a été décrite précédemment dans ce
chapitre, en considérant par exemple le réseau de la figure 1.5.
La sollicitation des nœuds n’est pas homogène géographiquement. Nous nous intéressons
alors à la durée de vie du capteur le plus sollicité dans trois cas de figures. Dans le premier
cas, tous les noeuds se positionnent à la puissance d’émission de 0 dBm. Dans le deuxième
cas, tous les noeuds se positionnent à une puissance d’émission fixe qui correspond à l’optimal
√
pour la distance maximale qui peut avoir à être parcourue, c’est-à-dire P. 2. Dans le troisième
cas, pour chaque transmission, le système est capable de positionner la puissance d’émission au
réglage adapté à la distance entre l’émetteur et le récepteur.
Le tableau 1.2 résume les résultats obtenus pour l’exemple d’un scénario de surveillance par
40
interrogation ponctuelle initiée par la station de base. Dans ce cas de figure, la consommation
énergétique de la première technique (la puissance d’émission étant configurée au pire cas)
est considérée comme la référence. La seconde technique, indexée sur le voisin le plus éloigné
permet alors une augmentation de la durée de vie totale d’environ 406 %, alors que l’utilisation
de la troisième technique, dans laquelle la puissance d’émission est effectivement optimale pour
chaque transmission permet d’obtenir des gains de 475 % de durée de vie.
Tab. 1.2: Impact sur la durée de vie du réseau de capteurs avec les trois politiques de réglage
des communications entre nœuds en communication directe
cas 1
Nombre moyen de sollicitations
26.11
Nombre maximal de sollicitations
55
cas 3
Énergie
par
bit
transmis
distance =
S
5.20
2.05
1.60
avec succès (mJ)
distance
=
√
S. 2
5.20
2.05
2.05
1
4.06
4.75
Facteur d’extension de durée de vie
1.9
cas 2
Conclusion
Après avoir décrit les applications possibles et modélisé des scénarios applicatifs réalistes,
il a été réalisé une modélisation conjointe performance/énergie d’une chaı̂ne de communication entre un émetteur et un récepteur donné. La métrique qui a été employée est l’énergie
consommée par bit transmis avec succès. Les courbes obtenues montrent qu’il existent une
configuration optimale de la puissance d’émission en fonction de la distance entre l’émetteur
et le récepteur. En considérant que le nœud est capable de choisir une puissance d’émission
différente pour chacun de ses interlocuteurs proches, il est alors possible d’atteindre des gains
importants en durée de vie comparé à une sélection ”aveugle” d’une puissance d’émission. Cela
est possible à partir du moment où la couche physique peut accéder à la table de voisinage qui
répertorie les positions géographiques des capteurs dans un périmètre proche. Notons que la
table de voisinage contient des informations qui relèvent plus du protocole de routage, mais ceci
est une illustration du fait que la perméabilité inter-niveau (optimisations cross-layer) permet
d’améliorer les performances.
Cependant, ces résultats comportent des défauts puisque la couche d’accès au média n’a pas
été modélisée, alors que cette modélisation est très importante pour avoir une prise en compte
1.9 Conclusion
41
des événements tels que les collisions de données et leurs conséquences sur la consommation
d’énergie. C’est une des raisons pour laquelle il est nécessaire d’employer une méthode d’évaluation beaucoup plus proche de la réalité basée sur une plate-forme réaliste qui est exposée
dans les chapitres suivants.
42
Chapitre 2
Architectures et traitements pour
des réseaux de capteurs
Contents
2.1
Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
2.2
Architecture des capteurs communicants . . . . . . . . . . . . . . .
45
2.3
2.4
2.5
2.2.1
Plate-forme générique . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
2.2.2
Récupération d’énergie . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
2.2.3
Systèmes d’exploitation événementiels . . . . . . . . . . . . . . . . . .
47
2.2.4
TinyOS et le langage de description nesC . . . . . . . . . . . . . . . .
51
2.2.5
Modèle en couche d’interconnexions de systèmes . . . . . . . . . . . .
55
Infrastructure logicielle de la pile de protocole développée
58
2.3.1
Niveau application . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
2.3.2
Niveau réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
2.3.3
Niveau liaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
2.3.4
Ordonnancement des tâches . . . . . . . . . . . . . . . . . . . . . . . .
65
2.3.5
Optimisation des buffers des SAP . . . . . . . . . . . . . . . . . . . . .
65
Modes de transmission et vecteurs de l’information . . . . . . . . .
67
2.4.1
Modes de transmission dans un contexte de réseau de capteurs . . . .
67
2.4.2
Structure des trames . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
Simulateur
2.5.1
2.6
. . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
Description des éléments spécifiques à l’implémentation virtuelle en
simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
2.5.2
Asynchronisme et simulation . . . . . . . . . . . . . . . . . . . . . . .
74
2.5.3
Avantages et limites de l’implémentation ”simulation” . . . . . . . . .
75
Conclusion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
76
44
Architectures et traitements pour des réseaux de capteurs
Fig. 2.1: Organigramme de la méthodologie suivie pour la conception du prototype de réseau
de capteurs R2D2.
2.1
Introduction
La modélisation analytique de la consommation énergétique qui a été exposée dans le chapitre
précédent a montré un certain nombre de défauts. Parmi ces défauts, l’architecture de calcul
des algorithmes mis en évidence est peu précise et traduit plutôt une implémentation ”fullcustom”. Or ce genre d’architecture n’est pas forcément une solution qui est adaptée aux réseaux
de capteurs puisque les nœuds du réseau sont plus communément implémentés autour d’un
microcontrôleur. Une réflexion sur l’architecture générique réaliste d’un nœud doit donc être
menée pour pouvoir tenter une meilleure évaluation de l’énergie consommée, plus proche de la
réalité. Les travaux qui ont étés menés ont été guidés par la conception du prototype de réseau
de capteurs R2D2. L’étude d’un prototype réel facilite l’évaluation des performances et de la
consommation du réseau de capteurs tout en fournissant des données plus précises permettant
l’obtention de résultats ainsi que de modèles théoriques plus convaincants.
Comme cela a été évoqué au cours de l’introduction, une méthodologie précise a été suivie
pour ce développement. Cette méthodologie est illustrée sur l’organigramme de la figure 2.1.
La première étape consiste à mettre en évidence les différents mécanismes et protocoles indispensables dans un réseau de capteurs.
2.2 Architecture des capteurs communicants
45
Au cours de ce chapitre, nous commencerons par décrire l’architecture générique des nœuds
d’un réseau de capteurs. Ensuite, le choix d’un système d’exploitation pour la plate-forme sera
abordé. Celui-ci doit en effet remplir des objectifs contradictoires de portabilité, de modularité
et d’occupation mémoire minimale et son choix est crucial pour la suite. Les systèmes événementiels sont capables de réunir toutes ces qualités et ils seront présentés, en insistant plus
particulièrement sur l’utilisation du cadre de programmation que constituent les protothreads
[20] (du système événementiel Contiki).
Après avoir décrit l’architecture générique et son système d’exploitation associé, la définition
des traitements d’un capteur sera abordée. Ces traitements sont capables de faire tourner des
applications telles que celles décrites au chapitre 1. Le cahier des charges pour leur conception
impose une forte modularité et doit inclure les mécanismes réseau de base, tels que l’autopositionnement, la connaissance du voisinage, la fonctionnalité de routage. De plus, l’utilisation
de la mémoire doit être la plus limitée possible afin de pouvoir employer le minimum de mémoire. La mémoire est en effet une source importante de consommation d’énergie statique. De
plus, la plus grande portabilité est nécessaire, ceci afin de permettre l’implémentation sur une
grande diversité d’architectures. En particulier, la couche physique est ouverte à de multiples
implémentations, il est même possible de réaliser un réseau de capteurs virtuel sous forme d’un
réseau de processus Unix communicant via un canal sans-fil émulé à partir de files de messages
IPC.
Pour permettre cette diversité d’implémentation, les processus sont distingués en trois catégories : les traitements indépendants du matériel et de l’application, ceux dépendant de
l’application et ceux dépendant du matériel. L’ensemble des traitements indépendants à la fois
du matériel et de l’application seront ensuite décrits.
2.2
2.2.1
Architecture des capteurs communicants
Plate-forme générique
La figure 2.2 présente une plate-forme générique d’un nœud de réseau de capteurs. Celui-ci
comporte bien entendu un certain nombre de capteurs embarqués, associés à des convertisseurs analogiques/numériques en vue de l’interfaçage avec le système numérique. Ensuite, la
plate-forme générique comporte nécessairement un composant de communication pour pouvoir
diffuser les rapports vers le reste du réseau et recevoir des informations des autres éléments. La
plupart du temps, ce composant de communication est bidirectionnel et peut non seulement
46
Fig. 2.2: Plate-forme générique de nœud d’un réseau de capteurs
émettre, mais aussi recevoir des informations. De plus, dans la plupart des cas, ce composant
utilise des communications radio, bien que quelques exceptions existent dans certaines implémentations, notamment Smart Dust [84] où le composant de communication emploie un principe de communication optique par reflexion de faisceau lumineux à l’aide d’un rétro-réflecteur
en coin de cube. La partie contrôle est constituée d’un microcontrôleur basse consommation
avec une capacité en mémoire RAM plutôt limitée ainsi qu’une mémoire flash contenant le
programme. Ce dernier est la plupart du temps construit autour d’un système d’exploitation
adapté pour des réseaux de capteurs, comme par exemple Contiki [19] [21] ou TinyOS [48]. Un
système d’alimentation permet d’alimenter en énergie les différents systèmes. L’alimentation
comprend des batteries et éventuellement un système de conversion de tension si les tensions
d’alimentation des systèmes sont incompatibles entre elles et dans le but de mieux exploiter tous
les états de charge des batteries (pleine charge, charge minimum). Certaines implémentations
incluent un récupérateur d’énergie.
2.2.2
Récupération d’énergie
Depuis l’émergence de la recherche sur les réseaux de capteurs, le défi proposé consistait à
réaliser des objets entièrement autonomes, sans fil, ni pour la communication, ni pour l’alimentation énergétique. En excluant la possibilité de recharger les batteries, car le contexte l’interdit
à cause du nombre de capteurs élevés d’un réseau de capteurs, il était nécessaire d’atteindre
des durée de vie de nœuds communicants les plus élevées possibles. Au vu des évolutions technologiques des architectures basse consommation, il apparaissait possible d’obtenir des durées
de vie correspondant aux durées de déploiement des réseaux de capteurs.
La récupération d’énergie est bien sûr liée au milieu dans lequel les capteurs sont intégrés.
Les récupérateurs solaires tels que les cellules photovoltaı̈ques sont intéressantes en termes
47
de puissance générée, mais nécessitent une exposition directe à la lumière et ce pendant des
périodes de temps importantes. Les capteurs intégrés sous la surface du sol ou sous les surfaces
tels que les murs et les plafonds sont a priori incompatibles avec cette option.
Les récupérateurs d’énergie de vibrations ont également un rendement intéressant, mais ne
peuvent pas convenir à toutes les situations. L’intégration des capteurs dans les sols et murs de
bâtiments fréquentés permettre de générer une puissance électrique moyenne issue de vibrations
de l’ordre de 200 µW/cm3 , ce qui commence à être une valeur exploitable.
Le tableau 2.1 résume les solutions possibles pour l’alimentation des systèmes, et en particulier les performances des systèmes de récupération d’énergie.
On peut constater que la puissance moyenne indicative de 1 mW est un objectif vers lequel
il faut tendre en ce qui concerne le budget énergétique.
2.2.3
Systèmes d’exploitation événementiels
Bien que la description des traitements n’implique ni de préciser la cible, ni a fortiori le
système d’exploitation employé, la question de l’ordonnancement des différentes tâches peut
tout de même être posée dès maintenant. En effet, comme il en a déjà été question au début de ce chapitre, l’implémentation centrée sur un microcontrôleur généraliste reste une des
meilleures possibles, du fait des raisons précédemment évoquées. Dans ces conditions, il est
possible d’amorcer une réflexion sur le système permettant de faire cohabiter les traitements
en tenant compte des contraintes fortes des réseaux de capteurs.
La trame logicielle du prototype doit être conçue de façon modulaire pour simplifier le travail
en équipe et la prise en main du logiciel. Dans cette optique, il est nécessaire de s’équiper
d’un système d’exploitation ou tout du moins d’une structure d’ordonnancement permettant
de concevoir les traitements indépendamment les uns des autres. De plus, une telle approche
modulaire simplifie la migration de traitements vers des cibles dédiées. Cependant, l’utilisation
d’un système d’exploitation (SE) consomme des ressources additionnelles en termes de mémoire
de programme, de mémoire vive et de temps de calcul au sein d’une architecture matérielle
légère.
Le système d’ordonnancement doit avoir les propriétés suivantes :
– il doit utiliser le minimum de mémoire, pour en laisser le maximum aux traitements effectifs,
– il doit minimiser le surplus de mémoire associé à chaque thread,
– il doit être aussi portable que possible, pour être implanté sur plusieurs microprocesseurs,
et pouvoir être simulé,
48
Tab. 2.1: Comparaison de générateurs d’énergie par récupération et par stockage d’énergie [70].
(Les effets de pertes sont pris en considération pour les batteries.)
Densité de puissance
Densité de puissance
3
(µW/cm )
(µW/cm3 )
Durée de vie d’un an
Durée de vie de 10 ans
15000 (éclairage direct) 15000 (éclairage direct)
Solaire
(exté- 150 (jour nuageux)
150 (jour nuageux)
rieur)
Solaire
6 (bureau)
6 (bureau)
(intérieur)[71]
Vibrations [71]
200
200
0.003 (sous 75 dBa)
0.003 (sous 75 dBa)
Bruit Acoustique
0.96 (sous 100 dBa)
0.96 (sous 100 dBa)
Variation journa- 10
10
lière de température
Gradient de tem- 15 (gradient de 10˚C)
15 (gradient de 10˚C)
pérature [77]
Energie
de
marche
(chaussures) [44]
Batteries
(non
rechargeables au lithium)
Batteries
(rechargeables au
lithium)
Micromoteur
thermique
(hydrocarbure)
[55]
Pile à combustible
(méthanol)
Pile nucléaire
(uranium)
330
330
45
3.5
7
0
333
33
280
28
6.106
6.105
49
– il doit autoriser l’existence d’une mémoire partagée, afin de permettre des optimisations
inter-niveaux,
– il doit pouvoir tenir partie des fonctions de mises en veille prolongé des microcontrôleurs.
Si le terme de système d’exploitation est employé dans le contexte des réseaux de capteurs,
dans la majorité des cas il ne s’agit pas de systèmes d’exploitation ”classiques”. En effet, les
systèmes classiques sont caractérisés par des performances élevées, et par de nombreux services
offerts aux applications. L’objectif d’un système d’exploitation est de faciliter l’accès aux ressources matérielles par les processus applicatifs et de permettre une meilleure portabilité des
applications en rendant l’utilisation des ressources matérielles la plus transparente possible.
Les services qu’il est possible de trouver sont par exemple :
– l’attribution de la ressource ”temps processeur” aux différents processus qui sont en concurrence pour s’exécuter (Cette attribution peut autoriser ou non la préemption du processeur.),
– la gestion des périphériques à l’aide des pilotes de périphériques,
– la gestion de la mémoire partagée pour permettre la communication inter-processus, à
l’aide de sémaphores et de files de messages par exemple,
– l’attribution de la mémoire aux processus,
– la gestion des timers matériels pour rendre transparente leur utilisation par les processus,
– la gestion des chiens de gardes plus communément appelés ”watchdogs” qui permettent
aux processus d’utiliser les ressources matérielles de timers spécifiques pour effectuer des
tâches ou des contrôles périodiques,
– la gestion des entrées/sorties,
– la gestion des fichiers à l’aide d’un système de fichiers,
– la gestion des protocoles réseaux qui peut éventuellement être incluse au sein même du
système d’exploitation,
– la gestion des différents utilisateurs d’une même machine.
On peut classer les systèmes d’exploitation selon de nombreux critères. En particulier, un
système peut être multi-tâches ou mono-tâche. La capacité d’être multi-tâches autorise l’exécution de plusieurs processus ”simultanément” à l’aide d’un seul processeur en attribuant le temps
processeur alternativement à chacun des processus. Ce mécanisme nécessite de gérer dans une
partie de la mémoire un certain nombre d’informations pour chaque processus (ou thread ) en
cours d’exécution. Les différentes informations liées à chaque processus sont :
– l’état du processus, qui peut être en train de s’exécuter (running), prêt à s’exécuter mais
en attente de la ressource processeur (ready), en attente d’une ressource (waiting), etc...,
50
– les valeurs des registres processeur, pour pouvoir sauvegarder et restituer un contexte
d’exécution lors d’une préemption (si ce mécanisme de préemption est disponible) ou plus
généralement à chaque fois qu’un processus rend la ressource processeur. Parmi ces valeurs
on peut aussi compter le pointeur d’exécution, le pointeur de position initiale dans la
mémoire, le pointeur de pile d’exécution, etc...
Il faut également distinguer les systèmes multi-processeurs des systèmes mono-processeurs.
Les systèmes multiprocesseurs sont capables comme leur nom l’indique de gérer l’attribution
de plusieurs processeurs, parfois avec le même espace mémoire. On peut donc dans ce cas trouver simultanément plusieurs processus en état d’exécution. Dans ce cas de figure les processus
peuvent s’exécuter réellement simultanément contrairement aux simples systèmes multi-tâches
où l’exécution s’effectue en ”pseudo-parallèle”. Les systèmes multi-processeurs sont dédiés à des
applications nécessitant des performances très importantes et a priori éloignées des contraintes
de forte autonomie requises dans le cadre des réseaux de capteurs.
Certains systèmes peuvent être qualifiés de systèmes temps-réel. Dans ce cas, cela implique
que le système a été conçu pour prendre en compte des contraintes temporelles d’exécution, et
si besoin garantir l’exécution de certains algorithmes dans des laps de temps définis, dans la
mesure des capacités de ”charge” du processeur.
On peut aussi distinguer deux grandes familles de systèmes d’exploitation, que sont les systèmes orientés threads ou systèmes orientés processus légers et les systèmes orientés événements. La distinction est alors très forte entre ces deux classes de systèmes d’exploitation. Les
systèmes orientés threads sont les systèmes les plus classiques et les plus répandus. A chaque
thread sont associées les informations d’état du thread et de valeur des registres processeur. Le
noyau du système d’exploitation est la partie du système qui, entre autre choses gère l’état des
threads, c’est-à-dire qui doit effectuer la sélection des processus légers qui accèdent au processeur
et qui effectuent les préemptions et les commutations de contexte.
Les systèmes événementiels fonctionnent d’une façon très différente. Dans ce type de système,
le coeur du noyau est constitué d’une boucle événementielle qui contrôle en permanence l’arrivée
d’événements. Les traitements sont réalisés non pas par des threads, mais exclusivement à l’aide
des traitants d’événements qui sont invoqués par la boucle événementielle. Il ne peut pas y avoir
de préemption pendant l’exécution d’un traitant. C’est pourquoi généralement ceux-ci sont de
courte durée et rendent la main rapidement à la boucle événementielle.
La principale difficulté de la réalisation de systèmes événementiels est le codage des trai-
51
tants, qui implique de programmer d’une façon radicalement différente d’une programmation
sous forme de threads qui est plus naturelle. De plus, ce type de fonctionnement non concurrentiel ne peut pas être employé dans tous les cas de figure, par exemple pour certaines applications
de calcul scientifique ou encore les systèmes comportant des interfaces d’entrée/sortie associées
à des buffers matériels sous-dimensionnés. Les traitants étant non préemptibles, le fonctionnement peut s’en trouver moins fluide, plus ”haché” que dans un système basé sur des threads,
surtout si certains traitants sont longs. Cependant, ce comportement est particulièrement bien
adapté à des applications de type GUI (Graphic User Interface, pour Interface Graphique
Utilisateur), mais aussi pour les systèmes distribués comme les réseaux de capteurs, où les traitements découlent d’événements précis tels que la réception d’une trame de données ou encore
la détection d’un événement lié au capteur.
Ce qui fait l’intérêt majeur des systèmes événementiels dans des contextes de mémoire fortement contrainte, c’est qu’il n’y a qu’un seul flot d’exécution, contrairement à un système à base
de threads, ce qui signifie qu’il n’y a pas concurrence pour obtenir la ressource processeur. Cette
remarque est très importante, parce que de nombreux problèmes sont ainsi écartés, comme par
exemple les interblocages, les accès multiples à une même variable en mémoire partagée, etc...
Le fait qu’il n’y ait qu’un seul flot d’exécution signifie aussi qu’il n’y a pas de commutations de
contexte, pas de pile d’exécution par threads à gérer, ce qui épargne beaucoup la mémoire nécessaire et constitue un avantage majeur dans le cas de systèmes fortement contraints en mémoire.
2.2.4
TinyOS et le langage de description nesC
Le système TinyOS est de loin le plus utilisé pour les réseaux de capteurs. C’est le système
dédié aux plate-formes de la société CrossBow fondées par des chercheurs de l’Université de
Berkeley et du M.I.T. et qui commercialise depuis 2001 des solutions de réseaux de capteurs
(modules Mica, WeC, Rene, Dot, Mica2, Micaz).
Le système, les bibliothèques et les applications de TinyOS sont écrits en nesC, un nouveau
langage de description pour la programmation structurée d’applications, adapté aux systèmes
embarqués et donc en particulier aux réseaux de capteurs. La syntaxe de nesC ressemble à la
syntaxe du C, mais elle autorise en plus l’exécution compétitive ainsi que des mécanismes pour
structurer, nommer et lier des modules logiciels. Cela permet de faciliter le développement de
modules logiciels qui peuvent être facilement assemblés les uns avec les autres.
TinyOS et son langage de programmation nesC sont construits autour de deux concepts
majeurs : des composants logiciels ayant des interfaces bi-directionnelles bien définies et un
52
Fig. 2.3: Exemple de partie d’application nesC constituée de deux composants.
module moduleN {
provides {
/*interface permettant d’initialiser ce composant*/
interface Init;
/*interface permettant d’allumer ou d’éteindre un composant*/
interface StdControl;
/*interface permettant d’accéder au service principal rendu par ce composant*/
interface ServiceN; }
uses{
/*interface permettant d’allumer ou d’éteindre un composant*/
interface StdControl as moduleNinf;
/*interface de service utilisé par ce composant*/
interface ServiceNinf as moduleNinf;
}
}
Fig. 2.4: Partie déclaration en nesC du composant moduleN.
modèle concurrentiel d’exécution, basé sur des tâches et des traitements d’événements matériels
Une application nesC est constituée d’un ou de plusieurs composants reliés ensemble et qui
forment un exécutable. Sur l’exemple de la figure 2.3, deux composants sont représentés :
moduleN et moduleNinf, le premier utilisant les services fournis par le second. Un composant
fournit et emploie des interfaces qui sont leurs seuls points d’accès et qui sont systématiquement
bi-directionnelles. Un même composant peut fournir plusieurs interfaces, de même qu’il peut
utiliser plusieurs interfaces d’autres composants. Sur la figure 2.4 est représentée la partie de
déclaration des interfaces du code du composant appelé moduleN sur la figure 2.3.
On distingue deux types de composants nesC qui sont les modules et les configurations. Les
modules fournissent le code de l’application et des interfaces. Les configurations sont utilisées
pour assembler les composants les uns avec les autres. Chaque application nesC est décrite par
une configuration de haut niveau qui relie ensemble les composants de l’application.
Modèle compétitif.
TinyOS exécute un programme qui consiste en un ensemble de com-
posants système et d’un ensemble de composants dépendant de l’application. Il y a deux flux
d’exécution : les tâches et les traitants d’événements matériels. Les tâches sont des fonctions
dont l’exécution est suspendue. Lorsqu’elles sont ordonnancées, elles se débloquent et s’exécutent jusqu’à leur terminaison. Les tâches ne peuvent pas effectuer de préemption. Les traitants
53
d’événements matériels sont exécutés en réponse à une interruption matérielle et s’exécutent
jusqu’à leur terminaison. La différence avec les tâches réside dans le fait que les traitants d’événements matériels peuvent faire de la préemption d’exécution sur une tâche ou un autre traitant
d’événement matériel.
Etant donné que les tâches et les traitants d’événements matériels peuvent subir de la préemption, les programmes en nesC ne se déroulent pas de façon déterministe. Pour fiabiliser les
traitements dans une situation de compétition entre programmes en nesC, il est possible de
gérer des accès exclusifs à la mémoire et il est également possible d’employer des instructions
atomiques1 .
Dans notre exemple choisi (figure 2.4), le code de l’application du composant moduleN (représenté sur la figure 2.5) est constitué d’une tâche qui fait appel à plusieurs services fournis par
le composant moduleNinf. Cette tâche correspond à un traitement linéaire, puisqu’il s’agit de
faire appel de façon séquentielle à trois services du composant moduleNinf (service1, service2,
service3 ). Pourtant, pour ce comportement linéaire simple, nesC oblige à faire une description
sous forme de machine d’états. Chacun des états évolue à la réception d’un signal de retour
envoyé par le composant fournisseur des services lorsque les services ont été réalisés.
Commentaires sur nesC et TinyOS. Plusieurs remarques peuvent être faites sur TinyOS
et le langage nesC au cœur de ce système événementiel. Tout d’abord on constate que la
conception d’un code séquentiel simple nécessite l’emploi d’une structure rigide et complexe.
Certes, la modularité est forte ce qui favorise l’abstraction et la réutilisabilité du code. La
programmation modulaire laisse entendre une réutilisabilité forte des modules pour concevoir
des applications rapidement, cela est effectivement très simple dans le cas d’une réutilisation
des plate-formes développées par les concepteurs de TinyOS (plate-formes Mica2, Micaz, etc.).
Dans le cas d’un portage de TinyOS vers d’autres plate-formes, cela devient alors plus difficile
parce que la programmation en nesC événementielle est particulièrement ardue. Les traitements
doivent le plus souvent être décrits sous forme de machines d’états ce qui n’est pas naturel. Pour
illustrer cela, le code de notre modules d’exemple, qui ne fait qu’invoquer de façon séquentielle
trois sous-procédures, nécessite une machine d’état complète et le code en résultant est très
lourd.
De plus, une application relativement simple nécessite tout de même un grand nombre de
composants simples et le nombre d’interfaces reliant ces composants est rapidement très grand.
Le compilateur qui génère un code exécutable à partir de ce langage de description nesC effectue
1
Les instructions atomiques s’exécutent en une seule fois et ne peuvent pas subir de préemption. Elles permettent de sécuriser des opérations critiques en interdisant toute préemption à l’intérieur des zones indiquées.
54
implementation {
enum{ ETAT0 = 0, ETAT1, ETAT2, ETAT3};
union {
uint8_t flat;
struct {
uint8_t etat : 2; /* état de la machine d’état*/
} bits;
} flag;
/*** Commande d’initialisation de ce composant (interface "Init") ***/
command error_t Init.init() {
flag.flat = ETAT0; }
/*** Commande de démarrage de ce composant (interface "StdControl" ***/
command error_t StdControl.start() {
call serviceNinf.StdControl.start(); }
/*** Commande d’arr^
et ce composant (interface "StdControl") ***/
command error_t StdControl.stop() {
call serviceNinf.stop();
atomic flag.bits.etat = ETAT0; }
/*** T^
ache correspondant au service principal rendu par ce module moduleN ***/
task void ServiceN.service() {
switch(etat) {
case ETAT0:
case ETAT1: call moduleNinf.ServiceNinf.service1();
/*fait appel au service d’un module "de niveau inférieur"*/
return; /*indique les points de la t^
ache où les préemptions sont possibles*/
case ETAT2:
call moduleNinf.ServiceNinf.service2();
return;
case ETAT3:
call moduleNinf.ServiceNinf.service3();
return;
} }
/*** Traitants d’événements matériels ***/
event void moduleNinf.serviceNinf.service1_fait() {
etat=ETAT2; } /*évolution de la machine d’état de la t^
ache principale*/
etat=ETAT3; }
etat=ETAT0;
post ServiceN.service_fait();
/*signale l’accomplissement de la t^
ache principale au module utilisateur de niveau supérieur*/
} }
Fig. 2.5: Partie implémentation en nesC du composant moduleN.
55
des opérations automatiques qui ne peuvent permettre d’explorer des optimisations mémoire
les plus fines. C’est le second reproche qu’on peut faire à TinyOS : une sous-optimalité qui est
due à l’utilisation d’un langage de description intermédiaire transformé de façon automatique
par un compilateur.
Nous considérons que TinyOS est fortement lié aux plateformes de la société Crossbow ce
qui leur permet d’offrir un package matériel et logiciel flexible pour l’étude de mécanismes de
haut-niveau, mais nous pensons que la rigidité de la programmation et le fait de se reposer sur
la qualité du compilateur pour l’obtention de codes performants n’est pas le meilleur point de
départ pour la conception d’un système extrêmement contraint en mémoire et en particulier
en mémoire RAM. De plus comme nous ne pensons pas nous fixer dans l’immédiat de cible
matérielle, la complexité de programmation des couches basses sous TinyOS nous a paru être
un choix difficile à assumer pour la suite du développement. Pour ces raisons nous n’avons pas
choisi de développer notre logiciel sur ce système événementiel.
2.2.5
Modèle en couche d’interconnexions de systèmes
Le modèle OSI (Open Systems Interconnection ou Interconnexion de Systèmes Ouverts) défini par l’ISO (International Standardization Organization) en 1984 avait pour objectif de définir
une architecture logicielle de référence, en réponse à une multiplication des solutions propriétaires pour la mise en réseau de systèmes informatiques. Ce modèle avait pour but de définir un
mécanisme permettant une plus grande interopérabilité entre systèmes différents tout en autorisant des évolutions technologiques des médiums de transport de l’information. Le terme de
“système ouvert”, dans ce contexte, signifie un système informatique dont l’architecture interne
est quelconque, mais dont les traitements réseaux respectent des règles d’interopérabilité. Ce
modèle est organisé en 7 couches et respectent un certain nombre de principes stricts. Chaque
couche décrit un protocole indépendant des autres couches, chaque couche fournit des services
à la couche immédiatement supérieure et requiert les services de la couche immédiatement inférieure. Les couches extrèmes fonctionnent de la même façon, la couche supérieure (la couche
application) fournissant un service à un programme ou à un opérateur humain, et la couche
inférieure (couche physique) exploitant le médium de communication.
Les couches de protocole. Le schéma des couches de protocole du modèle OSI est présenté
sur la figure 2.6.
– La couche physique a pour rôle de convertir un signal sous forme binaire en un signal
pouvant être transmis sur le médium de communication (paire de cuivre, une fibre optique,
56
Fig. 2.6: Les 7 couches du modèle OSI.
canal radio fréquence).
– La couche liaison de données gère le contrôle de l’intégrité des données. Elle doit gérer
l’accès au médium, sachant que plusieurs entités se partagent un ou plusieurs canaux de
communication. La couche liaison de données a aussi pour rôle de fiabiliser les communications à l’aide de diverses stratégies possibles basées sur de la détection et de la correction
d’erreurs ainsi sur des réémissions de paquets. Cette couche gère l’envoi et la réception
des messages d’aquittement nécessaire pour fiabiliser les communications. Elle offre à la
couche supérieure des transmissions de données garanties.
– La couche réseau a pour rôle de faire transiter les paquets de données au sein du réseau jusqu’au destinataire final de la communication. Elle gère le routage, mais aussi la
congestion.
– La couche transport est chargée d’assurer la supervision de la couche réseau. Cette couche
transport qui peut prendre l’initiative de réinitialiser des connexions et de reprendre le
transfert des données en cas d’interruption de connexion.
– Cette couche organise et synchronise les échanges entre tâches distantes. Elle réalise le
lien entre les adresses logiques et les adresses physiques des tâches réparties. Elle établit
également une liaison entre deux programmes d’application devant coopérer et commande
leur dialogue. Dans ce dernier cas, ce service d’organisation s’appelle la gestion du jeton.
La couche session permet aussi d’insérer des points de reprise dans le flot de données de
manière à pouvoir reprendre le dialogue après une panne. Une seule session peut ouvrir
et fermer plusieurs connexions, de même que plusieurs sessions peuvent se succéder sur la
même connexion.
57
– La couche présentation traite les problèmes liés à la syntaxe et à la sémantique des données transmises. Elle traite l’information de manière à la rendre compatible entre tâches
communicantes. Elle va assurer l’indépendance entre l’utilisateur et le transport de l’information. Par exemple, elle code les données sous un format standard pour que toutes les
machines puissent y lire les mêmes informations. Cette couche présentation peut convertir
des données, les reformater, les crypter ou encore les compresser.
– La couche application est la couche de plus haut niveau. Cette couche est le point de
contact entre l’utilisateur et le réseau. C’est donc elle qui va apporter à l’utilisateur les
services de base offerts par le réseau comme une messagerie, un client FTP (File Transfer
Protocol), etc.
Principe de communication inter-niveau.
Le principe de la communication est le suivant
(Fig. 2.15, page 66) : à un niveau N , les données sont transmises aux entités de même niveau
N à l’aide des services fournis par le point d’accès service (SAP, pour Service Acces Point)
de la couche de niveau N − 1, et selon le protocole de la couche N . Le protocole de niveau
N se traduit par l’adjonction de données spécifiques à ce niveau. Ces données ajoutées par
la couche N sont appelées informations de contrôle de protocole (PCI, pour Protocol Control
Information). Le PCI est juxtaposé aux données provenant de la couche N + 1 qui forment
l’unité de données de service (SDU, pour Service Data Unit). La juxtaposition du PCI et du
SDU forment l’unité de données de protocole (PDU, pour Protocol Data Unit)
Ce modèle OSI peut être interprété de plusieurs façons : il peut d’abord être interprété
comme un cadre général pour tout système de mise en réseau, à l’aide des concepts de couches
et d’utilisation de services de niveau inférieur. D’ailleurs, toutes les normes réseaux existantes
sont calquées sur ce modèle.
Si on le prend à la lettre, cependant, le modèle OSI strict n’a jamais débouché sur des
réalisations industrielles, son intérêt étant plutôt d’ordre académique.
Simplification du modèle dans le contexte des réseaux de capteurs. Au vu de la
grande complexité du modèle OSI et de l’imperméabilité des niveaux interdisant toute forme
d’optimisation inter-niveau, il est nécessaire de ne garder que ce qui est le plus utile dans
l’optique de la définition d’un logiciel de réseau de capteurs. Ce logiciel doit être respectueux
de l’espace mémoire et doit autoriser une perméabilité entre les niveaux au prix d’une réduction
de l’interopérabilité. Ainsi, alors que le modèle OSI est constitué de sept couches, le logiciel
développé n’en comprend que quatre, représentées sur la figure 2.7. Le niveau application inclut
outre les applications ”utilisateur”, les applications communes relevant de mécanismes réseaux
58
Fig. 2.7: Organisation réduite à quatre couches du logiciel développé.
incontournables ans les réseaux de cpateurs tels que l’autopositionnement ou encore la recherche
de voisins. Le niveau réseau prend en charge les opérations de routage au sein du réseau adhoc. Le niveau liaison assure la fiabilité des transferts à l’aide de mécanismes de réémission
automatique et de correction d’erreurs. Enfin, le niveau physique assure les opérations d’accès
au média et d’émission et réception à bas niveau.
2.3
Infrastructure logicielle de la pile de protocole développée
L’architecture générique, le système d’exploitation événementiel et le modèle en couches
ayant été décrits, il s’agit à présent de développer un logiciel qui puisse accepter différentes
déclinaisons matérielles. C’est ce qui va être développé dans les sous-sections suivantes.
La pile de protocole de la plate-forme R2D2 existe en plusieurs versions, toutes basées sur le
même dénominateur commun. La figure 2.8 représente schématiquement l’ensemble des traitements de la plate-forme R2D2. Le code couleur utilisé montre que les traitements sont divisés
en trois catégories.
– Certains traitements dépendent de l’application du réseau de capteur, par exemple, dans
le cas d’un réseau de capteur de surveillance de la température, les traitements propres à
cette application particulière consistent à effectuer des mesures et à générer des rapports
de mesures.
– Certains traitements dépendent du matériel employé, c’est-à-dire qu’ils dépendent de la
couche physique employée, mais aussi des ressources matérielles de bas niveau permettant
de générer une horloge. Dans le cas d’une implémentation basée sur un microcontrôleur,
l’ ”horloge” interne est générée à partir de l’utilisation des timers matériels du microcontrôleur.
2.3 Infrastructure logicielle de la pile de protocole développée
59
Fig. 2.8: Schéma logiciel global de la plate-forme R2D2.
– Enfin, certains traitements sont communs à toutes les applications et toutes les implémentations matérielles.
Lors de la réflexion pour la conception de cette trame logicielle, l’objectif était de faire en sorte
que le plus de traitements possibles ne dépendent ni des choix matériels liés à la couche physique
ou à un type de microcontrôleur particulier, ni de l’application visée. En ce qui concerne les
applications, l’étude préalable des besoins en termes de schémas de routage nécessaire nous
permet de penser que la trame logicielle actuelle est capable de s’adapter à la plupart des
applications.
De plus cette décomposition logicielle est également très ouverte par rapport au matériel sur
lequel il sera porté et permet des implémentations très différentes. Il est à noter que le logiciel est
écrit en C ce qui assure le plus grand panel de choix matériels. Les figures 2.9 et 2.10 illustrent
deux implémentations très différentes, respectivement pour une plate-forme réelle autour d’un
Texas Instrument MSP430 et d’un ChipCon CC1020, et pour une implémentation virtuelle dans
le but de créer des réseaux de processus Unix communicant sur des canaux virtuels réalisés à
partir de files de messages Unix. Cette dernière implémentation a un intérêt dans la phase de
création de l’application, où le concepteur d’application peut faire abstraction des contraintes
60
Fig. 2.9: Déclinaison du logiciel pour une architecture autour d’un TI MSP430 et d’un ChipCon
CC1020 en employant une technique d’accès au médium RICER.
Fig. 2.10: Déclinaison du logiciel pour un réseau de capteurs virtuel, sous système Unix.
de performance du canal pour se consacrer pleinement au développement de son application et
ce sans avoir à passer par la phase de reprogrammation de capteurs ”physiques” qui peut être
une étape très fastidieuse.
Le réseau de capteurs est formé de trois catégories de nœuds. La première catégorie de
nœuds est majoritaire et inclut des capteurs à mobilité très faible ou nulle, avec une énergie
embarquée limitée. Les stations de bases constituent des cas particuliers de la première catégorie
et sont en très petit nombre et supposées illimitées en énergie. Enfin, la troisième catégorie
de nœuds est minoritaire, avec une mobilité et une énergie embarquée éventuellement plus
importantes. La mobilité des nœuds du réseau est très faible, voire nulle, à l’exception des
capteurs spécifiquement mobiles, qui sont des cas particuliers et qui n’ont pas à assurer les
fonctions de routage, par exemple.
Catégorie
de nœud
Mobilité
Énergie
embarquée
Adressage
Nombre
Tab. 2.2: Catégories
Nœuds
fixes
Mobilité nulle
ou très faible
Très faible
Dépendant de la
position géographique
Élevé
61
des nœuds du réseau de capteurs
Station
Nœuds
de base
mobiles
Mobilité nulle
Mobilité importante
ou très faible
Moyenne
Élevée
Dépendant de la
Faible
Indépendant de la
Faible
Fig. 2.11: Niveau application du logiciel
2.3.1
Niveau application
Le niveau application du logiciel de réseau de capteur est constitué de plusieurs tâches représentées sur la figure 2.11.
Mécanisme d’autopositionnement. Dans les réseaux de capteurs, le mécanisme d’autopositionnement est nécessaire pour plusieurs raisons. D’une part, les données mesurées par le réseau
de capteurs doivent être localisées dans l’espace (et le temps), pour pouvoir être exploitées par
la suite par les stations de bases. D’autre part, la connaissance de la position géographique
peut être avantagement exploitée pour effectuer du routage géographique, réputé comme étant
un des plus simples et des moins coûteux, mais qui nécessite la connaissance de la position
des capteurs du réseau. Certains réseaux de capteurs sont bien organisés en des réseaux aux
mailles régulières. C’est le cas dans un certain nombre d’applications de surveillance de zone
(domaine militaire, mais aussi études de populations d’animaux, etc. ). Cependant, dans le
cas le plus général les capteurs présentent des organisations moins régulières pour plusieurs
raisons : lorsque la disposition des capteurs calque la configuration des lieux, par exemple un
schéma mixte avec des zone d’intérêt à fortes densité de capteurs et des zones de plus faible
densité de capteurs ayant plus un intérêt en termes d’interconnexion de zones, mais aussi dans
le cas où les capteurs ont été placés par un procédé aléatoire, tel que la diffusion par avion.
Dans le cas d’un réseau irrégulier, un mécanisme d’autopositionnement est indispensable à
62
partir du moment ou le nombre de capteurs devient important. Le principe de fonctionnement
de ce système d’autopositionnement est ouvert à toute technique physique, et nous supposons
simplement qu’il y a un processus qui entretient cette connaissance de la position propre.
Le mécanisme d’autopositionnement a été développé sous forme d’un processus d’autopositionnement
permet au nœud de trouver et si besoin de mettre à jour l’information de sa propre situation
au sein du réseau de capteurs. Cette information est utilisée pour les opérations de routage et
de signature spatiale des échantillons mesurés.
Mécanisme de recherche des voisins. Pour un nœud donné du réseau de capteurs, la connaissance des nœuds voisins proches est importante et doit être déterminée et maintenue à jour. La
connaissance des voisins proches est très importante dans le contexte de réseau de capteurs, en
effet cela rend possible de nombreux mécanismes propres aux réseaux de capteurs, tels que la
création de zones virtuelles sur un critère de proximité. Un voisinage peut agréger des données
localement à l’aide de mécanismes coopératifs dans le but de minimiser les données qui sont
transmises à longue distance en direction des stations de base, par exemple. De même, combiné
au mécanisme d’autopositionnement évoqué au paragraphe précédent, le mécanisme mettant
à jour la connaissance du voisinage permet de réaliser la fonction de routage géographique.
La mémoire étant considérée comme une ressource très critique, en particulier dans la partie
du réseau des nœuds fixes ou l’énergie embarquée est la plus faible (voir tableau 2.2), une
connaissance exhaustive ne peut pas être intégrée pour réaliser la fonction de routage. Dès lors,
la connaissance des voisins proches apparaı̂t comme un minimum pour réaliser la fonction de
routage. Le routage d’une information sur une distance s’étendant au-delà d’un même voisinage exploitera au fur et à mesure de la progression les informations locales limitées des nœuds
utilisés dans la progression. Ce mécanisme de recherche et de maintien de la connaissance du
voisinage est donc fondamental à plusieurs titres et est un des traitements de base présents
dans le prototype R2D2. Son bon fonctionnement permet d’assurer une certaine tolérance aux
pannes des capteurs voisins, mais aussi de prendre en considération des mouvements lents des
voisins.
Ce mécanisme se traduit dans la plateforme que nous avons développée par un processus de
mise à jour du voisinage qui permet au nœud de déterminer et d’entretenir les informations
sur les nœuds dans son voisinage. Ces informations comprennent bien sûr les positions relatives
des voisins et éventuellement des informations complémentaires sur l’état d’énergie estimée
de chaque voisin, pour permettre l’implémentation d’algorithmes de routages respectueux de
l’énergie. Ces informations sont stockées dans un tableau appelé table de voisinage.
63
Fig. 2.12: Niveau réseau du logiciel
Mécanisme de maintien des informations des stations de base. La connaissance du voisinage
est très importante mais cependant non suffisante pour assurer tous les cas de figure de routage
à longue distance. En effet, si on considère qu’une donnée mesurée a pour destinaire final une
station de base, dans le cas général, cette station de base est éloignée et ne fait par conséquent
pas partie du voisinage du capteur. Il faut donc un mécanisme qui maintienne à jour les adresses
(ou les positions géographiques) des différentes stations de bases présentes dans le réseau.
Ce mécanisme apparaı̂t dans le logiciel développé par le processus d’ écoute de la station
de base qui permet à un nœud du réseau (hormis la station de base) de traiter les ordres en
provenance de la station de base. Ces ordres peuvent être de toute nature, ce peut être des ordres
de mise à jour du voisinage, de réalisation de mesure, de transmission d’informations, etc... Ce
peut être aussi le processus qui met à jour la position de la station de base, puisque dans le cas
général la station de base n’est pas à portée radio du nœud, et elle est donc potentiellement
absente de la table de voisinage. Les informations liées à la station de base, et en particulier sa
position dans le réseau de capteurs, sont stockées dans la zone de stockage notée ”Infos station
de base”.
2.3.2
Niveau réseau
Le niveau réseau du logiciel générique est en charge du routage des informations dans le
réseau. Le schéma de ce niveau du logiciel est représenté sur la figure 2.12.
Mécanismes de routage. Chaque nœud du réseau est à la fois une source d’information, grâce
aux données issues du ou des capteurs embarqués, mais chaque nœud est également un relais
pour les autres nœuds. Autrement dit chaque nœud remplit la fonction de routage au sein du
réseau. Plusieurs modes de routage doivent être disponibles et pour chaque mode de routage,
la procédure est particulière. Ces modes ont été définis après analyse préalable des paradigmes
applicatifs de transports (ces derniers ayant été exposés au cours du chapitre 1). Les méca-
64
Fig. 2.13: Niveau liaison du logiciel
nismes de routage doivent être adaptés à des réseaux de capteurs, c’est-à-dire être robustes,
tolérants aux pannes, dans une certaine mesure tolérants à la mobilité. De plus, le routage doit
pouvoir être effectué sur des réseaux étendus et denses comprenant de nombreux nœuds. Ce
dernier point est délicat, puisque les données utilisées pour effectuer le routage sont bornées
par les capacités de stockage limitées de la mémoire embarquée dans chaque nœud.
Le logiciel développé est organisée de la façon décrite ci-après pour pouvoir remplir ces
fonctions de routages.
Le processus descendant (de la couche application vers la couche liaison) permet d’inclure
dans les trames à émettre les informations de routage nécessaires au bon acheminement des
paquets, en fonction du mode de transmission qui a été séléctionné par les applications en amont.
Ce processus exploite les informations de la table de voisinage pour réaliser ce traitement.
Le processus d’analyse du mode, ascendant (de la couche liaison vers les couches supérieures),
analyse comme son nom l’indique le champ mode des trames reçues, en fonction de quoi il peut
déclencher une réémission de message (cas des modes inondation, diffusion et multi-étapes)
et/ou transmettre le paquet reçu vers les couches supérieures tel un filtrage. Il effectue également
l’interprétation des champs de données de la trame brute à l’aide de cette information du mode.
Le processus d’analyse du type, également ascendant, receptionne les trames non filtrées par le
processus d’analyse du mode et déclenche le processus adéquat grâce à l’information constituée
par le type du message. Plusieurs types différents peuvent être aiguillés vers le même processus
applicatif.
2.3.3
Niveau liaison
Le niveau liaison a pour objectif de fiabiliser les transferts de données. Le schéma de ce
niveau est présenté sur la figure 2.13. Deux mécanismes sont employés en série : un système de
correction d’erreurs (FEC, pour Forward Error Coding) et un système de réémission automa-
while(1) {
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
}
65
(driverReception) ;
(driverEmission) ;
(simuleHorloge) ;
(liaison) ;
(reseau) ;
(gestionTimers) ;
(gestionREQvois) ;
(ConnaitreVois) ;
(MAJtabVois);
(managePresence);
(vagueREQvois);
Fig. 2.14: Boucle d’ordonnancement.
tique en cas d’impossibilité de reconstituer une trame valide à l’aide du premier mécanisme.
Chaque trame de données comporte 32 bits permettant de stocker de la redondance de donnée.
Les choix sont ouverts quant à la sélection d’un algorithme particulier.
2.3.4
Ordonnancement des tâches
L’ordonnancement des tâche est fixe contrairement à un système gérant le multi-threading.
Il respecte l’ordre d’ordonnancement de la figure 3.11. Ainsi , les traitements se voient proposer
chacun à leur tour l’occasion de s’exécuter. Si toutes les conditions sont réunies, alors un traitement donné s’exécute effectivement. Sinon, la tâche doit rendre la main. La rigidité apparente
de ce genre d’approche permet en fait de se passer d’un véritable ordonnanceur complexe de
tâches, et ce au sacrifice d’un peu de performance, notamment en termes de réactivité.
2.3.5
Optimisation des buffers des SAP
Le modèle OSI présenté à la section 2.2.5 est intéressant à de nombreux point de vue, en
particulier sur l’aspect de l’indépendance stricte entre les niveaux et le principe d’abstraction.
Cependant, en contrepartie, une telle organisation de la couche de protocole donne une certaine
rigidité et surtout une sous-optimalité à l’ensemble en particulier d’un point de vue de la
consommation énergétique. Ce défaut est mis en évidence dans [27] qui propose une plus grande
perméabilité des niveaux pour réaliser des optimisations conjointes ”cross-layer”.
En particulier, la rigidité et la sous-optimalité de niveaux complètements indépendants les uns
des autres se reflète dans le problème des buffers des points d’accès service (SAP). Les différents
niveaux du protocole réseau communiquent via les SAP et utilisent un principe d’encapsulation
des niveaux de protocoles (Fig. 2.15). Considérons la couche de niveau N dans le sens de
66
Fig. 2.15: Principe d’encapsulation des niveaux.
Fig. 2.16: Buffer amélioré avec une redondance nulle.
l’émission de données dans le réseau. La couche N prend en charge des données confiées via le
SAP(N + 1)par la couche N + 1, c’est-à-dire le SDU(N ) (qui peut aussi être noté PDU(N + 1)).
Les données apportées par la couche N sont juxtaposées au SDU(N ) ce qui forme le PDU(N ).
Ce PDU(N ) est ensuite transmis au SAP(N ) afin d’utiliser les services de la couche N − 1.
Concrètement, les données transmises via les SAP sont transmises via des buffers entre les
tâches des différents niveaux. Ce qu’on peut remarquer, c’est qu’il y a une forte redondance
entre les données placées dans le buffer du SAP(N ) et du SAP(N + 1), puisqu’il y a une partie
de l’information qui est identique (à savoir le SDU(N )). Cela se traduit par une utilisation non
optimale des ressources mémoire. Dans le cas d’un système embarqué à faible activité comme
dans un réseau de capteurs, la consommation d’énergie liée à la mémoire est majoritaire, c’est
la raison pour laquelle les ressources mémoire sont limitées au maximum.
Pour améliorer cet aspect, nous avons imaginé un buffer unique pouvant être accédé en lecture et en écriture par n’importe quelle tâche (Fig. 2.16). De cette façon, il devrait être possible
d’éliminer toute redondance non voulue au sein des trames de données. Evidemment, un tel
buffer ne peut pas être utilisé tel quel et des précautions doivent être prises. La ressource que
représente le buffer doit être gérée pour éviter des problèmes d’incohérences, à l’aide de méca-
2.4 Modes de transmission et vecteurs de l’information
67
Fig. 2.17: Les modes de transmission nécessaires pour des réseaux de capteurs
nismes d’exclusion mutuelle. Pour cela, un champ historique est présent en plus pour chaque
ligne de buffer (Fig. 2.16). Ce champ de données additionnel permet d’organiser la séquentialité
des traitements. Chaque couche de protocole effectue une lecture du champ historique ce qui
lui permet de savoir si son PCI peut être calculé (sens descendant) ou bien si le SDU peut être
extrait du PDU (sens ascendant). Le calcul est effectué le cas échéant, et la couche de protocole
doit alors faire évoluer le champ historique pour autoriser les traitements ultérieurs.
2.4
2.4.1
Modes de transmission et vecteurs de l’information
Modes de transmission dans un contexte de réseau de capteurs
Pour pouvoir réaliser l’ensemble des transferts tels que ceux qui ont été présentés au premier
chapitre, certains modes de transmissions devront être présents à la fois pour permettre aux
mécanismes de base de fonctionner (autopositionnement, recherche des voisins), mais également pour fournir au concepteur une boı̂te à outils lui permettant de définir les applications
communicantes. On retrouve ces modes illustrés sur la figure 2.17.
Les tableaux 2.3, 2.4, présentent les modes de routage disponibles dans le prototype R2D2
pour les communications respectivement, entre capteurs fixes uniquement, d’une part, et entre
capteurs fixes et mobiles, d’autre part. Lorsqu’un capteur d’émission génère un message à
émettre dans le réseau de capteurs, il doit employer un mode de transmission parmi ceux qui
sont utilisables.
2.4.2
Structure des trames
Des trames ”sur mesure”. Ce travail de thèse sur les réseaux de capteurs a été articulé
autour de la définition précise des besoins applicatifs pour adapter les traitements nécessaires
au mieux. La définition de la structure des trames échangées est faite ”sur mesure”. Ces trames
de données à ”géométrie variable” permettent d’économiser à la fois la quantité de mémoire
des buffers des capteurs, mais aussi de minimiser les temps nécessaires à l’émission, puisque
l’information à transmettre est réduite.
68
Tab. 2.3: Modes de routage disponibles sur la plate-forme R2D2 pour effectuer des communications entre des capteurs fixes uniquement.
Nom
du Fonctionnement
AcquitInformations du PCI du
mode
de
tement
niveau réseau
routage
Mode direct Permet de communi- Oui
Identifiant de l’émetacquitté
quer avec un nœud fixe
teur, identifiant du capidentifié présent dans le
teur fixe identifié, idenvoisinage
tifiant de trame pour acquittement
Mode
di- Permet de communi- Non
Identifiant de l’émetrect
non quer avec un nœud fixe
teur, identifiant du capacquitté
identifié présent dans le
teur fixe identifié
voisinage
Mode
Permet de communi- Oui
Identifiant de l’émetmultiquer avec un nœud fixe
teur, identifiant du
identifié et quelconque
nœud suivant, identiétapes
fiant du nœud destination, identifiant de
trame
Mode diffu- Permet de transmettre Non
Identifiant de l’émetsion
de l’information à l’enteur, identifiant de
semble des nœuds du
trame
voisinage
Mode inon- Permet de transmettre Non
Identifiant de l’émetdation
de l’information à l’enteur, identifiant de
semble des nœuds du rétrame
seau
69
Tab. 2.4: Modes de routage disponibles sur la plate-forme R2D2 pour effectuer des communications entre des capteurs fixes et des capteurs mobiles.
Mode de
Emetteur
Récepteur(s) Fonctionnement
AcquitInformations
tement
du PCI
routage
du niveau réseau
Mode
direct Fixe
Mobile
Permet de trans- Oui
Identifiant de
acquitté FM
mettre de l’inforl’émetteur fixe,
mation à un nœud
Identifiant du
mobile identifié
nœud mobile,
identifiant de
trame
Mode
direct Fixe
Mobile
Permet de trans- Non
Identifiant de
non acquitté
mettre de l’inforl’émetteur fixe,
FM
mation à un nœud
identifiant du
mobile identifié
nœud mobile
Mode diffusion Fixe
Mobile
Permet de trans- Non
Identifiant de
FM
mettre de l’inforl’émetteur fixe
mation à tous les
nœuds
mobiles
dans un périmètre
proche
Mode
direct
acquitté MF
Mobile
Fixe
Permet de transmettre de l’information à un nœud
fixe identifié
Oui
Mode
direct
non acquitté
MF
Mobile
Fixe
Non
Mode diffusion
MF
Mobile
Fixe
Permet de transmettre de l’information à un nœud
fixe identifié
Permet de transmettre de l’information à tous les
nœuds fixes dans
un
périmètre
proche
Non
Identifiant
de l’émetteur
mobile, Identifiant du nœud
fixe, identifiant
de trame
Identifiant de
l’émetteur mobile, identifiant
du nœud fixe
Identifiant de
l’émetteur mobile
70
Fig. 2.18: Schéma d’une trame générique
Pour rentrer un peu plus dans les détails, la taille des informations de contrôle de protocole
(PCI) est déterminée à l’avance par un procédé qui permet de minimiser l’occupation mémoire
des informations nécessaires à l’acheminement des messages et pour maximiser l’espace utile
dans une trame de données.
Description d’une trame particulière.
Le format d’une trame et son organisation corres-
pondent à un certain mode de transmission, parmi ceux qui ont été présentés précédemment en
section 2.4.1. La structure des trames dépend des informations requises par le mode de transmission correspondant. La figure 2.18 présente l’organisation d’une trame générique et la figure
2.19 présente la déclinaison de la trame pour le mode multi-étapes. Les structures génériques
sont notées ”mode” et ”type”. Le ”mode” correspond à l’un des modes de routage possibles tels
qu’énoncés dans les tableaux 2.3 et 2.4. A un mode donné sont associés des PCI de niveau réseau
particuliers. On retrouve les informations de PCI correspondant dans la colonne ”informations
du PCI de niveau réseau” des tableaux 2.3 et 2.4 et ces informations se retrouvent dans chaque
trame et ce pour tous les modes de routage. Le champ ”type” est la deuxième structure présente
dans la trame générique. Cette donnée a pour rôle d’associer la trame à un processus de niveau
applicatif particulier afin de pouvoir activer le bon processus à la réception de la trame par le
destinataire final. Le champ ”CRC”, enfin permet de stocker de la redondance d’information,
utile pour faire fonctionner les systèmes de détection et de correction d’erreurs basés sur un
code de redondance cyclique (CRC, pour Cyclic Redundancy Check). Ainsi les champs ”mode”,
”type” et ”CRC” sont présents dans les trames de données qui sont représentées sur les schémas
des figures 2.19, 2.20, 2.21 , 2.22 et 2.23 représentant respectivement les trames déclinées selon
les modes de communication choisis : mode multi-étapes, mode direct acquitté, mode direct
non acquitté, mode indondation et mode diffusion.
Les structures grisées non affectées sont réservées pour les données d’applications et contiennent
les données utiles utilisant le transfert de données. Au contraire de solutions réseaux orientées
71
Fig. 2.19: Trame générique selon le mode de routage multi-étapes
Fig. 2.20: Trame en mode direct acquitté
OSI dans lesquelles les différentes couches du protocole réseau se présentent sous forme de
boı̂tes noires pour les autres traitements en aval et en amont, la solution proposée ici ne permet
pas de définir les applications en ignorant le fonctionnement des traitements des couches de
traitements réseau. Comme on le constate sur les figures 2.19, 2.20, 2.21 , 2.22 et 2.23, les zones
grisées permettant de stocker des données d’applications utiles ne se situent pas aux mêmes
positions selon le mode de transmission choisi. De plus, les zones disponibles pour le stockage
d’informations utiles ne représentent pas autant d’espace en fonction du mode de routage sélectionné, par exemple le mode de routage multi-étapes qui nécessite le plus d’information de
routage ne peut contenir au mieux que 32 bits d’information utile sur les 128 bits de la trame
totale.
L’exemple des trames de données ici décrites illustre très bien l’idée générale qui est d’identifier l’information strictement nécessaire pour le service de mise en réseau, puis d’affecter la
totalité des bits restant disponibles à de l’information utile. Le tableau 2.5 résume les performances des différents modes de routage du point de vue du ratio quantité d’information utile
sur taille totale de la trame. Une solution plus rigide aurait mené à prendre le cas le pire et à
n’autoriser que 32 bits utiles par trame quel que soit le mode de transmission employé. Cette
amélioration peut également être interprétée comme un exemple d’optimisation cross-layer dans
le sens ou l’application doit connaı̂tre la structure des trames, donc par voie de conséquence les
mécanismes réseaux sous-jacents sont en partie connus par l’application.
72
Fig. 2.21: Trame en mode direct non acquitté
Fig. 2.22: Trame en mode inondation
Fig. 2.23: Trame en mode diffusion
Tab. 2.5: Ratio de l’information utile sur la taille totale des trames
Mode de transmission
Espace
Espace
Ratio
total
utile
mode multi-étape
128
32
0.25
mode direct acquitté
128
48
0.375
mode direct non acquitté
128
56
0.4375
mode inondation
128
64
0.5
mode diffusion
128
72
0.5625
2.5 Simulateur
73
Fig. 2.24: Schéma de l’implémentation en version simulation
2.5
Simulateur
A partir du noyau de base du logiciel implémentant les mécanismes basiques et indépendants
du matériel, plusieurs implémentations sont possibles. Chaque version se décline en adaptant
les composants désormais clairement identifiés comme dépendant du matériel choisi.
Parmi les différentes implémentations qui ont été réalisées au cours de cette thèse, l’une
d’entre elle se démarque puisque elle est entièrement virtuelle. Il s’agit d’un réseau de capteurs
virtuel qui se présente sous forme d’un ensemble de processus logiciels communicant via un
canal virtuel. Le canal virtuel permet d’émuler un canal sans fil jusqu’à un certain niveau de
réalisme. Le réseau virtuel est intéressant pour l’étude de protocoles réseau et applicatifs pour
lesquels il est possible de faire abstraction dans une certaine mesure des particularités et des
défauts du canal de communication entre les capteurs.
2.5.1
Description des éléments spécifiques à l’implémentation virtuelle en
simulation
L’implémentation virtuelle en simulation fait intervenir six entités :
– le pilote d’émission,
– le pilote de réception,
– la file message principale,
– la file de message de l’analyseur réseau,
– l’analyseur réseau,
– l’horloge virtuelle,
– le fichier de description du réseau.
La figure 2.24 met en évidence
74
Fig. 2.25: Fichier de description du réseau de capteurs en version simulation
Le pilote d’émission a pour rôle de consommer les messages ayant été placés dans le buffer
d’émission et de les envoyer aux noeuds voisins via des instructions d’émissions sur la file de
message principal. En parallèle à cet envoi sur la file de message principal, le pilote d’émission
a également pour rôle d’envoyer les messages sur la file de message de l’analyseur réseau, ce qui
permet d’observer de façon centralisée l’ensemble des messages qui sont transmis sur le réseau
de capteurs.
Le pilote de réception a pour rôle de consommer les messages concernant le noeud local et de
placer les messages décodés dans le buffer de réception du noeud où le message sera par la suite
analysé. Le pilote de réception est doté d’un mécanisme permettant de simuler en fonction de
la distance entre l’émetteur et le récepteur des erreurs binaires au sein des trames.
La file de message principal véhicule l’ensemble des messages qui transitent au sein du réseau.
Un système d’identifiant transparent pour le reste du système permet d’identifier le destinataire
d’un message donné.
La file de message de l’analyseur réseau est une copie de l’activité de la file de message
principale, mais les messages sont consommés par l’analyseur réseau dans un but d’observation
centralisée.
L’analyseur réseau consomme tous les messages de la file de message de l’analyseur réseau et
mémorise des informations telles que des statistiques de fonctionnement du réseau, en fonction
des modes de fonctionnement utilisés, des émetteurs ou des récepteurs mis en jeu, etc.
L’horloge virtuelle permet de générer logiciellement un signal temporel utilisé par les différents traitements du noyau de base du logiciel de réseau de capteurs. Elle ”émule” en quelque
sorte un résultat qui aurait été obtenu à partir de timers physiques de microcontrôleur par
l’utilisation de primitives Unix apropriées.
Enfin, le fichier de description du réseau permet de définir le déploiement et la topologie du
réseau de capteur. Un exemple de fichier de description du réseau est présenté sur la figure
2.25.
2.5.2
Asynchronisme et simulation
La version simulation est rendue possible grâce à l’asynchronisme des traitements des noeuds.
Le noyau de base du traitement et par conséquent toutes les versions qui sont basées sur ce
noyau fonctionnent sans aucun présupposé sur l’état d’exécution des autres noeuds du réseau.
2.5 Simulateur
75
La notion de temps existe cependant au sein d’un noeud, notamment pour ce qui est de la
génération d’événements internes. Cet asynchronisme a de nombreux avantages dans notre
contexte. Comme le cadre de programmation choisi est celui des Protothreads et que la préemption n’est pas possible dans ce contexte, cela provoque une exécution globale saccadée ce
qui exclut tout fonctionnement basé sur de la synchronisation inter-noeuds (à l’exception bien
entendu de certaines zones précises au sein du protocole d’accès au média, qui ne rende pas la
main à l’ordonnanceur lors des sections de code critiques). Le fait de considérer l’asynchronisme
des noeuds du réseau permet également de ne pas utiliser de communication spécifiquement
dédiée à cette tâche de synchronisation. Pour la conception d’un réseau de capteurs virtuel,
l’asynchronisme est en outre indispensable étant donné que le réseau est exécuté par une seule
machine dotée d’un système multiprocessus, dans notre cas il s’agit du système Unix. Bien sûr,
les différents processus Unix s’exécutent en pseudo-parallèle, toute notion de synchronisation
entre processus est donc par construction impossible.
Le point particulier de la communication inter-processus, qui nécessite dans l’implémentation
réelle de la synchronisation sur des durées courtes, est géré dans le cas du simulateur par le
recours à une file de message, ce qui est une méthode centralisée et asynchrone qui permet de
faire abstraction de toute synchronisation.
2.5.3
Avantages et limites de l’implémentation ”simulation”
Cette version en simulation du réseau de capteurs offre plusieurs avantages par rapport à la
version réelle.
Tout d’abord, il est possible de simuler un grand nombre de capteurs. Pendant une phase de
conception, cela se révèle être appréciable parce que si le programme change, tous les éléments
du réseau doivent être reprogrammés ce qui est une tâche très fatidieuse au delà de quelques
noeuds.
De plus, le déploiement des noeuds est facilité, puisque virtuel et réalisé conformément à un
fichier de description du réseau.
Le noyau de base est strictement identique aux autres implémentations, ce qui facilite l’évolution du simulateur vers l’implémentation réelle sur des noeuds physiques. Cela est rendu
possible par le fait que les éléments du réseau indépendant de l’implémentation ont été clairement identifiés comme tel.
Comme on dispose d’une exécution physiquement centralisé sur un ordinateur, il est possible
de centraliser la vue des messages échangés dans le réseau virtuel, ce qui est difficile à réaliser
dans un réseau réel qui est distribué physiquement. Cela est fait grâce à l’analyseur réseau.
76
En revanche, ce type d’implémentation présente également certaines limitations.
Tout d’abord, bien qu’il soit possible dans une certaine mesure de prendre en compte des
imperfections dues à la communication entre les noeuds du réseau, le canal de communication
reste simplifié. Par conséquent, l’implémentation vers le simulateur n’est utilisable que pour
étudier des protocoles réseaux et définir des applications.
De plus, bien que les simulations peuvent être réalisées sur de grand nombre de capteurs, le
nombre de noeuds pouvant être simulés est limité par les performances du système sur lequel
la simulation est exécutée.
2.6
Conclusion
Ce chapitre a été l’occasion de définir un logiciel de réseau de capteurs qui respecte des mots
d’ordre de flexibilité quant aux applications possibles, et de portabilité également grande, grâce
à l’emploi du cadre de programmation des protothreads entièrement codés en C standard. Les
mécanismes communs à des applications variées de réseaux de capteurs ont été programmés
dans une partie du programme qui constitue une base commune, quelle que soit l’application et
quel que soit le matériel employé (en particulier quelle que soit la partie radio de ce matériel).
Ainsi, les processus faisant partie de ce noyau commun de traitement sont :
– le processus d’apprentissage du voisinage,
– le processus de communication avec la station de base,
– le processus de gestion des timers, qui permet de gérer des échéances temporelles dans le
but de générer des événements divers, par exemple un ordre de réveil,
– l’ensemble des processus de routage géographique,
– les processus de la couche liaison autorisant la demande de réémission automatique et la
correction d’erreurs.
Plusieurs modes de routages possibles sont disponibles pour répondre aux besoins des applications en fonction de la façon dont l’information doit se diffuser dans le réseau. Ces modes
sont :
– le mode direct acquitté,
– le mode direct non acquitté,
– le mode multi-étapes,
– le mode diffusion,
– le mode inondation.
Les trames ont ensuite été définies avec le plus grand soin pour maximiser l’information utile.
2.6 Conclusion
77
Enfin, une technique de buffer optimisée permet de limiter au maximum l’utilisation mémoire.
Dans le chapitre suivant, l’adaptation de ce logiciel générique à une plate-forme réelle sera
abordée, et l’évaluation de la consommation d’énergie sera réalisée sur la base de mesures de
consommation sur la plate-forme.
78
Chapitre 3
Évaluation de la consommation et
optimisation du prototype
Contents
3.1
Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
3.2
Description de la plate-forme R2D2 . . . . . . . . . . . . . . . . . .
83
3.3
3.4
3.1
3.2.1
Description du matériel . . . . . . . . . . . . . . . . . . . . . . . . . .
83
3.2.2
Protocoles d’accès au médium . . . . . . . . . . . . . . . . . . . . . . .
84
Evaluation de l’énergie par traçage d’exécution de code . . . . . .
88
3.3.1
Traçage d’exécution dans un système événementiel . . . . . . . . . . .
89
3.3.2
Identification des cycles d’ordonnancement caractéristiques . . . . . .
92
3.3.3
Caractérisation en consommation des cycles d’ordonnancement . . . .
97
Evaluation de l’énergie par une approche analytique . . . . . . . .
98
3.4.1
Estimation analytique de la répartition des cycles d’ordonnancement .
99
3.4.2
Événements anormaux des communications et coût énergétique . . . . 101
3.4.3
Résultats d’évaluation de consommation d’énergie . . . . . . . . . . . 106
3.5
Optimisation énergétique : exemple de l’intervalle de réveil. . . .
107
3.6
Conclusion
109
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction
La réalisation de systèmes à faible consommation énergétique est un problème d’actualité
très dynamique dans la recherche en architecture. Pour pouvoir réaliser des systèmes à faible
consommation, un préalable est de disposer d’outils permettant d’estimer la consommation de
différentes solutions afin de sélectionner les meilleures. Des techniques et des outils existent
79
80
Évaluation de la consommation et optimisation du prototype
pour estimer la consommation de systèmes, en particulier dans le cas de systèmes intégrés sur
une même puce.
L’estimation de l’énergie d’un nœud du réseau nécessite au préalable d’identifier les composants consommateurs d’énergie. Cette identification des élements consommateurs d’énergie
débute par l’établissement d’une liste des différents composants constitutifs du système. En
règle générale, le modèle d’énergie de haut-niveau adopté est défini par la somme entre l’énergie de ”calcul” consommée par les divers traitements et l’énergie dédiée à la communication
entre les capteurs.
Cette première décomposition n’est pas extrêmement claire, étant donné que la frontière
entre les traitements et les communications n’est pas facile à mettre en évidence. La part de
communication prend-elle en compte l’intégralité de la gestion de la pile de protocole réseau ?
Cette distinction est possible, mais dans ce cas de nombreux traitements numériques ainsi que
l’exécution de protocoles complexes tels que le routage ou encore la fiabilisation des données
par la couche liaison sont alors inclus dans le terme d’énergie de communication, alors que leur
estimation a plus de similarité avec l’évaluation de la consommation des traitements.
Une deuxième possibilité de décomposition consiste à distinguer les traitements numériques
des traitements analogiques, de la même façon que cela avait été présenté à l’équation 1.21 dans
le premier chapitre, mais cette fois-ci exprimée sous forme de d’énergies et non de puissances :
Etot = Ealgo + Eanalog + Eamp
(3.1)
avec Etot , toujours l’énergie totale, Ealgo l’énergie due aux calculs numériques, Eamp l’énergie
consommée par l’amplificateur d’émission analogique et enfin Eanalog l’énergie due aux traitements analogiques de mise en forme des signaux de communication et toutes autres causes
”analogiques” de consommation. En considérant la plate-forme choisie, le terme Ealgo représente la consommation du processeur et de ses mémoires RAM et flash, ainsi qu’une part de
traitement numérique qui serait incluse dans la partie radio. Le terme Eanalog correspond quant
à lui à l’énergie dépensée par le capteur et le convertisseur analogique-numérique et l’énergie
de la partie radio analogique à l’exception de l’amplificateur. Le terme Eamp est associé à l’amplificateur présent dans la partie radio. Cet élément est à part parce qu’il constitue à lui tout
seul une part importante de la consommation et est fortement variable dans un contexte de
réseau de capteurs où l’énergie est fortement contrainte.
Notre approche pour l’évaluation de la consommation se décompose en trois niveaux d’estimation (fig. 3.1).
3.1 Introduction
81
Fig. 3.1: Trois méthodes d’évaluation de la consommation d’énergie
Le niveau 0 consiste à mesurer le produit courant tension aux bornes de l’alimentation pendant le fonctionnement du système. En notant u(t) la tension instantanée aux bornes de l’alimentation ou de la batterie et i(t) l’intensité instantanée sur une des électrodes de l’alimentation, la puissance instantanée s’exprime alors par p(t) = u(t)i(t). Si on considère T0 l’instant
initial et un instant quelconque T , l’énergie consommée pendant l’intervalle [T0 T ] s’exprime
RT
RT
alors par e(T ) = T0 p(t)dt = T0 u(t)i(t)dt. Cette technique d’évaluation aussi précise et simple
soit-elle, est difficile à appliquer en principe et souffre d’inconviénients majeurs dans la plupart
des cas. Pour réaliser cette mesure, il suffit d’un oscilloscope numérique à mémoire capable de
fournir les données recueillies sous forme de fichiers de données à exploiter par un logiciel de
traitement. Le protocole expérimental est donc relativement simple. Cependant, il faut pouvoir disposer du système matériel réel et complet entièrement défini et opérationnel, ce qui
va à l’encontre d’un besoin de prototypage et d’anticipation nécessaire pour obtenir des sys-
tèmes atteignants les performances d’un cahier des charges donné. Certains travaux centrés sur
des petits systèmes basés sur l’optimisation de systèmes réels complets déjà existants avaient
pour objet la réalisation d’estimations selon cette technique. Les retours d’expérimentations
montrent que l’évaluation est simple et précise et qu’elle ne nécessite pas de matériel haut de
gamme pour les mesures. Cependant, cette technique est fastidieuse et difficile à mettre en
place dans une optique de prototypage et nous ne l’avons pas employée.
L’évaluation de e niveau 1 consiste à effectuer l’analyse à partir du traçage d’exécution de
code. Il s’agit :
1. de classifier les comportements des capteurs sous forme de cycles d’exécution,
2. de mesurer la consommation énergétique pour chacun des cycles d’exécution,
3. de compter ces cycles d’exécution pendant le déroulement d’un programme sur la plate-
82
Fig. 3.2: Organigramme de la méthodologie suivie pour la conception du prototype de réseau
de capteurs R2D2.
forme réelle.
L’évaluation de niveau 2 se base sur l’analyse du niveau 1, mais cette fois-ci nous cherchons
à évaluer de façon analytique et statistique les comportements des capteurs. Dans ce cas :
1. la classification des cycles d’exécution est la même que pour le traçage d’exécution de
code,
2. l’évaluation de consommation énergétique pour chacun des cycles d’exécution est en partie
analytique,
3. le nombre des cycles d’exécution est évalué de façon analytique et statistique.
Dans ce chapitre sera présentée la plate-forme du prototype de capteur qui a été développé, et
les traitements qui avaient été identifiés au chapitre précédent comme ”dépendant du matériel”
seront définis, en particulier le système d’accès au médium, point critique pour la consommation d’énergie. Ensuite, nous développerons le traçage d’exécution de code (niveau 1), puis la
méthode d’évaluation analytique et statistique (niveau 2). Enfin, nous appliquerons la dernière
méthode dans un problème d’optimisation énergétique par réglage d’un paramètre important
qui est l’intervalle de réveil, lié à la technique d’accès au média utilisée.
3.2 Description de la plate-forme R2D2
3.2
83
Description de la plate-forme R2D2
La méthodologie suivie dans le cadre de cette thèse est illustrée sur la figure 3.2. La première
étape consiste en la définition du besoin, pour pouvoir imaginer réaliser des structures de traitements qui correspondent parfaitement aux contraintes imposées par les couches supérieures
en matière de mémoire, de débits, d’échelle et de densité du réseau et en tenant compte de
la nature des événements issus des capteurs embarqués. Cette étape a été présentée dans le
chapitre précedent. La deuxième étape consiste à implanter les traitements mis en évidence à
l’étape précédente et ne dépendant pas du matériel choisi. Lors de la troisième étape, il s’agit
de fixer des choix matériels et architecturaux parmi les meilleurs possibles. Ce choix doit bien
entendu être fait en fonction des besoins mis en évidence précédemment. Après quoi les traitements doivent être adaptés à ces architectures dédiées pour terminer la réalisation d’un réseau
de capteurs à la fois opérationnel et performant.
3.2.1
Description du matériel
La cible adaptée doit être simple et polyvalente et peut par exemple être basée sur un microcontrôleur généraliste avec suffisamment de mémoire embarquée, associée à un système de
communication radio simple. La plate-forme R2D2 s’inscrit précisément dans cette logique, et
n’a pas pour ambition d’être optimale, mais elle s’inscrit plutôt dans une étape de validation
initiale des traitements. Par la suite, après avoir mis en évidence les points de la conception
nécessitant le plus de soin, il s’agira de proposer des solutions matérielles plus performantes.
Le prototype, dont la figure 3.3 présente une photographie, a été réalisé à partir de composants commerciaux courants. Les nœuds sont basés sur un micro-contrôleur 16 bits Texas
Instrument MSP430 dans une version comportant 2 ko de mémoire RAM et 60 ko de mémoire
Flash. Ils comportent un capteur de température intégré, 2 interfaces de type UART, 2 timers 16 bits, 2 ”watchdogs” et un convertisseur analogique-numérique associé au capteur de
température (voir le tableau 3.1).
Le composant de communication est un Chipcon CC1020 employant des modulations FSK
(Frequency Shift Keying), GFSK (Gaussian Frequency Shift Keying) ou OOK (On/Off Keying)
dont les caractéristiques précises sont détaillées dans le tableau 3.1.
Le prototype de réseau existant est constitué actuellement de 20 nœuds pouvant intégrer
les capteurs et d’un nœud station de base qui est lui-même constitué d’un capteur complet
couplé à un ordinateur qui fournit un point d’accès à l’utilisateur, pour envoyer des requêtes
et des ordres en direction du réseau de capteurs et pour récupérer et afficher des résultats en
84
Fig. 3.3: Photo de la plate-forme du prototype de réseau de capteur R2D2
Fig. 3.4: Architecture réseau du prototype r2d2 de réseau de capteurs
provenance du réseau. La figure 3.4 illustre les choix pris en ce qui concerne l’architecture réseau
avec une construction simple constituée d’une station de base et des 20 nœuds satellites.
3.2.2
Protocoles d’accès au médium
Le fait de se fixer sur un matériel, en particulier la partie radio est l’occasion de fixer un
protocole d’accès au médium. Cette partie est un des traitements les plus délicats à concevoir
et ce particulièrement pour les réseaux sans fil, dû au fait que le canal est partagé par tous
les nœuds communicants. Ce protocole est avant tout construit autour d’un matériel avec ses
caractéristiques spécifiques.
Les réseaux de capteurs se caractérisant par des contraintes énergétiques fortes, les techniques
d’accès au médium doivent être adaptées aux besoins des réseaux de capteurs.
Les raisons des gaspillages énergétiques ont été identifiées [87]. Elles consistent en quatre
facteurs :
1. les collisions, qui obligent l’émetteur, le récepteur, ou les deux à recommencer une opération de réception ou d’émission,
2. l’ overhearing, qui se produit lorsqu’un récepteur receptionne un paquet qui ne lui est pas
destiné,
85
Tab. 3.1: Caractéristiques de la plate-forme R2D2
Microcontroleur
Type
Texas Instrument MSP430
Fréquence de fonctionnement
8 MHz
Tension d’alimentation
entre 2,7 V et 3,6 V
Mémoire RAM
2 ko
Mémoire Flash
60 ko
Convertisseur Analogique Numé- 12 bits SAR (Successive Approximation Register)
rique
Interfaces matérielles UART (Uni- 2
versal Asynchronous Receiver and
Transmitter)
Timers
2 timers 16 bits
Watchdog
2 watchdogs de 8 bits
Capteur
1 capteur de température
Multiplieur matériel
1
Composant Radio
Type
ChipCon CC1020
Modulation
OOK (On/Off Keying), FSK (Frequency Shift Keying)
ou GFSK(Gaussian Frequency Shift Keying)
Tension d’alimentation
entre 2.3 V et 3.6 V
Puissance d’émission
Variable de -20 dBm à +10 dBm
Bande de fréquences utilisables
402 MHz – 470 MHz, 804 MHz – 940 MHz
Sensibilité
-112 dBm pour une largeur de bande de 12.5 kHz
RSSI
Numérique
Taux de transmission maximal
153.6 kBaud
Alimentation
4 batteries 1,2 V
Capteur embarqué
Capteur de température du MSP430
Antenne
Antenne ”quart d’onde” de 8 cm
86
3. le volume des informations de contrôle,
4. et enfin l’écoute, hors réception, du canal (idle listening).
Comme cela a déjà été remarqué, les transferts d’informations se font par paquets de taille
faible et à une fréquence également relativement faible. Dès lors, l’utilisation d’une technique
d’accès au médium ”classique”, c’est-à-dire asynchrone et avec une disponibilité permanente
de la réception semble inadaptée [53] puisque dans ces conditions, l’écoute hors réception est
prédominante. En effet, la consommation d’énergie liée uniquement à l’écoute active du canal
de communication est élevée [60]. On peut également se référer au calcul rapide évoqué dans le
chapitre introductif où on avait constaté que le simple fait d’utiliser de l’écoute active à l’aide
d’un composant RF disponible dans le commerce, à savoir le Chipcon CC1020, associé à une
quantité d’énergie embarquée limitée à environ 21600 J 1 , donnait une idée de la borne max de
la durée de vie d’un nœud du réseau de l’ordre de 120 heures. Ce genre de technique d’accès
au médium est donc exclu dans une application de réseaux de capteurs.
L’idée pour diminuer le temps passé en mode écoute hors réception consiste à désactiver le
composant de communication en émission et en réception le plus longtemps possible, et de ne
l’activer que lorsque des transferts d’information ont effectivement lieu. Autrement dit, il s’agit
de minimiser le facteur d’activité du composant de communication, ce qu’on peut définir par le
rapport entre le temps d’activité effective et le temps total. Cependant, la communication entre
nœuds n’est possible qu’à condition que l’émetteur et le récepteur soient actifs simultanément.
Les transferts de données présupposent alors que l’émetteur et le récepteur se synchronisent
ce qui se concrétise sous forme de rendez-vous. L’établissement d’un rendez-vous entre un
émetteur et un récepteur est un traitement supplémentaire qui est à la charge du protocole
d’accès au médium. L’établissement du rendez-vous peut être réalisé de plusieurs façons [51].
– Les algorithmes purement synchrones fonctionnent à l’aide de la connaissance des instants
où les rendez-vous ont lieu. Le mécanisme de synchronisation tend à augmenter de façon
importante la part des informations de contrôle, en particulier si le réseau est étendu. Il
peut éventuellement y avoir de multiples synchronisations à l’échelle de zones, les différentes
zones d’un réseau étendu n’étant pas forcément synchronisées entre elles (protocole TEEM
[78]). Parmi cette classe des algorithmes synchrones, on peut citer S-MAC [87], TEEM [78],
qui est une optimisation de S-MAC, et encore TRAMA [69].
– Avec les algorithmes purement asynchrones, les nœuds du réseau ont la capacité de réveiller
les nœuds avec lesquels ils souhaitent communiquer. Cela suppose la présence d’un matériel
supplémentaire spécifique qui emploie un canal parallèle appelé canal de réveil [29]. Le
1
21600 Joules correspond la quantité d’énergie de 3 batteries de capacité 1600 mAh pour 1.2V.
87
récepteur du canal de réveil a la propriété d’être actif en permanence, contrairement au
canal principal de données. Pour que cela soit intéressant, il faut bien entendu que la
puissance consommée par la reception sur ce canal de réveil soit la plus faible possible,
ce qui n’est réalisable qu’à l’aide de modulations n’autorisant que de très faibles débits.
Evidemment, il est gênant de devoir avoir un système de communication double, c’est le
principal inconvénient de ces techniques purement asynchrones.
– Enfin, avec les algorithmes dits pseudo asynchrones, les nœuds du réseau établissent des
rendez-vous à la demande, mais basés sur un réveil périodique, cette période pouvant être
statique ou dynamique [73], [86]. Les travaux ayant exploré ces systèmes de rendez-vous
pseudo-asynchrones incluent les algorithmes RICER et TICER [53], basés respectivement
sur une réception périodique et sur une émission périodique.
Au cours des travaux sur la plate-forme R2D2 de réseaux de capteurs, nous nous sommes
focalisés plus spécifiquement sur l’algorithme RICER [52] (acronyme pour Receiver-Initiated
CyclEd Receiver), plus récent, et basé sur un système de rendez-vous pseudo asynchrone. Ce
choix a le gros avantage de ne pas nécessiter de système de synchronisation, très difficile à
mettre au point en pratique. De plus, le fait que la période de réveil puisse varier dans une
grande gamme de durées a un intérêt pour la réalisation des optimisations ”cross-layer”.
Le fonctionnement de cette méthode d’accès au médium est illustré par la figure 3.5. Avec
cette technique pseudo-asynchrone, le rendez-vous est initié par le récepteur. Lorsqu’un nœud
sort de son mode de veille, il cherche à se rendre disponible pour une réception éventuelle
de paquet de données. Il fait savoir aux nœuds autour de lui qu’il est disponible par l’envoi
d’une trame de réveil contenant son identifiant. L’émission à proprement parler de cette trame
de réveil est précédée par une période d’écoute du canal servant à éviter les collisions sur le
canal. Après l’envoi de la trame, le nœud passe alors en mode réception pour une certaine
durée pendant laquelle un émetteur peut éventuellement effectuer la communication. Si aucun
émetteur ne s’est manifesté au bout du temps d’attente, alors, le nœud se remet en veille
jusqu’au réveil suivant. Dans l’hypothèse où un émetteur se manifeste, alors la réception a lieu,
suivie par l’émission d’une trame d’acquittement. Du point de vue de l’émetteur, lorsqu’une
trame de données doit être transmise à un destinataire, alors le nœud positionne le système
de communication en mode de réception, jusqu’à la réception d’une trame de réveil. Après la
réception de cette trame, si le récepteur n’est pas identifié comme le bon interlucuteur, alors
la procédure s’interrompt. Sinon, après le respect d’un temps d’attente anti-collision de durée
aléatoire (pour limiter les risques de collisions entre émetteurs), l’émission de la trame a lieu,
suivie de la réception de la trame d’acquittement.
88
Fig. 3.5: Protocole de rendez-vous initié par récepteur RICER3 [52]
Pour conclure sur cette technique, on peut dire qu’elle est difficile à appliquer en pratique
pour un certain nombre de raisons. La première raison est la nécessité de se fixer dès le départ
sur une architecture quasiment dédiée, ce qui est l’objectif vers lequel on tend. Cette méthode
d’évaluation serait donc basée sur des essais successifs d’architectures candidates. Pour chacune des architectures candidates, une description architecturale complète est nécessaire ce qui
demande beaucoup de travail. Le deuxième inconvénient est la relative imprécision de la technique car l’évaluation de consommation est faite brique de base par brique de base, ce qui fait
se propager les imprécisions lorsqu’on passe à plus grande échelle sur le système entier. Pour
pallier à cet inconvénient, il convient donc par conséquent de réaliser l’évaluation énergétique
des briques de base de la plus grosse granularité possible.
3.3
Evaluation de l’énergie par traçage d’exécution de code
Le principe d’évaluation de la consommation énergétique par traçage d’exécution est centré
sur une description de code précise et de son exécution sur une plate-forme générique. Tout
d’abord, il est important de remarquer que cette évaluation est rendue possible uniquement si
la plate-forme générique définie précédemment est utilisée. Plus généralement, la technique qui
va être présentée nécessite la présence d’une structure capable d’exécuter du code, à savoir un
microcontrôleur ou plus généralement un microprocesseur.
Cette technique peut se schématiser à l’aide de la figure 3.6. L’élément ”consommation des
cycles d’ordonnancement” inclut les données issues des mesures sur la plate-forme de test. Le
deuxième élément, ”répartition des cycles d’ordonnancement”, contient la trace d’exécution sous
la forme qui sera précisée dans la suite de cette section. En comptant le nombre de cycle de
chaque type, et en multipliant les termes par leur consommation énergétique, on obtient alors
3.3 Evaluation de l’énergie par traçage d’exécution de code
89
Fig. 3.6: Interdépendance des éléments de calcul de consommation (niveau 1).
la consommation totale.
Cette technique d’évaluation consiste donc à tracer l’exécution du code d’un nœud du réseau, intégré dans un environnement fonctionnel, et associé à une application test. D’autres
travaux similaires fondés sur du traçage d’exécution ont été menés, notamment au sein du
projet de plate-forme Crossbow/TinyOs développée à Berkeley [68], ainsi qu’en Allemagne par
l’Université de Tubigen par Landsiedel et al. [45] avec leur projet AEON (Accurate Prediction of Power Consumption), basé sur une extension du fameux système TinyOS, sans oublier
Schnayder et al., à l’Université de Harvard pour la plate-forme Crossbow dans une extension
également affiliée au système TinyOS qui est connue sous le nom de PowerTOSSIM [74].
L’approche que nous présentons est différente cependant, car elle se détache de TinyOS,
pour s’appuyer sur la bibliothèque nommée protothread qui consiste en une bibliothèque de
programation utilisée au coeur du système d’exploitation Contiki. Ce choix de se détacher de
TinyOS a été pris pour des raisons techniques qui ont été présentées au chapitre précédent.
3.3.1
Traçage d’exécution dans un système événementiel
Comme cela a été évoqué au chapitre précédent, les systèmes événementiels constituent un
bon choix pour une application de réseau de capteurs. Le système TinyOS très répandu dans le
domaine des réseaux de capteurs est un système événementiel, tout comme le système Contiki.
Cependant, même si les systèmes événementiels ont ces bonnes propriétés, la question du traçage
d’exécution est un problème particulier. En effet, en considérant les traitements sous forme de
threads, il est plus facile de déterminer les différents traitements qui ont été employés car leur
séquentialité est définie à l’avance, à l’exception des branches conditionnelles d’un programme,
pour lesquelles il faut pouvoir mémoriser les branches qui ont été choisies. À l’inverse, dans
un style de programmation événementiel, les traitements sont écrits de façon éparse et une
même macro-fonctionnalité pourra être une combinaison de nombreux traitants. De plus, les
événements qui surviennent n’ont pas, a priori, de séquentialité évidente, contrairement à un
programme écrit sous forme de threads, ce qui rend le traçage d’exécution plus délicat.
90
Le cas des protothreads
La bibliothèque C intitulée ”protothreads” est une réalisation qui s’est révélée particulièrement prometteuse dans les réseaux de capteurs comme en témoignent un certain nombre de
projets de recherche récents qui s’appuient sur cette bibliothèque elle-même récente. À l’aide
de cette bibliothèque, il est possible de cumuler les avantages de performances et de faible
utilisation mémoire propre à la programmation événementielle, tout en gardant les avantages
de la programmation sous forme de threads qui sont principalement une plus grande facilité du
traçage d’exécution et une plus grande facilité de conception des programmes.
Les protothreads sont des fonctions C qui utilisent des instructions ”en code préprocesseur”.
Ce qui fait leur originalité est que le code de la fonction peut être interrompu et repris ultérieurement, un peu comme s’il y avait eu une préemption de la part de l’ordonnanceur d’un
noyau. En réalité, la fonction est ponctuée d’instructions particulières PT WAIT UNTIL qui
peuvent constituer tout autant de points d’arrêts potentiels, et la fonction ne peut pas rendre la
main ailleurs qu’au niveau de ces points d’arrêt. Lorsque la fonction rencontre une instruction
PT WAIT UNTIL, si la condition associée est vraie alors le programme continue son exécution,
si celle-ci est fausse, alors le contexte ”simplifié” est sauvegardé sous forme de la mémorisation
du seul pointeur d’exécution, puis la fonction rend la main à l’ordonnanceur supérieur. Le principe du fonctionnement des instructions en code préprocesseur est détaillé et commenté sur
les figures 3.8 et 3.9. On retrouve dans cette description des éléments appartenant à la fois
au monde de la programmation sous forme de threads, comme la sauvegarde de contexte et la
programmation modulaire, et d’autres éléments qui sont caractéristiques de la programmation
événementielle, à savoir la non préemptibilité, la non concurrence d’exécution et le très faible
surcoût mémoire lié à chaque protothread. Le surcoût mémoire d’un protothread se limite en
effet à la mémorisation du pointeur d’exécution ( (pt)->lc ) ce qui correspond à une taille
variable en fonction de la cible pour laquelle le code est compilé, mais qui représente en général
un ou deux octets sur la plupart des cibles. La boucle d’ordonnancement fixe représentée sur la
figure 3.7 peut être interprétée comme une sorte d’hybride entre un ordonnanceur dynamique
de threads et une boucle événementielle.
A l’aide des protothreads, le traçage d’exécution est grandement facilité. Il n’est cependant possible que si ce cadre de programmation des protothreads est respecté, ce qui est une
contrainte qui n’affecte ni la généralité, ni les performances, puisque ce cadre de programmation
est plutôt un bon choix en soi comme cela a déjà été dit précédemment.
Pour nos expérimentations, nous avons inclus des variables globales pour tracer l’exécution.
91
PT_INIT(protothread_a);
PT_INIT(protothread_b);
PT_INIT(protothread_c);
PT_INIT(protothread_d);
while(1){
PT_SCHEDULE(protothread_a);
PT_SCHEDULE(protothread_b);
PT_SCHEDULE(protothread_c);
PT_SCHEDULE(protothread_d);
}
Fig. 3.7: Boucle d’ordonnancement fixe.
PT_THREAD(protothread_a(struct pt *pt)) {
PT_BEGIN(pt);
while(1){
/* bloc de traitement */
PT_WAIT_UNTIL(pt, ressource_1_disponible);
if (test)
/* bloc de traitement principal*/
else
/* bloc de traitement alternatif*/
PT_WAIT_UNTIL(pt, ressource_2_disponible);
}
PT_END(pt);
}
Fig. 3.8: Exemple de protothread. On peut constater que le codage s’apparente à celui d’un
thread. Il semble être programmé indépendamment des autres traitements comme le témoigne la
présence de la boucle infinie. Pourtant, des instructions blocantes sont présentes et permettent
au protothread de ”rendre la main” à la boucle d’ordonnancement principal pour laisser la
chance aux autres traitements de s’exécuter à leur tour.
92
char protothread_a(struct pt *pt) {
switch((pt)->lc) { case 0: ;
while(1){
/* bloc de traitement */
(pt)->lc = __LINE__; case __LINE__: ;
if(!(ressource_1_disponible)) return 0;
if (test)
{/* bloc de traitement principal*/}
else
{/* bloc de traitement alternatif*/}
(pt)->lc = __LINE__; case __LINE__: ;
if(!(ressource_2_disponible)) return 0;
}
(pt)->lc = 0;
return 1;
}
Fig. 3.9: Traduction de protothread a en C standard après traitement par le préprocesseur.
On peut noter l’utilisation de l’instruction switch/case dans une situation non conventionnelle
(le case étant ici à l’intérieur d’une boucle infinie). Cette utilisation non conventionnelle est
néanmoins conforme à l’ANSI C et par conséquent n’importe quel compilateur ANSI C est
capable de compiler un tel code.
Pour entrer plus précisément dans les détails de ce qui a été réalisé, la technique employée est
illustrée par le schéma de la figure 3.10.
3.3.2
Identification des cycles d’ordonnancement caractéristiques
Dans un premier temps, il s’agit de recenser tous les cycles d’ordonnancement pouvant survenir. Cela peut sembler être un point impossible à réaliser mais si on entre dans le détail on
constate qu’il est assez facile de recenser les différentes branches de taitement possibles dont le
nombre n’est pas extrêmement élevé. En effet, il n’y a pas vraiment de traitement de fond dans
les nœuds du réseaux. Les traitements sont consécutifs à des événements précis, comme une
réception de message, ou encore un temps d’attente écoulé qui déclenche des traitements. On
peut prendre l’exemple d’un échantillonnage à l’aide du capteur qui est réalisé à intervalle de
temps constant. L’évolution d’un timer matériel va débloquer des traitements adéquats d’accès
à la valeur du capteur en interrogeant un registre ou en faisant fonctionner un convertisseur
analogique numérique. Eventuellement, cet événement peut en déclencher d’autres, comme par
exemple lorsque l’envoi d’un message d’alerte est nécessaire consécutivement à la valeur mesurée. De même, la réception d’un message va déclencher tous les mécanismes ”ascendants”
de réception, et peut ensuite déclencher des envois de messages (cas d’une retransmission) et
l’activation d’applications locales.
93
Fig. 3.10: Méthode de traçage d’exécution dans le cadre d’une programmation utilisant les
protothreads.
while(1) {
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
PT_SCHEDULE
}
(driverReception) ;
(driverEmission) ;
(simuleHorloge) ;
(liaison) ;
(reseau) ;
(gestionTimers) ;
(gestionREQvois) ;
(ConnaitreVois) ;
(MAJtabVois);
(managePresence);
(vagueREQvois);
Fig. 3.11: Boucle d’ordonnancement réelle.
C’est pourquoi il est possible de dresser une liste exhaustive de tous les comportements
possibles.
Dans un premier temps, analysons plus précisément la boucle d’ordonnancement réelle utilisée (fig. 3.11). La boucle commence par les prototreads contrôlant les entrée/sortie. Le premier
protothread nommé driverReception a pour rôle de tenter de recevoir des messages provenant
des autre éléments du réseau de capteurs. Ce protothread a plusieurs terminaisons possibles :
aucun nœud n’a cherché à envoyer des messages, un nœud a cherché à envoyer un message,
mais il y a eu un problème lors de la réception de ce message, ou un message a été reçu avec
succès. Le résultat de la terminaison peut être stocké dans une variable.
94
Certains événements peuvent déclencher l’exécution de traitements plus ou moins complexes,
pouvant nécessiter éventuellement plusieurs cycles d’ordonnancement complets juxtaposés. En
effet, c’est un petit peu la même chose qui se passe si on considère un système d’exploitation
orienté thread : lorsqu’un traitement s’étend en longueur, le noyau peut prendre la décision
d’interrompre un traitement en cours d’exécution. Sans même parler de temps d’exécution
long, l’interruption de l’exécution peut être également initiée par le thread, lorsque par exemple
une ressource peut être attendue de la part d’un traitement issu d’un autre thread.
Avec le cadre de programmation événementiel des protothreads, il en est de même ; et pour
la réalisation d’une opération complexe, les traitements ont besoin d’être exécutés dans un
certain ordre. Pour donner un exemple, supposons que le mécanisme déclenché par la réception
de l’événement nécessite l’enchaı̂nement d’exécution suivant, : protothread A, protothread B,
protothread C, protothread B, protothread A (l’ordre devant impérativement être respecté car
on suppose que chaque traitement utilise des données générées par l’ensemble des traitements
prcédents). Le cadre de programmation des protothreads implique une rigidité supplémentaire
apportée par le fait que l’ordonnancement se fait toujours dans le même ordre. Supposons
le cas le plus simple dans lequel le cycle d’ordonnancement fixe, chaque protothread ne soit
ordonnancé qu’une seule fois, dans l’ordre : protothread A, puis protothread B, puis protothread
C.
2
Dans ce cas de figure, la structure figée des protothreads oblige à exécuter trois cycles
d’ordonnancement entiers. Dans le premier cycle, on fait s’exécuter l’enchaı̂nement protothread
A, protothread B, et protothread C. Dans le deuxième cycle, la séquentialité figée n’autorise pas
le protothread A à être ordonnancé avant le protothread B, donc seul le protothread B peut être
activé à ce cycle. Enfin, lors du troisième cycle, le protothread A est ordonnancé, ce qui met fin
au mécanisme complet.
On peut alors considérer des macro-structures, qui sont des juxtapositions (ou combinaisons)
de plusieurs cycles d’ordonnancement. Prenons l’exemple d’un événement de réception d’un
message ayant été émis en mode multi-étapes. Si le nœud du réseau n’est pas le destinataire
final, la réception du message est suivie par une procédure de réémission. L’enchaı̂nement
d’exécution des protothreads doit alors être :
1. protothread de réception (mac/phy),
2
On pourrait en effet très bien imaginer qu’un traitement particulièrement prioritaire comparé aux autres
puisse être ordonnancé plusieurs fois dans le même cycle d’ordonnancement , pour pallier par exemple au fonctionnement ”saccadé” apporté par le fait que dans un système événementiel, sans préemption possible, ce sont
les traitements qui rendent la main. Par exemple, on pourrait appliquer astucieusement cette technique sur un
protothread qui aurait la responsabilité de lire un buffer d’entrée dont les capacités de stockage seraient très
limitées, ceci afin d’éviter au maximum des pertes de données par écrasement. Dans ce cas on pourrait avoir
des cycles d’ordonnancements fixes du type : protothread A, protothread I/O, protothread B, protothread I/O,
protothread C, protothread I/O, protothread D, etc.
95
2. protothread de liaison,
3. protothread de routage,
4. protothread de liaison,
5. protothread d’émission (mac/phy).
En considérant la boucle d’ordonnancement réelle de la figure 3.11, on constate que les trois
premiers traitements peuvent s’effectuer au sein d’un même cycle d’ordonnancement qui a déjà
été identifié dans le tableau 3.2, sous le nom de ”cycle réception de trame sans erreur et propagation”. Ensuite, un cycle d’ordonnancement est nécessaire pour le protothread de liaison
descendant, c’est celui qui avait précédemment été identifié par l’appellation ”cycle calcul de
trame pour émission phase 2”. Enfin, le protothread d’émission est exécuté au sein d’un troisième cycle d’ordonnancement qui a été identifié par ”cycle émission de trame sans échec”. On
a donc les cycles suivants qui sont consécutifs à l’événement de réception de trame en mode
multi-étapes pour laquelle le nœud n’est pas l’élément final : un ”cycle réception de trame sans
erreur et propagation”, suivi d’un ”cycle calcul de trame pour émission phase 2”, pour finir par
un ”cycle émission de trame sans échec”.
Le tableau 3.2 présente les différents cas de figure qui peuvent se présenter. Dès lors, la
technique de traçage se déroule en 4 temps.
1. Tout d’abord, la première étape est l’énumération des différents cycles typiques qui sont
susceptibles de survenir au cours de l’exécution et le tableau 3.2 est le résultat de cette
analyse. À chacun de ces cycles typiques, on associe un compteur sous forme de variable.
2. Ensuite, il s’agit de mettre en place des drapeaux pour chacun des threads afin de pouvoir
déterminer la terminaison des protothreads. C’est à partir de l’analyse de ces drapeaux
que sera identifié le type de cycle d’ordonnancement.
3. L’analyse de la boucle d’ordonnancement à partir des valeurs des drapeaux de terminaison
se fait conformément aux observations réunies sur le tableau 3.2, et ce à la fin de chaque
cycle d’ordonnancement.
4. Enfin, à la fin de chaque boucle d’ordonnancement, le compteur correspondant au cycle
identifié est alors incrémenté.
Tab. 3.2: Cycles d’ordonnancement typiques sur le prototype
R2D2 de réseau de capteurs
Nom de cycle
Description
96
Cycle vide (RAS)
Le cycle le plus fréquent. Aucun événement particulier n’est survenu. Seul le calcul des échéances d’événements est réalisé.
Cycle tentative récep-
Le protothread de réception est activé, mais aucun émetteur ne
tion (RI)
cherche à communiquer (terminaison : pas d’émetteur). Aucun
autre traitement n’est employé dans ce cycle d’ordonnancement.
Cycle
réception
avec
collision (CR)
Le protothread de réception est activé, mais la phase d’écoute avant
l’émission d’une trame de réveil a détecté la présence d’un transfert en cours sur le canal, mettant fin à la procédure (terminaison :
collision). Aucun autre traitement n’est employé dans ce cycle d’ordonnancement.
Cycle
réception
de
trame erronée (RA)
Le protothread de réception est activé et une réception correcte a
lieu (terminaison : reception OK). Le protothread de traitement ascendant de la couche liaison est alors réquisitionné et détecte une
trame corrompue au delà de ses capacités de correction (terminaison : erreur trame). Un paquet d’aquittement négatif est programmé à l’émission ce qui se répercutera sur le cycle d’ordonnancement suivant. Aucun autre traitement n’est employé dans ce
cycle d’ordonnancement.
Cycle
réception
de
Le protothread de réception est activé et une réception correcte a
trame sans erreur et
lieu (terminaison : reception OK). Le protothread de traitement
activation d’application
ascendant de la couche liaison est alors réquisitionné et est en me-
(RC1/
sure de constituer une trame intègre (terminaison : trame OK). Le
RC2/
RC3/
RC4)
protothread effectuant les traitements de la couche réseau est activé et un protothread de niveau applicatif est activé (terminaison :
activation d’application).
Cycle calcul de trame
Le protothread des couches réseau et liaison sont activés dans le
pour émission (CAE)
sens descendant.
Cycle émission de trame
Le protothread d’émission est activé et la trame est émise avec
avec succès (E)
succès (terminaison : émission OK).
Cycle émission de trame
Le protothread d’émission est activé, l’attente du récepteur a lieu,
avec collision avec un
mais un autre émetteur commence à transmettre des informations
autre émetteur (CE)
provoquant une collision mettant fin au protothread en cours (terminaison : collision).
97
Tab. 3.3: Temps d’exécution des différents traitements lors d’un cycle vide
Traitement
temps d’exécution
PT reception
0,044 ms
PT emission
0,034 ms
PT horloges
0,456 ms
PT liaison
0,071 ms
PT reseau
0,106 ms
PT reqvois
0 ms
PT repvois
0 ms
ordonnanceur
0,308 ms
Tab. 3.4: Mesures de temps d’exécution (en ms) effectuées sur le
cycle ex.
RA
RC1
RC2
RC3
RC4
CAE E
réception 78.3
78.3
78.3
78.3
78.3
0.04
0.04
émission
0.03
0.03
0.03
0.03
0.03
0.03
1026
horloges
0.46
0.46
0.46
0.46
0.46
0.46
0.46
liaison
5.0
0.4
0.4
0.4
0.4
5.0
0
réseau
0
0.4
0.4
0.4
0.4
0.4
0
reqvois
0
0
0
0
0.1
0
0
repvois
0
0
0
0.1
0
0
0
ordonn.
0.31
0.31
0.31
0.31
0.31
0.31
0.31
3.3.3
prototype de plate-forme
RI
CR
CE
RAS
66.6
1.5
0.04
0.04
0.03
0.03
3008 0.03
0.46
0.46
0.46
0.46
0.071 0.071 0.071 0.071
0.106 0.106 0.106 0.106
0
0
0
0
0
0
0
0
0.31
0.31
0.31
0.31
Caractérisation en consommation des cycles d’ordonnancement
L’évaluation de consommation énergétique des cycles d’ordonnancement est réalisée par mesure du temps d’exécution de chacune des sous-procédures. Le logiciel intégré comporte des
légères modifications comparé au logiciel normal afin de pouvoir faire s’exécuter chacun des
protothreads dans chacune des terminaisons possibles. De plus, un autre type de modification est apporté pour pourvoir visualiser les débuts et fin des protothreads. Les instants où le
protothread récupère le processeur et où il rend le processeur sont localisés à l’aide de ports
d’entrée-sortie inutilisés par l’application. À l’aide d’un oscilloscope, nous avons ainsi pu déterminer les temps d’exécutions des traitements de la boucle d’ordonnancement.
Le tableau 3.3 présente différentes mesures de temps d’exécution qui ont été réalisées sur
le prototype R2D2, dans le cas de figure particulier du cycle ”vide”, aussi appelé cycle ”RAS”.
Il s’agit d’un cycle pendant lequel tous les processus ont rendu la main immédiatement après
l’avoir obtenu, faute d’avoir une ressource ou un événement. Le cycle ”vide” est donc le cycle
d’ordonnancement le plus simple.
Les tableaux 3.4 et 3.5 donnent les mesures réalisées sur la plate-forme R2D2 pour l’ensemble
des cycles d’ordonnancement typiques identifiés dans le tableau 3.2.
Les temps d’exécution permettent ensuite le calcul de la consommation d’énergie à l’aide de
la consommation des composants de la plate-forme.
98
Tab. 3.5: Temps passé avec le composant de communication actif
d’ordonnancement typique
cycle ex.
RA
RC1
RC2
RC3
RC4
CAE E
mode re- 0.05
0.05
0.05
0.05
0.05
0
1
cep.
mode
0.03
0.03
0.03
0.03
0.03
0
0.03
émis.
(P = 0
dBm)
(en ms) pour chaque cycle
RI
0.04
CR
0.01
CE
3.06
RAS
0
0.03
0
0
0
Le microcontrôleur utilisé par la plate-forme est un TI MSP430, et peut fonctionner sous 6
modes correspondant à des activités et des consommations d’énergie différentes, du mode actif
où tous les systèmes sont activés, au mode inactif le plus profond LPM4 où tous les systèmes
annexes sont désactivés, à savoir le convertisseur analogique/numérique, toutes les horloges,
ainsi que le DCO (Digitally Controlled Oscillator, pour oscillateur contrôlé numériquement)
permettant de générer le signal d’horloge. Le mode actif est le seul où le CPU est utilisable et,
d’après la documentation du composant, la consommation est de 0.28 mA, sous une tension
d’alimentation de 2.2 V et une fréquence de fonctionnement de 1 MHz. En extrapolant on
trouve donc un courant consommé de 2 mA sous une tension d’alimentation de 3 V et une
fréquence d’horloge de 4 MHz, ce qui correspond aux conditions expérimentales conformes au
prototype de test R2D2. La puissance consommée instantanée en mode actif est par conséquent
d’environ 6 mW.
Pour le composant radio, on distingue le temps passé en réception de celui passé en émission
et à quelle puissance (cf. tableau 3.5).
Cette méthode d’évaluation est réaliste, cependant elle nécessite de programmer entièrement
le réseau de capteur et de tracer l’exécution pour chaque nœud. Le protocole expérimental est
donc fastidieux à mettre en place. Une alternative à cette évaluation de consommation a donc
été proposée et présentée dans la section suivante.
3.4
Evaluation de l’énergie par une approche analytique
La méthode d’évaluation de l’énergie par une approche analytique et statistique est une
évolution de la méthode de traçage d’exécution.
Elle consiste à estimer les cycles d’ordonnancement typiques par simulation, comme illustré
sur la figure 3.12. La consommation des cycles d’ordonnancement est non plus comptée au cours
d’expérimentations réelles, mais estimée de façon théorique à partir d’informations concernant
3.4 Evaluation de l’énergie par une approche analytique
99
Fig. 3.12: Interdépendance des éléments de calcul de consommation (niveau 2).
la couche MAC, ainsi que des éléments de topologie pour estimer le réglage de la puissance
d’émission qui aurait été choisie par le capteur en fonction de la distance entre émetteur et
récepteur.
De même, la répartition des cycles d’ordonnancement est estimée théoriquement à partir
de l’estimation du nombre de collisions de réveil, du nombre de collisions entre émetteurs, du
nombre de retransmissions nécessaires et de la matrice de volume de données.
3.4.1
Estimation analytique de la répartition des cycles d’ordonnancement
Entrons à présent dans le détail de la méthode d’évaluation analytique de la répartition des
cycles d’ordonnancement.
Ce problème d’estimation fait intervenir de nombreux paramètres. Avant tout, et pour appuyer la description qui suit, le schéma de la figure 3.13 présente les paramètres mis en jeu
dans cette évaluation.
1. La topologie du réseau est décrite par le nombre de nœuds N , d’une part, et par la matrice
de coordonnées des nœuds à partir de laquelle on calcule une matrice de distances D entre
les nœuds. D est une matrice carrée et D(i, j) représente la distance géométrique entre
les nœuds i et j.
2. L’application est modélisée par la matrice de volume de données V , comme cela a été
présenté dans chapitre 2. Ce volume de transfert de données s’entend bien ”au niveau
réseau” et non pas ”au niveau application”, c’est-à-dire que V (i, j) représente le nombre
de trames à émettre de l’émetteur i vers le récepteur j y compris lorsque i, j ou les deux
100
Fig. 3.13: Dépendance entre les paramètres utilisés pour estimer une trace d’exécution.
ne sont que des intermédiaires pour une transmission multi-étapes.
3. L’environnement traduit les caractéristiques du canal utilisé. Nous ne retenons que deux
paramètres : la puissance du bruit ambiant observable au niveau d’un récepteur pbruit et
le coefficient d’affaiblissement α.
4. La couche liaison permettant de fiabiliser les transferts de données est caractérisée par
le paramètre de la tolérance aux erreurs (tol). Cette valeur vaut pour les systèmes de
correction d’erreurs basés sur des codes en blocs et elle correspond au nombre d’erreurs
maximal dans une trame de données pouvant être corrigées par le système de décodage.
5. La couche d’accès au médium a également un impact important sur les traces d’exécution
et plus particulièrement les paramètres que sont : la longueur des paquets, le taux de
transmission binaire et l’intervalle de réveil de la technique MAPLAP.
6. Enfin, les paramètres qui nous intéressent plus particulièrement dans la couche physique
sont la fréquence de la porteuse Fp , le gain Gantennes des antennes et le type de la
modulation.
À partir de ces différents paramètres, qui proviennent de tous les niveaux du protocole de
communication, il s’agit d’estimer la répartition des cycles d’ordonnancement. Comme l’illustre
le schéma 3.12, cette répartition dépend de quatre éléments :
– la matrice de volume de donnée V décrivant les transferts de données entre les nœuds du
réseau,
– le nombre de collisions de réveil NCR,
– le nombre de collisions d’émetteurs NCE,
101
Fig. 3.14: Cas idéal d’une communication de trame.
– le nombre de retransmissions NR, dues à la présence d’un trop grand nombre d’erreurs
binaires dans les trames reçues,
Dans la section qui suit seront développées les relations mathématiques de dépendance entre
tous ces paramètres.
3.4.2
Événements anormaux des communications et coût énergétique
Pour comprendre ce que peuvent être les défauts de la communication et l’ensemble des
événements ”anormaux” qui peuvent nuire à la consommation énergétique, il faut faire une
analyse temporelle détaillée des comportements de la couche d’accès au médium. La figure
3.14 illustre le déroulement idéal d’un transfert de trame entre un émetteur i et un récepteur
j. On constate qu’une transmission idéale de trame est un enchaı̂nement d’événements selon
une certaine séquentialité. Du point de vue de l’émetteur, une phase initiale consiste à générer
la trame à envoyer en passant par deux sous-phases. La première sous-phase, calcul de trame,
phase 1, permet d’insérer dans la trame le PCI (Protocol Control Information) du niveau réseau
autrement dit les informations de routage. La deuxième sous-phase initiale a pour rôle d’insérer
le PCI du niveau liaison, qui se limite dans notre cas à de la redondance de données dans le but
de faire fonctionner les systèmes de correction d’erreurs. Dans une seconde phase, l’émetteur
prend la décision de réaliser l’émission à l’aide d’un événement interne. Il est supposé que cette
procédure d’émission se déroule sans problème (terminaison ”émission OK”). Enfin, toujours
du point de vue de l’émetteur, la procédure d’émission s’achève par un événement de réception
de l’acquittement avec succès.
Du point de vue du récepteur, on a dans l’ordre un événement de réception de trame évaluée
comme intègre. Cet événement provoque le déclenchement de l’événement de génération de
102
Fig. 3.15: Communication de trame affectée d’événements problématiques.
message d’acquittement, qui est une procédure simplifiée de création de trame, et qui ne passe
par conséquent que par la phase calcul de trame, phase 2. Enfin, un événement d’émission est
planifié et on suppose que cette émission se termine par un succès (terminaison ”émission OK”.
À présent que nous avons présenté les événements normaux lors d’une communication, voyons
les événements anormaux gênants. La figure 3.15 nous permet d’illustrer toute la diversité des
cas gênants pouvant se présenter lors d’une communication.
Erreurs binaires non corrigeables. Tout d’abord, il peut y avoir des erreurs binaires non
corrigeables par la couche liaison (voir fig. 3.15). Cela entraı̂ne un rejet de la trame reçue et
nécessite une retransmission de l’information. Les conséquences sont :
– du point de vue de l’émetteur, un cycle supplémentaire d’”émission normale”(EOK) s’ajoute
au total des événements d’une communication normale,
– du point de vue du récepteur, un cycle supplémentaire de ”réception de trame erronnée”(RET) s’ajoute au total des événements d’une communication normale.
La probabilité d’occurence d’un événement d’erreurs binaires non corrigeables entre l’émetteur
i et le récepteur j dépend du paramètre tol indiquant le nombre d’erreurs corrigeables par
le système de correction d’erreurs. Cette probabilité d’occurence dépend également du TEB
(Taux d’erreur binaire) caractérisant le canal et de la taille des paquets échangés lp. La probabilité d’occurence d’un événement d’erreurs binaires non corrigeables Ri,j (tol) s’exprime par
l’équation :
Ri,j (tol) = 1 −
tol
X
k=0
k
.TEBk .(1 − TEB)lp−k
Clp
!
(3.2)
Le nombre moyen d’événements d’erreurs binaires non corrigeables NRi,j ayant lieu pour une
transmission de donnée réussie se calcule de la façon suivante. En notant VNRi,j la variable
103
aléatoire discrète traduisant le nombre de tentatives d’émission ayant échoué par émission
finalement réussie entre un émetteur i et un récepteur j. Les probabilités suivantes peuvent
alors être calculées :
p(VNRi,j = 0) = 1 − Ri,j (tol)
(3.3)
p(VNRi,j = 1) = (1 − Ri,j (tol)).Ri,j (tol)
(3.4)
p(VNRi,j = 2) = (1 − Ri,j (tol)).Ri,j (tol)2
(3.5)
et on en déduit le cas général :
p(VNRi,j = k) = (1 − Ri,j (tol)).Ri,j (tol)k
(3.6)
L’espérance mathématique du nombre d’événements non corrigeables pour une transmission
donnée est alors :
E[VNRi,j ] =
∞
X
k.p(VNRi,j = k)
(3.7)
k=0
E[VNRi,j ] = (1 − Ri,j (tol)).
∞
X
k.Ri,j (tol)k
(3.8)
E[VNRi,j ] = (1 − Ri,j (tol)).
Ri,j (tol)
(1 − Ri,j (tol))2
(3.9)
E[VNRi,j ] =
k=0
Ri,j (tol)
1 − Ri,j (tol)
(3.10)
Le nombre moyen d’événements d’erreurs binaires non corrigeables NRi,j est en fait égal à
cette espérance mathématique, donc :
NRi,j = (
Collision de réveil du récepteur.
1
− 1)
1 − Ri,j (tol)
(3.11)
Lors d’un événement de réveil du récepteur, la procédure
de réveil peut s’interrompre prématurément si le canal est détecté comme occupé pendant la
phase d’écoute préalable servant à éviter les collisions. C’est un cas de collision de réveil du
récepteur illustré sur les figures 3.15 et 3.16. Les conséquences d’un tel événement sont :
– du point de vue de l’émetteur, il n’y a pas de conséquence,
– du point de vue du récepteur, un cycle supplémentaire de ”collision à la réception” (CR)
s’ajoute au total des événements d’une communication normale.
Lorsqu’un nœud se réveille, il s’octroie le canal pendant une durée Trev . Si N est le nombre
de nœuds dans le réseau, Tobs le temps d’observation et IntRev l’intervalle de temps entre deux
104
Fig. 3.16: Déroulement du protocole d’accès au médium MAPLAP/RICER. Cas d’une collision
d’un récepteur lors de la phase de transmission de la trame de réveil.
réveils successifs d’un même nœud, on en déduit le nombre total de rendez-vous NRDV est :
NRDV = N.
Tobs
IntRev
(3.12)
Le taux d’occupation du canal TxOc est alors :
TxOc =
Trev .N
IntRev
(3.13)
Pour un nœud donné, la probabilité d’occurence CR d’une collision lors d’un événement de
réveil est alors :
CR =
Trev .(N − 1)
IntRev
(3.14)
Le nombre moyen d’événements de collision de réveil du récepteur NCR se calcule comme
cela a été fait pour le nomre moyen d’événements d’erreurs binaires non corrigeables. De la
même façon, on obtient alors l’expression :
CR
1 − CR
(3.15)
Collision de l’émetteur avec un autre émetteur.
Lorsque le récepteur émet une trame
NCR =
de réveil, il peut y avoir plusieurs émetteurs cherchant à communiquer avec lui. Grâce à un
système de temps d’attente aléatoire, un seul des émetteurs parvient à émettre sa trame de
donnée. Tous les autres émetteurs subissent alors une collision de l’émetteur avec un autre
émetteur. Cela est illustré par les figures 3.15 et 3.17. Les conséquences d’un tel événement
sont :
– du point de vue de l’émetteur, un cycle supplémentaire de ”collision de l’émetteur avec un
autre émetteur” (CE) s’ajoute au total des événements d’une communication normale,
– du point de vue du récepteur, il n’y a pas de conséquence.
La loi de probabilité indiquant le nombre d’émetteurs souhaitant répondre à un récepteur se
réveillant peut être modélisée à l’aide d’une loi de Poisson. Soit i le nœud cherchant à émettre
105
Fig. 3.17: Déroulement du protocole d’accès au médium MAPLAP/RICER. Cas d’une collision
entre émetteurs lors de la phase de transfert des données.
et j le nœud se réveillant. Vi,j est le nombre de trames émises du capteur i au capteur j pendant
le temps d’observation Tobs et IntRev est l’intervalle de réveil des nœuds. La probabilité µj pour
un nœud donné de chercher à émettre une trame à j pendant le réveil de ce dernier est :
µj =
X
Vi,j .
i6=j
IntRev
Tobs
(3.16)
La probabilité que k nœud cherchent à répondre au nœud j se réveillant est alors, (d’après la
loi de Poisson) :
pj,k = exp(−µj ).
µkj
k!
(3.17)
Finalement, la probabilité CE(j) pour un nœud i de subir une collision d’émetteur avec un
autre émetteur dans une tentative de communication avec j est :
CE(j) =
∞
X
pj,k .
k=2
k−1
k
(3.18)
Par analogie avec les méthodes précédentes, le nombre moyen d’événements de collision de
l’émetteur avec un autre émetteur NCE(j) ayant lieu pour une transmission de donnée réussie
vers le récepteur j est alors donné par l’expression
NCE(j) =
CE(j)
1 − CE(j)
(3.19)
Le schéma de la figure 3.13 illustre les dépendances de données quant à ces événements
anormaux se produisant lors des communications.
106
Fig. 3.18: Consommation énergétique par traitement (en joules) pour un capteur un sein d’un
réseau effectuant un entretien périodique de la connaissance du voisinage
3.4.3
Résultats d’évaluation de consommation d’énergie
Des premiers résultats de consommation ont été obtenus sous les conditions suivantes :
– taux de transmission : 4800 bit/s ;
– taille de la trame de réveil : 128 bits ;
– durée d’écoute anti-collision “réveil” : 0.01 s ;
– durée d’attente si aucun émetteur : 0.03 s ;
– taille de la trame de donnée : 128 bits ;
– durée d’écoute anti-collision “données” : 0.015 s ;
– intervalle de réveil : 2 s.
La consommation d’énergie par traitement a été obtenue en confrontant les données de
consommation des cycles d’ordonnancement typiques et les traces d’exécutions. Un exemple de
résultat est montré sur la figure 3.18.
Plusieurs informations peuvent être remarquées : tout d’abord, la consommation du module
radio est majoritaire, mais reste néanmoins maı̂trisée grâce à un système d’accès au média
respectueux de l’énergie. La puissance moyenne totale du composant de communication uniquement est de 4.44 mW.
On peut également noter une part de la consommation dû uniquement à l’ordonnanceur à
base de protothread qui est d’environ 11 %, ce qui est non négligeable, mais néanmoins tout à
fait contrôlé.
L’autonomie ainsi obtenue à l’aide de l’implémentation de ce système d’accès au médium
RICER est estimée à 126 jours, ce qui représente un gain d’un facteur 10 par rapport à une
solution basée sur une couche MAC offrant une disponibilité totale.
3.5 Optimisation énergétique : exemple de l’intervalle de réveil.
107
Fig. 3.19: Consommation énergétique obtenue pour un intervalle de réveil court de 0,18 seconde
et schéma d’occupation du canal. La consommation moyenne est de 1,21 mW, ce qui correspond
à une durée de vie de 0,84 ans.
Fig. 3.20: Consommation énergétique obtenue pour un intervalle de réveil optimal de 3,0 secondes et schéma d’occupation du canal. La consommation moyenne est de 0,151 mW, ce qui
correspond à une durée de vie de 6,7 ans.
3.5
Optimisation énergétique : exemple de l’intervalle de réveil.
L’intervalle de réveil est un paramètre très important de la couche d’accès au médium. Intuitivement, on peut penser que le choix de l’intervalle de réveil permet de choisir le compromis
entre la latence ou la réactivité du réseau et sa durée de vie. En effet, en choisissant un intervalle
de réveil très court, les rendez-vous s’établissent plus fréquemment et permettent d’écouler un
plus grand volume d’information et plus vite. La contrepartie est que le canal est plus occupé
et donc la probabilité augmente de rencontrer des événements anormaux tels que les différents
types de collisions et la consommation d’énergie augmente parce que le temps passé avec le
composant de communication actif augmente. A l’inverse, on peut penser qu’il suffit de choisir
un grand intervalle de réveil pour gagner en durée de vie au sacrifice de la réactivité.
108
Fig. 3.21: Consommation énergétique obtenue pour un intervalle de réveil long de 6,0 secondes
et schéma d’occupation du canal. La consommation moyenne est de 0,192 mW, ce qui correspond à une durée de vie de 5,32 ans.
Les figures 3.19, 3.20 et 3.21 présentent trois réglages différents de l’intervalle de réveil.
L’intervalle de réveil est la seule différence de configuration entre les trois simulations et les
matrices de volume de données échangées sont les mêmes, ce qui signifie qu’autant de trames
de données utiles sont échangées dans les trois situation. Par contre le nombre de trames de
réveil pour l’établissement des rendez-vous varie.
La figure 3.19 illustre le choix d’un intervalle de réveil court de 0,18 seconde. La représentation temporelle des rendez-vous montre en effet une utilisation du canal intensive. La
consommation élevée de 1,21 mW correspond à une durée de vie de 0,84 année et la majeure
partie de la consommation d’énergie (92,12 %) est due au mode d’émission du composant de
communication. Cela est dû au fait qu’un grand nombre de trames de réveil sont émises mais
peu aboutissent réellement à des émissions de trames de données.
La figure 3.20 illustre une configuration idéale du point de vue de la consommation énergétique moyenne qui est de 0,151 mW correspondant à une autonomie de 6,7 années, ce qui est
une augmentation d’un facteur 8 pour réaliser la même fonctionnalité. La seule concession qui
est faite concerne la latence qui est augmentée en moyenne de 2,82 secondes. La répartition de
la consommation est plus équilibrée et la part de consommation énergétique due au composant
de communication est contenue avec 73,35 % de la consommation totale.
Enfin, la figure 3.21 montre le cas d’un intervalle de réveil trop long, de 6 secondes. Outre la
latence qui est 5,82 secondes plus élevée que le meilleur cas, la consommation d’énergie globale
est supérieure au cas précédent, puisqu’elle est de 0,192 mW ce qui permet d’atteindre une durée
de vie de 5,32 années. La principale cause de consommation est due au mode de réception du
composant de communication. En effet, le petit schéma du comportement temporel montre que
3.6 Conclusion
109
Fig. 3.22: Puissance moyenne consommée en mW en fonction de l’intervalle de réveil.
le mode de réception est utilisé principalement lors de la phase initiale de l’émission pendant
laquelle le capteur attend le réveil du destinataire des informations.
La figure 3.22 représente la puissance moyenne consommée par les capteurs en fonction de
l’intervalle de réveil et la figure 3.23 montre la durée de vie moyenne en fonction de l’intervalle
de réveil. On visualise le point optimal qui se situe ici pour un intervalle de réveil d’environ 3
secondes. Il est a remarquer que le réglage optimal de l’intervalle de réveil dépend des informations échangées. Encore une fois, son optimisation ne peut être faite sans information sur les
niveaux supérieurs, et en particulier le niveau application. Il est donc très intéressant d’avoir
à disposition les modèles de transferts d’informations qui ont été abordés dans le chapitre 1.
Cela illustre une fois de plus un cas d’optimisation cross-layer.
3.6
Conclusion
Le portage de l’application vers une plate-forme réelle permet de clore le cycle de conception.
Le choix de la couche physique a été l’occasion de s’intéresser aux systèmes d’accès au médium
adaptés aux caractéristiques et aux besoins des réseaux de capteurs. Grâce à des techniques de
rendez-vous, nous avons vu comment faire des économies énergétiques en minimisant le temps
d’écoute hors émission, qui est la principale cause de gaspillage énergétique du composant
de communication. Notre choix s’est porté sur un système d’accès au médium inspiré de la
technique RICER (Receiver-Initiated CyclEd Receiver).
L’étude du prototype réel permet d’aller beaucoup plus loin dans le réalisme de l’évaluation
110
Fig. 3.23: Durée de vie moyenne d’un capteur en années en fonction de l’intervalle de réveil.
énergétique, comparée aux méthodes d’évaluation théoriques qui avaient été amorcées au début
de ce travail de thèse et qui apparaissent dans le chapitre 1 où nous ne disposions alors pas de
prototype de capteurs communicants. Les causes de consommation peuvent être indentifiées de
façon plus réaliste et plus détaillée.
Enfin, l’optimisation de l’intervalle de réveil a été présentée dans un certain cas de figure
d’application et de configuration des timings du protocole d’accès au média RICER. Il a été
montré que par une légère augmentation de la latence des communications, il est possible de
multiplier la durée de vie d’un facteur important, mais qu’il est inutile d’augmenter cette latence
au delà d’un certain seuil qui dépend de l’application.
Conclusion
Les objectifs initiaux pour ce travail de thèse étaient d’aboutir à la réalisation d’une plateforme de réseau de capteur efficace en énergie. Le budget énergétique est serré puisqu’il est
nécessaire de concevoir des capteurs communicants dont la consommation énergétique moyenne
est d’environ 100 µW. Dans ces conditions, aucune solution actuelle n’est suffisamment performante pour respecter un tel budget énergétique. Beaucoup de directions étaient possibles
tant le domaine est vaste, puisque le problème pouvait être abordé d’un point de vue de la
communication numérique, de l’architecture, du système, des algorithmes de routage...
Nos contributions sur les réseaux de capteurs ont été dans un premier temps l’étude et l’optimisation d’une chaı̂ne de communication entre deux nœuds communicants en liaison directe.
Ce travail a comporté une permière étape de modélisation d’une chaı̂ne de communication
fortement paramétrable. Les nombreux paramètres ont été séparés en plusieurs catégories :
– les paramètres de scénario dépendant de l’application visée ou de l’environnement dans
lequel le réseau de capteurs est intégré ;
– les paramètres de choix technologiques qui définissent les caractéristiques des choix matériels qui ont été pris. Le fait de fixer ces paramètres a permis de réduire la complexité du
problème d’optimisation ;
– et enfin les paramètres non connus a priori.
Nous nous sommes ensuite focalisés sur l’optimisation de l’efficacité énergétique représentée
par l’énergie par bit transmis avec succès de cette chaı̂ne de communication en nous intéressant
tout particulièrement au choix de la puissance d’émission optimale. En considérant le système
de communication incluant le système de correction d’erreur et en considérant les réémissions
de paquets en cas d’échec de la transmission, il est possible de déterminer un point optimal de
fonctionnement. Cependant, pour permettre au système de se placer à ce point optimal, il faut
pouvoir accéder à l’information de la distance entre l’émetteur et le récepteur. Or, il apparaı̂t
qu’il est tout à fait possible d’accéder à cette information puisque les capteurs implémentent par
ailleurs deux mécanismes servant principalement au routage qui sont l’auto-positionnement des
111
112
Conclusion
nœuds et la connaissance du voisinage. En autorisant les couches de protocole les plus basses
de la couche à accéder à ces informations au même titre que la fonction de routage, il apparaı̂t
alors que des gains significatifs de durée de vie de l’ordre de 400 % peuvent être obtenus sur
un réseau étendu.
La deuxième contribution a été la modélisation des trafics réseau, puisque l’évaluation des
performances et de la consommation des nœuds ne peut pas être précise sans cette information.
Cette analyse des trafics réseau a été réalisée à partir d’une réflexion basée sur des applications
réalistes de réseaux de capteurs. La modélisation des couches liaison et physique qui a été
réalisé au premier point montrent certaines limites. En effet, le protocole d’accès au médium
n’est pas défini ce qui ne permet pas de modéliser des événements tels que les collisions de
données, par exemple. De plus, seuls les traitements de communication sont pris en compte
pour l’évaluation énergétique sans inclure d’autres types de traitements gérés par les capteurs
communicant. C’est la raison pour laquelle il est apparu nécessaire d’avoir une approche moins
théorique et donc plus expérimentale afin d’obtenir des résultats plus fiables et plus réalistes.
Destiné à une plate-forme générique comportant un micro-contrôleur et un composant radio,
un logiciel a été défini avec pour ambition d’être modulaire, portable, indépendant du matériel,
adaptable à de nombreuses applications et aussi limité que possible dans l’utilisation de la
mémoire. Le cadre de programmation de ce logiciel est formé par les protothreads, qui sont au
cœur du système événementiel Contiki.
Enfin, ce logiciel a été porté sur une plate-forme réelle de capteur communicant construit
autour d’un micro-contrôleur TI MSP430 et d’un composant de communication numérique
Chipcon CC1020. Au vu des caractéristiques de composant de communication, le système
d’accès au médium RICER a été sélectionné. Il permet la réalisation de rendez-vous entre
émetteurs et récepteurs à partir d’une liaison radio mono-canal en half-duplex. La description
précise des traitements a abouti à une évaluation de la consommation plus fine, basée sur le
principe du traçage d’exécution.
De cette estimation sont tirés les enseignements pour faire des choix éclairés en vue de la
définition d’une future plate-forme matérielle plus performante.
L’optimiation du paramètre de l’intervalle de réveil dans le but de maximiser la durée de vie
a ensuite été réalisé, et permet d’illuster, la technique d’évaluation de consommation présentée
précédemment.
Perspectives
113
Perspectives
Au vu des résultats de consommation obtenus, il est clair que la plate-forme R2D2 actuelle
n’est pas à même de surpasser en l’état la concurrence à cause principalement de son composant de communication à la consommation trop élevée si on la compare à d’autres réalisations.
Cependant, cela a permis de mettre au point la méthode d’évaluation de la consommation. Ceci
dit, le CC1020 ou d’autres composants de sa famille sont utilisés par les autres laboratoires
concurrents réalisant des plate-formes complètes, à l’exception du CSEM [22], par exemple, qui
travaille spécifiquement sur la conception de matériel de communication plus performant. Les
choix pris concernant ce composant de communication ne sont pas définitifs, et devront évoluer
dans une étape ultérieure.
La couche physique mono-canal peut être avantageusement remplacée par un système de
communication à deux canaux [51], ce qui permettrait d’améliorer la consommation de l’accès au média, en particulier le temps d’écoute, hors réception, (ou idle listening) qui, comme
cela a été présenté au cours du chapitre 3 reste la principale cause de consommation de ces
capteurs communicants. Dans le cas d’un matériel à double canal, l’idée consiste à allouer l’un
des canaux au transfert des données (débit élevé, consommation) et l’autre au contrôle, pour
l’établissement des rendez-vous entre l’émetteur et le récepteur.
Une autre opportunité d’amélioration de la couche physique consiste à réaliser des communications à entrées multiples et sorties multiples distribuées (MIMO, pour Multiple Input Multiple
Output) pour la communication entre zones éloignées. Plutôt que d’effectuer des transmissions
multi-étapes pour réaliser des communications à longue distance, l’idée serait de faire collaborer
des capteurs situés dans une même zone comme un seul émetteur multi-antennes, pour communiquer avec un récepteur multi-antennes lui même constitué de nœuds mono-antenne. Les zones
d’émission et de réception doivent effectuer des opérations de synchronisation supplémentaires
pour pouvoir collaborer. Les applications visées doivent se prêter à un regroupement des capteurs en zones éloignées les unes des autres. Cette voie de recherche est actuellement en cours
d’étude au sein du laboratoire R2D2 (projet CAPTIV) et l’application visée concerne des capteurs intégrés sur des panneaux routiers. Ces capteurs ont un rôle de sécurité et d’information
sur les conditions locales de circulation et permettent de diffuser des alertes et des informations
diverses. Les panneaux routiers étant plus concentrés au niveau des carrefours dans les zones
urbaines, la communication entre carrefours éloignés pourrait utiliser avantageusement ce genre
de communication MIMO.
114
Perspectives
Bibliographie
[1] George Aggelou and Rahim Tafazolli. RDMAR : A Bandwidth-efficient Routing Protocol
for Mobile Ad Hoc Networks. In Proc. of the 2nd ACM International Workshop on Wireless
Mobile Multimedia. ACM, August 1999.
[2] Géraud Allard, Philippe Jacquet, and Laurent Viennot. Ad Hoc Routing With Multipoint
Relaying. In Techniques Algorithmiques, Réseaux et d’Optimisation pour les Télécommunications (AlgoTel 2003, 2003.
[3] G. Asada, M. Dong, T.S. Lin, F. Newberg, G. Pottie, W.J. Kaiser, and H.O. Marcy.
Wireless Integrated Network Sensors : Low Power Systems on a Chip. In Proc. of the 1998
European Solid State Circuit Conference (ESSCIRC’98), 1998.
[4] Stefano Basagni, Irnrich Chlamtac, Violet Syrotiuk, and Barry Woodward. A Distance
Routing Effect Algorithm For Mobility (DREAM). In Proc. of International Conference
on Mobile Computing and Networking (MobiCom’98). ACM/IEEE, October 1998.
[5] Henry Bertoni, Seong-Cheol Kim, and Miklos Stern. Pulse Propagation Characteristics at
2.4 GHz Inside Buildings. IEEE Transaction on Vehicular Technology, 45 :579–592, 1996.
[6] Dimitri Bertsekas and Robert Gallager. Distributed Asynchronous Bellman-Ford Algorithm. In Data Networks, chapter 5.2.4, pages 325–333. Prentice Hall, Englewood Cliffs,
1987.
[7] Edoardo Biagioni and Shu Hui Chen. A Reliability Layer for Ad-Hoc Wireless Sensor
Network Routing. In Proc. of the 37th annual Hawaii International Conference on System
Sciences (HICSS’04). IEEE, 2004.
[8] Ljubica Blazević, Levente Buttyán, Srdjan Capkun, Silvia Giordano, Jean-Pierre Hubaux,
and Jean-Yves Le Boudec. Self-Organization in Mobile Ad Hoc Networks : The Approach
of Terminodes. IEEE Comunications Magazine, 39(6) :166–174, June 2001.
[9] Jeff Boleng, Tracy Camp, and Vishy Tolety. Mesh-based Geocast Routing Protocols in an
Ad Hoc Network. In Proc. of IEEE International Workshop on Parallel and Distributed
Computing Issues in Wireless Networks and Mobile Computing (IPDPS), 2001.
115
116
BIBLIOGRAPHIE
[10] Torkil Brunsvik and Snorre Kjesbu. Radiowave Propagation in Industrial Environments.
In Proc. of 21st International Conference on Industrial Electronics (IECON’00), October
2000.
[11] Daniel Camara and Antonio Alfredo Loureiro. A GPS/Ant-Like Routing Algorithm for Ad
hoc Networks. In Proc. of Wireless Communications and Networking Conference (WCNC
2000), volume 3, pages 1232–1236. IEEE, September 2000.
[12] Mickaël Cartron and Olivier Sentieys. Optimisation énergétique d’un système de communication dédié à un réseau de capteurs. In Actes du 20ème colloque GRETSI : Traitement du
signal et des images, Louvain-la-Neuve, Belgique, septembre 2005. Diffusion universitaire
CIACO, Presses universitaires de Louvain.
[13] Anantha Chandrakasan and Massoud Pedram. Low Power CMOS Design. Kluwer Academic Publishers, 1995.
[14] Ching-Chuan Chiang, Hsiao-Kuang Wu, Winston Liu, and Mario Gerla. Routing in Clustered Multihop Mobile Wireless Networks with Fading Channel. In IEEE Singapore International Conference on Networks, pages 197–211. IEEE, 1997.
[15] Charles Chien. Digital System On A Chip. Kluwer Academic Publishers, 2001.
[16] M. Scott Corson and Anthony Ephremides. A Distributed Routing Algorithm for Mobile Wireless Networks. In Wireless Networks, volume 1, pages 61–81. Kluwer Academic
Publishers, 1995.
[17] Julio da Silva Jr., Jason Shamberger, Josie Ammer, Chunglong Guo, Suetfei Li, Rahul Shah, Tim Tuan, Mike Sheets, Jan Rabaey, Borivoje Nikolic, Alberto SangiovanniVincentelli, and Paul Wright. Design Methodology for PicoRadio Networks. In Design,
Automation and Test in Europe Conference. IEEE/ACM, 2001.
[18] Rohit Dube, Cynthia Rais, Kuang-Yeh Wang, and Satish Tripathi. Signal Stability Based
Adaptive Routing (SSA) for Ad Hoc Mobile Networks. IEEE Personal Communications,
4(1) :36–45, January 1997.
[19] Adam Dunkels, Björn Grönvall, and Thiemo Voigt. Contiki - a Lightweight and Flexible
Operating System for Tiny Networked Sensors. In Proc. of the First IEEE Workshop on
Embedded Networked Sensors 2004, November 2004.
[20] Adam Dunkels, Oliver Schmidt, and Thiemo Voigt. Using Protothreads for Sensor Node
Programming. In Proc. Workshop on Real-World Wireless Sensor Networks, Stockholm,
Sweden, 2005.
BIBLIOGRAPHIE
117
[21] Adam Dunkels, Oliver Schmidt, Thiemo Voigt, and Muneeb Ali. Protothreads : Simplifying
Event-Driven Programming of Memory-Constrained Embedded Systems. In Proc. of the
Fourth ACM Conference on Embedded Networked Sensor Systems (SenSys 2006). ACM,
November 2006.
[22] Christian Enz, Amre El-Hoiydi, Jean-Dominique Decotignie, and Vincent Peiris. WiseNET : An Ultralow Power Wireless Sensor Network Solution. IEEE Comunications
Magazine, 40(4) :62–70, 2004.
[23] Eli Gafni and Dimitri Bertsekas. Distributed Algorithms for Generating Loop-free Routes
in Networks with Frequently Changing Topology. IEEE Transactions on Communication,
29(1) :11–15, January 1981.
[24] Jose Joaquin Garcia-Luna-Aceves. Flow-oriented Protocols for Scalable Wireless Networks.
In ACM International Workshop on Modeling Analysis and Simulation of Wireless and
Mobile Systems (MSWiM, pages 1–6. ACM, 2002.
[25] Jose Joaquin Garcia-Luna-Aceves and Marcelo Spohn. Source-Tree Routing in Wireless
Networks. In IEEE Seventh Annual International Conference on Network Protocols, page
273. IEEE, 1999.
[26] M. Gerla and J. Tsai. Multicluster, mobile, multimedia radio network. ACM Journal of
Wireless Networks, 1(3) :255–265, 1995.
[27] Andrea Goldsmith and Stephen Wicker. Design Challenges for Energy-Constrained Ad
Hoc Wireless Networks. IEEE Wireless Communications, 9(4) :8–27, August 2002.
[28] M. Gunes, U. Sorges, and I. Bouazizi. ARA – The Ant-Colony Based Routing Algorithm
For Manets. In Proc. of International Conference on Parallel Processing Workshops, pages
79–85. IEEE, 2002.
[29] Chen Guo, Charlie Zhong, and Jan Rabaey. Low Power Distributed MAC for Ad Hoc
Sensor Radio Networks. In IEEE Globecom 2001. IEEE, November 2001.
[30] Zygmunt Haas and Marc Pearlman. ZRP : A Hybrid Framework for Routing in Ad Hoc
Networks. In Ad Hoc Networking, chapter 7, pages 221–253. Addison-Wesley Longman
Publishing Co., 2001.
[31] Zygmunt Haas, Marc Pearlman, and Prince Samar. The Intrazone Routing Protocol
(IARP) for Ad Hoc Networks. Technical report, IETF MANET Working Group, July
2002.
118
BIBLIOGRAPHIE
[32] Homayoun Hashemi. Indoor Propagation Modeling. In Wireless Communications in the
21st Century, chapter 8, pages 149–168. IEEE Press Series on Digital & Mobile Communication, 2002.
[33] Wendi Heinzelman. Application-Specific Protocol Architectures for Wireless Networks.
PhD thesis, Massachusetts Institute of Technology, 2000.
[34] Yih-Chun Hu and David Johnson. Implicit Source Routes For On-demand Ad Hoc Network
Routing. In ACM International Symposium on Mobile Ad Hoc Networking and Computing
(MibiHoc. ACM, 2001.
[35] Chalermek Intanagonwiwat, Ramesh Govindan, and Deborah Estrin. Directed Diffusion :
A Scalable and Robust Communication Paradigm for Sensor Networks. In Proc. of 4th
ACM International Conference on Mobile Computing and Networking (Mobicom’98), August 2000.
[36] Philippe Jacquet, Paul Muhlethaler, Amir Qayyum, Anis Laouiti, Laurent Viennot, and
Thomas Clausen. Optimized Link State Routing Protocol. In IEEE INMIC, Pakistan,
December 2001.
[37] Gerard Janssen and Ramjee Prasad. Propagation Measurements in an Indoor Radio Environment at 2.4GHz, 4.75GHz and 11.5GHz. In Proc. of the VTS Conference Frontiers
of Technology, pages 617–620, 1992.
[38] Mario Joa-Ng and I-Tai Lu. A Peer-to Peer Zone-Based Two-Level Link State Routing for
Mobile Ad Hoc Networks. IEEE Journal on Selected Areas In Communication, 17(8) :1415–
1425, August 1999.
[39] David Johnson and David Maltz. Dynamic Source Routing in Ad Hoc Wireless Networks.
In Thomasz Imielinski and Hank Korth, editors, Mobile Computing, volume 353, chapter 5,
pages 153–181. Kluwer Academic Publishers, 1996.
[40] Brad Karp and H.T. Kung. GPSR : Greedy Perimeter Stateless Routing for Wireless
Networks. In International Conference on Mobile Computing and Networking (MobiCom),
pages 243–254. ACM, 2000.
[41] Noureddine Kettaf, Abdelhafid Abouaissa, Thang Vuduong, and Pascal Lorenz. A Cross
Layer Admission Control On-demand Routing Protocol for QoS Applications. International Journal of Computer Science and Network Security (IJCSNS), 6 :98–105, September
2006.
BIBLIOGRAPHIE
119
[42] Young-Bae Ko and Nitin Vaidya. GeoTORA : A Protocol For Geocasting In Mobile
Ad Hoc Networks. In Proc. of the 2000 International Conference on Network Protocols
(ICNP), page 240. IEEE, 2000.
[43] Young-Bae Ko and Nitin Vaidya. Location-Aided Routing (LAR) in Mobile Ad Hoc
Networks. ACM Wireless Networks, 6(4) :307–321, July 2000.
[44] J. Kymissis, C. Kendall, J. Paradiso, and N. Gershenfeld. Parasitic Power Harvesting in
Shoes. In Proc. of th second IEEE International Conference on Wearable Computing, 1998.
[45] Olaf Landsiedel, Klaus Wehrle, and Stefan Götz. Accurate Prediction of Power Consumption in Sensor Networks. In IEEE Workshop on Embedded Networked Sensors, 2005.
[46] Young Lee and George Riley. Dynamic NIx-Vector Routing for Mobile Ad Hoc Networks.
In IEEE Wireless Communications and Networking Conference (WCNC 2005), 2005.
[47] Paul Lettieri, Christina Fragouli, and Mani Srivastava. Low Power Error Control for
Wireless Links. In Mobicom’97, pages 139–150. ACM, 1997.
[48] Philip Levis, Sam Madden, David Gay, Joe Polastre, Robert Szewczyk, Alec Woo, Eric
Brewer, and David Culler. The Emergence of Networking Abstractions and Techniques in
TinyOS. In Proc. of the First USENIX/ACM Symposium on Networked Systems Design
and Implementation (NSDI 2004), March 2004.
[49] Jinyang Li, John Janotti, Douglas de Coutu, David Karger, and Robert Morris. A Scalable
Location Service For Geographic Ad Hoc Routing. In Proc. of the 6th ACM International
Conference on Mobile Computing and Networking (MobiCom 2000), pages 120–130. ACM,
August 2000.
[50] Wen-Hwa Liao, Yu-Chee Tseng, Kuo-Lun Lo, and Jang-Ping Sheu. GeoGRID : A Geocasting Protocol For Mobile Ad Hoc Networks Based on Grid. Journal of Internet Technology,
1 :23–32, 2000.
[51] En-Yi Lin. A comprehensive Study of Power-Efficient Rendez-vous Schemes for Wireless
Sensor Networks. PhD thesis, University of California, Berkeley, 2005.
[52] En-Yi Lin, Jan Rabaey, Sven Wiethoelter, and Adam Wolitz. Receiver Initiated Rendezvous Schemes for Sensor Networks. In Proc. of IEEE Globecom 2005, 2005.
[53] En-Yi Lin, Jan M. Rabaey, and Adam Wolisz. Power-Efficient Rendez-vous Schemes for
Dense Wireless Sensor Networks. In IEEE International Conference on Communications,
2004.
120
BIBLIOGRAPHIE
[54] B. S. Manoj, R. Ananthapadmanabha, and C. Siva Ram Murthy. Link life Based Routing Protocol for Ad hoc Wireless Networks. In IEEE 10th International Conference on
Computer Communications (IC3N 2001). IEEE, October 2001.
[55] Amit Mehra, Xin Zhang, Arturo Ayon, Ian Waitz, Martin Schmidt, and Christopher Spadaccini. A Six-Wafer Combustion System For A Silicon Micro Gas Turbine Engine. Journal
of Microelectromechanical Systems, 9 :517–527, 2000.
[56] William Merrill, Lewis Girod, Jeremy Elson, Kathy Sohrabi, Fredric Newberg, and William
Kaiser. Autonomous Position Location in Distributed, Embedded, Wireless Systems. In
Workshop on Wireless Communications and Networking Conference. IEEE/CAS, 2002.
[57] Rex Min, Manish Bhardwaj, Seong-Hwan Cho, Nathan Ickes, Eugene Shih, Amit Sinha,
Alice Wang, and Anantha Chandrakasan. Energy-Centric Enabling Technologies for Wireless Sensor Networks. IEEE Wireless Communications, 9(4) :28–39, August 2002.
[58] Shree Murthy and Jose Joaquin Garcia-Luna-Aceves. An Efficient Routing Protocol for
WIreless Networks. ACM/Baltzer Journal on Mobile Networks and Applications, Special
Issue on Routing in Mobile Communication Networks, 1(2) :183–197, October 1996.
[59] Richard Ogier, Fred Templin, and Mark Lewis. Topology Dissemination Based on ResersePath Forwarding (TBRPF). In IETF RFC 3684, February 2004.
[60] Brian Otis, Yuen Hui Chee, Richard Lu, Nathan Pletcher, Jan Rabaey, and Simone Gambini. Highly Integrated Ultra-Low Power RF Transceivers for Wireless Sensor Networks.
In Christian Piguet, editor, Low-Power Electronics Design, chapter 31. CRC Press, 2003.
[61] Vincent Park and Scott Corson. A Highly Adaptive Distributed Routing Algorithm for
Mobile Wireless Networks. In Proc. of INFOCOM’97. IEEE, April 1997.
[62] Tom Parker and Koen Langendoen. Guesswork : Robust Routing in an Uncertain World.
In IEEE International Conference on Mobile Ad-hoc and Sensor Systems (MASS 2005).
IEEE, 2005.
[63] C. Perkins and P. Bhagwat. Highly Dynamic Destination-Sequenced Distance Vector
(DTDV) for Mobile Computers. In SIGCOMM 1994 Conference on Communications
Architectures, Protocols and Applications, pages 234–244. ACM, August 1994.
[64] Charles Perkins and Elizabeth Belding-Royer. Ad hoc On-Demand Distance Vector Routing. In Proc. of the 2nd IEEE Workshop on Mobile Computing Systems and Applications,
pages 90–100. IEEE, February 1999.
[65] Christian Piguet, editor. Low-Power Circuit Design. CRC Press, 2005.
BIBLIOGRAPHIE
121
[66] Daji Qiao, Sunghyun Choi, Amjad Soomro, and Kang G. Shin. Energy-Efficient PCF
Operation of IEEE 802.11a Wireless LAN. In Infocom’02. IEEE, 2002.
[67] Jan Rabaey, Josie Ammer, Julio da Silva Jr., Danny Patel, and Shad Roundy. PicoRadio
Supports Ad Hoc Ultra-Low Power Wireless Networking. Computer, 33(7) :42–48, July
2000.
[68] Jan Rabaey, Josie Ammer, Tufan Karalar, Suetfei Li, Brian Otis, Mike Sheets, and Tim
Tuan. PicoRadios for Wireless Sensor Networks — The Next Challenge in Ultra-Low
Power Design. In International Solid-State Circuit Conference. IEEE, 2002.
[69] Venkatesh Rajendran, Katia Obraczka, and Jose Joaquin Garcia-Luna-Aceves. EnergyEfficient,Collision-Free Medium Access Control for Wireless Sensor Networks. In SenSys’03, pages 181–192. ACM, 2003.
[70] Shad Roundy. Energy Scavenging for Wireless Sensor Nodes with a Focus on Vibration to
Electricity Conversion. PhD thesis, University of California, Berkeley, 2003.
[71] Shad Roundy, Dan Steingart, Luc Frechette, Paul Wright, and Jan Rabaey. Power Sources
For Wireless Sensor Networks. In Proc. of EWSN 2004, 2004.
[72] Chris Savarese. Robust Positioning Algorithms for Distributed Ad-Hoc Wireless Sensor
Networks. PhD thesis, University of California, Berkeley, 2002.
[73] Curt Schurgers, Vlasios Tsiatsis, Saurabh Ganeriwal, and Mani Srivastava. Optimizing
Sensor Networks in the Energy-Latency-Density Design Space. IEEE Transactions on
Mobile Computing, 1(1) :70–80, January-March 2002.
[74] Victor Shnayder, Mark Hempstead, Bor rong Chen, Geoff Werner Allen, and Matt Welch.
Simulating the Power Consumption of Large-Scale Sensor Network Applications. In SenSys’04. ACM, 2004.
[75] Rajendra Singh Sisodia, B. S. Manoj, and C. Siva Ram Murthy. A Preferred Link Based Routing Protocol for Ad Hoc Wireless Networks. Journal of Communications and
Networks, 4(1) :14–21, March 2002.
[76] Oliver Yang Song Guo. Performance of Backup Source Routing (BSR) in Mobile Ad Hoc
Networks. In IEEE Wireless Networking Conference, 2002.
[77] Matthias Stordeur and Ingo Stark. Low Power Thermoelectric Generator - Self-sufficient
Energy Supply For Micro Systems. In Proc. of 16th International Conference on Thermoelectrics, pages 575–577, 1997.
122
BIBLIOGRAPHIE
[78] Changsu Suh and Young-Bae Ko. A Traffic Aware, Energy Efficient MAC Protocol for
Wireless Sensor Networks. In IEEE International Symposium on Circuits and Systems,
pages 2975–2978, 2005.
[79] Sameer Tilak, Nael Abu-Ghazaleh, and Wendi Heinzelman. A Taxonomy of Wireles MicroSensors Network Models. ACM Mobile Computing and Communications Review, 1 :1–8,
2002.
[80] Chai-Keong Toh. A Novel Distributed Routing Protocol To Support Ad hoc Mobile Computing. In IEEE 15th Annual International Phoenix Conference on Computers and Communications (IPCCC 1996), pages 480–486. IEEE, 1996.
[81] Yu-Chee Tseng, Shih-Lin Wu, Wen-Hwa Liao, and Chih-Min Chao. Location Awareness
in Ad Hoc Wireless Mobile Networks. Computer, 34(6) :46–52, June 2001.
[82] Alvin Valera, Winston Seah, and S.V. Rao. CHAMP : A Highly-Resilient and EnergyEfficient Routing Protocol for Mobile Ad hoc Networks. In 5th IEEE Conference on Mobile
and Wireless Communications Networks (MWCN 2002), September, 2002. IEEE.
[83] Brett Warneke, Matt Last, Brian Liebowitz, and Kristofer Pister. Smart Dust : Communicating with a Cubic-Millimeter Computer. IEEE Computer, 34(1) :44–51, 2001.
[84] Brett Warneke and Kristofer Pister. An Ultra-Low Energy Microcontroller for Smart Dust
Wireless Sensor Networks. In Proc. of Int’l Solid-State Circuits Conf. 2004, (ISSCC 2004),
February 2004.
[85] Matthias Witt and Volker Turau. BGR : Blind Geographic Routing for Sensor Networks.
In Proc. of the Third Workshop on Intelligent Solutions in Embedded Systems (WISES’05).
GI/IEEE, May 2005.
[86] Wei Ye, John Heidemann, and Deborah Estrin. An Energy-Efficient MAC protocol for
Wireless Sensor Networks. In IEEE Infocom, pages 1567–1576, 2002.
[87] Wei Ye, John Heidemann, and Deborah Estrin. Medium Access Control with Coordinated,
Adaptive Sleeping for Wireless Sensor Networks. Technical report, USC/ISI, January 2003.
[88] Lizhi Charlie Zhong, Jan M. Rabaey, and Adam Wolisz. An Integrated Data-link Energy
Model for Wireless Sensor Networks. In IEEE International Conference on Communications, pages 3777–3783, 2004.
Vers une plate-forme efficace en énergie pour les réseaux de capteurs
sans fil
Thèse de doctorat – 2006 – Mickael CARTRON
Université de Rennes 1 / IRISA
RESUME : Les réseaux de capteurs constituent un thème de recherche très dynamique actuellement, tiré vers
le haut d’une part par l’opportunité de développer des applications novatrices liées à la position géographique
des éléments du réseau, et d’autre part, plus généralement, par le challenge de la conception d’objets
communicants entièrement autonomes. Le but de ce travail est de parvenir à définir des solutions architecturales
opérationnelles capables de maximiser l’autonomie des nœuds du réseau. Pour parvenir à ce but, les travaux de
recherche qui ont été menés ont pour objectif dans un premier temps de cerner les besoins de ces réseaux de
capteurs en termes de performances, de complexité de calcul, de mémoire nécessaire, en s’appuyant sur des
analyses de scénarios précis et réalistes.
Dans un second temps, une plate-forme de nœud générique est décrite à partir de l’analyse préalable des
besoins, des couches les plus proches du matériel jusqu’aux couches applicatives les plus élevées. Cet
environnement intégré fortement réglable offre une vision totale des traitements au sein des nœuds et autorise
par là-même les optimisations ”cross-layer”. En particulier, les différents traitements liés à la communication sont
identifiés sous forme d’éléments génériques. Des modèles de performances ont été définis pour ces
composants déclinés sous forme de chaîne de communication, dans le but d’en déterminer des points de
fonctionnement optimaux du point de vue de l’efficacité énergétique. Ces travaux ont été réalisés sur un logiciel
de simulation développé au sein du laboratoire. La conception d’architecture et d’algorithmes à faible
consommation nécessite des outils performants et une vision particulière. C’est pourquoi dans un troisième
temps, l’évaluation de la consommation énergétique a été abordée par différentes approches correspondant à
différentes phases de la conception. Des solutions ont été développées pour évaluer des choix logiciels et
matériels d’un point de vue du coût énergétique. Notre approche est basée sur le traçage d’exécution de code,
simple et fondée sur un cadre de programmation événementiel général et portable.
MOTS CLES : réseau de capteurs, consommation énergétique, design « cross-layer », systèmes
événementiels
________________________________________________________________________________________________________________
Towards an energy-efficient platform for wireless sensor networks
Ph.D. Thesis – 2006 – Mickaël CARTRON
Université de Rennes 1 / IRISA
ABSTRACT: Sensor networks are a very dynamic domain of research due, on the one hand, to the opportunity
to develop innovative applications that are linked to a specific environment, and on the other hand to the
challenge of designing totally automonous communicating objects. The aim of this work is to define architectural
operational solutions able to maximize the lifetime of these sensor networks.
In order to reach this goal, the work that has been led aims to define the needs of performance, processing
complexity, and memory, solving particular sensor networks applicative scenarios.
Then, a generic sensor node platform is described according to the application constraints analysis, from the
lower-level hardware processing to the higher-level applicative tasks. This highly adjustable integrated
environment gives a global vision of the processing of the nodes, which gives the means to study cross-layer
optimizations. In particular, wireless communication processings have been analytically described in order to
evaluate and optimize the energy efficiency. This work has been realized on a simulation program that has been
developed in our laboratory.
Low power architectural and algorithmic design requires high performance tools and a particular vision. For this
reason, the energy consumption evaluation has been studied, for all differents steps of the design, and solutions
have been given for the evaluation of energy consumption and performance of hardware and software designs.
The approach described is based on code execution tracing on a general and portable event-driven system.
KEY W ORDS: sensor networks, energy consumption, cross-layer design, event-oriented systems

Vers une plate-forme efficace en énergie pour les

Transcription

Documents pareils

Méthodes probabilistes pour le routage dans les réseaux

Fiche syst`eme d`assainissement 2014 St

Fiche système dàssainissement 2014 CREON DÀRMAGNAC

Fiche syst`eme d`assainissement 2014 CETTE EYGUN (EYGUN

Solid Drink®-Diet Bio 56 gm cups

Lire la suite - Ville de Pont à Marcq

Crème de Tartre Pure PatisFrance

Collettori solari FR

Auto-organisation et chaos spatiotemporel pour un modèle proie

Tre Bicchieri Gambero Rosso Tre Bicchieri Gambero Rosso DRO IT d