See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/275343154

Les bases de données dans les réseaux de capteurs sans fil

Article in Techniques et Sciences Informatiques · December 2014

DOI: 10.3166/tsi.33.739-776

CITATIONS READS

3 7,829

4 authors:

Abderrahmen Belfkih Bruno Sadeg

Université du Havre Université du Havre
11 PUBLICATIONS 34 CITATIONS 86 PUBLICATIONS 299 CITATIONS

SEE PROFILE SEE PROFILE

Claude Duvallet Laurent Amanton

Université du Havre Université du Havre
88 PUBLICATIONS 285 CITATIONS 46 PUBLICATIONS 87 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Building Information Modeling View project

On solving constrained optimal control problems via nonsmooth Newton method. View project

All content following this page was uploaded by Claude Duvallet on 07 March 2016.

The user has requested enhancement of the downloaded file.

Les bases de données dans les réseaux
de capteurs sans fil

Abderrahmen Belfkih, Bruno Sadeg, Claude Duvallet,

Laurent Amanton

Université du Havre
Laboratoire d’Informatique du Traitement de l’Information et des Systèmes
BP 1123, 76063 Le Havre cedex, France
[email protected]

RÉSUMÉ. Ces dernières années, l’utilisation des capteurs sans fil est en plein essor. Les réseaux
de capteurs sans fil (RCSF) ont attiré l’intérêt des industriels et ils ont conquis une diversité de
champs d’applications (militaire, santé, transport, agriculture, etc). Ces capteurs sont souvent
organisés en réseau ad hoc, qui n’a pas a priori de topologie définie. Les applications utilisant
les capteurs et les réseaux de capteurs sont orientées données, dans le sens où les capteurs
acquièrent puis envoient leurs données vers une station de base. Des recherches intensives ont
commencé il y a un peu plus d’une dizaine d’années sur la structuration des données de cap-
teurs en bases de données. Dans cet article, nous effectuons un état de l’art sur les bases de
données de capteurs. Nous présentons les différentes approches proposées après avoir décrit les
principaux types de capteurs, leur organisation en réseau et les problèmes y afférant, puis nous
décrivons quelques modèles implantés et/ou de recherche de bases de données de capteurs.
ABSTRACT. In recent years, the use of wireless sensors in most fields has increased drastically.
Wireless Sensor Networks (WSN) have attracted the interest of industrial and they have been
used on several application areas (military, health, transport, agriculture). These sensors, are
often organized in sensors networks to facilitate the exchange of data. In most cases, a sensors
network is an ad hoc network, i.e., has not a predefined topology. Application using sensors and
sensors networks are data-center, in which the sensors send their data to a central station (base
station). Since about a decade, intensive research started on the means to structure the sensor
data in sensor databases. In this article, we give an overview on existing research prototypes of
sensor databases. We begin to recall the characteristics and typology of the main types of sen-
sors and their organization in network, then we describe some implemented models of sensor
databases.
MOTS-CLÉS : capteur, réseau de capteurs, base de données, langage de requêtes.
KEYWORDS: sensor, sensor Network, database, query language.

DOI:10.3166/TSI.33.739-776 c 2014 Lavoisier

Technique et science informatiques – no 9-10/2014, 739-776

740 TSI. Volume 33 – no 9-10/2014

1. Introduction

Les réseaux de capteurs sans fil constituent une technologie émergente qui connaît
un succès grandissant aussi bien dans le domaine civil que militaire. Un RCSF peut
généralement être décrit comme un réseau de nœuds, relié par des canaux sans fil, qui
permettent de détecter des informations (telles que la température ou la pression) à
l’aide des capteurs sur le milieu dans lequel ils sont déployés, et de les envoyer par la
suite vers des points de collecte, appelés « stations de base ». C’est ainsi que les RCSF
sont utilisés dans plusieurs domaines tels que la surveillance de l’environnement, les
transports intelligents, le bâtiment, la surveillance de malades, l’agriculture, etc.
Dans de nombreuses applications, le déploiement de capteurs est effectué sans
planification préalable. Une fois déployés, les capteurs doivent être capables de s’auto-
organiser. Ils sont soumis à plusieurs contraintes, telles que les contraintes énergé-
tiques, de puissance de calcul, de faible portée radio, de précision des résultats, de
quantités de données échangées, ... (cf. section 3.5). Ces contraintes sont dues à l’en-
vironnement dynamique, aux communications sans fil et à la densité du réseau.
Les travaux de recherche menés pour faire face à ces défis se sont focalisés no-
tamment sur la mise en place de standards et de normes tels que le standard 802.15.4
(Gutierrez et al., 2001) et le protocole ZigBee (Jun Zheng, 2009), afin d’organiser le
réseau et de faciliter les communications entre les capteurs. Il s’agit de mettre en place
une architecture qui prend en considération les capacités énergétiques des capteurs.
Plusieurs systèmes d’exploitation sur lesquels se basent ces réseaux ont également été
proposés pour résoudre les défis rencontrés dans les RCSF et pour améliorer la qualité
de service proposée. Parmi ces systèmes, on peut citer : TinyOS (Levis, Gay, 2009),
Contiki (Dunkels et al., 2004), SOS (Han et al., 2005), RETOS (Hojung et al., 2007)
et LiteOS (Cao et al., 2008).
Les réseaux de capteurs récoltent les données mais n’effectuent que très peu de
traitements (Petit, 2009). Les stations de base récupèrent les informations et forment
avec des nœuds un réseau de traitement de données. Les bases de données peuvent
répondre à certains défis liés à la gestion des données dans les réseaux de capteurs. Une
base de données de capteurs est un ensemble de données qui représente des mesures
effectives sur l’environnement physique. Les données ne sont pas toujours stockées
dans cette base. Elles sont instantanées, transitoires, et fréquemment variables (Gurgen
et al., 2009).
Cougar (Fung et al., 2002), TinyDB (Madden, Franklin et al., 2003), Sina (Jaikaeo
et al., 2000), Antelope (Adam, Tsiftes, 2011) sont des intergiciels basés sur une ap-
proche orientée base de données. Ils fournissent aux utilisateurs des interfaces flex-
ibles qui permettent d’exécuter des requêtes dans un langage proche de SQL 1 , afin
d’extraire les données pertinentes du réseau de capteurs.

1. SQL : Structured Query Language

 Les bases de données dans les RCSF 741

Dans ce travail, nous présentons un état de l’art sur les bases de données dans les
réseaux de capteurs. Nous commençons par donner une définition des capteurs et leurs
caractéristiques dans la section 2. Dans la section 3, nous présentons les réseaux de
capteurs sans fil et les différents problèmes rencontrés. Nous étudions par la suite les
différents systèmes d’exploitation et les intergiciels qui s’apparentent à des bases de
données, proposés pour gérer les données dans les RCSF.

2. Les capteurs

2.1. Définition

Un capteur est un dispositif destiné à effectuer des tâches de télédétection. La

télédétection est définie comme la mesure ou l’acquisition d’informations sur les pro-
priétés d’un objet, un phénomène ou un matériel par l’intermédiaire d’un capteur qui
peut ne pas avoir de contact avec l’objet étudié (Khorram et al., 2012). Il convertit par
la suite les paramètres ou les événements du monde physique en signaux qui peuvent
être mesurés et analysés (cf. figure 1).

Conversion
Capteur Conditionnement
analogique-numérique

détection

Traitement du signal
Processus

Conversion
Actionneur Conditionnement
numérique-analogique

actionnement

Figure 1. Acquisition de données et actionnement (Dargie, Poellabauer, 2010)

2.2. Caractéristiques d’un capteur

Un capteur possède les caractéristiques suivantes (Wilson, 2004) :

– L’étendue de la mesure : c’est la différence entre la limite supérieure et la limite
inférieure de la grandeur mesurable par un capteur.
– La linéarité : elle caractérise l’aptitude d’un capteur à fournir une grandeur de
sortie dont la valeur est proportionnelle à celle mesurée.
– La non-linéarité : elle désigne l’écart maximal entre le signal de sortie du capteur
et la droite de référence sur la plage de mesures spécifiée.
– La sensibilité : elle représente la variation du signal de sortie par rapport au
signal d’entrée.
– La précision : il s’agit de l’aptitude d’un capteur à donner des mesures proches
de la réalité.
742 TSI. Volume 33 – no 9-10/2014

– La finesse : elle permet d’estimer l’influence que peut avoir un capteur sur la
grandeur à mesurer.
– La rapidité : représente le temps de réponse d’un capteur, qui est en rapport avec
la bande passante utilisée.
– La répétabilité : représente la capacité d’un capteur à présenter la même valeur
dans des conditions identiques.
– L’incertitude : représente l’estimateur de la dispersion ou l’écart entre la valeur
mesurée et la valeur exacte. Chaque mesure doit être accompagnée de cet écart, pour
considérer le résultat comme complet.
– Hystérésis (hystérèse) : représente la différence maximale entre les deux
grandeurs de sortie obtenues pour la même grandeur à mesurer.

3. Du capteur au réseau de capteurs

3.1. Définition

Un réseau de capteurs sans fil est un type particulier de réseau Ad-hoc Mobile
(MANET 2 ) (Egea-López et al., 2005). Il est composé d’un grand nombre de nœuds
(dispositifs de détection) qui communiquent entre eux via des transmissions sans fil.
Chaque nœud possède la capacité de collecter des données et de les transmettre à une
station de base (cf. figure 2).

Gestionnaire de réseau

Station de base

Utilistateur

Capteurs
Station de base

Figure 2. Architecture d’un réseau de capteurs sans fil

3.2. Topologies des réseaux de capteurs sans fil

Un réseau de capteurs est composé d’un grand nombre de nœuds à forte den-
sité déployés dans une zone de détection, avec une ou plusieurs stations de base qui
se trouvent à l’intérieur de la zone ou à proximité. La station de base communique
avec les capteurs via des requêtes ou des commandes, et les capteurs communiquent
entre eux via des communications sans fil. Ils participent à l’accomplissement de la

2. Mobile Ad-hoc NETwork

 Les bases de données dans les RCSF 743

tâche de détection et d’envoi des données à la station de base. Dans les réseaux de
capteurs, l’énergie consommée pour la communication est beaucoup plus élevée que
celle nécessaire à la détection ou au calcul. Par exemple, la transmission d’un seul
bit de données est équivalente à 800 instructions (Madden et al., 2002). Un réseau de
capteurs sans fil peut être organisé selon différents types de topologies, dont voici les
principales.

3.2.1. Topologie en étoile

Dans cette topologie de communication, le réseau est constitué d’une seule station
de base qui peut envoyer et/ou recevoir des messages depuis un certain nombre de
nœuds distants (Matin, 2012). Les nœuds ne sont pas autorisés à communiquer entre
eux. Cette topologie a pour avantages d’être facile à déployer, et de garantir des com-
munications à faible latence entre les nœuds distants et la station de base (Kaur, Garg,
2012).

3.2.2. Topologie maillée

Cette topologie utilise un réseau multisaut pour couvrir l’ensemble des nœuds con-
nectés, c’est-à-dire que le signal passe d’un capteur à l’autre jusqu’à ce qu’il atteigne
la station de base. La portée de communication de chaque nœud n’est pas limitée par
une distance, on peut toutefois ajouter un nœud intermédiaire pour l’étendre (Matin,
2012). L’avantage principal de cette topologie est qu’elle permet de maintenir la con-
nectivité globale du réseau, mais son inconvénient majeur réside dans le nombre de
sauts qui augmente d’une communication à une autre, ce qui augmente la consomma-
tion d’énergie dans le réseau.

3.2.3. Topologie hybride

La topologie hybride (Matin, 2012) combine à la fois la topologie en étoile et la
topologie maillée. Elle fournit un réseau robuste avec plusieurs fonctions de commu-
nication, tout en conservant la consommation d’énergie des capteurs au minimum.
Les nœuds qui ont une capacité énergétique plus élevée sont activés pour assurer une
communication multisaut. Par contre, les nœuds à faible puissance sont désactivés.

3.3. Structure d’un capteur sans fil

Un capteur sans fil est un dispositif souvent capable d’effectuer un certain nombre
de traitements tel que la collecte d’informations et la communication avec d’autres
capteurs dans le réseau (Kumar et al., 2010). Il est composé de plusieurs unités (cf.
figure 3).

3.3.1. Unité de traitement

Elle contient un microcontrôleur qui gère les données provenant des autres cap-
teurs et qui décide par la suite de la destination et du temps nécessaire pour les en-
voyer. Il peut exécuter différents programmes et les basculer entre différents modes de
744 TSI. Volume 33 – no 9-10/2014

Système de localisation et
Mobilisateur
de recherche

Unité de détection Unité de traitement

Processeur
Capteur ADC Emetteur-récepteur
stockage

Unité d'alimentation Générateur d'énergie

Figure 3. Structure d’un capteur sans fil (Akyildiz et al., 2002)

fonctionnement (actif, inactif, sommeil) pour économiser l’énergie du capteur (Munir,

Ross, 2010).

3.3.2. Unité de stockage

Elle est constituée d’une mémoire flash pour stocker temporairement les données,
et d’une mémoire vive statique SRAM 3 pour stocker les valeurs intermédiaires des
capteurs et les paquets reçus des autres nœuds. La vitesse de lecture/écriture et le
temps d’accès aux données, qui sont des facteurs importants, doivent être pris en
compte pour assurer une faible consommation d’énergie (Matin, 2012). Par exemple,
un capteur MicaZ possède une mémoire flash de 128 Kb et une mémoire EEPROM 4
de 4Kb (Boyle, Newe, 2008).

3.3.3. Unité de détection

Elle est composée d’un dispositif de détection pour détecter les paramètres de l’en-
vironnement telles que la température, la pression, la lumière,l’humidité, etc., et d’un
convertisseur analogique-numérique (Akyildiz et al., 2002). L’unité de détection con-
trôle la consommation d’énergie du capteur en ajustant la consommation du conver-
tisseur analogique-numérique. Elle fournit une détection constante et une détection
périodique (Munir, Ross, 2010). Généralement, la détection périodique consomme
moins d’énergie que la détection constante. Dans une détection périodique, l’acquisi-
tion de données est cyclique. Les capteurs acquièrent de nouvelles mesures après un
intervalle de temps, alors que dans une détection constante, les capteurs détectent en
permanence les phénomènes physiques, et la fréquence de détection est limitée par les
capacités matérielles du capteur.

3. Static Random Access Memory.

4. Electrically-Erasable Programmable Read-Only Memory.
 Les bases de données dans les RCSF 745

3.3.4. Unité d’émission/réception

Elle permet d’envoyer les données à travers un émetteur radio muni d’une antenne
suivant une fréquence, pour les récupérer par la suite sur d’autres nœuds. L’unité émet-
trice/réceptrice du capteur peut être un dispositif passif ou actif (Pottie, Kaiser, 2000).
La plupart du temps, la radio est en écoute de messages entrants, sinon elle se met en
veille pour réduire la consommation d’énergie du capteur.

3.3.5. Unité d’alimentation

Elle est constituée d’une batterie et d’un convertisseur DC-DC 5 (Munir, Ross,
2010). Un convertisseur DC-DC est alimenté par des batteries. Sa fonction principale
est de fournir l’énergie au capteur et également de réguler sa tension de sortie. La
circulation du courant dans le convertisseur DC-DC est élevée, ce qui peut amener à
des pertes importantes en énergie, réduisant considérablement le rendement global du
système (Forghani-zadeh, Rincón-Mora, 2005).

3.4. Domaines d’applications

Les capteurs peuvent être utilisés pour détecter et surveiller un certain nombre
de paramètres physiques : la lumière, le son, l’humidité, la pression, la température,
la composition du sol, de l’air ou de l’eau, etc. L’avantage principal des capteurs
est qu’ils peuvent être déployés dans plusieurs environnements avec un faible coût.
Les réseaux de capteurs sans fil peuvent améliorer de nombreuses applications : la
médecine, l’agriculture, les transports, le contrôle de processus industriels et de l’ar-
mée. Dans la suite de cette section, nous décrivons brièvement l’utilisation des RCSF
dans quelques domaines.

3.4.1. Domaine militaire

Les RCSF sont bien exploités dans les applications militaires. Certains ont pour
objectif le suivi et la détection des intrusions non autorisées dans une zone protégée.
Le système de surveillance basé sur des capteurs sans fil doit fournir des informa-
tions avec une précision et une confidentialité acceptables sur la position des objets
qui se déplacent dans une zone géographique, localiser et suivre les déplacements
des forces ennemies avec précision et prévenir les attaques chimiques, biologiques,
voire nucléaires, par une détection anticipée (De Sousa, 2008). Toutes les informa-
tions requises sont signalées à une station de base à distance, dans un temps de latence
acceptable pour avoir le temps de prendre les précautions nécessaires et agir au bon
moment.

5. Direct Current to Direct Current

746 TSI. Volume 33 – no 9-10/2014

3.4.2. Le domaine de l’agriculture

Les RCSF peuvent améliorer le domaine de l’agriculture. Ils offrent un support
important qui permettra la gestion précise des ressources, le suivi de développement
des maladies, la prédiction du moment adéquat de la récolte (Bechkit et al., 2011).
Ils ne nécessitent qu’un coût d’installation réduit, et sont faciles à déployer sur le
terrain, puisque la mise en place des capteurs ne demande pas un câblage spécial. Les
capteurs collectent des données sur les cultures et la qualité du sol et les transmettent
à une station centrale présente dans la ferme (De Sousa, 2008).

3.4.3. Le contrôle de l’environnement

Les RCSF peuvent aider à étudier les phénomènes complexes comme les séismes,
les volcans et les tempêtes. Nearest (Integrated observation from near shores sources
of Tsunami) est un projet de la commission européenne visant le développement d’un
système de détection précoce des Tsunamis locaux dans le Golfe de Cadiz. Des cap-
teurs sismiques et de pression ont été mis en place pour des observations sous-marines
(Pignagnoli et al., 2011). Le réseau de détection sismique de l’observatoire de Greno-
ble (réseau Sismalp), lancé en 1987, est le seul réseau sismologique couvrant l’ensem-
ble des Alpes occidentales françaises. Les objectifs de ce réseau sont de surveiller la
sismicité régionale pour mieux en comprendre la sismotectonique et pour estimer le
risque sismique (Guyoton, 1991).

3.4.4. Applications liées à la santé

Les RCSF peuvent améliorer notre vie quotidienne à travers différents services : la
surveillance à domicile des personnes âgées, la surveillance de malades dans les hôpi-
taux, la recherche rapide des animaux domestiques perdus, etc. Le projet STAR (sys-
tème télé-assistant réparti) (Haiying et al., 2004) consiste à concevoir une plateforme
dédiée à la surveillance de personnes souffrant d’arythmies cardiaques. Il permet d’ac-
quérir et d’analyser les signaux ECG 6 en temps réel et de les envoyer à travers une
passerelle connectée à Internet depuis la personne vers un centre de traitement médical
ou un hôpital (De Sousa, 2008).

3.4.5. Systèmes de transports intelligents

Les systèmes à base de capteurs sont souvent utilisés dans les systèmes de trans-
port intelligents (STI). Ils sont exploités dans des applications comme la gestion de
flottes de véhicules et la surveillance du trafic. Des capteurs (capteurs vidéo, capteurs
à boucle, capteurs acoustiques, capteurs de pression, capteurs micro-ondes et radars)
posés temporairement sur certains axes routiers, fournissent des données sur les vari-
ables fondamentales du trafic comme le débit, la vitesse, la densité, le taux d’occupa-
tion, les mouvements tournants dans les carrefours, les événements affectant le trafic
comme les bouchons et les accidents (Breheret et al., 2000). L’ensemble des mesures
collectées permet de répondre à certaines applications de sécurité comme la gestion

6. Électrocardiographie : une représentation graphique de l’activité électrique du cœur.

 Les bases de données dans les RCSF 747

des congestions et la prévention des accidents. Ces données sont stockées dans des
bases de données. La majorité des réseaux de capteurs envoie les données vers une
base centralisée localisée en mémoire vive. Une réplication des données peut être ef-
fectuée vers d’ autres bases ou des entrepôts de données en dehors du réseau et sur
disque (Servigne et al., 2009).
Une application possible dans le domaine du transport est la solution ParkSense
(Solivellas, 2012) qui permet aux automobilistes de se rendre directement à une place
de stationnement libre sans avoir à chercher via une application mobile et une carte
géographique. L’idée générale s’appuie sur des capteurs autonomes, installés sur la
chaussée. Ces capteurs (des capteurs magnétiques) peuvent détecter la présence d’un
véhicule en analysant les variations du champ magnétique. Ce champ est stable lorsque
la place est libre et sera déformé à l’arrivée d’un véhicule.

3.5. Contraintes liées aux réseaux de capteurs

Les réseaux de capteurs sont soumis à différents types de contraintes : temporelles,

d’énergie, de puissance de calcul, de portée radio, etc. Elles sont dues à l’environ-
nement dynamique et aux communications sans fil.

3.5.1. Gestion de l’énergie

Le prolongement de l’autonomie de la batterie du capteur est l’un des principaux
défis dans la conception des RCSF. Certaines approches proposent des méthodes telles
que le contrôle en mode sommeil (Yutaka et al., 2009) : pour minimiser la consomma-
tion d’énergie, un nœud peut être dans un état de veille pendant que son voisin lui four-
nit une couverture de détection (Yong-Sun et al., 2006). D’autres approches proposent
une nouvelle classe de services sans fil qui fonctionne à base de capteurs intelligents
(Tarannum, 2010). Les capteurs s’organisent entre eux pour former des éléments actifs
capables de coopérer pour mesurer, filtrer, partager et combiner les mesures du monde
réel. La coopération entre les capteurs permet de réduire la consommation d’énergie.
La quantité d’informations échangées augmente la consommation d’énergie du cap-
teur. Jacquot A. propose une nouvelle approche pour l’administration des réseaux de
capteurs sans fil, nommée LiveNCM (Jacquot, 2010). À travers cette approche, il a
réussi à réduire les échanges d’informations et préserver une autonomie maximale des
nœuds grâce à des méthodes de diagnostic indirect et grâce à des techniques basées
sur des estimateurs.

3.5.2. Topologie dynamique

Les RCSF sont caractérisés par une topologie dynamique, qui peut donc changer
au cours du temps. Un capteur doit connaître sa situation dans un réseau, et en cas de
changement de position, un autre nœud peut assurer la surveillance. Parmi les méth-
odes proposées pour résoudre ce problème de dynamicité, on peut citer la méthode
d’optimisation heuristique décentralisée (Iino et al., 2010). Elle permet d’augmenter
le taux de communication entre les capteurs dans une topologie dynamique. Une autre
748 TSI. Volume 33 – no 9-10/2014

approche a été discutée dans (Yu et al., 2006). Elle est basée sur une méthode de re-
groupement des capteurs en sous-ensembles puis sur l’attribution des chefs de groupe
(cluster-heads). Cette approche propose aussi des algorithmes pour minimiser le nom-
bre de chefs de groupe dans un réseau. Ces techniques de regroupement utilisent dif-
férents critères de priorité pour sélectionner les chefs de groupe afin d’assurer un fonc-
tionnent sans interruptions du réseau.

3.5.3. Tolérance aux fautes

La fiabilité des RCSF est liée à la résistance des réseaux aux erreurs qui peuvent
survenir pour diverses raisons telles que le mauvais fonctionnement du matériel, des
problèmes logiciels, ou les risques environnementaux. Lorsqu’un RCSF n’est pas pré-
paré à faire face à de telles situations, cela peut conduire parfois à des conséquences
graves dans le contexte d’applications critiques. Plusieurs techniques ont été pro-
posées pour la détection des erreurs dans un RCSF telles que :
– L’auto-diagnostic (Harte et al., 2005) : un capteur effectuera un auto-diagnostic
pour déterminer s’il existe un problème qui pourrait entraîner des dysfonctionnements
matériels.
– La détection groupée : Bhaskar et Sitharama (Bhaskar, Sitharama, 2004) ont
proposé une approche basée sur le principe des capteurs qui sont dans la même région
qui doivent obtenir les mêmes mesures, sauf pour les capteurs qui se trouvent sur les
limites de la zone. Une fois les mesures collectées, des calculs seront effectués pour
déterminer s’il y a un capteur défaillant dans le groupe.
– La détection hiérarchique : l’utilisation d’un arbre de détection est une solution
fiable pour la détection d’erreurs dans les RCSF (Paradis, Han, 2007). Dans (Rost,
Balakrishnan, 2006), les auteurs proposent que chaque nœud transmette le statut du
nœud enfant, suivi par celui du nœud parent jusqu’à la passerelle. Cette méthode per-
met la transmission du défaut d’un capteur suivant la topologie du réseau.

3.5.4. Qualité de service

Plusieurs types de données peuvent être échangés dans un RCSF. De plus, l’infor-
mation doit être acheminée dans un temps limité, et doit être identique à celle prélevée
au niveau du capteur. Certains paramètres tels que les messages de retard, les varia-
tions de délais, la bande passante, le débit et la latence (Wang et al., 2008) doivent
être considérés pour exprimer la qualité de service (QoS) dans un RCSF. Le protocole
SAR (sequential assignment routing) (Sohrabi et al., 2000) est le premier protocole
de routage qui prend en compte la QoS dans les RCSF. Ce protocole créé une ar-
borescence de capteurs ayant un chemin vers la passerelle. Il considère les ressources
énergétiques, les indicateurs de qualité de service et la priorité de chaque paquet à
transmettre. Il existe d’autres protocoles qui gèrent la QoS, parmi lesquels on peut
citer :
- SPEED (He et al., 2003), qui est un protocole de routage temps réel basé sur
un routage géographique avec QoS pour les RCSF. Il utilise une nouvelle technique
de re-routage qui prend en considération le mécanisme de contre-pression (Neely,
 Les bases de données dans les RCSF 749

Urgaonkar, 2009) pour éviter l’acheminement des paquets à travers les liens conges-
tionnés du réseau et la prise en charge des vides de routage.
- MMSPEED (Multi-Path Multi-Speed Protocol) (Emad et al., 2006), qui est une
extension de SPEED, pour améliorer les mécanismes de QoS dans les RCSF. Il fournit
deux paramètres de QoS : la ponctualité et la fiabilité dans l’acheminement des paquets
(Aissani, 2011). La ponctualité est garantie en prévoyant différents niveaux de vitesse
de livraison des paquets. La fiabilité est assurée par l’utilisation de chemins multiples
de routage.

3.5.5. Contraintes temps réel

Les applications critiques comme la surveillance dans une centrale nucléaire sont
considérées comme des applications temps réel dans un RCSF. Elles doivent fournir
des garanties de retard borné pour la transmission des données. Pour mettre en place
ce type d’applications, il faut prendre en compte deux problèmes : les retards de trans-
mission, et la coordination entre les capteurs et les actionneurs. SPEED (cf. 3.5.4)
supporte un service de communication temps-réel mou (soft), il garantit une vitesse
de livraison des paquets de manière à ce que le délai de bout en bout soit proportionnel
à la distance entre la source et la destination dans un RCSF. SPEED utilise un routage
basé sur les étapes suivantes (Nefzi, 2007) : (i) Quand un nœud reçoit un paquet, il
sélectionne ses voisins les plus proches de la destination, (ii) il divise ses nœuds en
deux groupes. Le premier groupe contient les nœuds qui ont une vitesse inférieure à
une certaine valeur fixée, et le second groupe avec une vitesse de relais supérieure à
cette valeur. Dans le cas où le groupe n’est pas construit, SPEED diminue la valeur
fixée pour trouver un nœud relais pour la transmission. Cette valeur dépend de la taille
du paquet, de la bande passante et de la couverture radio. La vitesse entre un nœud i
et un nœud j est calculée comme suit :

distance(i,j)
V itesse(i,j) =
délai d0 envoi(i,j)

(iii) Le candidat pour la transmission est choisi parmi les capteurs du premier groupe
selon un choix probabiliste (He et al., 2002).

4. Gestion des données dans les réseaux de capteurs

4.1. Collecte des données

La collecte des données est une opération basique dans les RCSF. Elle consiste
à transmettre les données prélevées par des capteurs vers une station de base. Les
données sont collectées suivant un protocole de routage de type « convergecast »
(Annamalai et al., 2003) : les nœuds forment un arbre de recouvrement et transmet-
tent leurs données vers la racine (station de base). Généralement, la collecte des don-
nées peut être déclenchée par des requêtes (à la demande de l’utilisateur) pour avoir
750 TSI. Volume 33 – no 9-10/2014

des informations sur le réseau. Elle peut également être déclenchée périodiquement
pour surveiller une zone géographique, comme elle peut être déclenchée par l’appari-
tion d’un événement. Les données collectées au niveau de la station de base peuvent
être traitées immédiatement pour répondre aux besoins de l’utilisateur. Elles peuvent
être également stockées dans une base de données pour être analysées par la suite
(Incel et al., 2011). On distingue deux types de collecte de données : (i) les données
collectées et transmises individuellement vers la station de base lorsque les mesures
sont importantes, (ii) l’agrégation de données, définie comme le processus de fusion
de données provenant de plusieurs capteurs au niveau des nœuds intermédiaires afin
d’éliminer les transmissions redondantes et réduire la quantité de données transmises à
travers le réseau (Ozdemir, Xiao, 2009). L’agrégation de données cherche à collecter
les données les plus critiques des capteurs et les transmettre à la station de base de
manière efficace, i.e. avec une latence minimale et une faible consommation d’énergie
(Rajagopalan, Varshney, 2006).

4.2. Traitement de requêtes

Dans les RCSF, les requêtes représentent des demandes d’une station de base aux
capteurs pour envoyer leurs données prélevées (Rahman, Hussain, 2007). Ils peuvent
être classés en fonction de critères tels que la fréquence des réponses qui peut être
périodique, à la demande, etc. ou la quantité de données, ou les événements ou la
durée de vie (Jun Zheng, 2009).

4.2.1. Fréquence des réponses aux requêtes

– Requêtes périodiques : elles consistent à interroger périodiquement un ou
plusieurs capteurs selon un intervalle de temps fixé par l’utilisateur pour, par exemple,
surveiller une zone géographique. Ce type de requête peut être lancé depuis un instant
donné jusqu’à un temps logique infini (Jun Zheng, 2009).
– Requêtes historiques : elles sont utilisées pour interroger des données his-
toriques stockées dans une station de base ou dans n’importe quel nœud du réseau.
Cependant, les capteurs ayant une capacité de stockage limitée, la plupart des données
sont stockées dans des bases données distantes.
– Requêtes instantanées : elles consistent à interroger un ou plusieurs capteurs à
un instant donné une seule fois, pour donner une vue instantanée à l’utilisateur sur une
zone du réseau.

4.2.2. Quantité de donnée

– Requêtes de sélection : elles permettent l’extraction de toutes les données de
capteurs qui satisfont les conditions de la clause "<WHERE>" dans une requête d’in-
terrogation "SELECT". Ces requêtes sont efficaces pour extraire des mesures sélec-
tives de certains capteurs, par exemple, la requête "SELECT temperature, humidity
FROM sensors WHERE location in Region and sensor_ID=123", signifie qu’on de-
mande la valeur de la température et de l’humidité à extraire depuis des capteurs lo-
calisés dans une région où l’identificateur du capteur est 123.
 Les bases de données dans les RCSF 751

– Requêtes d’agrégation : ces requêtes sont appliquées quand les capteurs doivent
envoyer une grande quantité de données à travers le réseau. Elles permettent d’éviter
la redondance d’informations provenant de plusieurs sources. Elles utilisent des fonc-
tions telles que MIN, MAX, SUM, COUNT et AVG pour manipuler ces données.

4.2.3. Événements et durée de vie

– Requêtes basées sur des événements : ces requêtes sont déclenchées dès qu’un
événement remplit les conditions de la requête. Par exemple, dans le cas d’un incendie,
si la température atteint un degré supérieur à 100, les capteurs envoient des nouvelles
mesures de température toutes les 5 secondes. On écrit alors la requête : "ON EVENT
temperature > 100 SELECT nodeid, temperature FROM sensors EVERY 5 seconds".
Ces requêtes peuvent réduire considérablement la quantité d’énergie utilisée dans le
réseau.
– Requêtes basées sur la durée : ces requêtes sont définies pour fixer une durée
de vie pour les requêtes à longue durée d’exécution, car ces dernières n’ont pas de
limite pour leur temps d’exécution. Les systèmes de traitement de requêtes TinyDB
et Cougar implémentent ce type de requêtes. TinyDB utilise la clause "LIFETIME
<valeur>" et Cougar utilise la clause "DURATION" et la clause "EVERY" pour définir
la durée de vie de la requête.

4.2.4. Précision des réponses

– Requêtes de précision : elles sont moins fréquentes, mais utiles pour les appli-
cations critiques telles que la surveillance dans les systèmes de santé. Elles expriment
le besoin d’extraire des données précises de capteurs et supposent une communication
fiable pour assurer une livraison de données précises.
– Requêtes approximatives : elles reflètent la tolérance de l’erreur sur la donnée
en intégrant un seuil d’erreur (souvent suivi d’un seuil de confiance). Par exemple, la
requête suivante : "SELECT nodeid, temperature FROM sensors ERROR 2 CONFI-
DENCE 95 %", qui indique que la différence entre la valeur de l’erreur déclarée par
chaque capteur, c.à.d. la valeur absolue de la quantité (valeur réelle - valeur détectée),
doit être délimitée par un seuil d’erreur égal à 2, avec un seuil de confiance de 95 %.
La tolérance d’une certaine marge d’erreur peut réduire considérablement l’énergie
dépensée dans la propagation du résultat (Trigoni et al., 2007).

4.2.5. Nature de la recherche

– Requêtes spatiales : elles cherchent la valeur d’un attribut produit dans un em-
placement. Par exemple, la requête "SELECT temperature FROM sensor WHERE
location = (50,60)", cherche la température d’un capteur situé dans un point du plan
de coordonnées (50,60).
– Requêtes temporelles : elles cherchent la valeur d’un attribut produit à une cer-
taine date. Par exemple, la requête "SELECT temperature FROM sensor WHERE date
= ’12/12/2012’", recherche la temperature de chaque capteur à la date du ’12/12/2012’.
752 TSI. Volume 33 – no 9-10/2014

– Requêtes spatio-temporelles : elles cherchent la valeur d’un attribut produit à

une date et dans un emplacement donnés. Par exemple, la requête "SELECT temper-
ature FROM sensor WHERE date = ’12/12/2012’ and location = (50,60)", recherche
la température d’un capteur localisé en (50,60), à la date du ’12/12/2012’.

4.2.6. Phase de diffusion

Une fois que l’utilisateur a formulé sa requête, il la transmet à la station de base qui
la diffuse dans le RCSF. Il existe deux sortes de diffusion de requêtes : la première est
une diffusion pour tous les nœuds du réseau et la deuxième est une diffusion sélective
pour les nœuds qui contribuent au résultat de la requête.

4.3. Phase de collecte de réponses

Chaque capteur reçoit la requête de la station de base, il commence à générer les

réponses. La réponse à la requête n’est pas immédiate. Parfois le traitement d’une re-
quête est reparti sur plusieurs nœuds (cf. figure 4). Un nœud peut appeler des nœuds
fils pour générer une partie du résultat qui sera transmise par la suite à la station de
base. Cependant, la transmission des résultats et la communication entre les nœuds
Fils
Res
ult
ats
Resultats

Fils capteur Parent

s
u ltat
Res

Figure 4. Traitement des données et propagation des résultats

nécessitent beaucoup d’énergie. Cela signifie qu’un traitement local des données au
niveau de nœuds est nécessaire pour réduire la consommation énergétique dans le
réseau. Plusieurs techniques ont été proposées, telles que l’agrégation, l’approxima-
tion (Considine et al., 2004) et la compression (Hoeller et al., 2010) des données.
Les performances d’un système de traitement de requêtes dans un RCSF sont prin-
cipalement liées au protocole de routage utilisé. Ce protocole est responsable de la
diffusion et de la collecte des réponses aux requêtes diffusées (Krishnakumar, 2010).
Un protocole de routage intelligent au niveau de la couche réseau offre un mécanisme
efficace de sélection d’itinéraires et réduit le nombre de transmissions de données. La
réduction de la quantité de données échangées minimise la consommation d’énergie
dans le réseau (Jacquot, 2010). L’intégration de la couche de traitement des requêtes
à la couche réseau conduit à une gestion intelligente des ressources pour fournir une
qualité de service qui satisfait les besoins de l’utilisateur.

4.4. Stockage de données

On distingue également deux approches de stockage de données dans les RCSF.

 Les bases de données dans les RCSF 753

4.4.1. Approche entreposage

L’approche entreposage est basée sur un système centralisé. Les données collectées
depuis un réseau de capteurs sont envoyées vers une base de données centralisée. Le
traitement des données est effectué au niveau de cette base pour répondre aux requêtes
des utilisateurs. Dans cette approche, le traitement des requêtes et l’accès au réseau de
capteurs sont séparés (Bonnet et al., 2001). L’approche entreposage est bien adaptée
pour répondre à des requêtes prédéfinies sur des données historiques. Les limites de
cette approche résident dans le fait qu’elle génère un grand nombre de données qui
peut créer un goulot d’étranglement sur le serveur central. De plus, la transmission
sans fil de données nécessite plus d’énergie que les traitements. Selon une étude faite
par Hill et al. (Hill et al., 2000), la transmission d’un bit dans les réseaux de capteurs
consomme l’équivalant de l’exécution de 800 à 1 000 instructions.

4.4.2. Approche distribuée

Dans cette approche, les données sont stockées dans un serveur de base de don-
nées et dans les capteurs eux-mêmes, qui seront alors considérés comme des bases de
données. Généralement, le système de base de données construit un plan d’exécution
pour le traitement des requêtes (Bonnet, Seshadri, 2000). Dans un contexte distribué,
le plan d’exécution est reparti sur plusieurs sites. La charge de travail des requêtes
détermine les données qui doivent être extraites des sites distants. En effet, les re-
quêtes de longue durée engendrent un long temps de réponse. De ce fait, seules les
données pertinentes sont extraites à partir du réseau de capteurs (Bonnet et al., 2001),
permettant ainsi de minimiser le nombre de transferts de données entre les capteurs
et mieux exploiter leurs capacités de calcul. Pour minimiser les transferts, il arrive
également que l’on n’extrait que certaines données agrégées (par exemple la moyenne
des températures dans un voisinage). Cependant, les bases de données distribuées tra-
ditionnelles ne sont pas adaptées pour les réseaux de capteurs à grande échelle. De
plus, la conception de l’approche distribuée suppose que la distribution globale des
métadonnées est bien définie et que la topologie du réseau est bien maintenue (Sarkar,
2012).
Des méthodes d’indexation sont également proposées pour bien gérer les données
issues d’un réseau de capteurs en temps réel. Par exemple, la méthode PoTree pro-
posée dans (Noël, Servigne, 2004), la méthode PasTree proposée dans (Noël, 2006),
et la méthode StH proposée dans (Servigne, Noël, 2008). Ces méthodes consistent
à indexer les bases de données spatio-temporelles en mémoire vive (Noël, Servigne,
2005). Le modèle PoTree consiste à utiliser des arbres pour structurer les données.
Cette méthode permet de réduire la taille de la structure de données et facilite sa
mise à jour. Le modèle PasTree est une amélioration du modèle PoTree. Il supporte le
phénomène d’agilité des capteurs et est présenté sous la forme d’un arbre d’indexation
permettant l’accès aux données par le biais des identifiants des capteurs. Elle contient
une couche d’abstraction pour différencier les données collectées des données concer-
nant le changement de position des capteurs.
754 TSI. Volume 33 – no 9-10/2014

Enfin, le modèle STH (spatio temporal / heat) est basé sur le même principe que
PasTree, mais il est dédié en plus pour la gestion de la saturation de la mémoire de la
base de donnée.

5. Systèmes de gestion des données dans les RCSF

Les réseaux de capteurs peuvent être considérés comme des bases de données
distribuées (Akyildiz, Vuran, 2010), où les données sont générées en flux continu.
L’ensemble de données perçu forme une grande base de données répartie, qui né-
cessite un système de gestion des données (SGD) pour les maintenir. Les SGD pour
RCSF sont vus aussi comme des bases de données distribuées puisqu’ils gèrent toutes
les données du réseau. Ils assurent une séparation entre le modèle logique des données
(l’accès, l’exploitation et la mise à jour) géré par le réseau et la mise en œuvre effec-
tive de ces opérations sur le réseau. L’utilisateur peut interroger les capteurs à travers
des requêtes, sans avoir par avance une idée sur la topologie du réseau.

5.1. Les bases de données de capteurs et les bases de données traditionnelles

Les SGD pour RCSF sont différents des systèmes de bases de données distribuées
traditionnels (SBDDT) :
– Le traitement des données dans les RCSF est fortement lié à l’environnement
du réseau. Cet environnement est composé d’un ensemble de capteurs caractérisés par
un espace de stockage et une capacité de calcul limités et une faible autonomie. Au
contraire, les SBDDT ne dépendent pas du réseau. Ils ne sont que des applications
installés sur des machines performantes.
– Les bases de données traditionnelles peuvent contenir des données statiques i.e.
des données qui ne sont que rarement modifiées. Les données historiques qui stockent
les dernières mises à jour sur les données peuvent aussi être considérées comme des
données statiques.
Par contre, les SGD pour RCSF utilisent de données dynamiques (flux continu de
données) et les réponses aux requêtes sont approximatives.
– Les techniques de traitement de requêtes dans les SBDDT ne s’adaptent pas aux
RCSF :
a) Les SBDDT utilisent des fonctions de verrouillage sur les données lorsque
des erreurs se produisent. Ces fonctions ne conviennent pas aux flux de données con-
tinues et aux requêtes de longue durée.
b) Les techniques d’optimisation de requêtes dans les SBDDT sont basées sur
des modèles à coût fixe et sur des informations statiques. Les SGD pour RCSF utilisent
un plan de requête basé sur le coût de consommation d’énergie et sur des données
dynamiques.
– Les SGD pour RCSF ont des opérateurs supplémentaires pour fixer la durée de
vie et le cycle d’exécution d’une requête.
 Les bases de données dans les RCSF 755

– Les tables d’une base de données traditionnelle sont stockées sous forme de
fichiers sur une unité de stockage. Les tables dans un réseau de capteurs sont des
tables virtuelles, qui représentent des vues relationnelles générées par le réseau de
capteurs (Govindan et al., 2002).

5.2. Les données de capteurs

Les bases de données de capteurs contiennent deux types de données : des données
dites statiques, qui sont relatives aux caractéristiques des capteurs telles que son type,
sa capacité de stockage, sa puissance d’émission, etc., et des données collectées sur
les caractéristiques physiques de l’environnement telles que la température, l’humid-
ité, la lumière, etc. Ces données sont enregistrées sous forme de relations (tables) pour
faciliter la formulation de requêtes. Bonnet et al. ont choisi de représenter les données
de capteurs comme des séries chronologiques avec les propriétés suivantes (Bonnet
et al., 2001) : (i) l’ensemble des données enregistrées sont des valeurs qui représen-
tent les sorties des fonctions de traitement du signal, (ii) toutes les valeurs de sortie
sont générées au cours d’un quantum de temps et associées à une position. La série de
données doit être mise à jour avec la position correspondante, durant le temps de pro-
duction. Le modèle de données dans les bases de données de capteurs est inspiré des
modèles de bases de données traditionnelles pour faciliter l’utilisation des données de
capteurs. Parmi les bases de données de capteurs, on peut citer : Cougar (Yao, Gehrke,
2002), Antelope (Adam, Tsiftes, 2011) et TinyDB (Madden, Hellerstein, Hong, 2003),
que nous allons décrire dans la section 6.

5.3. Les défis dans les bases de données de capteurs

Les performances des bases de données de capteurs sont directement liées au bon
fonctionnement du système d’exploitation, et aux capacités des capteurs utilisés. Le
rôle essentiel du système d’exploitation est d’abstraire l’acquisition des mesures et
de faciliter la transmission des données (Labbé, 2010). Dans les bases de données
traditionnelles, le temps de réponse moyen des transactions est la métrique principale
de mesure de performance des SGBD. Dans les bases de données de capteurs, Bonnet
et al. proposent de nouvelles métriques comme la quantité totale d’énergie consommée
par les capteurs lors de l’exécution d’une requête (car les capteurs sont généralement
alimentés par des batteries) et le temps de réaction qui représente l’intervalle entre le
moment d’envoi de la valeur et le moment de sa réception.
En général, les capteurs ne peuvent pas générer des requêtes sur les données détec-
tées. Ils ne font que de l’acquisition de données, un traitement simple sur ces données
(conversion de format, etc.) et reçoivent l’ensemble des requêtes à traiter. Chaque cap-
teur doit être capable de planifier ses tâches pour satisfaire toutes les demandes. L’ac-
cès aux données peut être entravé par des retards, qui peuvent dépendre de la vitesse
à laquelle ces données sont arrivées. Une des solutions apportées à ce problème est
la réduction de la quantité de données au niveau des nœuds en utilisant des fonctions
d’agrégation (Feng Zhao, 2004), qui consistent à envoyer une seule valeur agrégée
756 TSI. Volume 33 – no 9-10/2014

depuis plusieurs capteurs, réduisant ainsi le nombre de communications et diminuant

donc la quantitée d’énergie consommée.
Les bases de données de capteurs sont dynamiques car leurs contenus évoluent au
cours du temps par les mises à jour périodiques des nouvelles valeurs prélevées depuis
l’environnement concerné (Feng Zhao, 2004). Certaines opérations de ré-organisation,
comme le tri, ne sont pas adaptées à la gestion des flux continus de données.
La nature dynamique du réseau de capteurs dégrade les performances des bases
de données de capteurs. En effet, les réseaux de capteurs construisent un arbre cou-
vrant pour le traitement des requêtes, dont la racine est la station de base (Nath et al.,
2004). Cependant, la structure d’arbre couvrant n’est pas robuste et est sensible aux
coupures de communication (Gobriel et al., 2006) qui conduisent à des pertes de don-
nées. Da Silva et al. ont étudié d’autres mécanismes de traitement de requêtes, plus
précisément les requêtes spatiales (Da Silva et al., 2014). Dans la littérature, il ex-
iste deux mécanismes de traitement de ce type de requêtes : l’approche de traitement
par fenêtre (window query) et l’approche K-plus proches voisins, en anglais KNN (k-
nearest Neighbor query). L’analyse des mécanismes de traitement des requêtes par
fenêtre a montré que le mécanisme IWQE (itinerary based window query execution),
basé sur les itinéraires et sans structure technique, a donné les meilleurs résultats par
rapport aux autres mécanismes structurés (georouting tree, SPIX) et non structurés
(irregular shapes, SWIP). Il a été montré que l’approche IWQE donne des résultats
efficaces en termes de consommation d’énergie, de précision des résultats de requêtes
et de traitement des requêtes de longue durée (Kang et al., 2012). Les expériences sur
les mécanismes de traitement des requêtes KNN ont montré que les stratégies paral-
lèles telles que DIKNN, IKNN, PCIKNN présentent les meilleures performances en
consommation d’énergie, en latence des requêtes et en précision. L’approche PCIKNN
présente les meilleurs résultats (Fu et al., 2007). Elle permet aux requêtes KNN de se
propager dans des itinéraires bien conçus qui répondent aux exigences spécifiques des
applications telles que l’efficacité énergétique et le temps de réponse.
La capacité de stockage des capteurs étant limitée et comme le système de bases
de données qu’ils forment doit maintenir un historique, il est nécessaire de nettoyer la
base de données au fur et à mesure de l’acquisition des mesures.

5.4. Modèle de données de bases de données de capteurs

Les réseaux de capteurs sont considérés comme des modèles de données relation-
nelles. Le modèle de données proposé par (Govindan et al., 2002), est composé d’un
ensemble des capteurs, dont chacun produit un ou plusieurs tuples de données, appelé
source (ou table relationnelle). Les tables, dans les bases de données classiques, sont
généralement stockées sur disque. Les tables dans le contexte des réseaux de capteurs
sont virtuelles et représentent des vues générées par le réseau de capteurs. Les accès
à ces tables virtuelles sont des opérations de collecte des données pertinentes perçues
par les capteurs. La conception d’une base de données de capteurs doit assurer une
abstraction complète du réseau car l’utilisateur n’est pas sensé connaître la topologie
 Les bases de données dans les RCSF 757

réelle du réseau. Les bases de données partagent la même terminologie que les bases
de données classiques, sauf pour la source de données (cf. tableau 1) (Govindan et al.,
2002).
Tableau 1. Terminologie des bases de données de capteurs
Terme Description
Modèle de données Un modèle qui décrit de façon abstraite la représentation sé-
mantique des données
Un tuple Un groupe de données composé de plusieurs valeurs d’at-
tributs relatifs à un objet
Une source Le capteur qui génère un tuple
Une table Une collection de tuples de même type
Un opérateur Une fonction qui prend une ou plusieurs tables en entrée et
génère une table en sortie
Une requête Une composition d’opérateurs

5.5. Les opérateurs

Les bases de données de capteurs partagent les mêmes opérateurs que les bases
de données relationnelles. Les opérateurs traditionnels des bases de données tels que
l’agrégation, le regroupement, la sélection et les jointures, sont adaptés au contexte des
réseaux de capteurs. Le résultat de l’un de ces opérateurs est une table relationnelle,
qui peut servir comme entrée à d’autres opérateurs.
L’agrégation de données est une opération effectuée pour éviter la transmission
d’informations redondantes et pour améliorer la durée de vie du réseau (Sivaranjani et
al., 2013). Généralement, les opérations d’agrégation utilisent un ensemble de fonc-
tions pour calculer la somme (SUM), la moyenne (AVERAGE) ou le minimum, et
maximum (MIN, MAX). Exemple « Quelle est la température moyenne retournée par
l’ensemble des capteurs au troisième étage », traduit par la requête suivante avec la
syntaxe de TinyDB : SELECT AVG(temperature) FROM sensors WHERE floor=3.
L’opération de jointure permet de réunir plusieurs tables qui satisfont le critère de join-
ture. Elle consiste à générer toutes les paires de tuples, puis à faire une itération de tous
les tuples qui satisfont le prédicat de sélection. Il existe d’autres opérateurs relationnels
tels que le regroupement (GROUP BY), la sélection (SELECT), la projection, l’union
(UNION), la différence (EXCEPT) et l’élimination des doublons (DISTINCT).

6. Approches bases de données de capteurs

6.1. Le système COUGAR

6.1.1. Présentation
Le projet COUGAR (Yao, Gehrke, 2002) a été réalisé à l’Université Cornell (USA).
Il présente une infrastructure dédiée à la gestion de données de capteurs. COUGAR
758 TSI. Volume 33 – no 9-10/2014

est basé sur des capteurs pré-programmés et sur une entité centrale à laquelle les don-
nées sont agrégées et stockées pour tester des techniques de traitement des requêtes
sur les réseaux de capteurs sans fil (Fung et al., 2002). COUGAR considère le réseau
de capteurs comme une grande base de données distribuée où les données sont assim-
ilées à une table relationnelle. Les attributs de cette table sont les attributs des capteurs
et les valeurs sont les mesures. Les nœuds sont organisés en groupes « clusters », dont
chacun possède un chef de cluster, qui joue le rôle d’un point d’agrégation de données
(Makhoul, 2008).

6.1.2. Architecture
A. Le proxy Requête
Il s’agit d’une petite application associée à chaque capteur, entre sa couche réseau
et sa couche application, pour interpréter et exécuter les requêtes échangées entre le
capteur et la station de base (Jun Zheng, 2009). Le proxy Requête est responsable des
communications entre les trois éléments : les capteurs, la station de base et les requêtes
utilisateur (cf. figure 5). Il regroupe et élimine les données non pertinentes.

B. Le composant Frontal
Il joue le rôle de passerelle entre l’interface graphique et le réseau de capteurs
(cf. figure 5). Il exécute les tâches suivantes : (i) il envoie les requêtes qu’il reçoit
de l’interface graphique vers le proxy requête qui les traite, (ii) il reçoit les résultats
des chefs de clusters, en gardant une trace des requêtes en cours d’exécution pour
l’interface graphique, (iii) il fournit les tuples nécessaires aux requêtes, et il envoie
par la suite les résultats à l’interface utilisateur. Il peut émettre aussi des tuples de
données vers une base de données MySQL installée sur un serveur central.

C. L’interface graphique
Elle permet à l’utilisateur d’interroger le réseau de capteurs via des requêtes qui lui
permettent de visualiser la topologie du réseau (cf. figure 5). Les résultats des requêtes
sont affichés à l’utilisateur sous forme d’un tableau.

6.1.3. Agrégation des données

COUGAR regroupe les capteurs sous forme de clusters. L’agrégation de données
permet d’économiser l’énergie et de réduire le flux de communication entre les nœuds.
Chaque nœud contient une liste de tous les nœuds à qui il doit envoyer les données.
Le nœud responsable de l’agrégation des données demande les tuples nécessaires au
gestionnaire de périphériques, qui lui transmet les mesures provenant des capteurs. Le
nœud agrégat combine les données locales avec les données agrégées partiellement,
reçues par d’autres capteurs. Ensuite, il envoie le résultat au chef de cluster qui calcule
la moyenne des résultats agrégés et les compare à un seuil défini par l’utilisateur. Si la
moyenne calculée est supérieure au seuil, alors le chef de cluster envoie les résultats à
la passerelle (Frontal), qui seront présentés par la suite à l’utilisateur sous forme d’un
tableau.
 Les bases de données dans les RCSF 759

Résultats de requêtes (Tuples) pour ClusterLeader

Résultats de requêtes (Tuples) pour FrontEnd

start/stop tuples
Messages Expédition requêtes Tuples
Couche File d'attente Gestion de requêtes
Processeur leader
réseau Leader requêtes

start/stop tuples
Messages requêtes Tuples
dirigée ] File d'attente Expédition Gestion de
requêtes
Processeur leader requêtes
Leader

Données Capteurs

Gestionnaire de
périphériques

capteur capteur capteur

GPS acoustique
Les capteurs sismique pir
Proxy requête

Composant frontal start/stop requêtes

TCP/IP Messages Connection Database

Couche GUI Couche
réseau réseau
start/stop JAVA GUI
dirigée ds messages requêtes [TCP/IP ]
dirigée
TCP/IP] Tuples
Gestion de requêtes
requêtes

Tuples
Tuples (pour GUI)
Interface graphique

Figure 5. Architecture du système cougar

6.1.4. Langage de requête

COUGAR utilise un langage de requête de type quasi-SQL (SQL-Like). Ce lan-

gage assure la continuité des requêtes pour fournir des résultats à l’utilisateur. Le
canevas de requête suivant illustre la grammaire de ce langage.

SELECT temp FROM [Sensordata]

[ WHERE predicate ]
[ GROUP BY attributes ]
[ HAVING predicate ]
DURATION time-interval
EVERY time-span

Dans cet exemple, les clauses WHERE, SELECT, GROUP BY et HAVING ont la
même signification que dans SQL standard, c’est-à-dire : la clause SELECT permet de
récupérer les données, la clause WHERE permet de filtrer les n-uplets en imposant une
condition à remplir, la clause GROUP BY regroupe les capteurs selon leurs attributs
et la clause HAVING agit comme le filtre WHERE, mais sur les opérations résultant
des regroupements. Les clauses DURATION et EVERY sont spécifiques au langage
SQL de COUGAR. Ainsi, la clause DURATION spécifie la durée de vie de la requête
et la clause EVERY détermine le cycle d’exécution de la requête.
760 TSI. Volume 33 – no 9-10/2014

6.1.5. COUGAR et l’abstraction de données

COUGAR (Fung et al., 2002) définit un capteur en tant qu’objet de type abstrait,
ADT (Abstract Data Type) pour tous les capteurs de même type. Les bases de données
objets-relationnelles supportent les données de type abstrait. En effet, un objet ADT
dans une base de données de capteurs correspond à un capteur physique dans le monde
réel (Bonnet et al., 2001). L’interface publique d’un capteur correspond aux fonctions
spécifiques de traitements du signal. L’abstraction permet à l’utilisateur de ne pas
connaître la topologie du réseau de capteurs, la manière de collecter et de traiter les
données et la façon d’envoyer les résultats.

6.2. Le système TinyDB

TinyDB est un système d’exécution de requêtes sur un réseau de capteurs, intégré

au système d’exploitation TinyOS (Mazzer, Tourancheau, 2008). Il a été développé par
l’université de Californie. Il s’agit d’un système de gestion de bases de données destiné
à l’extraction d’informations à partir d’un réseau de capteurs ayant des ressources
limitées (Madden, Franklin et al., 2003). TinyDB collecte les données de capteurs, les
filtre et les agrège, et les achemine vers un serveur central. TinyDB possède plusieurs
caractéristiques (Y. Li et al., 2008) :
– Il fournit un catalogue de métadonnées pour décrire les attributs d’un réseau de
capteurs, y compris les types de données, les paramètres logiciels et matériels, etc. Il
fournit aussi un grand nombre de commandes pour gérer les métadonnées.
– Il utilise un langage de requêtes déclaratives de type SQL, qui permet aux util-
isateurs de décrire les données, sans connaître la façon dont les données sont traitées.
Ceci facilite la création des applications et garantit la continuité d’exécution des re-
quêtes.
– Il maintient les tables de routage dans le réseau pour s’assurer que tous les cap-
teurs peuvent livrer leurs données aux utilisateurs.
– Il permet l’exécution de plusieurs requêtes sur les mêmes capteurs et équilibre le
travail entre les requêtes, ce qui augmente leur vitesse et l’efficacité de leur traitement.

6.2.1. Architecture
Dans l’utilisation de TinyDB, on distingue trois parties (cf. figure 6) : l’utilisa-
teur, le serveur et le réseau de capteurs. L’utilisateur peut se connecter au réseau à
travers la station de base via un port série et les capteurs peuvent communiquer entre
eux à travers le réseau sans fil. La machine de l’utilisateur doit contenir l’application
TinyDB, pour gérer les requêtes utilisateur. Elle les analyse, les décompose, puis les
envoie aux nœuds du réseau à travers la station de base. Dès qu’elle reçoit les résultats
des requêtes, elle les transmet à l’utilisateur.
Le système TinyDB possède deux sous-systèmes : une application pour les réseaux
de capteurs et une interface graphique en java pour utilisateur. L’application TinyDB
s’exécute sur chaque capteur. Elle est composée des parties suivantes :
 Les bases de données dans les RCSF 761

1. Un catalogue et un gestionnaire de schéma : pour le suivi de l’ensemble des

attributs, ou des types de lectures (lumière, température, humidité), ou les propriétés
du capteur tel que son identifiant. Le schéma du capteur décrit sa capacité à contenir
des attributs comme une table virtuelle.
2. Un processeur de requêtes : le processeur de requêtes utilise le catalogue du
capteur pour extraire les valeurs des attributs locaux, recevoir les lectures de capteurs
voisins, agréger l’ensemble des données les filtrer et les acheminer vers les nœuds
parents.
3. Un gestionnaire de mémoire : TinyDB peut gérer l’espace mémoire d’une
manière dynamique et stocker les données de façon compacte pour économiser l’es-
pace de stockage.
4. Un gestionnaire de topologie réseau : TinyDB gère de manière efficace la con-
nectivité des nœuds. Il maintient les tables de routage et veille à ce que les données et
les résultats des requêtes soient bien acheminés à travers le réseau.
TinyDB possède deux types d’interface client (Madden, Hellerstein, Hong, 2003). Une
interface basée sur un langage de requête SQL, appelé TinySQL, et une autre interface
graphique constituée d’un ensemble d’applications et de classes Java.

Les applications capteurs

API TinyDB Client

Serveur TinyDB SGBD

Données Requêtes

TinyDB

Les capteurs

Figure 6. L’architecture de TinyDB (J. Li et al., 2008)

6.2.2. Langage de requête

TinyDB fournit un langage déclaratif simple (TinySQL) et une interface « SQL-

like » pour la collecte et l’agrégation de données (Madden et al., 2005). Le langage
de requêtes TinySQL comprend la sélection, la projection, la détermination du taux
d’échantillonnage, l’agrégation, les déclencheurs, la durée de vie d’une requête, la
mise à jour et les jointures simples (Patil, Patil, 2011). La grammaire du langage de
requêtes TinySQL est la suivante :
762 TSI. Volume 33 – no 9-10/2014

SELECT select-list [FROM sensors]

WHERE predicate
[GROUP BY gb-list]
[HAVING predicate]
[TRIGGER ACTION command-name[(param)]]
[EPOCH DURATION time]

Dans ce canevas de requêtes, les clauses WHERE, GROUP BY et HAVING ont les
mêmes significations que pour SQL standard. Les clauses TRIGGER ACTION et
EPOCH DURATION sont spécifiques au langage TinySQL.
TinyDB comprend un service pour le déclencheur (Madden, Hellerstein, Hong,
2003). Une action de déclenchement est exécutée lorsque le résultat satisfait la clause
WHERE de la requête. La requête suivante illustre ce propos :

SELECT temp FROM sensors

WHERE temp > thresh
TRIGGER ACTION SetSnd(512)
EPOCH DURATION 512

Cette requête correspond à une alarme déclenchée à chaque fois que la température
dépasse un seuil fixé par l’utilisateur. SetSnd(512) indique que la durée sonore de
l’alarme est de 512 ms.

6.2.3. Agrégation de données

TinyDB possède un mécanisme d’agrégation qui permet de combiner les messages

du réseau, ce qui réduit le nombre de messages à envoyer. Il utilise aussi un système de
gestion de métadonnées qui prend en charge les optimisations de l’agrégation. Le mé-
canisme d’agrégation est représenté par une structure arborescente (Makhoul, 2008),
où la racine est une station de base et les feuilles de l’arbre constituent tous les nœuds
du réseau de capteurs. Le canevas ci-dessous présente une requête d’agrégation (Patil,
Patil, 2011). Cette requête retourne les identifiants de nœuds, leurs luminosités et tem-
pératures moyennes lorsque la mesure de la lumière est inférieure ou égale à 100
Kelvin, pour une période de cinq minutes.

SELECT idCluster, AVG(light), AVG(temp)

FROM sensors
WHERE light<=100
GROUP BY idCluster
EPOCH DURATION 5min
 Les bases de données dans les RCSF 763

6.2.4. Les faiblesses de TinyDB

L’implémentation actuelle de TinyDB souffre de quelques faiblesses : (i) il subsiste

des erreurs relatives aux fonctions d’agrégation : elles retournent les mêmes valeurs
pour différentes requêtes agrégées, (ii) il manque des fonctions de filtrage : la clause
HAVING n’est pas implémentée dans le langage de requêtes, (iii) il existe une perte
considérable de messages dans le réseau (Kofoed, 2007). Bien que TinyDB puisse
stocker les résultats des requêtes dans une base de données PostgreSQL, cette option
ne fonctionne que pour les requêtes non agrégées.

6.3. Le système TinyQP

TinyQP est une application de traitement de requêtes comme TinyDB, basée sur
TinyOS, installée sur chaque capteur dans le réseau. Elle fournit un traitement pour
plusieurs requêtes complexes, y compris les requêtes en temps réel, les requêtes his-
toriques et les requêtes agrégées (Mo et al., 2013). TinyQP est composée de deux
sous-systèmes (cf. figure 7) :
1. Un sous-système web composé : (i) d’une interface graphique pour person-
naliser et afficher les résultats des requêtes utilisateur, (ii) un optimiseur de requêtes
pour analyser et formuler les requêtes, (iii) un port de communication en série pour
transmettre les requêtes utilisateur à la station de base et recevoir les réponses aux
requêtes.
2. Une sous-système de traitement de requêtes qui assure : (i) la transmission des
requêtes à la station de base, le parçage des requêtes SQL, la diffusion des requêtes à
tous les nœuds, la collecte des réponses aux requêtes et la transmission des données
au serveur d’application.

Figure 7. L’architecture de TinyQP (Mo et al., 2013)

764 TSI. Volume 33 – no 9-10/2014

6.4. Le système Antelope

Antelope est un système de gestion de bases de données spécifique aux réseaux

de capteurs à ressources limitées. Il fonctionne au-dessus du système d’exploitation
Contiki (Adam, Tsiftes, 2011). Il propose un stockage des données dans le capteur
lui-même, et fournit un ensemble d’opérateurs relationnels permettant la création dy-
namique et l’interrogation des bases de données. Antelope met en œuvre une abstrac-
tion du stockage en utilisant un système de fichiers, appelé Coffee (Tsiftes et al.,
2009), qui permet de réduire la complexité des systèmes de stockage.

6.4.1. Architecture d’Antelope

Antelope est composé de huit éléments (cf. figure 8) :
1. Un processeur basé sur le langage AQL (Antelope Query Langage) (Adam,
Tsiftes, 2011) pour l’analyse des requêtes.
2. Un contrôleur de confidentialité pour vérifier que les requêtes sont autorisées.
3. Un noyau qui contient la logique de la base de données et les coordonnées de
l’exécution des requêtes.
4. Une machine virtuelle pour exécuter les requêtes.
5. L’indice abstrait qui contient la logique d’indexation.
6. Le processus d’indexation pour construire des index à partir des données exis-
tantes.
7. L’abstraction des ressources de stockage à travers le système de fichier Coffee,
qui permet des opérations sur des fichiers stockés sur une mémoire flash externe.
8. Le transformateur de résultats pour améliorer leur présentation à l’utilisateur.

Contrôle
confidentiel MV logique

Requêtes Résultat
Processeur de Résultats transformés
requêtes
Noyau de la base
de données

Indice abstrait Abstraction du puce de

stockage stockage

Processeur indexeur

Figure 8. L’architecture d’Antelope (Adam, Tsiftes, 2011)

6.4.2. Le processeur de requêtes

Antelope utilise le langage de requête AQL défini pour construire et interroger
les bases de données dans les réseaux de capteurs. AQL n’est pas un sous-ensemble
de SQL, mais les deux langages partagent des éléments syntaxiques. AQL exclut
 Les bases de données dans les RCSF 765

toutes les fonctionnalités SQL complexes telles que les extensions procédurales, les
déclencheurs et les transactions (Adam, Tsiftes, 2011).
L’analyseur AQL traduit les opérations d’une représentation textuelle en données
de calcul abstraites. Il permet l’exécution de plusieurs requêtes simultanément. La
création d’une base de données avec AQL passe par trois étapes : la création de la
relation, puis de ses attributs, et enfin de ses index (cf. figure 9).
Dans le canevas de requêtes (cf. figure 9), nous présentons les étapes de création
de la base de données avec Antelope en utilisant les clauses CREATE RELATION,
CREATE ATTRIBUTE et CREATE INDEX. Nous créons d’abord la relation, puis
ses attributs, et enfin ses index. Une fois la base de données créée, l’utilisateur peut
l’interroger en utilisant les opérations listées dans la figure 10.

CREATE RELATION sensor ;

CREATE ATTRIBUTE id DOMAIN INT IN sensor ;
CREATE ATTRIBUTE name DOMAIN STRING(20) IN sensor ;
CREATE ATTRIBUTE position DOMAIN LONG IN sensor ;
CREATE INDEX sensor.id TYPE INLINE ;
CREATE INDEX sensor.position TYPE MAXHEAP ;

Figure 9. Création d’une base de données avec Antelope

Operation Usage
INSERT Insérer un tuple dans une relation.
REMOVE Supprimer les tuples correspondant à une condition.
SELECT Sélectionner les tuples et les attributs du projet.
JOIN Joindre deux relations selon une condition.
CREATE RELATION Créer une relation vide.
REMOVE RELATION Supprimer une relation et tous les index associés.
CREATE ATTRIBUTE Ajouter un attribut à une relation.
CREATE INDEX Créer un index d’attribut.
REMOVE INDEX Supprimer un index d’attribut.

Figure 10. Synthèse des opérations utilisées par Antelope

6.4.3. Le noyau de la base de données

Le noyau de la base de données Antelope est appelé par le module d’exécution des
requêtes pour évaluer toutes les opérations AQL. Il est adapté aux systèmes embar-
qués utilisant souvent un ordonnancement coopératif pour assurer aux processus une
exécution jusqu’à la fin sans préemption.
766 TSI. Volume 33 – no 9-10/2014

6.4.4. Les méthodes d’indexation d’Antelope

Antelope utilise trois algorithmes d’indexation pour optimiser l’exécution des re-
quêtes dans les bases de données en délimitant l’ensemble des tuples à traiter (Adam,
Tsiftes, 2011) :

– MaxHeap qui réduit la consommation d’énergie et l’utilisation de la mémoire.

– Inline qui assemble les données de capteurs et d’autres données.
– Hash qui stocke les paires « clé-valeur » dans la mémoire vive pour les relations
utilisées dans les requêtes.

6.5. Le système SINA

SINA est un intergiciel permettant aux applications capteurs d’émettre des re-
quêtes à travers le réseau et de collecter les réponses. SINA s’exécute sur chaque nœud
du réseau. Il fournit une organisation des informations collectées et une surveillance
des événements. Pour assurer l’efficacité énergétique et l’évolution des opérations, les
nœuds du réseau sont regroupés en clusters.

6.5.1. Architecture de SINA

L’architecture de SINA comprend les fonctionnalités suivantes :

– Groupement hiérarchique : les nœuds sont regroupés sous forme de clusters en

fonction de leur niveau de puissance et de leurs positions. Le processus d’agrégation
est appliqué d’une manière récursive pour former une hiérarchie de groupes. Chaque
cluster doit avoir un responsable qui s’occupe du filtrage, de la fusion, de l’agrégation
des données et des calculs périodiques. Si le chef de cluster rencontre des problèmes,
le processus de regroupement sera initié et un nouveau chef de cluster sera élu.
– Identification des capteurs par attribut : avec un grand nombre de capteurs, il est
difficile de contrôler chaque nœud. Srisathapornphat et al. proposent d’identifier les
nœuds cibles en utilisant des paires d’attributs (Srisathapornphat et al., 2001). Par ex-
emple, la définition [type=température, location=NE, température=103] décrit tous
les capteurs de température situés dans le secteur nord-est avec une lecture de tem-
pérature de 103◦ C.
– La détection de l’emplacement des capteurs : le système de positionnement
global (GPS) fournit des informations de positionnement absolu des capteurs. Un seul
sous-ensemble de capteurs peut être équipé d’un récepteur GPS pour que les autres
nœuds puissent récupérer leurs positions approximatives dans la zone. SINA utilise
aussi les dispositifs de poursuite optique qui donnent une grande précision sur la lo-
calisation des nœuds. La figure 11 présente un modèle de réseau de capteurs avec l’in-
tergiciel SINA. L’intergiciel SINA avec les traits en pointillé sur la figure 11, permet
aux applications capteurs d’émettre des requêtes et des commandes vers les capteurs,
et de recueillir les réponses et les résultats par la suite.
 Les bases de données dans les RCSF 767

Les applications
capteurs
Intergiciel SINA

Réponses Evènement

Requêtes Tâches et suivi

(a)
(b) Les capteurs

Figure 11. Un modèle de réseau de capteurs avec l’intergiciel SINA

6.5.2. La collecte d’informations

SINA utilise trois méthodes pour effectuer la collecte d’informations :
– Les opérations d’échantillonnage : cela permet de réduire l’implosion des
réponses. Les nœuds doivent prendre des décisions autonomes pour répondre ou non
aux demandes d’information. SINA calcule la probabilité de réponse à partir du nom-
bre de réponses dans chaque groupe de capteurs.
– Les opérations auto-orchestrées : dans les réseaux possédant un minimum de
nœuds, l’exactitude du résultat final dépend des réponses de tous les nœuds dans le
réseau. Pour réduire les risques de collision, SINA implémente une approche qui con-
siste à retarder l’envoi de réponses pendant un laps de temps pour chaque nœud.
– Les opérations de diffusion de calcul : les algorithmes utilisés pour la collecte
d’informations sont limités par la capacité de communication des nœuds. Chaque cap-
teur n’est censé communiquer qu’avec ses voisins. La logique d’agrégation des infor-
mations est programmée avec le langage SQTL (sensor query and tasking language)
(Chaiporn et al., 2000) et diffusée auprès des capteurs. Un des inconvénients est que
cette logique est difficile à implémenter dans des réseaux de taille importante.

6.5.3. Abstraction d’informations

SINA considère le réseau de capteurs comme une collection de fiches de calcul.
Chaque fiche contient l’ensemble des attributs de chaque capteur et chaque attribut est
considéré comme une cellule. Au départ, la fiche technique de chaque capteur contient
un petit nombre d’attributs prédéfinis (alimentation, taux de transfert, sensibilité, pro-
cesseur, mémoire, etc). Ces fiches peuvent être demandées par d’autres nœuds pour
créer de nouvelles cellules. Chaque nouvelle cellule transformée, doit avoir un nom
unique, et devient par la suite l’attribut d’un nœud.

6.5.4. Langage de requête de SINA

SQTL est un langage de script conçu pour être flexible et compact (Srisathapornphat
et al., 2001). Il interprète les requêtes déclaratives entre les applications de capteurs et
l’intergiciel SINA. Il offre un accès au matériel et aux primitives de communication.
Il fournit une gestion appropriée d’événements pour les applications des réseaux de
768 TSI. Volume 33 – no 9-10/2014

capteurs. SINA prend en charge trois types d’événements : (i) les événements générés
lorsqu’un message est reçu par un capteur, (ii) les événements déclenchés périodique-
ment par une minuterie et (iii) les événements provoqués par l’expiration d’un tempo-
risateur. Voici un exemple de modèle de déclaration de requête (Srisathapornphat et
al., 2001) :

SELECT avg(getTemperature())
AS avgTemperature
FROM CLUSTER-MEMBERS

Ces lignes de code permettent de calculer la moyenne des températures des clusters
formant le réseau.

7. Comparaison des systèmes de gestion de données dans les RCSF

Le tableau 2 représente un comparatif entre les principales bases de données de

capteurs.

Tableau 2. Comparaison des bases de données de capteurs

Sina Cougar TinyDB Antilope

Année de création 2000 2002 2004 2011
Système d’exploitation Non Non TinyOS ContikiOS

Simulateur Glomosim SimTracker Tossim et Cooja

et applet TinyDB
java GUI

Type de capteurs Nœuds de Nœuds de Mica2 TelosB,

simulateur simulateur TMote Sky,
Zolertia Z1

Requête de type SQL Oui Oui Oui Oui

Interface graphique Non Non Oui Non

Agrégation de données Oui Oui Oui Oui

Optimisation multirequête Non Non Non Non

Requêtes événementielles Oui Non Oui Non

Durée de vie de requêtes Oui Oui Oui Non

Support réseau hétérogène Non Non Non Non

Synchronisation du temps Non Non Oui Non

 Les bases de données dans les RCSF 769

7.1. Requête de type SQL

TinyDB et Cougar fournissent un langage de requête de type SQL (Gehrke, Mad-

den, 2004). Sina fournit également un langage de type SQL appelé SQTL (capteur de
requêtes et de polyvalence language). Antelope fournit un langage de requête appelé
AQL. Il est utilisé à la fois pour construire et interroger la base de données (Adam,
Tsiftes, 2011).

7.2. Interface graphique

Cougar ne fournit pas d’interface graphique, alors que TinyDB fournit une in-
terface graphique qui permet à l’utilisateur de spécifier des données à extraire du
réseau, de fixer des paramètres supplémentaires tel que la vitesse à laquelle les données
doivent être mises à jour et de saisir de requêtes SQL. Sina ne fournit pas d’interface
graphique mais elle offre une interface procédurale pour saisir un script. Antelope ne
fournit pas d’interface graphique mais utilise une application réseau NetDB qui dis-
pose d’une interface en ligne de commande par laquelle l’utilisateur peut saisir ses
requêtes.

7.3. Agrégation de données

Antelope supporte les fonctions d’agrégation. L’opération SELECT permet à l’u-

tilisateur d’utiliser des fonctions d’agrégation telles que COUNT, MAX, MEAN, MIN
et SUM. TinyDB et Cougar supportent également les requêtes d’agrégation (Iyengar,
Brooks, 2012). Sina utilise un processus d’agrégation pour former les groupes de cap-
teurs et faciliter les opérations évolutives au sein des réseaux de capteurs (Jaikaeo et
al., 2000).

7.4. Optimisation multirequête

À notre connaissance, aucun système de bases de données de capteurs ne sup-

porte l’optimisation multirequête qui permettrait de réduire les communications et
donc économiser de l’énergie dans le cas de requêtes similaires provenant de plusieurs
utilisateurs. En ce qui concerne l’exécution multirequête, TinyDB et Antelope la sup-
porte, mais ils ne tiennent pas compte de l’optimisation multirequête (Madden et al.,
2005) (Adam, Tsiftes, 2011).

7.5. Requêtes à durée de vie

Cougar et TinyDB utilisent la clause "<DURATION>" dans leurs requêtes qui

spécifie la durée de vie de la requête. Sina inclut l’expiration des événements à travers
la clause "<EXPIRE>" dans le langage SQLT qui définit les événements qui se pro-
duisent quand un temporisateur a expiré. Antelope ne supporte par la durée de vie des
requêtes.
770 TSI. Volume 33 – no 9-10/2014

7.6. Requêtes basées sur les évènements

Nous avons expliqué ce type de requêtes dans 4.2.3. Cougar et Antelope ne suppor-
tent pas ce type de requêtes. TinyDB supporte les événements comme un mécanisme
pour déclencher la collecte des données. Les événements sont générés de manière ex-
plicite, soit par une autre requête, soit par une partie de niveau inférieur du système
d’exploitation (Madden et al., 2005). TinyDB utilise le prédicat "ON EVENT" pour
définir un évènement dans une requête. SQTL, le langage de script de Sina supporte
trois types d’événements. Il utilise des prédicats pour définir ces événements : (i) RE-
CEIVE pour les événements générés quand un message est reçu par un capteur, (ii)
EVERY pour les événements déclenchés périodiquement par un temporisateur et (iii)
EXPIRE pour les événements déclenchés par l’expiration du temporisateur (Jaikaeo
et al., 2000).

7.7. Synchronisation

TinyDB utilise un protocole de synchronisation sur chaque nøeud qui définit le

début et la fin de chaque période pour les différents nœuds (Madden et al., 2005).
Cougar, ainsi que Sina et Antelope n’appliquent pas la synchronisation entre les cap-
teurs pendant le traitement des résultats (Yao, Gehrke, 2002).

8. Conclusion et perspectives

Les capteurs et les réseaux de capteurs sont de plus en plus présents dans notre vie
quotidienne. Les recherches actuelles s’orientent vers la mise en œuvre des données
provenant de ces réseaux en bases de données, appelées bases de données de capteurs.
Une fois que les données de capteurs sont organisées en base de données, on peut
exploiter la puissance liée aux bases de données, grâce notamment à leur mécanisme
de sécurité, de contrôle de concurrence, des opérateurs de leur langage de manipula-
tion, etc. Cependant, les outils performants de création et de manipulation de bases
de données de capteurs nécessitent des recherches, car beaucoup de verrous restent
encore à lever, comme la structuration en base de données centralisée ou distribuée,
l’utilisation des données de capteurs individuelles ou de leur agrégation, etc.
Dans cet article, nous avons présenté une synthèse sur les travaux relatifs aux
réseaux et bases de données de capteurs. Nous avons commencé par une présenta-
tion générale sur les capteurs. Ensuite, nous avons détaillé leurs caractéristiques et
la topologie qui les définissent. Nous avons décrit la structure d’un capteur et d’un
réseau de capteurs, et montré les défis qui existent dans ces réseaux. Nous avons ter-
miné par une étude spécifique des différentes solutions proposées pour la structuration
des données acquises depuis un réseau de capteurs en base de données et leur traite-
ment. D’autres recherches sont menées sur les réseaux et bases de données de capteurs
pour prendre en compte les contraintes d’économie d’énergie (rallonger la durée de
vie des capteurs), les communications entre les capteurs, les traitements qui peuvent
être intégrés au sein d’un capteur, etc.
 Les bases de données dans les RCSF 771

Parmi les perspectives liées aux recherches sur les bases de données de capteurs, il
y a la prise en compte des contraintes temps réel liées à la manipulation des données
de capteurs. En effet, dans la plupart des cas, les capteurs, pour refléter de la manière
la plus fidèle possible l’état de l’environnement, doivent délivrer leurs mesures avant
une échéance donnée, sinon les données délivrées deviennent obsolètes et ne corre-
spondront plus à l’état réel de l’environnement. De même que les opérations de ma-
nipulation de la base, qui doivent être contraintes par le temps. A défaut de respecter
strictement les échéances des actions et les durées de validité des données, il est pos-
sible de travailler sur le respect d’une certaine qualité de service, comme la délivrance
de données avec une certaine incertitude, ou avec un retard borné.

Bibliographie

Adam D., Tsiftes N. (2011). A database in every sensor. In Proceedings of the acm conference
on networked embedded sensor systems. Seattle, WA, USA, ACM.
Aissani M. (2011). Optimisation du routage dans les réseaux de capteurs pour les applications
temps-réel. Thèse de doctorat en informatique, Université Paris-Est, Université des sciences
et de la technologie Houari-Boumediene (USTHB).
Akyildiz F. I., Su W., Sankarasubramaniam Y., Cayirci E. (2002). Wireless sensor networks: a
survey. Computer Networks, vol. 38, no 4, p. 393-422.
Akyildiz F. I., Vuran M. C. (2010). Wireless sensor networks. Wiley.
Annamalai V., Gupta S. K. S., Schwiebert L. (2003). On tree-based convergecasting in wireless
sensor networks. In Wireless communications and networking conference, p. 1942-1947.
IEEE.
Bechkit W., Bouabdallah A., Challal Y. (2011). Un prototype de réseaux de capteurs sans fil
pour l’agriculture et le contrôle de l’environnement. In CFIP 2011 - Colloque Francophone
sur l Ingénierie des Protocoles. Sainte Maxime, France.
Bhaskar K., Sitharama I. (2004). Distributed bayesian algorithms for fault-tolerant event region
detection in wireless sensor networks. IEEE Transactions on Computers, vol. 53, p. 241–
250.
Bonnet P., Gehrke J., Seshadri P. (2001). Towards sensor database systems. In Proceedings
of the second international conference on mobile data management, p. 3–14. London,UK,
Springer-Verlag.
Bonnet P., Seshadri P. (2000). Device database systems. In Proceedings of the 16th international
conference on data engineering, p. 194. IEEE Computer Society.
Boyle D., Newe T. (2008). Securing wireless sensor networks: Security architectures. Journal
of Networks, vol. 3, p. 65-77.
Breheret L., Schettini F., Bernauer E., Barbier M. (2000). Traitements des données de trafic.
Rapport technique. Direction de la Recherche et des Affaires Scientifiques et Techniques.
Cao Q., Abdelzaher T., Stankovic J., Whitehouse K., Luo L. (2008). Declarative tracepoints: a
programmable and application independent debugging system for wireless sensor networks.
772 TSI. Volume 33 – no 9-10/2014

In Proceedings of the 6th ACM conference on Embedded network sensor systems, p. 85–98.
New York, NY, USA, ACM.
Chaiporn J., Chavalit S., Chien-chung S. (2000). Squerying and tasking in sensor networks. In
Proceedings of the 14th international symposium on aerospace/defense sensing, simulation,
and control, p. 184–197.
Considine J., Li F., Kollios G., Byers J. (2004). Approximate aggregation techniques for sensor
databases. In Proceedings of the international conference on data engineering, p. 449–460.
Washington, DC, USA, IEEE Computer Society.
Dargie W., Poellabauer C. (2010). Fundamentals of wireless sensor networks: Theory and
practice. Wiley.
Da Silva R. I., Macedo D. F., Nogueira J. M. S. (2014, janvier). Spatial query processing in
wireless sensor networks - a survey. Information Fusion, vol. 15, p. 32–43.
De Sousa G. (2008). Étude en vue de la réalisation de logiciels bas niveau dédiés aux réseaux
de capteurs sans fil : microsystème de fichiers. Thèse de doctorat non publiée, Université
Blaise Pascal–Clermont II.
Dunkels A., Grönvall B., Voigt T. (2004). Contiki - a lightweight and flexible operating sys-
tem for tiny networked sensors. In Proceedings of the first ieee workshop on embedded
networked sensors. Tampa, Florida, USA.
Egea-López E., Vales-Alonso J., Martínez-Sala A. S., Pavón-Mariño P., García-Haro J. (2005).
Simulation tools for wireless sensor networks. Proceedings of the International Symposium
on Performance Evaluation of Computer and Telecommunication Systems, p. 2–9.
Emad F., Chang-Gun L., Eylem E. (2006, juin). MMSPEED: Multipath Multi-SPEED Proto-
col for QoS Guarantee of Reliability and Timeliness in Wireless Sensor Networks. IEEE
Transactions on Mobile Computing, vol. 5, p. 738–754.
Feng Zhao L. J. G. (2004). Wireless sensor networks: An information processing approach.
Morgan Kaufmann Publishers.
Forghani-zadeh H. P., Rincón-Mora G. A. (2005). A lossless, accurate, self-calibrating current-
sensing technique for DC-DC converters. In Conference of the IEEE Industrial Electronics
Society, p. 549–554.
Fu T.-Y., Peng W.-C., Lee W.-C. (2007). Optimizing parallel itineraries for knn query pro-
cessing in wireless sensor networks. In Proceedings of the sixteenth acm conference on
conference on information and knowledge management, p. 391–400. New York, NY, USA,
ACM.
Fung W. F., Sun D., Gehrke J. (2002). Cougar: the network is the database. In Proceedings
of the 2002 ACM SIGMOD international conference on Management of data, p. 621–621.
New York, NY, USA, ACM.
Gehrke J., Madden S. (2004). Query processing in sensor networks. IEEE Pervasive Comput-
ing, vol. 3, no 1, p. 46-55.
Gobriel S., Khattab S., Mosse D., Brustoloni J., Melhem R. (2006, Sept). Ridesharing: Fault
tolerant aggregation in sensor networks using corrective actions. In Sensor and ad hoc com-
munications and networks, 2006. secon ’06. 2006 3rd annual ieee communications society
on, vol. 2, p. 595-604.
 Les bases de données dans les RCSF 773

Govindan R., Hellerstein J., Hong W., Madden S., Franklin M., Shenker S. (2002). The sensor
network as a database. Rapport technique no 02-771. Usc information sciences institute.
Gurgen L., Roncancio C. L., Labbé C., Olive V. (2009). Gestion de données de capteurs.
Ingénièrie des systèmes d’Information,Gestion des données dans les SI pervasifs, vol. 14.
Gutierrez J., Naeve M., Callaway E., Bourgeois M., Mitter V., Heile B. (2001). IEEE 802.15.4:
a developing standard for low-power low-cost wireless personal area networks. Network
IEEE, vol. 15, no 5, p. 12–19.
Guyoton F. (1991). Sismicité et structure lithosphérique des alpes occidentales. Thèse de
doctorat non publiée, Université Joseph Fourier – Grenoble I.
Haiying Z., Kun M. H., Jean P., Laurent G. (2004). Remote continuous cardiac arrhythmias
detection and monitoring. Transformation of Healthcare with Information Technologies,
vol. 5, p. 112–120.
Han C., Kumar R., Shea R., Kohler E., Srivastava M. (2005). SOS - A Dynamic operating
system for Sensor Networks. In Proceedings of the 3rd international conference on mobile
systems, applications and services. ACM Press.
Harte S., Rahman A., Razeeb K. (2005). Fault tolerance in sensor networks using self-
diagnosing sensor nodes. The IEEE International Workshop on Intelligent Environment,
p. 7–12.
He T., Stankovic J. A., Lu C., Abdelzaher T. (2002). SPEED: A Real-Time Protocol for Sensor
Networks. Rapport technique. Charlottesville, VA, USA.
He T., Stankovic J. A., Lu C., Abdelzaher T. (2003). SPEED: A Stateless Protocol for Real-
Time Communication in Sensor Networks. In Proceedings of the 23rd international confer-
ence on distributed computing systems, p. 46–55. Washington, DC, USA, IEEE Computer
Society.
Hill J., Szewczyk R., Woo A., Hollar S., Culler D., Pister K. (2000). System architecture
directions for networked sensors. ACM SIGPLAN Notices, vol. 35, no 11, p. 93–104.
Hoeller N., Reinke C., Neumann J., Groppe S. (2010, Aug). Stream-based xml template com-
pression for wireless sensor network data management. In Multimedia and ubiquitous en-
gineering (mue), 2010 4th international conference on, p. 1-9.
Hojung C., Sukwon C., Inuk J., Hyoseung K. (2007). RETOS: resilient, expandable, and
threaded operating system for wireless sensor networks. In Proceedings of the 6th inter-
national conference on information processing in sensor networks, p. 148–157. New York,
NY, USA, ACM.
Iino Y., Hatanaka T., Fujita M. (2010). Dynamic topology optimization for dependable sensor
networks. In IEEE International Conference on Control Applications, p. 274-279.
Incel O., Ghosh A., Krishnamachari B. (2011). Scheduling algorithms for tree-based data
collection in wireless sensor networks. In Theoretical aspects of distributed computing in
sensor networks, p. 407-445. Springer Berlin Heidelberg.
Iyengar S. S., Brooks R. R. (2012). Distributed sensor networks, second edition: Two volume
set (2nd éd.). Chapman & Hall/CRC.
Jacquot A. (2010). Supervision de réseaux d’objets intelligents communicants sans fil. Thèse
de doctorat non publiée, Université Blaise Pascal - Clermont-Ferrand II.
774 TSI. Volume 33 – no 9-10/2014

Jaikaeo C., Srisathapornphat C., Shen C. chung. (2000). Sensor information networking archi-
tecture. In Proceedings of the 2000 international workshop on parallel processing, p. 23-
30.
Jun Zheng A. J. (2009). Wireless sensor networks: A networking perspective (1re éd.). Wiley-
IEEE Press.
Kang J. jin, Lee K. young, Kim J. joon, Choi G. seok, Im Y. soon, Kang E. young. (2012).
In-network query for wireless sensor networks. Journal of Multimedia and Ubiquitous
Engineering, vol. 7, p. 377–382.
Kaur G., Garg R. M. (2012). Energy efficient topologies for wireless sensor networks. Interna-
tional Journal of Distributed and Parallel systems (IJDPS), vol. 3, no 5, p. 179–192.
Khorram S., Koch F., Nelson S., Wiele C. van der. (2012). Remote sensing. Springer.
Kofoed L. M. (2007). Enhancing sensor network programming:Extending TinyDB with HAV-
ING and aggregation, and investigating TinyDB reliability. Mémoire de Master non publié,
University of Oslo, Oslo, Norvège.
Krishnakumar T. (2010). Integrated Routing and Query Processing in Wireless Sensor Net-
works. International journal of applied engineering research, vol. 1, no 1, p. 115–123.
Kumar D., Patel R., Aseri T. C. (2010). Prolonging network lifetime and data accumulation in
heterogeneous sensor networks. The International Arab Journal of Information Technology,
vol. 7, no 3, p. 302-309.
Labbé C. (2010). Le sens au coeur des systèmes d’information. Habilitation à diriger des
recherches, Université de Grenoble. (74 pages)
Levis P., Gay D. (2009). Tinyos programming (1re éd.). Cambridge University Press.
Li J., Cai Z., Li J. (2008). Data management in sensor networks. In Y. Li, M. Thai, W. Wu
(Eds.), Wireless sensor networks and applications, p. 287-330. Springer US.
Li Y., Thai M. T., Wu W. (2008). Wireless sensor networks and applications. Springer.
Madden S., Franklin M. J., Hellerstein J. M., Hong W. (2002). Tag: a tiny aggregation ser-
vice for ad-hoc sensor networks. ACM SIGOPS Operating Systems Review, vol. 36, no SI,
p. 131–146.
Madden S., Franklin M. J., Hellerstein J. M., Hong W. (2003). The design of an acquisitional
query processor for sensor networks. In Proceedings of the 2003 acm sigmod international
conference on management of data, p. 491–502. New York, NY, USA, ACM.
Madden S., Franklin M. J., Hellerstein J. M., Hong W. (2005, mars). Tinydb: an acquisitional
query processing system for sensor networks. ACM Transactions on Database Systems,
vol. 30, no 1, p. 122–173.
Madden S., Hellerstein J. M., Hong W. (2003). TinyDB: In-Network Query Processing in
TinyOS Manuel de logiciel.
Makhoul A. (2008). Réseaux de capteurs : localisation, couverture et fusion de données. Thèse
de doctorat non publiée, Université de Franche-Comté.
Matin M. A. (2012). Wireless sensor networks: Technology and protocols. InTech.
 Les bases de données dans les RCSF 775

Mazzer Y., Tourancheau B. (2008). Réseaux de micro-contrôleurs à faible consommation d’én-

ergie embarquant des capteurs : Premières expériences et développement d’une nouvelle
interface paramétrable et programmable. Rapport technique no 6450. INRIA.
Mo S., Chen H., Zhang X., Li C. (2013). Tinyqp : A query processing system in wireless
sensor networks. In Web-age information management, vol. 7923, p. 788-791. Springer
Berlin Heidelberg.
Munir A., Ross A. G. (2010). Optimization approaches in wireless sensor networks. In W. Seah,
Y. K. Tan (Eds.), Sustainable wireless sensor networks, p. 313–338. InTech.
Nath S., Gibbons P. B., Seshan S., Anderson Z. R. (2004). Synopsis diffusion for robust
aggregation in sensor networks. In Proceedings of the 2nd international conference on
embedded networked sensor systems, p. 250–262. New York, NY, USA, ACM.
Neely M. J., Urgaonkar R. (2009, juillet). Optimal backpressure routing for wireless networks
with multi-receiver diversity. Ad Hoc Netw., vol. 7, no 5, p. 862–881.
Nefzi B. (2007). Qualité de service temps réel dans les protocoles IEEE 802.15.4 et ZigBee et
leurs améliorations. Mémoire de Master non publié, Henri Poincaré, Nancy I.
Noël G. (2006). Indexation dans les bases de données capteurs temps réel. Thèse de doctorat
non publiée, Institut National des Sciences Appliquées de Lyon.
Noël G., Servigne S. (2004, juin). Po-Tree: un système d’indexation spatio-temporel temps-
réel. In Cassini (Ed.), Conférence cassini-sigma 2004 : Géomatique et analyse spatiale, p.
120–121.
Noël G., Servigne S. (2005, octobre). Indexation multidimensionnelle de bases de données
capteur temps-réel et spatiotemporelles. Ingénierie des Systèmes d’Information, vol. 10,
no 4, p. 59–88.
Ozdemir S., Xiao Y. (2009, août). Secure data aggregation in wireless sensor networks: A
comprehensive overview. Computer Networks, vol. 53, no 12, p. 2022–2037.
Paradis L., Han Q. (2007, juin). A survey of fault management in wireless sensor networks. J.
Netw. Syst. Manage., vol. 15, no 2, p. 171–190.
Patil N. S., Patil P. R. (2011). Data aggregation in wireless sensor network. International
Journal Of Service Computing And Computational Intelligence, vol. 1, no 1, p. 7–10.
Petit L. (2009). Modèles d’interrogation sur les flux de données issues de capteurs. Mémoire
de Master non publié, Université Joseph Fourier, Grenoble–France.
Pignagnoli L., Chierici F., Favali P., Beranzoli L., Embriaco D. (2011). Tsunami early warning
system: Deep sea measurements in the source area. Marine Research at CNR.
Pottie G. J., Kaiser W. J. (2000). Wireless integrated network sensors. Commun. ACM, vol. 43,
p. 51–58.
Rahman M. A., Hussain S. (2007). Energy efficient query processing in wireless sensor net-
work. In Aina workshops (2), p. 696-700.
Rajagopalan R., Varshney P. K. (2006, octobre). Data-aggregation techniques in sensor net-
works: A survey. IEEE Communications Surveys & Tutorials, vol. 8, no 4, p. 48–63.
Rost S., Balakrishnan H. (2006). Memento: A Health Monitoring System for Wireless Sensor
Networks. In Ieee secon. Reston, VA.
 776 TSI. Volume 33 – no 9-10/2014

Sarkar S. K. (2012). Wireless sensor and ad hoc networks under diversified network scenarios.
Artech House.
Servigne S., Noël G. (2008). Real time and spatiotemporal data indexing for sensor based
databases. In Geo-information technology for emergency response, p. 123–141.
Servigne S., Ray C., Bouju A., Devogele T. (2009). Gestion de masses de données au sein de
bases de données capteurs. Revue Internationale de Géomatique, vol. 19, no 2, p. 133-150.
Sivaranjani S., Radhakrishnan S., Thangaraj C. (2013). Adaptive delay and energy aware data
aggregation technique in wireless sensor networks. In V. Das, Y. Chaba (Eds.), Mobile
communication and power engineering, vol. 296, p. 41-49. Springer Berlin Heidelberg.
Sohrabi K., Gao J., Ailawadhi V., Pottie G. J. (2000). Protocols for self-organization of a
wireless sensor network. IEEE Personal Communications, vol. 7, p. 16–27.
Solivellas B. (2012). Ce capteur pourrait révolutionner le stationnement en ville. Consulté
sur http://www.cnetfrance.fr/cartech/ce-capteur-pourrait-revolutionner-le-stationnement-en
-ville-39785210.htm
Srisathapornphat C., Jaikaeo C., Shen C. chung. (2001). Sensor information networking archi-
tecture and applications. IEEE Personal Communications, vol. 8, p. 52–59.
Tarannum S. (2010). Energy conservation challenges in wireless sensor networks: A compre-
hensive study. Wireless Sensor Network, vol. 2, no 6, p. 483-491.
Trigoni N., Guitton A., Skordylis A. (2007). Learning from data streams: Processing techniques
in sensor networks. chapter 6: Querying of sensor data (J. Gama, M. M. Gaber, Eds.).
Springer.
Tsiftes N., Dunkels A., He Z., Voigt T. (2009). Enabling large-scale storage in sensor networks
with the coffee file system. In Proceedings of the 2009 international conference on infor-
mation processing in sensor networks, p. 349–360. Washington, DC, USA, IEEE Computer
Society.
Wang M., Cao J., Li J., Das S. K. (2008). Middleware for wireless sensor networks: A survey.
Journal of Computer Science and Technology, vol. 23, no 3, p. 305-326.
Wilson J. S. (2004). Sensor technology handbook. Amsterdam, Elsevier.
Yao Y., Gehrke J. (2002). The cougar approach to in-network query processing in sensor
networks. SIGMOD Rec., vol. 31, no 3, p. 9–18.
Yong-Sun K., Se-Han K., Woo-Yong L. (2006). Method for managing dormant nodes in wire-
less sensor network, patent no 8040828.
Yu W., Weizhao W., Xiang-Yang L. (2006). Efficient distributed low-cost backbone formation
for wireless networks. IEEE Transactions on Parallel and Distributed Systems, vol. 17,
p. 681-693.
Yutaka I., Takeshi H., Masayuki F. (2009). Event-predictive control for energy saving of wire-
less networked control system. In Proceedings of the american control conference, p. 2236–
2242. Piscataway, NJ, USA.

Article soumis 2/12/2013

Accepté le 12/01/2015

View publication stats