Le Saut de Fréquence Dans Les Réseaux de Capteurs Sans Fil

Le saut de fréquence dans les
Réseaux de Capteurs Sans Fil
VERGNE Aurore – VOIRIN Rémi

Licence Professionnelle Réseaux Sans Fil et Sécurité
2010 - 2011
Tuteur : Gérard Chalhoub
Le saut de fréquence dans les Réseaux de Capteurs Sans Fil
Remerciements
Nous remercions tout d’abord notre tuteur, Gérard Chalhoub, pour le temps qu’il nous a
accordé tout au long de notre projet ainsi que les conseils qu’il nous a donnés.
Nous tenons aussi à remercier le LIMOS (Laboratoire d’Informatique, de Modélisation et

d’Optimisation des Systèmes) pour le prêt des cartes TelosB nécessaires à l’aboutissement du
projet.
Nous souhaitons remercier David Coursimault pour ses explications quant à l’utilisation de
l’analyseur de spectre.
Enfin, toute l’équipe pédagogique de la section Réseaux et Télécommunications de

l’Institut Universitaire de Technologie de Clermont-Ferrand pour son investissement dans le bon
déroulement des projets tuteurés de licence professionnelle.
Aurore VERGNE – Rémi VOIRIN Licence Professionnelle Réseaux Sans Fil et Sécurité
1
Tuteur : Gérard CHALHOUB 2010-2011
Sommaire
Remerciements………………………………………………………………………………………………………… page 1
Introduction…………………………………………………………………………………………….………………..page 3
1. Présentation du contexte……………………………………………………………………………………… page 4

1.1. Les réseaux de capteurs sans fil : une nécessité croissante…………………………………… page 4
1.1.1. Définitions………………………………………………………………………………………… page 4
1.1.2. Les besoins en termes de réseau de capteurs sans fil…………………………………. page 5
1.1.3. La nécessité de faire du saut de fréquence……………………………………………… page 6
1.2. Réseaux Sans Fil et Sécurité : une formation adaptée…………………………………………. page 7
1.3. Démarche……………………………………………………………………………………………….. page 7
2. Déploiement de l’environnement de travail…………………………………………………................ page 8

2.1. Présentation de TinyOS………………………………………………………………………………...page 8
2.2. Installation et test de la configuration de TinyOS………………………………………………... page 10
2.3. Prise en main de TinyOS et des cartes TelosB…………………………………………………….. page 12
2.3.1. Découverte du matériel………………………………………………………………………. page 12
2.3.2. Découverte d’applications simples…………………………………………………………. page 14
2.3.2.1. Blink…………………………………………………………………………………..…….. page 14
2.3.2.2. Oscilloscope et BaseStation…………………………………..………….…………… page 16
3. Mise en place du saut de fréquence……………………………………………………………………… page 19

3.1. Les aspects théoriques du saut de fréquence….………………………………………………...page 19
3.2. Procédure d’installation.……………………………………………………………………………... page 21
3.2.1. Présentation d’OpenWSN et téléchargement……………………………………………. page 21
3.2.2. Étude du code et modifications apportées………………………………………………. page 23
3.3. Observation……………………………………………………………………………………………... page 26
3.3.1. De manière logicielle…..………………………………………………………………………. page 26
3.3.2. Avec du matériel adapté.……………………………………………………………………. page 35
4. Bilan du projet…………………………………..…………………………………………………................ page 38

4.1. Les résultats obtenus…………………………………………………………………………………... page 38
4.2. Un contexte expérimental………………………….………………………………………………... page 38
4.3. Les prolongements possibles…….…………………………………………………………………... page 38
Conclusion………………………………………………………………………………………………………………. page 39
Questionnaire en anglais…………………………………………………………………………………………….. page 40
Glossaire…………………………………………………………………………………………………………………. page 42
Bibliographie……………………………………………………………………………………………………………. page 44
Annexes…………………………………………………………………………………………………………………..page 45
2
Introduction
Dans le cadre de la Licence Professionnelle Réseaux Sans-Fil et Sécurité, nous avons réalisé
un projet tuteuré sous la direction de M. Chalhoub, projet qui donne lieu à ce rapport.
Notre projet concerne les réseaux de capteurs sans fil. Ceux-ci sont de plus en plus utilisés
dans des domaines variés dont l’automobile, la médecine, la domotique ou encore dans le cadre
militaire. Leurs applications, très diverses, vont de la gestion des stocks dans une entreprise à la
surveillance d’une zone sécurisée en passant par le contrôle du rythme cardiaque d’un patient. Un
réseau de capteurs sans fil (RCSF ou WSN pour Wireless Sensor Network) répond à deux
contraintes : la consommation énergétique et la mobilité. Pour surmonter la contrainte de
l’énergie, il est nécessaire de limiter les pertes de paquets* dans un réseau de capteurs. En effet, un
paquet perdu est une perte précieuse aussi bien pour l’émetteur qui doit effectuer une seconde
fois sa tâche (et donc consommer deux fois plus d’énergie pour la même chose) que pour le
récepteur qui doit passer plus de temps à écouter et attendre le message de l’émetteur. Les RCSF
opèrent sur des bandes de fréquences utilisées par d’autres technologies (par exemple WiFi et
Bluetooth à 2,4 GHz), et c’est précisément des pertes de paquets qui surviennent lorsque des
interférences provenant d’autres types de réseaux apparaissent sur la fréquence utilisée. Cette
constatation a mené au développement d’une solution : le saut de fréquence. Cela consiste à ce
que tous les éléments d’un même RCSF changent de fréquence simultanément, de manière
régulière, et si possible très souvent pour limiter l’influence négative de la présence d’un éventuel
autre système interférent.
Nous nous sommes ainsi posés les questions suivantes :

 Comment mettre en place le saut de fréquences dans un réseau de capteurs sans fil ?
 Comment observer ce phénomène ?
Afin de répondre à ces deux questions, nous avons articulé notre travail en trois étapes.
Nous allons tout d’abord présenter le contexte du projet tuteuré. Puis nous détaillerons notre travail
et enfin, nous évoquerons les difficultés rencontrées ainsi que les prolongements possibles.
Les mots suivis de * sont définis dans le glossaire à la page 42
3
1. Présentation du contexte
1.1. Les réseaux de capteurs sans fil : une nécessité croissante
1.1.1. Définitions
En premier lieu, il est nécessaire de définir ce que sont les capteurs sans fil et la manière de
les mettre en réseau.
Composants d’un nœud capteur sans fil
Figure 1.1.1.1. : Photographie d’une carte TelosB, le modèle de nœud capteur sans fil utilisé dans nos expérimentations.
Source : http://www.cs.nmsu.edu/~jlafon/courses.html
Un nœud capteur sans fil est caractérisé par différents éléments :

 un dispositif de captage qui va récupérer une donnée présente dans son
environnement (par exemple la température).
 un processeur analysant les données récupérées par le capteur avec
éventuellement une unité de stockage pour conserver ces données.
 un module d’émission/réception radio afin d’échanger en sans-fil des informations
avec un capteur voisin.
 une batterie pour alimenter les composants précédents.
Par abus de langage, les nœuds capteurs sont appelés couramment capteurs. De fait, nous
utiliserons indifféremment les deux termes.
4
Mécanisme de mise en réseau
La mise en réseau des capteurs sans fil fonctionnant s’effectue matériellement via le
module d’émission/réception radio (concrètement, une carte réseau sans fil). Ce qui nous intéresse
ici est la partie logicielle. Nous devons l’aborder pour pouvoir définir plus loin la notion de saut de
fréquence.
Les protocoles* utilisés sont calqués sur le modèle OSI*.
Application
Présentation
Session
ZigBee
Transport
Réseau
Sens de
lecture Liaison de données
802.15.4
Physique
Figure 1.1.1.2. : Schéma de correspondance entre le modèle OSI et les protocoles classiques des capteurs sans fil.
Source personnelle
Nous observons ici que deux éléments interviennent, ZigBee et 802.15.4. ZigBee s’occupe
des opérations de haut niveau, du routage jusqu’au formatage de l’information pour qu’elle soit
compréhensible par une application qui la manipule. 802.15.4 a, quant à lui, un rôle de plus bas
niveau : il s’agit du transfert même de l’information sur le réseau. Ce standard ne s’occupe que de
la manière dont elle doit transiter sur le réseau, d’un nœud capteur à l’autre.
Ces protocoles sont intégrés dans TinyOS. C’est le système d’exploitation* des capteurs sans
fil.
1.1.2. Les besoins en termes de réseau de capteurs sans fil
Il existe aujourd’hui une demande très forte en matière de réseaux de capteurs sans fil.
Celle-ci concerne de nombreux domaines ; voici quelques exemples :
 détecter des intrusions dans un périmètre où sont disséminés des capteurs. Nous
pouvons imaginer la détection du passage d’êtres humains ou de gibier sur des voies
de chemin de fer, ou, dans le cadre militaire, l’arrivée d’éléments hostiles dans la base.
 surveiller l’environnement dans le cadre de la protection d’un espace ou de
l’agriculture. Dans ce cas, la récupération de données telles que la température et
l’humidité permettent, dans un champ, de visualiser quelles sont les zones à arroser en
priorité.
 contrôler le rétablissement des patients : on peut implanter sous la peau un capteur
prenant régulièrement des photos d’une zone récemment opérée pour vérifier sa
bonne guérison.
5
1.1.3. La nécessité de faire du saut de fréquence
Les réseaux de capteurs sans fil opèrent sur deux types de bandes principaux : 868/915
MHz* et 2,4 GHz*. C’est ce dernier qui nous intéressera. En effet, c’est une bande de fréquences
libre dans pratiquement tous les pays du monde. Elle fait partie des bandes ISM (Instrumentation,
Scientific and Medical). Elle a comme autre atout, dans le cas des réseaux de capteurs sans fil, de
permettre un débit plus élevé qu’avec les autres bandes (250 kb/s* contre 20 ou 40 kb/s).
Il existe cependant un inconvénient majeur à l’utilisation de la bande des 2,4 GHz (ou, pour
être plus exact, des 2400 à 2483,5 MHz) : celle-ci est utilisée par différentes technologies sans fil, à
commencer par WiFi, norme 802.11 qui correspond à des réseaux locaux sans fil, et Bluetooth,
système de connexion de matériel à courte portée.
Figure 1.1.3.1. : Logo de WiFi et Bluetooth.

Source : Google Images
Nous pouvons, dès lors, imaginer quels problèmes potentiels le responsable d’un réseau de
capteurs sans fil peut rencontrer : il suffit qu’un réseau d’une autre nature émette sur la même
fréquence pour qu’il y ait des interférences. Il fallait donc une solution : le saut de fréquence.
Figure 1.1.3.2. : Schéma des canaux utilisés par les RCSF.

Source : http://www.processonline.com.au/articles/29975-Data-acquisition-no-limits-digital-wireless-technology-using-the-IEEE8-
2-15-4-ZigBee-standard
Le schéma ci-dessus montre la manière dont 802.15.4 utilise la bande de fréquences ISM
des 2,4 GHz. Nous observons qu’il existe 16 canaux indépendants (i.e. qui ne se recouvrent pas)
espacés de 5 MHz et ayant une largeur de 3 MHz. Ainsi, théoriquement, il est possible de faire
fonctionner 16 réseaux de capteurs en un même lieu sans qu’ils interfèrent.
Le principe du saut de fréquence est d’utiliser différents canaux dans le temps. De manière
coordonnée et périodique, tous les nœuds capteurs d’un même réseau vont changer de
fréquence. L’objectif visé est la robustesse. En effet, imaginons qu’un réseau WiFi soit mis en place
à proximité d’un RCSF et se mette à émettre sur une fréquence proche (ou la même) que ce
dernier. S’il n’y a pas de saut de fréquence, alors les transmissions sont mises à mal dans les deux
réseaux. En revanche, la perturbation reste limitée si la fréquence utilisée par le RCSF change très
peu de temps après.
Étant donné que le saut de fréquence est un changement important dans la manière dont
les nœuds capteurs utilisent le médium*, il a donné lieu à un nouveau standard de l’IEEE* :
802.15.4E.
6
1.2. Réseaux Sans Fil et Sécurité : une formation adaptée
L’Institut Universitaire de Technologie, de par sa licence professionnelle Réseaux Sans Fil et

Sécurité (RSFS), forme des administrateurs réseau pouvant être amenés au cours de leur carrière à
étudier puis à déployer des capteurs sans fil. Afin de pouvoir mener à bien cette tâche, il est
nécessaire d’avoir des connaissances dans divers domaines enseignés tels que la sécurité des
communications sans fil, les réseaux de capteurs, les télécommunications et l’informatique.
Dans le cas de ce projet, le saut de fréquence dans les réseaux de capteurs sans fil, c’est
plus particulièrement le module ‘‘Réseaux de Capteurs Sans Fil’’ qui va nous être utile bien que
d’autres peuvent également nous servir. En effet, pour mener nos expérimentations, nous avons dû
installer une machine virtuelle. Cette compétence, acquise durant le Diplôme Universitaire de
Technologie, a été réutilisée lors du module ‘‘Systèmes d’Exploitation Réseau’’.
Par conséquent, nous pouvons donc dire que la licence Réseaux Sans Fil et Sécurité est en
parfaite adéquation avec ce projet.
1.3. Démarche
La démarche mise en place pour ce projet est la suivante. Dans un premier temps, nous
avons déployé une machine virtuelle afin de découvrir le fonctionnement des nœuds capteurs.
Pour se faire, nous avons installé Debian Lenny puis TinyOS qui est le système d’exploitation des
capteurs. Nous avons, par la suite, installé ce dernier sur les cartes TelosB.
Par la suite, nous avons téléchargé le code permettant de faire du saut de fréquence et
l’avons étudié afin de comprendre son fonctionnement.
La dernière étape consiste à tester le bon fonctionnement du code. Ce test a été fait par
étapes : faire clignoter les LED des capteurs en fonction de la fréquence, émettre un message sur
chacune d’elle, utiliser un sniffer* et enfin un analyseur d’état logique*.
La démarche décrite ci-dessus peut être résumée grâce au graphique suivant :
Installation
Etude du machine
code virtuelle et
permettant TinyOS
de faire du
saut de
fréquence
Test du
code
Mise en place d'un mini réseau de

noeuds capteurs faisant du saut de
fréquence
Figure 1.3.1. : Schéma de la démarche.
Source personnelle
7
2. Déploiement de l’environnement de travail
L’environnement de travail est composé d’un système d’exploitation et d’une suite

logicielle permettant de mettre des applications sur les cartes. L’installation du système
d’exploitation Debian est décrite à l’annexe I. La suite logicielle s’appelle TinyOS : son installation et
sa prise en main sont décrites dans la suite de ce rapport.
2.1. Présentation de TinyOS
TinyOS est un système d’exploitation pour capteurs sans fil. Il est à l’origine développé par
l’Université de Berkeley (Californie) à la fin des années 1990. Étant donnée la croissance rapide du
secteur, le projet a pris de l’importance jusqu’à provoquer la fondation de la TinyOS Alliance, un
consortium international comprenant Intel, Crossbow Technology et l’Université de Berkeley.
Figure 2.1.1. : Logo de TinyOS.

Source : http ;//en.wikiperdia.org/wiki/Tiny_OS
TinyOS a la particularité d’être libre, c’est-à-dire que nous pouvons modifier son code
source à sa guise et éventuellement le redistribuer. Le langage nesC est utilisé pour ce code. C’est
un dérivé du langage C*, beaucoup plus adapté aux capteurs de par sa conception plus légère.
L’équipe en charge de TinyOS à l’Université de Berkeley lui a fixé les objectifs suivants :
 permettre un haut niveau de concurrence : dans un réseau de capteurs sans fil, les
différents éléments sont en compétition pour émettre. Or, lorsque des données sont
récoltées fréquemment et régulièrement, il faut être en mesure de les transmettre en
conséquence. La conception du système doit donc prendre en compte ces deux
problématiques.
 fonctionner avec des ressources limitées : cette contrainte prend en compte deux
problèmes distincts : d’une part, un capteur est petit donc les composants qu’il
embarque sont peu puissants et peuvent stocker extrêmement peu de données.
D’autre part, il y a l’énergie, un nœud capteur disposant de piles ou d’une batterie au
lithium pour fonctionner. Un capteur consomme environ 900 fois plus d’énergie lorsqu’il
émet, reçoit ou traite des informations que lorsqu’il est au repos (35 mA en activité
contre 40 µA au repos), il faut donc limiter ces opérations. En fait, pour atteindre cet
objectif, TinyOS doit être léger.
 s’adapter à l’évolution matérielle : le matériel utilisé pour les capteurs évolue

rapidement, la conception de TinyOS doit prendre cela en compte au maximum pour
pouvoir porter son code d’une génération à une autre avec le moins de bugs possibles.
8
 supporter un maximum de matériels possibles : cet objectif, lié au précédent, a besoin

d’être réalisé pour que TinyOS soit adopté par un maximum d’acteurs du domaine des
capteurs sans fil.
Figure 2.1.2. : Schéma présentant les composants classiques d’un capteur sans fil.
Source : http://fr.wikipedia.org
Ainsi, l’idée est de supporter le panel le plus large possible d’éléments présents à la figure
2.2.1.1., du module radio à la mémoire flash. En effet, les différents modèles de capteurs
embarquent des matériels qui sont susceptibles de varier. Par exemple, il existe plusieurs
modules radio : nous pouvons citer le MPR400CB utilisé sur les cartes Mica2 (la radio étant
intégrée au processeur) alors que le CC2420 est celui des cartes Micaz et TelosB.
 la robustesse : un RCSF est souvent amené à être laissé tel quel, sans intervention
extérieure pendant plusieurs semaines, mois voire années. La conception du système
d’exploitation des capteurs doit en conséquence être robuste pour éviter le moindre
bug qui paralyserait le réseau ou ferait consommer inutilement de l’énergie aux nœuds.
TinyOS est disponible sous forme de paquets pour la plupart des distributions Linux, sinon il
est possible de compiler* son code source. Sur ordinateur, TinyOS sert à créer des applications pour
capteurs et flasher* les cartes qui y sont branchées.
Nous allons désormais l’installer sur notre machine.
9
2.2. Installation et test de la configuration de TinyOS
Ayant choisi Debian pour les raisons évoquées dans l’annexe I, nous allons décrire la
procédure d’installation de TinyOS pour cette distribution et, plus précisément, pour la version
stable. Cependant, il est bon de savoir que les paquets nécessaires à l’installation de TinyOS sont
les mêmes pour Ubuntu et pour Debian.
Ces paquets ne se trouvent pas sur le miroir officiel de Debian ; il faut dont ajouter son adresse
dans le fichier /etc/apt/sources.list. Nous utilisons l’utilisateur système (root) pour le modifier :
$ su
# echo ‘‘deb http://tinyos.stanford.edu/tinyos/dists/ubuntu hardy
main’’ >> /etc/apt/sources.list
Afin que cet ajout soit pris en compte lors de la recherche de paquets, il faut mettre à jour
le cache de la commande aptitude :
# aptitude update
Il est désormais possible d’installer TinyOS :

# aptitude install tinyos-2.1.1
Figure 2.2.1. : Installation de TinyOS 2.1.1 avec Aptitude.

Source personnelle
Une fois l’installation terminée, quelques configurations s’imposent. Par défaut, le répertoire
/opt/tinyos-2.1.1 appartient au super utilisateur (root). Sur un système Unix, il est déconseillé d’utiliser
root pour autre chose que la configuration du système. Nous allons donc changer le propriétaire
de ce répertoire ainsi que de ses sous répertoires. Pour cela, nous nous connectons en root (seul lui
a le droit de changer l’appartenance d’un répertoire ou d’un fichier à un utilisateur) et modifions le
propriétaire grâce à la commande suivante :
# chown –R projet /opt/tinyos-2.1.1
Nous nous déconnectons de la session root sur le terminal (commande exit) et continuons avec
l’utilisateur projet.
10
Il faut créer des variables d’environnement* contenant le chemin vers des répertoires
spécifiques à TinyOS. Afin qu’elles soient permanentes c’est-à-dire qu’elles soient toujours présentes
même après un redémarrage (ce qui n’est pas le cas lorsque nous donnons une valeur à une
variable dans un terminal), il faut les mettre dans le fichier ~/.bashrc. Nous ouvrons ce fichier avec
un éditeur de texte (gedit par exemple) et ajoutons les lignes suivantes :
export TOSROOT=‘‘/opt/tinyos-2.1.1’’
export CLASSPATH=‘‘$CLASSPATH:$TOSROOT/support/sdk/java/tinyos.jar:.’’
export MAKERULES=‘‘$TOSROOT/support/make/Makerules’’
export TOSDIR=‘‘$TOSROOT/tos’’
Ces variables sont utilisées par les scripts de TinyOS pour connaître l’emplacement de différents
éléments :
 TOSROOT est la racine de TinyOS (c’est-à-dire le répertoire où sont placés tous les
composants de TinyOS, ainsi que les applications ou encore la documentation).
 CLASSPATH correspond à l’emplacement des classes Java utilisées par TinyOS.
 MAKERULES est la variable contenant le chemin vers les règles de compilation des
applications.
 TOSDIR contient l’emplacement de la racine des fichiers système de TinyOS.
Nous enregistrons le fichier et fermons tous les terminaux afin que les modifications soient prises en
compte.
Nous vérifions en affichant, par exemple, la valeur de TOSROOT :

$ echo $TOSROOT
Figure 2.2.2. : Affichage de la variable TOSROOT.

Source personnelle
/opt/tinyos-2.1.1 apparaît, cette valeur est celle que nous attendions. Nous en concluons que les
variables sont bien initialisées.
L’installation et la configuration de TinyOS étant fonctionnelles, nous allons, afin de prendre

TinyOS en main, tester le flashage des cartes avec un code simple.
11
2.3. Prise en main de TinyOS et des cartes TelosB
2.3.1. Découverte du matériel
Le matériel mis à notre disposition dans le cadre de ce projet est constitué de trois cartes
TelosB. Aussi appelées ‘‘motes’’ en anglais, les cartes TelosB ont été au départ développées par
l’Université de Berkeley et sont maintenant fabriquées à plus grande échelle par l’entreprise
californienne Crossbow Technology. Concrètement, ces nœuds capteurs sont composés d’une
plaque d’époxy sur laquelle sont disposés différents composants électroniques comme un
processeur, un module radio ou encore un port USB.
Figure 2.3.1.1. : Schéma d’une carte TelosB.

Source : Étude des mécanismes de synchronisation dans un réseau de capteurs sans fil, Stéphane Roicomte, 2010
 Antenne embarquée : cet élément permet la communication avec les autres cartes d’un
réseau. C’est le CC2420 qui est capable de traiter les informations transitant par l’antenne.
 Bouton user : celui-ci ne remplit pas de fonction précise, cela dépend du programme
exécuté par la carte TelosB (le programmeur est libre d’y adjoindre une fonction).
 Bouton reset : le bouton reset permet de redémarrer la carte sans avoir à la

débrancher/rebrancher de l’ordinateur ou enlever la batterie.
 CC2420 : le module radio CC2420 permet de réaliser des échanges sur la bande radio
s’étendant de 2,400 à 2,4835 GHz. Il sert d’intermédiaire entre le MSP430 et l’antenne.
 Capteurs : éléments matériels de mesure d’un paramètre environnemental. Une carte

TelosB possède trois capteurs : lumière, humidité et IR (infrarouge).
 LEDs : trois LEDs de couleur rouge, jaune et bleu sont présentes. C’est au programmeur de
décider pour quels événements elles s’allumeront.
12
 MSP340 : le micro-processeur MSP430 traite les données de la carte TelosB. Fabriqué par
Texas Instrument, il est cadencé à 8 MHz et est équipé de 10 kilobits de mémoire vive et 48
kilobits de mémoire flash (mémoire qui ne s’efface pas même si elle est privée d’électricité).
 Port USB : Élément par lequel la carte TelosB peut communiquer avec un ordinateur. Son
utilisation ne requiert pas de logiciel spécifique, la carte apparaît comme un port série*.
 Slots d’extensions : il s’agit d’emplacements vides. Ils sont destinés à accueillir des éléments
supplémentaires comme un microphone.
Pour finir, les cartes TelosB sont programmables. Nous pouvons donc leur faire exécuter le
code que nous voulons, chose que nous allons désormais faire avec des applications simples
intégrées à TinyOS.
13
2.3.2. Découverte d’applications simples
2.3.2.1. Blink
Afin de prendre en main TinyOS et les cartes TelosB, nous allons expérimenter l’installation
d’une application simple : Blink. Sa finalité n’est que de faire clignoter les trois LEDs présentes sur la
carte. Cependant, cette expérimentation aura deux objectifs : d’une part, tester l’architecture
logicielle que nous venons d’installer ; d’autre part, nous faire découvrir comment est organisé en
pratique TinyOS et comment installer une application sur une carte.
La première chose à faire est d’ajouter les lignes suivantes dans le fichier /opt/tinyos-
2.1.1/support/make/telosb.target. Celui-ci contient les instructions particulières de compilation des
applications TinyOS pour les cartes TelosB.
CFLAGS +=-I/usr/lib/gcc/i486-linux-gnu/4.4/include/
CFLAGS +=-I/usr/msp430/include/
CFLAGS +=-I/usr/msp430/include/sys/
Cet ajout résout un bug qui entraîne l’arrêt de la compilation alors qu’elle n’est pas
terminée.
Nous branchons ensuite la carte que nous souhaitons flasher. La bonne détection du
matériel peut être vérifiée à l’aide de la commande motelist .
Figure 2.3.2.1.1. : Affichage de la liste des cartes connectées.

Source personelle
Nous nous plaçons à présent dans le répertoire de l’application à compiler, à savoir Blink :
$ cd /opt/tinyos-2.1.1/apps/Blink
Nous lançons la compilation pour les cartes TelosB :

$ make telosb
Figure 2.3.2.1.2. : Compilation de Blink.

Source personnelle
14
Enfin, il ne reste qu’à flasher la carte avec ce code en utilisant la commande suivante :
$ make telosb reinstall bsl,/dev/ttyUSB0
Figure 2.3.2.1.3: Flashage de la carte TelosB.

Source personnelle
Après la fin de l’installation, les LEDs de la carte clignotent, ce qui témoigne de la réussite
des étapes précédentes.
Figure 2.3.2.1.4. : Clignotement des LEDs.

Source personnelle
15
2.3.2.2. Oscilloscope et BaseStation
Pour parfaire la prise en main de TinyOS, nous allons maintenant tester un groupe
d’applications : Oscilloscope et BaseStation. En fait, il s’agit ici de faire communiquer deux cartes :
la première émet les données recueillies par son capteur à la seconde qui joue le rôle de station
de base.
Nous commençons par nous déplacer dans le répertoire de l’application Oscilloscope :

$ cd /opt/tinyos-2.1.1/apps/Oscilloscope
Nous la compilons pour TelosB :

$ make telosb
Nous installons Oscilloscope sur la première carte :

Cette carte faisait, auparavant, fonctionner Blink. À la fin du processus, elle ne clignote plus
ce qui confirme son flashage. Nous branchons maintenant la deuxième carte. D’un point de vue
logiciel, elle se situe à l’emplacement /dev/ttyUSB1. C’est ce que nous remarquons en utilisant la
commande motelist.
Figure 2.3.2.2.1. : Commande motelist en présence de plusieurs cartes TelosB branchées.

Source personnelle
Nous allons maintenant installer BaseStation sur la deuxième carte TelosB. Nous nous plaçons
tout d’abord dans le dossier de cette application :
$ cd /opt/tinyos-2.1.1/apps/BaseStation
Nous l’installons sur la deuxième carte :

$ make telosb && make telosb reinstall bsl,/dev/ttyUSB1
Désormais, il nous faut un moyen de récupérer et afficher les données qui sont envoyées
par la première carte. Concrètement, cela se traduit par l’utilisation de deux logiciels :
 Le premier permet d’obtenir les données reçues par la carte où est installé BaseStation.
Il s’agit du programme Serial Forwarder.
 L’autre, nommé Oscilloscope et écrit par des contributeurs au projet TinyOS, se charge
d’afficher les données reçues grâce au programme précédent sous forme de
graphique.
Ces deux logiciels sont écrits en Java. C’est un langage de programmation répandu
aujourd’hui car il s’exécute sur de nombreux systèmes d’exploitation et est plutôt facile à prendre
en main. Pour pouvoir les utiliser, il faut installer les librairies Java pour TinyOS à l’aide de la
commande suivante (exécutée en mode superutilisateur) :
# tos-install-jni
Nous repassons en simple utilisateur et pouvons désormais lancer Serial Forwarder en

tapant :
$ java net.tinyos.sf.SerialForwarder -comm serial@/dev/ttyUSB1:telosb
Cette commande signifie que nous lançons le programme net.tinyos.sf.SerialForwarder dans

une machine java. Nous spécifions que nous voulons communiquer en liaison série avec une carte
TelosB à l’emplacement /dev/ttyUSB1.
16
La fenêtre suivante s’affiche. Elle confirme la bonne marche de la connexion avec la carte
TelosB ainsi que diverses informations sur la liaison série : le numéro de port, le nombre de paquets
lus et écrits.
Figure 2.3.2.2.2. : Serial Forwarder.

Source personnelle
Nous allons désormais lancer Oscilloscope. Pour cela, nous devons tout d’abord nous
placer dans le dossier java de l’application (/opt/tinyos-2.1.1/apps/Oscilloscope/java/) et la
compiler avec la commande :
$ make
Cette étape terminée, nous entrons la commande permettant de démarrer l’application :

$ ./run
Figure 2.3.2.2.3. : Application Oscilloscope.

Source personnelle
Cette fenêtre s’affiche et montre un graphique où apparaissent les valeurs envoyées par la
première carte à la deuxième. Celui-ci est bien entendu actualisé régulièrement en fonction des
nouveaux relevés.
17
Nous pouvons donc dire que nous avons installé l’application Oscilloscope avec succès.
Nous savons désormais flasher les cartes TelosB et avons compris le fonctionnement global
de TinyOS. Nous pouvons, dès lors, nous intéresser à la mise en place du saut de fréquence qui est
le but même de ce projet.
18
3. Mise en place du saut de fréquence
3.1. Les aspects théoriques du saut de fréquence
Le saut de fréquence (en anglais ‘‘frequency hopping’’) est une fonctionnalité intégrée
dans un nouveau standard appelé 802.15.4E. Il s’agit d’une variante de 802.15.4 qui n’est pas
encore finalisée en février 2011.
802.15.4E est un standard qui concerne l’aspect du contrôle de l’accès au medium (MAC*)
de la couche 2 du modèle OSI.
En 802.15.4E repose sur le mécanisme du TDMA* : il faut savoir que tous les nœuds sont tous
mis sur la même fréquence en un instant donné et que le changement se fait de manière
synchronisée. Cela suppose plusieurs éléments :
- Il doit exister une prévision dans l’utilisation des fréquences et du temps.
- Les nœuds doivent être synchronisés dans la mesure du possible.
- Une tolérance doit être introduite dans le temps (des décalages infimes d’horloge
subsisteront), notamment pour laisser le temps au destinataire d’un message de pouvoir
être en écoute.
L’utilisation des canaux avec le saut de fréquence peut être résumée par ce schéma.
Temps Canal 12 Canal 16 Canal 20

Channel Offset
Figure 3.1.1. : Schéma du fonctionnement du saut de fréquence.

Source: Enhancement to IEEE 802.15.4-2006 for Industrial Markets
Nous y observons qu’un lien entre deux nœuds est composé d’un slot de temps et d’un
channel offset. Le channel offset est la différence de fréquence entre la fréquence de référence
de la bande (pour nous 2,400 GHz) et le canal utilisé pour la transmission.
19
Dans cet exemple, nous voyons qu’il existe une supertrame contenant quatre timeslots, les
supertrames étant espacées par des traits plus épais. Chaque timeslot est utilisé pour une
transmission précise entre nœuds capteurs. Cette transmission garde un channel offset constant (la
position de celle-ci dans la grille n’est pas modifiée entre chaque supertrame) mais l’ensemble est
décalé en fréquence lors du changement de supertrame.
La fréquence utilisée à un instant t est donnée par l’équation suivante :
Fréquence = (ASN+Channel Offset)%Nombre de fréquences
ASN signifie Absolute Slot Number. C’est un nombre qui s’incrémente à chaque nouveau
timeslot.
Le channel offset est défini différemment pour chaque lien. Quant au nombre de
fréquences, il dépend de la technologie utilisée. Les réseaux de capteurs sans fil disposent de 16
fréquences qui débutent au canal 11. Ainsi, l’équation sera la suivante :
Fréquence = ((ASN+Channel Offset)%16)+11
Une fonction de translation est chargée de convertir ces données en fréquence réelle.
Notons enfin qu’une trame ADV (Advertisement), non indiquée sur le schéma, est envoyée
par défaut pendant le premier timeslot.
Un projet ayant pour but d’implémenter des protocoles comme 802.15.4E sur des capteurs
sans fil existe : il s’agit d’OpenWSN.
20
3.2. Procédure d’installation
3.2.1. Présentation d’OpenWSN et téléchargement
OpenWSN est un projet lancé fin 2009 qui est mené à l’Université de Berkeley, en Californie.
Il vise à implémenter des protocoles nouveaux ou habituellement inutilisés sur des nœuds capteurs.
Actuellement, deux projets d’implémentation sont menés : l’un, codé en C, prévu pour fonctionner
sur des cartes GINA ; l’autre, codé en NesC, conçu pour TinyOS sur des cartes TelosB.
Application
Présentation sensor.network
Session
Transport TCP, UDP
Réseau RPL
6LoWPAN
Sens de
lecture Liaison de données 802.15.4E
Physique 802.15.4-2006
Figure 3.2.1.1. : Schéma de la pile protocolaire utilisée par l’équipe OpenWSN.

Source personnelle
 802.15.4-2006 : ce protocole vise à remplacer la version de 2003 utilisée auparavant.

L’accent a été mis sur les bandes de fréquences disponibles.
 802.15.4E : protocole de couche liaison de données, il implémente le saut de fréquence

détaillé en partie 3.1.
 6LoWPAN : développé par l’IETF*, ce standard consiste à supprimer une partie des en-
têtes des messages de couche réseau pour les simplifier. Par exemple, en IPv6*, la
version du protocole IP utilisée est envoyée systématiquement dans l’en-tête et est
identique d’un paquet de données à l’autre. Ainsi, 6LoWPAN permet d’économiser des
ressources.
 RPL : développé par l’IETF, RPL (pour Routing Protocol Layer) est le protocole de routage
pour IPv6 dédié aux réseaux à faible énergie et dont les pertes de paquets sont
fréquentes. Il entretient une table où sont enregistrés les nœuds capteurs voisins et le
nœud suivant si la destination n’est pas directement à portée.
 TCP, UDP : ils signifient respectivement Transport Control Protocol et User Datagram
Protocol. Ils n’interviennent qu’à chaque extrémité lors d’un échange, c’est-à-dire que
seuls l’émetteur initial du message et le destinataire final sont concernés.
 sensor.network : C’est le protocole qui va sauvegarder et échanger les données

recueillies par le capteur.
21
Comme TinyOS, OpenWSN est un projet libre. Pour le télécharger, il faut utiliser le système
SVN*. En effet, c’est un projet qui évolue rapidement et dont chaque fichier est amélioré un à un. Il
n’y a donc pas, contrairement à la plupart des projets, de version précise. Nous téléchargeons
juste le projet à l’état où il se trouve à la fin décembre 2010.
Nous commençons par installer le paquet subversion sur notre machine virtuelle Debian. Il
faut tout d’abord se connecter en mode superutilisateur :
$ su
Puis entrer :
# aptitude install subversion
Nous procédons maintenant au téléchargement des fichiers du projet OpenWSN :

$ svn co http://openwsn.berkeley.edu/svn/ openwsn
o svn : appel du logiciel subversion.
o co : correspond à ‘‘checkout’’ : c’est la récupération des fichiers d’un serveur.
o http://openwsn.berkeley.edu/svn/ : adresse à laquelle se trouvent les fichiers à
télécharger.
o openwsn : emplacement où mettre les fichiers téléchargés. Nous choisissons de
créer un répertoire openwsn.
Figure 3.2.1.2. : Téléchargement d’OpenWSN avec Subversion.

Source personnelle
Nous allons dans le répertoire openwsn et observons que deux parties se présentent à nous :
 la première est une partie software* qui contient des applications en Python* relatives
aux réseaux de capteurs.
 la deuxième est une partie firmware* qui contient les deux implémentations pour les
cartes GINA et les cartes TelosB.
L’implémentation pour TinyOS et cartes TelosB se présente sous la forme d’une application. Il
nous faut donc la déplacer dans le répertoire ‘‘apps’’ de TinyOS à l’aide de la commande
suivante :
$ cp -r openwsn/firmware/tinyos-2.x/apps/OpenWSN/ /opt/tinyos-2.1.1/apps/
Maintenant qu’OpenWSN est présent dans l’environnement de travail, nous allons

maintenant étudier les aspects relatifs au saut de fréquence dans son code.
22
3.2.2. Étude du code et modifications apportées
Vis-à-vis du code, la première chose que nous avons remarquée est que les différentes
parties du code sont rangées par couche du modèle OSI correspondante.
Figure 3.2.2.1. : Liste des fichiers et dossiers d’OpenWSN.

Source personnelle
Le code qui nous intéresse concerne la partie MAC de la couche 2 du modèle OSI. C’est
donc à celui-ci que nous allons apporter des modifications : en conséquence, nous faisons tout
d’abord une sauvegarde de la configuration par défaut.
$ cp -r 02a-MAC/ 02a-MAC.old.d/
Pour étudier le code source d’OpenWSN, il nous est préférable d’utiliser un éditeur de texte
puissant, capable d’afficher la coloration syntaxique (par exemple les variables en rouge, les
fonctions en bleu … pour plus de clarté). Nous installons Geany.
Nous commençons par entrer en mode superutilisateur :
$ su
Puis nous installons Geany avec aptitude :
# aptitude install geany
Notre objectif est alors de rechercher quelles portions de codes sont concernées par le
phénomène du saut de fréquence. Pour ce faire, nous avons créé un script bash servant à afficher
dans Geany tous les fichiers contenant une chaîne entrée par l’utilisateur.
#!/bin/bash Shell à utiliser.

Initialisation de la variable
listefichier=""
‘‘listefichier’’ à chaîne vide.
Affichage de ‘‘Chaîne à
echo "Chaîne à rechercher ?"
rechercher’’.
read chaine Lecture de la réponse.
Écriture des noms de tous les fichiers
find $TOSROOT/apps/OpenWSN/ -name "*.h" > result source d’OpenWSN dans un fichier
find $TOSROOT/apps/OpenWSN/ -name "*.c" >> result ‘‘result’’.
find $TOSROOT/apps/OpenWSN/ -name "*.nc" >> result >> permet de ne pas écraser le
fichier mais d’écrire à la suite.
Parcours du fichier ‘‘result’’ créé
for i in `cat result`; do
précédemment.
Ouverture de chaque fichier source
if ( cat $i | grep $chaine ); then et vérification de la présence de la
chaîne recherchée.
Si la chaîne est trouvée dans un
listefichiers="$listefichiers $i" fichier alors le nom de ce dernier est
ajouté à ‘‘listefichiers’’
fi Fin de la boucle if
done Fin de la boucle for
Les fichiers contenant la chaîne
geany $listefichiers
voulue sont ouverts dans geany*.
rm result Le fichier ‘‘result’’ est supprimé.
Le script quitte en retournant 0 ce qui
exit 0
signifie qu’il n’a pas fait d’erreur.
23
Dès lors, nous avons utilisé certains mots clés comme ‘‘hopping’’ pour pouvoir aborder de
manière efficace le code d’OpenWSN.
Nous sommes rapidement arrivés à identifier les portions impliquant le saut de fréquence. La
première d’entre elles est la ligne 5 d’OpenWSN.h. Ce fichier définit les paramètres globaux
d’utilisation d’OpenWSN, par exemple activer ou désactiver une fonctionnalité sur le réseau de
capteurs. Le saut de fréquence fait partie de ces paramètres. Il est nommé ‘‘HOPPING_ENABLED’’.
Par défaut, celui-ci est à FALSE, c’est-à-dire qu’il est désactivé. Nous choisissons de l’activer en
passant la valeur à ‘‘TRUE’’.
Figure 3.2.2.2. : Activation du saut de fréquence dans OpenWSN.h.

Source personnelle
Dans le répertoire 02a-MAC, un sous-répertoire nommé ‘‘IEEE802154E’’ existe. Il contient trois

fichiers :
- IEEE802154EC.nc sert à appeler les fonctions utilisées par 802.15.4E.
- IEEE802154E.h définit les paramètres du saut de fréquence (par exemple, la taille d’une
supertrame).
- IEEE802154EP.nc met en œuvre le saut de fréquence.
C’est dans ce dernier fichier, ligne 275, que se trouve la formule du saut de fréquence
expliquée en partie 3.1.
Comme attendu, elle est la suivante :
atomic frequencyChannel = ((temp_asn+temp_channelOffset)%16)+11;
Le canal de fréquence à utiliser est égal à l’addition du numéro absolu de slot et du
channel offset, modulo 16, plus 11.
Il nous reste à vérifier un paramètre pour avoir un réseau de capteurs cohérent : il faut en
effet qu’il possède un coordinateur, ici appelé DAGroot ou Sink dans le cadre d’OpenWSN. C’est
lui qui définit les règles pour que les nœuds capteurs puissent communiquer entre eux de manière
harmonieuse.
Le choix du DAGroot se fait dans le fichier cross-layers/idmanager/IDmanagerP.nc, ligne
133.
Figure 3.2.2.3. : Définition d’un DAGroot statique.

Source personnelle
Initialement commentée, cette portion de code indique qu’il est possible de définir un
nœud qui se définisse DAGroot de par son TOS_NODE_ID. Par défaut, le TOS_NODE_ID du DAGroot
est fixé à 18 mais n’ayant pas tant de nœuds capteurs, nous choisissons 2. Ainsi, en décommentant
ces lignes, lorsque nous installerons OpenWSN sur une carte en spécifiant 2 comme TOS_NODE_ID,
celle-ci sera DAGroot.
Ayant effectué les modifications voulues sur le code, nous pouvons désormais passer à son
installation sur les cartes. Nous choisissons de brancher deux cartes auxquelles nous attribuerons
respectivement comme adresses (ou plus techniquement TOS_NODE_ID) 1 et 2.
Nous commençons par compiler OpenWSN. Nous nous plaçons dans le répertoire
d’OpenWSN :
$ cd $TOSROOT/apps/OpenWSN
24
Puis nous entrons :

$ make telosb
Enfin, nous flashons les deux cartes :

$ make telosb reinstall.1 bsl,/dev/ttyUSB0
$ make telosb reinstall.2 bsl,/dev/ttyUSB1
TOS_NODE_ID
OpenWSN étant une application beaucoup plus importante en terme de place que les
autres applications TinyOS testées précédemment, cette opération prendra significativement plus
de temps.
25
3.3. Observation
3.3.1. De manière logicielle
Par observation de manière logicielle, nous entendons l’utilisation d’outils s’exécutant sur
l’ordinateur sur lequel sont branchées les cartes TelosB. Il s’agit de l’étape de projet qui nous a posé
le plus de difficultés. En effet, nous avons commencé par tenter d’utiliser Wireshark avec des outils
TinyOS pour capturer. Ces essais se sont avérés infructueux. Enfin, la communication avec l’équipe
de Berkeley nous a amenés à tester leur solution : OpenVisualizer.
Avec un analyseur de trafic : Wireshark
Figure 3.3.1.1. : Schéma de l’expérimentation.

Source personnelle
Wireshark est un logiciel libre utilisé pour analyser le trafic circulant sur un réseau. On parle
aussi de ‘‘paquet sniffer’’. Il est communément employé dans le but de dépanner un réseau,
étudier un protocole ou encore pirater.
L’un de ses avantages est aussi sa modularité : il est possible d’y adjoindre des plugins,
c’est-à-dire des bouts de code dont le but est d’amener une fonctionnalité supplémentaire au
logiciel.
Les deux objectifs recherchés ici sont les suivants : tout d’abord, faire en sorte que nous
puissions utiliser une carte comme interface permettant la capture. Puis, de pouvoir analyser ce qui
serait capturé. Le premier objectif serait rempli en installant l’application PacketSniffer_802_15_4 sur
une carte TelosB. Pour le deuxième objectif, nous allons utiliser son plugin Wireshark correspondant.
Celui-ci ne fonctionne qu’avec la version 1.0.0.
Nous allons tout d’abord installer Wireshark avec le plugin PacketSniffer_802_15_4. La

méthode choisie est la compilation : en effet, si on utilise un plugin alors nous devons ‘‘construire’’
l’application en intégrant le code apporté par le plugin. Nous commençons par nous rendre sur le
site officiel du logiciel (http://www.wireshark.org/) et téléchargeons l’archive contenant son code
source.
Nous la décompression avec la commande suivante :
$ tar –xz wireshark-1.0.0.tar.gz
 l’option x indique que l’on souhaite décompresser l’archive.
 z signifie que gunzip (le logiciel de décompression des fichiers gz) est utilisé.
Nous allons maintenant à l’adresse du projet PacketSniffer_802_15_4 qui est la suivante :

http ://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x-contrib/tub/apps/PacketSniffer_802_15_4/wiresharkPlugins/
26
Nous téléchargeons le contenu du dossier. Celui-ci est au format .tar.gz comme l’archive
Wireshark. Nous décompressons le fichier.
$ tar –xz index.html?view=tar
Un répertoire wiresharkPlugins en contenant quatre autres a été créé. Ces quatres
répertoires correspondent aux éléments matériels et logiciels de la carte TelosB
Nous nous plaçons maintenant dans celui de Wireshark.
$ cd wireshark-1.0.0
Les commandes suivantes permettent de copier intégralement les plugins fournis par
PacketSniffer_802_15_4 dans le répertoire de plugins de Wireshark.
$ cp –ra ../wiresharkPlugins/802_15_4/ plugins/
$ cp –ra ../wiresharkPlugins/cc2420/ plugins/
$ cp –ra ~/wiresharkPlugins/t2sf/ plugins/
$ cp –ra ~/wiresharkPlugins/t2am/ plugins/
Désormais, nous allons déclarer les quatre plugins pour qu’ils soient pris en compte lors de la
compilation de Wireshark. Cette opération consiste à modifier les fichiers de configuration de la
compilation. Pour cela, nous utilisons à nouveau Geany.
Dans le fichier configure, nous ajoutons ceci à la ligne 31812. Il s’agit de la section
ac_config_files, l’endroit où les Makefiles (fichiers indiquant la procédure de compilation) de
chaque plugin sont indiqués.
plugins/802_15_4/Makefile
plugins/cc2420/Makefile
plugins/t2sf/Makefile
plugins/t2am/Makefile
Dans le fichier Makefile.in, ligne 333, il existe une section SUBDIRS où sont indiqués les plugins
où la compilation doit avoir lieu. Nous ajoutons donc ceci.
802_15_4 \
cc2420 \
t2sf \
t2am \
Figure 3.3.1.2 : Ajout des répertoires des plugins dans Makefile.in.

Source personnelle
Nous pouvons désormais passer à la compilation. Pour ce faire, nous passons en mode
superutilisateur :
$ su
La première étape est de lancer le script configure pour vérifier que l’ensemble des
éléments nécessaires sont présents. Nous indiquons par la même occasion, avec l’option prefix,
que nous souhaitons installer Wireshark dans le répertoire /opt/wireshark.
# ./configure --prefix=/opt/wireshark
27
Figure 3.3.1.3. : Étape de configuration de Wireshark.

Source personnelle
Puis nous compilons les fichiers et installons l’application :

# make
# make install
Désormais, nous allons lancer l’application et vérifier que le plugin 802.15.4 soit bien présent.
Nous nous rendons dans /opt/wireshark. Le fichier exécutable se trouve dans le sous-répertoire bin.
Nous tapons donc :
# cd /opt/wireshark/bin
# ./wireshark
Une fois Wireshark ouvert, nous allons dans Analyze > Enabled protocols. Nous remarquons
que 802.15.4 est bien pris en charge.
28
Figure 3.3.1.4. : Protocoles activés dans Wireshark.

Source personnelle
Nous allons maintenant installer PacketSniffer_802_15_4 sur la carte TelosB qui n’a pas
OpenWSN. Pour ce faire, nous commençons par télécharger l’application sur le dépôt sourceforge
à la même adresse que précédemment.
Nous désarchivons ce que nous venons de télécharger :
$ tar –xz index.html?view=tar
Un répertoire PacketSniffer_802_15_4 a été créé. Nous le déplaçons dans le dossier des
applications de TinyOS :
$ mv PacketSniffer_802_15_4 $TOSROOT/apps/
Nous allons compiler l’application :
$ cd $TOSROOT/apps/PacketSniffer_802_15_4
$ make telosb
Nous rencontrons alors des problèmes : l’application ne compile pas. De nombreuses

erreurs relatives au code s’affichent. Cela est probablement dû à la différence de version entre le
TinyOS de notre installation et celui de l’époque où le PacketSniffer a été écrit (il y a plus d’un an).
29
Figure 3.3.1.6. : Compilation de PacketSniffer_802_15_4.

Source personnelle
Nous décidons de continuer avec les outils classiques de TinyOS et notamment BaseStation.
Comme dans la deuxième partie du rapport de projet, nous nous plaçons dans le répertoire
de l’application BaseStation et flashons la carte avec ce code :
$ cd $TOSROOT/apps/BaseStation
A ce stade, nous plaçons des piles dans la carte flashée avec OpenWSN. Celle-ci se met en
marche. Nous lançons SerialForwarder sur l’ordinateur :
$ java net.tinyos.sf.SerialForwarder -comm serial@/dev/ttyUSB0:telosb
Pour vérifier si des données sont reçues, nous lançons un outil basique qui affiche les
données recueillies via la carte TelosB. Il se nomme Listen. Nous le lançons avec cette commande :
$ java net.tinyos.tools.Listen

Source personnelle
Rien n’apparaît, même au bout de plusieurs secondes. Cela signifie que les outils de TinyOS
sont incompatibles avec OpenWSN. Il nous a fallu trouver un autre moyen logiciel pour observer le
saut de fréquence.
30
OpenVisualizer

Source personnelle
Le seul outil logiciel viable pour observer et analyser les événements au niveau de la
couche MAC dans un réseau à base de nœuds capteurs exécutant OpenWSN est OpenVisualizer.
Il se trouve dans la partie software du projet OpenWSN et est codé en langage Python.
Nous nous rendons dans le répertoire où nous avons précédemment téléchargé OpenWSN
avec Subversion puis allons dans openwsn/software/openvisualizer. Pour lancer OpenVisualizer,
nous entrons :
$ python openVisualizer.py
Nous rencontrons alors une erreur de segmentation.
Figure 3.3.1.9. : Erreur de segmentation avec OpenVisualizer sous Linux.

Source personnelle
Le problème réside dans le fait que cette erreur peut avoir de nombreuses sources et, de
plus, elle n’est pas explicite : elle ne dit pas ce qui est à l’origine du problème (le code ou les
logiciels installés sur l’ordinateur qui ne sont pas à une version valide ou compatible).
Afin de résoudre, ou plutôt contourner le problème, nous décidons d’utiliser un autre

système d’exploitation. En effet, alors que TinyOS est plutôt lié au monde Linux, les outils OpenWSN
sont plutôt associés à Windows – c’est en tout cas ce que l’on peut voir sur le site d’OpenWSN où
les captures d’écran montrent que les travaux sont menés sous ce système d’exploitation.
Nous utiliserons Windows Server 2003 du fait de sa stabilité et sa rapidité. De plus, nous
pouvons en prendre les licences de l’Institut Universitaire de Technologie. L’installation de Windows
Server est disponible à l’annexe III de ce rapport. Ainsi, nous passons directement au déploiement
du plan de travail.
31
L’installation de notre environnement sous Windows passera par quatre étapes : les
installations de Python, PythonSerial, le téléchargement d’OpenWSN par SVN et le test des logiciels.
Figure 3.3.1.10 : Logo de Python.

Source Google Images
Installation de Python :
Sur le site d’OpenWSN, la version 2.5.4. de Python est recommandée pour utiliser
OpenVisualizer. Nous nous rendons sur www.python.org pour la télécharger.
Une fois l’exécutable téléchargé, nous double cliquons sur ce dernier : l’installation
commence après l’acceptation du contrat de licence.
Figure 3.3.1.11 : Installation de Python.

Source personnelle.
L’installation se poursuit et se termine.
Installation de PythonSerial :
Ce programme permet de prendre en charge les communications par port série. Nous
installons la version 2.5rc1 que nous téléchargeons sur pyserial.sourceforge.net.
L’installation se déroule de manière analogue à celle de Python.
32
Figure 3.3.1.12 : Installation de PythonSerial.

Source personnelle.
Une fois celle-ci terminée, nous passons à l’ajout d’OpenWSN sur le système ainsi que la
phase de test des logiciels que nous venons d’installer.
Installation d’OpenWSN :
Afin d’éviter toute discordance dans les versions, nous choisissons de réutiliser celle que
nous avons déjà téléchargé sous Debian. Nous ne ferons donc qu’un simple copier-coller du
répertoire software d’OpenWSN sur le bureau Windows.
Test de l’environnement de travail :

Ce test est très simple, il suffit de double cliquer sur le fichier test_python_installation.py
présent dans openwsn/software/testing. L’écran suivant s’affiche alors.
Figure 3.3.1.13 : Test de l’installation de Python et PythonSerial.

Source personnelle.
33
Nous pouvons maintenant lancer OpenVisualizer. Pour ce faire, nous double cliquons sur
openVisualizer.py qui est dans openwsn/software/openvisualizer.
La fenêtre suivante s’affiche.
Figure 3.3.1.14. : OpenVisualizer.

Source personnelle.
Dans le volet de gauche, en haut, figure un plan où sont disposés les bureaux de l’équipe
de développement d’OpenWSN. Les deux cartes (0x1 et 0x2, correspondant aux TOS_NODE_ID 1 et
2) sont présentes à l’emplacement du bureau de Thomas.
En bas figurent des messages d’information sur l’état du réseau et des nœuds capteurs.
Entre les deux, des cases à cocher avec les adresses des cartes permettent d’afficher ou non plus
d’informations sur celles-ci dans le volet de droite.
Le volet de droite laisse apparaître des informations détaillées sur les cartes connectées à
l’ordinateur. Nous voyons notamment si le nœud capteur est DAGroot, quels sont ses voisins et
quelle séquence (incluant l’envoi et la réception) va s’appliquer.
Nous observons tout d’abord que la carte TelosB ayant l’adresse 2 n’est pas DAGroot,
contrairement à ce qui est attendu. Ainsi, même si elles se voient entre elles (une ligne apparaît
dans la partie ‘‘neighbors’’), elles sont incapables de s’échanger des données. L’une d’elles doit
être DAGroot pour qu’elles puissent s’échanger des messages. Il est théoriquement possible
d’injecter des messages TCP et UDP sur le réseau via les boutons TCPInject et UDPInject.
Malheureusement, en les cliquant, des erreurs liées à la longueur du buffer (‘‘error inputBuffer
lenght’’) apparaissent. À ce jour (le 12 février 2010), nous ne savons pas comment résoudre ces
erreurs. Nous ne savons pas non plus si elles sont liées entre elles.
34
3.3.2. Avec du matériel adapté
Si nous reprenons l’aspect théorique du saut de fréquence, nous observons que l’ensemble
des messages est décalé en fréquence d’une supertrame à l’autre. Nous en concluons que la
trame ADV (Advertisement) qui consiste à informer de la présence du nœud change elle aussi de
fréquence.
Notre but, ici, est d’aller au plus simple : nous voulons montrer qu’au moins deux fréquences
peuvent être utilisées par une carte pour émettre une trame advertisement (c’est en effet le seul
type de trame envoyé, étant donné l’absence d’autre élément dans le réseau). Bien sûr, le
paramètre qui doit entrer en jeu ici est temp_asn. C’est le décalage du numéro de slot de temps
qui doit changer la variable frequencyChannel. Cela est possible à deux conditions :
- Le channel offset doit être à 0. C’est le cas car les trames advertisement sont
typiquement envoyées sur le premier canal.
Figure 3.3.2.1 : Supertrame 80215.4E avec trame advertisement émise sur le canal 0 (cas typique).
Source : Thomas Watteyne, introduction to Wireless Sensor Networks
- Le nombre de slots qui composent une supertrame doit être impair. Si celui-ci était pair,
sachant que seules deux fréquences sont possibles, alors la division modulo 2 de
temp_asn resterait nulle et la trame adv serait toujours transmise sur le même canal. Par
exemple, si la supertrame a quatre slots de temps :
o A la première supertrame : temp_asn = 0 => (temp_asn+channel offset)%2 = 0.
o A la deuxième supertrame : temp_asn = 4 => (temp_asn+channel offset)%2 = 0
Nous vérifions si le nombre de slots d’une supertrame est bien impair. C’est dans le fichier
IEEE802154E.h que nous en obtenons la réponse :
Figure 3.3.2.2 : Valeur de la taille de la supertrame.

Source personnelle
La valeur est en hexadécimal. 1F signifie 31 en décimal.
Nous allons désormais modifier le code correspondant à la valeur des fréquences utilisées.
Au lieu d’avoir une variation modulo 16, celle-ci sera modulo 2. Le code devient ainsi le suivant
dans IEEE802154EP.nc :
Figure 3.3.2.1. : Formule du saut de fréquence modifiée dans IEEE802154EP.nc.

Source personnelle
35
Passons désormais aux expérimentations.
Le matériel que nous allons utiliser est un analyseur de spectre Rohde & Schwarz FSIQ.
Figure 3.3.2.2. : Photo du FSIQ en cours de démarrage.

Source personnelle.
Celui-ci a récemment été acquis par l’Institut Universitaire de Technologie. C’est le plus
avancé disponible au département Réseaux et Télécommunications. Il est capable d’analyser le
spectre de fréquences s’étalant de 20 Hz à 3,5 GHz. Il exécute le système d’exploitation Windows
NT.
Après son démarrage, nous modifions les paramètres suivants :

- Fréquence centrale : 2,45 GHz.
- Span (étendue d’analyse autour de la fréquence centrale) : 100 MHz. On analyse donc
les fréquences de 2,4 à 2,5 GHz.
- Niveau de référence : -43 dBm (on ne s’attend pas à dépasser les -60 dBm de puissance
de réception pour les trames envoyées par la carte TelosB).
- Coupling swipe time : 560 ms. Cette valeur correspond au temps mis par l’analyseur de
spectre pour relever le gain sur la plage de fréquences observée.
- Persistance : nous l’activons car, si nous la laissons désactivée comme c’est le cas par
défaut, alors nous ne pourrions jamais observer simultanément les deux raies
correspondant aux fréquences où les trames advertisement sont émises.
36
Figure 3.3.2.3. : Relevé du spectre de fréquences de 2,4 à 2,5 GHz.

Source personnelle.
Nous observons deux raies à la même puissance. L’une est à 2,40624 GHz (soit environ
2,405), l’autre à 2,40941 GHz (environ 2,410).
Le premier canal de WiFi est 2,12 GHz. Quant à Bluetooth, s’il opérait pendant nos
expérimentations alors nous verrions de nombreuses raies espacées de 1 MHz chacune (Bluetooth
pratiquant lui aussi le saut de fréquence. Les raies observées ne peuvent donc être originaires de
ces types de réseaux.
Le saut de fréquence est donc bien mis en œuvre.
37
4. Bilan du projet
4.1. Les résultats obtenus
Les résultats que nous avons obtenus ne sont pas probants d’un point de vue logiciel mais le
sont si l’on se réfère à nos expérimentations avec un analyseur de spectre.
Ainsi, nous considérons avoir répondu correctement au sujet posé ; il reste cependant à
éclaircir toute la partie logicielle encadrant OpenWSN pour pouvoir, par exemple, analyser
effectivement le comportement d’un réseau de capteurs utilisant le protocole 802.15.4E.
Un point positif important par rapport à ce projet est qu’il a permis de nouer un contact
avec l’équipe en charge d’OpenWSN à l’Université de Berkeley : celui-ci nous a d’ailleurs été
nécessaire et particulièrement utile pour comprendre le mode de fonctionnement, les enjeux et les
buts d’OpenWSN.
Cependant, nous n’avons pas obtenu ces résultats facilement. Nous avons ainsi, durant
notre projet, rencontré des difficultés souvent bloquantes.
4.2. Un contexte expérimental
Les capteurs sans fil étaient, à l’origine, inconnus pour nous. Nous ne les avions pas étudiés
avant le seul cours sur les réseaux de capteurs enseignés lors du cursus en Réseaux Sans Fil et
Sécurité.
Dans ce domaine, le mode de pensée est tout autre que pour l’informatique traditionnelle.
Le langage de programmation et les outils sortent de l’ordinaire de l’administrateur système. Ainsi,
pour chaque problème rencontré, même mineur, nous étions incapables de le résoudre en faisant
appel à nos seules connaissances.
De plus, la documentation se fait plutôt rare si l’on exclut les documents de l’IEEE, ce qui
compliquait d’autant plus la résolution des problèmes lorsque nous devions y faire face.
Nous avons donc exploité beaucoup de pistes vainement, notamment quand il a été
question de sniffer : Wireshark a été une fausse piste, tout comme la volonté d’utiliser des outils de
TinyOS pour écouter un réseau OpenWSN. Nous avons appris, sans doute trop tard, qu’il y avait
incompatibilité entre les outils ‘‘natifs’’ de TinyOS et ceux d’OpenWSN.
Nous avons enfin rencontré quelques bugs, dont le plus contraignant a été l’erreur de
segmentation d’OpenVisualizer sous Debian : cela nous a contraint jusqu’à changer de système
d’exploitation pour nos expérimentations.
Voyons désormais quelles sont les pistes pour continuer notre travail.
4.3. Les prolongements possibles
La première chose à faire pour prolonger notre travail est d’avoir une carte DAGroot dans
le réseau. Cela aura deux effets directs : d’une part, le réseau de capteurs fonctionnant avec
OpenWSN sera fonctionnel. D’autre part, on pourra alors démontrer probablement de manière
logicielle (avec OpenVisualizer) l’existence du saut de fréquence.
Une piste intéressante pour prolonger notre travail serait de mettre en œuvre d’autres
éléments de la pile protocolaire d’OpenWSN. Par exemple, pourquoi ne pas étudier le routage RPL
sur TelosB ? Cela peut donner lieu à des expériences.
38
Conclusion
En guise de conclusion, nous pouvons tout d’abord dire que les besoins en termes de
capteurs sans fil grandissent rapidement. Il s’agit d’un domaine nouveau où les entreprises et les
institutions se montrent très intéressées par leurs possibilités. La licence professionnelle Réseaux Sans
Fil et Sécurité permet de répondre aux problématiques soulevées par les réseaux de capteurs, un
cours étant dispensé dans cette matière durant le cursus.
Nous avons commencé par découvrir TinyOS : il s’agit d’un système d’exploitation
fonctionnant sur de nombreux matériels de capteurs sans fil. Sur un ordinateur, c’est en fait un
environnement de travail complet, composé de nombreuses applications destinées aux capteurs.
Une fois son installation terminée sur notre ordinateur de travail, nous nous sommes intéressés au
matériel qui nous a été prêté : des cartes TelosB. Celles-ci possèdent de nombreux éléments,
contrairement à l’idée classique qui est faite d’un capteur sans fil. Pour prendre en main TinyOS et
les cartes, nous avons décidé d’installer les applications basiques que sont Blink, BaseStation et
Oscilloscope.
Puis nous avons étudié le standard du saut de fréquence, 802.15.4E, ainsi que le moyen
permettant de le faire fonctionner sur les cartes TelosB : OpenWSN. Nous y avons apporté les
modifications que nous avons jugées utiles. Il nous fallait alors mettre en évidence de manière
expérimentale le saut de fréquence au travers de moyens logiciels et matériels.
Les résultats les plus significatifs concernent nos expérimentations à l’aide de l’analyseur de
spectre. Le contexte de notre projet étant expérimental, nous avons été confrontés à des erreurs
qui ont retardé notre avancée. Enfin, notre projet peut être prolongé en observant effectivement
le saut de fréquence avec OpenVisualizer ou encore en étudiant d’autres protocoles d’OpenWSN.
39
Questionnaire en anglais
PROJECT TITLE : Frequency hopping in wireless sensor networks
START DATE : Friday, October 21st 2010
END DATE : Friday, February 18th 2011
PROJECT SUPERVISOR : Gérard Chalhoub
Question One : Where did you do your project ?

In order to graduate from university we have to do a sixteen-week project. This was done at the IUT
(University Institute of Technology) even though most of our work was done at home. Given that we
were provided the necessary tools needed to make an efficient wireless sensor network (WSN), we
prefered working in a calmer and quieter place than the IUT.
Question Two : Who did you work with/ for ?

We, Aurore Vergne and Rémi Voirin, are the only people involved in this work along with our project
supervisor : Gérard Chalhoub, teacher in networking and wireless communications.
However, some help was provided by several people from our class, including Christian
Courtecuisse. And finally, Mr. Coursimault, teaching telecommunications and electronics at the
Networks and Telecommunications department, helped us using the spectrum analyzer.
Question Three : What were you asked to do ?

We were asked to study how the frequency hopping in wireless sensor network works. This is a new
feature in such networks as the standard describing it is not validated yet.
This project involves looking at the code which allows the nodes to change from a channel to
another, and thus analyzing it.
To do it, we were given three TelosB motes. It is possible to write any code we want on them, so we
were free with our experiments.
Question Four : Explain in stages what you did.

Our first step was to discover what exactly a TelosB mote is. For instance, we learnt that multiple
sensors (light, humidity and infrared) are present on each mote
Then, we had to set up our work environment. It is made up of a computer with an operating
system. We chose Linux Debian for its stability and reliability. We also had to install TinyOS. It’s the
operating system of most models of motes, including TelosB. TinyOS is designed to run on slow
hardware and to use very few energy. At this time, we were able to test the work environment by
putting basic applications on the motes.
The third thing we did was trying to implement the frequency hopping. It is done by using a specific
application called OpenWSN. We studied the part of the code which enables this feature, and
changed a few parameters in order to fit our needs. For example, we had to declare a master
node called DAGroot – the one which coordinates the time and provides synchronization.
Finally, we tried to see the frequency hopping in action, firstly with appropriate software, secondly
with a spectrum analyzer.
Question Five : Did you have any problems ?

We encountered several problems during our experiments. In fact, as sensor networks are a new
field of study for both of us, we had to learn how to deploy them with TelosB motes from scratch. So
it took time for us to fully understand what our subject was about and to begin working efficiently.
We also had problems proving that frequency hopping works. We first took the wrong tools to do it
and had errors while using the appropriate application called OpenVisualizer. We bypassed these
problems by using a spectrum analyzer.
40
Question Six : Was your work successful ?

In a way, yes. Although we weren’t able to make the piece of software dedicated to analyze the
network, watching what’s happening on the frequency spectrum allowed to prove that the
frequency hopping was implemented.
Moreover, one of our goals was to learn how common WSN and TelosB motes work, which we did
well.
Question Seven : How could your work be continued by another student ?

Our work could be continued by another student by finding a way to solve the problems we had
with OpenVisualizer. We think this could be done by getting in touch with the OpenWSN
development team based at the University of Berkeley, which is what we started to do by the
beginning of February.
Question Eight : What technical skills did you gain from doing this project ?
The first technical skill we gained from doing this project is a better understanding of the current
development status of wireless sensor networks. We think it’s important because this kind of
networks is going to be more and more used in the military industry, the medical field or even in
agriculture.
This project also involved computing skills, which we improved since we had to put command-line
instructions and to compile programs in order to make them work.
Question Nine : What other skills did you obtain ?

Both of us obtained human skills. We developed our sense of cooperation and teamwork. Because
people can’t always agree, we had to find a common ground.
In addition, the fact that we had to face complex problems improved our ability to structure a
complete solution.
Question Ten : Was the project linked to your future studies or your future career ?
This project might be linked to our future studies or future career. In fact, the WSN market is growing
very fast. Therefore, by working in network administration, it’s probable that we meet them again in
the next few years.
41
Glossaire
Bit Unité de mesure en informatique. C’est la plus petite quantité
d’information pouvant être traitée par un ordinateur. Elle
correspond à un chiffre binaire, 0 ou 1.
Compiler Action de convertir du code compréhensible par l’homme en
code compréhensible par la machine (du binaire).
Firmware On désigne par firmware un micrologiciel, c’est-à-dire un petit
programme ayant pour but de fonctionner sur un composant
matériel souvent de faible puissance.
Flasher Écrire un logiciel à partir de zéro sur une carte.
GHz Giga Hertz
Unité de mesure de la fréquence.
1 GHz = 109 Hertz =1 000 000 000 Hertz
IEEE Institute of Electronical and Electronic Engineers
Se dit ‘‘I 3 E’’
Organisme américain de normalisation.
IETF Internet Engineering Task Force
En Français, on parle de ‘‘Détachement d’Ingéniérie
d’Internet’’. Il s’agit d’un groupe participant à l’élaboration des
standards utilisés sur Internet.
IPv6 IPv6 est un protocole de réseau. Il permet d’attribuer des
adresses aux différents composants d’un réseau.
Kb/s Kilobits par seconde
Vitesse de transfert de données.
Un bit correspond à un 0 ou un 1.
1 Kb = 1024 bits
Langage C Langage de programmation apparu dans les années 1970 qui
a servi à coder UNIX. Toujours très utilisé, il est surtout dédié à la
programmation système mais des langages modernes comme
C++, Java ou PHP en reprennent certains aspects.
MAC Pour Medium Access Control (contrôle de l’accès au medium),
c’est une technologie de couche 2 qui gère le moment où la
carte va émettre ou recevoir ainsi que la fréquence à utiliser.
Médium Support de communication.
Exemple : fibre optique, câbles en cuivre, air.
MHz Méga Hertz
Cf. GHz
1 MHz = 106 Hertz = 1 000 000 Hertz
Modèle OSI Norme définie par l’ISO (International Standard Institute,
organisme de normalisation internationale) afin de permettre
l’interconnexion de systèmes hétérogènes (ex : un ordinateur,
un téléphone, …).
Modèle comportant 7 couches.
Applications
Présentation
Session
Transport
Réseau
Liaison de données
Physique
Paquet Unité d’information relative à la couche 3 du modèle OSI

utilisée pour communiquer sur un réseau.
42
Protocole Ensemble de règles régissant la communication entre deux

systèmes pour qu’ils se comprennent.
Python Langage de programmation apparu en 1990 et fonctionnant
sur différents systèmes d’exploitation. Son avantage est de
proposer une syntaxe simple pour le programmeur.
Série (liaison, port) Transmission lors de laquelle les bits sont envoyés un à un sur le
médium, sans synchronisation de l'horloge entre les deux
périphériques.
Software Terme anglais désignant le logiciel. C’est une application
informatique ayant pour but d’assister l’utilisateur dans une de
ses activités.
Système d’exploitation Ensemble d’applications servant d’interface entre le matériel et
l’utilisateur.
Exemple : Windows XP, Mac OS X, Debian, …
SVN Abréviation de ‘‘Subversion’’. C’est un acronyme désignant un
système de gestion de version dédié aux mainteneurs de
projets. Pour les utilisateurs, l’intérêt est de pouvoir
synchroniser/mettre à jour une application locale (sur son
ordinateur) avec un serveur distant en une seule commande.
TDMA Time Division Multiple Access
Méthode d’accès où tous les éléments d’un réseau utilisent la
même fréquence et se partagent le temps à tour de rôle pour
émettre.
Variable d’environnement Variable utilisée par plusieurs programmes. On les compare aux
variables locales qui, elles, ne sont valides que dans un seul
programme.
43
Bibliographie
Publications :
Gérard CHALHOUB, Réseaux de Capteurs Sans Fil, décembre 2009
Thierry VAL, Eric CAMPO, Adrien VAN DEN BOSSCHE, Technologie ZigBee / 802.15.4 : Protocoles,
topologies et domaines d’applications, mai 2008
William STALLINGS, Operating Systems: Internals and Design Principles, Pearson Prentice Hall, 2008
Documentation interne :
Stéphane ROICOMTE, Étude des mécanismes de synchronisation dans un réseau de capteurs sans
fil, Juin 2010
Sites web :
Debian :
Site officiel de Debian : www.debian.org
Cours sur les réseaux de capteurs sans fil

http://igm.univ-mlv.fr/~dr/XPOSE2006/Bunel/
http://tice.utc.fr/moodle/file.php/498/support-SIT60.pdf
Installation de TinyOS :
Wiki du LIMOS (accessible uniquement en Intranet)
http://docs.tinyos.net/index.php/Main_Page
http://fr.wikipedia.org/wiki/TinyOS
Saut de fréquence :
http://www.ieee802.org/15/pub/TG4e.html
Wireshark :
http://wiki.wireshark.org/
44
45
Annexes
Sommaire
Annexe I : Installation de Debian………………………………………………………………………………… page II
Annexe II : Communication avec l’équipe de développement OpenWSN de l’Université de page VII

Berkeley………………………………………………………………………………………………………………..
Annexe III : Installation de Windows Server 2003………………………………………...……………………. page X
Glossaire………………………………………………………………………………………………………………. Page XII
I
Annexes
Annexe I : Installation de Debian
L’environnement de travail est composé d’un système d’exploitation* sur lequel est présent
TinyOS. Nous allons vous présenter l’installation du système d’exploitation (aussi appelé OS, de
l’Anglais Operating System).
Nos besoins consistent en un système stable et robuste où la nouveauté des logiciels est
secondaire (du moment que l’on puisse installer la dernière version de TinyOS).
Celui que nous avons choisi est Debian. Il s’agit d’un OS développé par une association
internationale dynamique et structurée. Debian est utilisé par de nombreuses entreprises et
institutions dont la liste est disponible sur http://www.debian.org/users. Ce système se veut être
‘‘universel’’, fonctionne sur de nombreux types de matériels et possède une version ‘‘stable’’ qui
n’est renouvelée qu’au bout de plusieurs années de travail de la communauté. De par ses
propriétés et sa philosophie, Debian correspond à nos besoins.
Nous décidons d’installer notre système en machine virtuelle. Cette option possède divers
avantages dont la facilité de sauvegarde et de redéploiement en cas de bug (il suffit de copier sur
un support fiable le fichier de la machine une fois l’installation terminée) ou encore la possibilité de
travailler à des endroits différents, sans la contrainte d’utiliser un ordinateur précis tant qu’un
hyperviseur* est présent.
L’hyperviseur que nous choisissons est VMware Workstation. C’est le plus répandu car il est le
plus efficace dans ce domaine. De plus, les outils employés à l’Institut Universitaire de Technologie
en matière de virtualisation sont de VMware.
Nous commençons par télécharger la dernière version stable de Debian sur le site officiel :
http://www.debian.org. Pour cela, nous allons dans la partie ‘‘Obtenir Debian’’. Notre choix
s’oriente vers une édition de type ‘‘netinstall’’. Celle-ci est plus légère et ne comporte qu’un
système de base. Les logiciels installés seront téléchargés pendant le processus. Nous obtenons une
image disque qui est faite pour être gravée sur un CD ou DVD. Il est aussi possible de l’utiliser
comme image disque sur une machine virtuelle, et c’est ce que nous allons faire.
Les mots suivis de * sont définis dans le glossaire à la page XII
II
Annexes
Dans la fenêtre principale de VMware Workstation, nous cliquons sur ‘‘New Virtual
Machine’’. Une fenêtre nous demandant quel type de configuration nous voulons pour la machine
virtuelle apparait. Deux choix nous sont proposés : ‘‘typical’’ permet d’effectuer une con figuration
rapide telle que nous la détaillons ci-après ; ‘‘custom’’ propose de mettre en place une
configuration plus fine. Nous souhaitons utiliser une configuration classique c’est pourquoi nous
optons pour la première alternative.
Nous indiquons alors l’emplacement de l’image à utiliser au premier démarrage qui servira
à installer le système.
Figure I.1 : Sélection de la source pour l’installation de la machine virtuelle.

Source personnelle.
À présent, nous choisissons un nom pour la machine virtuelle : ‘‘Debian-projet’’ et indiquons

l’emplacement où elle sera stockée (D:\Projet\VM\Debian-projet).
Figure I.2 : Choix d’un nom et d’un emplacement pour la machine virtuelle.
Source personnelle.
III
Annexes
Un récapitulatif s’affiche, montrant les paramètres entrés jusqu’ici ainsi que la quantité de
ressources allouées à la machine (nous ne modifierons pas ces données). Nous démarrons cette
dernière. L’écran de démarrage de Debian apparaît.
Figure I.3 : Menu de démarrage de Debian.

Source personnelle.
Nous sélectionnons ‘‘Install’’ pour démarrer la procédure d’installation. Le premier écran

concerne le choix du mappage de clavier, puis de la langue de l’OS.
Figure I.4. : Choix de la langue du système d’exploitation.

Source personnelle.
IV
Annexes
Nous choisissons Français dans les deux cas. Le programme d’installation nous invite alors à
choisir un nom pour la machine : nous mettons ‘‘debian-projet’’. L’étape suivante apparaît : elle
concerne le partitionnement. Ce dernier consiste à séparer le disque dur en plusieurs zones ayant
chacune une utilité différente. Pour illustrer ce propos, nous pouvons imaginer la séparation entre
une zone dédiée au système et celle dédiée aux données de l’utilisateur. Cela correspondrait à
placer ‘‘/home’’ (le répertoire contenant les fichiers des utilisateurs du système) sur une partition
différente de ‘‘/’’ (la partition système). L’utilité dans ce cas précis serait de pouvoir réinstaller le
système tout en conservant les données utilisateur. Ce n’est pas ce que nous allons appliquer ici
mais cela constitue un exemple d’utilisation du partitionnement.
Nous disposons d’un disque virtuel de 8,6 Go. Nous décidons de séparer celui-ci en deux
partitions. La première sera le ‘‘swap’’ : c’est une zone du disque qui ne sert que lorsque toute la
mémoire vive est utilisée. Le disque dur remplit alors le rôle de la mémoire vive. Afin de maintenir
une bonne stabilité dans toutes les situations, nous préférons voir large et choisissons une taille de 2
Go pour le swap. Le reste du disque virtuel (6,6 Go) sera dédié à la partition / qui contient toutes les
données du système : nous n’avons pas besoin d’un partitionnement élaboré pour notre projet.
Cette partition sera formatée en ReiserFS, un système de fichiers* réputé pour sa rapidité de
traitement des petits fichiers. Finalement, à l’écran, nous obtenons le partitionnement suivant :
Figure I.5. : Écran de partitionnement.

Source personelle.
Nous validons en sélectionnant ‘‘Terminer le partitionnement et appliquer les

changements’’. Le système de base s’installe alors.
Figure I.6. : Installation des paquets système.

Source personnelle.
V
Annexes
A la fin de cette étape, nous indiquons le mot de passe root. Il s’agit du mot de passe utilisé
pour l’administration de la machine, dans les cas où nous modifions des fichiers systèmes ou
ajoutons des programmes. Nous sommes alors invités à créer un utilisateur avec des droits
classiques sur la machine. Nous renseignons son nom (nous l’appellerons ‘‘projet’’) ainsi que son
mot de passe. Puis une liste de miroirs nous est proposée. Un miroir est un serveur hébergeant
l’ensemble des applications proposées par Debian. Lorsque nous voudrons installer une application
sur la machine, les paquets correspondant seront téléchargés à partir de ce serveur. Le choix par
défaut pour la France est le miroir officiel de Debian, à savoir ftp.fr.debian.org. C’est celui que nous
utiliserons.
La dernière étape consiste à sélectionner le type d’installation voulue. Par défaut, les
options ‘‘Système standard’’ et ‘‘Environnement graphique de bureau’’ sont cochées. Cela
correspond à nos besoins : en effet, le système de base est obligatoire. Quant à l’environnement
graphique de bureau, il permet de simplifier l’utilisation du système.
Figure I.7. : Choix du type d’installation.

Source personnelle.
Les paquets sont automatiquement téléchargés et installés. A la fin du processus, le

programme d’installation nous propose de redémarrer.
Figure I.8. : Fin de l’installation.

Source personnelle.
Nous avons désormais un système fonctionnel qui servira de base à nos travaux avec TinyOS
et les capteurs sans fil.
VI
Annexes
Annexe II : Communication avec l’équipe de développement

OpenWSN de l’Université de Berkeley
Le premier contact, Thomas Watteyne, nous a été donné par notre tuteur de projet, Gérard
Chalhoub.
Envoyé à Thomas Watteyne (twatteyne@dustnetworks.com) le 1er février
Bonjour,
Nous sommes deux étudiants en Licence Pro réseaux sans fil et sécurité à Clermont-Ferrand qui
avons un projet relatif aux réseaux de capteurs sans fil.
En fait, nous devons étudier le saut de fréquence avec des cartes TelosB.
Nous avons donc regardé le code à l'origine de celui-ci, et sommes passés à la pratique. Après la
compilation et l'installation d'OpenWSN, la LED rouge s'allume par intermittence.
L'erreur est écrite dans un buffer, a priori (cross-layers/OpenSerialP.nc, lignes 114-135) mais on ne
sait pas comment la récupérer.
Par ailleurs, lorsque nous tentons de récupérer les données de la carte avec SerialForwarder, nous
rencontrons l'erreur "Packet too long", mais nous ne savons pas comment la résoudre.
Enfin, pourriez-vous nous suggérer vers quelle portion de code nous devrions nous tourner pour
générer un envoi de trame à chaque nouveau slot de temps ? Il y a une variable
dataFrameToSend dont nous ne savons pas de quoi elle dépend.
Merci d'avance.
Cordialement,
Rémi Voirin & Aurore Vergne
Réponse le 2 février de Thomas Watteyne (twatteyne@dustnetworks.com)
Salut Remi,
Hmm, ca fait un bout de temps que je n’ai pas touché au code TinyOS et au code de channel
hopping. Je ne travaille plus a l’universite, et je n’ai plus acces a des TelosB …
Ceci etant dit, as-tu reussi a lancer l’application Python OpenVisualizer sur ton ordi? C’est
l’application qui permet de visualizer l’etat des capteurs connectes au port serie de ton ordi. Il y a
dans openwsn.h une longue liste d’erreurs possibles, que openvisualizer retraduit en texte.
Je mets Fabien Chraim en copie, un etudiant en these de mon ancient labo. Il parle francais et
devrait pouvoir te guider (en ayant des capteurs). Etes-vous oblige d’utiliser TelosB et TinyOS?
Thomas
VII
Annexes
Envoyé à Fabien Chraim (fabien.chraim@gmail.com) le 4 février
Bonjour,
Je suis l'un des deux étudiants qui réalise un projet de licence professionnelle réseaux sans fil relatif
à TinyOS avec des cartes TelosB.
Notre but est d'observer le saut de fréquence à l'aide du code d'OpenWSN.
Nous avons donc compilé OpenWSN et installé celui-ci sur nos cartes avec Debian. OpenVisualizer
donnant une segfault au lancement, c'est sous Windows que nous le testons.
Nous rencontrons deux problèmes :

- d'une part, lorsque nous cliquons sur un des boutons (TCPInject...ICMPv6RPL), une erreur de
longueur de l'inputBuffer apparaît à gauche (cf. capture en pièce jointe) et nous n'avons pas
d'idée pour la résoudre.
- d'autre part, est-ce que l'affichage de la fréquence utilisée est implémentée dans OpenVisualizer
? En effet, même en mettant HOPPING_ENABLED à TRUE dans OpenWSN.h, on a toujours 0 pour le
channel dans l'interface.
Merci d'avance.
Rémi Voirin & Aurore Vergne
Réponse le 4 février de Fabien Chraim (fabien.chraim@gmail.com)
Remi,
Bienvenue sur OpenWSN.
A propos de ta premiere erreur, as-tu programme les deux cartes avec la meme addresse? Sur
l'image que tu as envoye, je vois deux 0x1. Il faut donner differentes address a tes cartes. Thomas a
ecrit un script pour programmer plusieures cartes branchees en meme temps, leur donnant
differentes addresses:
http://openwsn.berkeley.edu/browser/firmware/tinyos-2.x/apps/OpenWSN/deploy.sh
Fabien.
Salut,
Tout d'abord, merci pour ta réponse.

Le souci des adresses identiques est réglé ! ;)
Par contre, nous avons toujours les mêmes erreurs de buffer et le manque d'infos sur le channel.
Est-ce que tu penses qu'utiliser un analyseur de spectre est une bonne idée ? Ou reste-t-il un moyen
de vérifier le saut de fréquence au niveau logiciel ?
Merci !
Rémi & Aurore
VIII
Annexes
Réponse le 6 février de Fabien Chraim (fabien.chraim@gmail.com)
Remi,
Une autre chose que je vient de remarquer: aucunes de tes cartes n'est DAGroot. Il faut que tu
selectionne une pour que les autres synchronisent avec elle. C'est a ce moment que tu verra les
LED bleues s'allumer.
Je ne suis pas sur des raisons des erreurs de l'input buffer. C'est Thomas qui a ajoute toutes ces
fonctions. Par contre, je vais t' "apprendre a pecher":
Si j'ai bien compris de ton premier email, tu as acces a un ordinateur avec Debian. Utilise cette
fonction dans ton fichier contenant le svn:
grep -ri "error inputbuffer length" *
Tu seras ou rechercher pour trouver la realisation de la fonction qui cause cette erreur.
Fabien.
Salut Fabien,
Merci pour tes indications.

On a essayé de compiler OpenWSN de manière à ce qu'une carte soit DAG root.
Dans IDManagerP.nc, vers les lignes 130, on a donc décommenté ça :

if (TOS_NODE_ID==18) {
call IDManager.setIsDAGroot(TRUE);
}
Malgré cela, en faisant attention d'avoir mis l'adresse 18 à la compilation, dans OpenVisualizer elle
n'est pas DAG root.
Il y a aussi des variables IsDAGroot dans les fichiers du dossier idmanager, à FALSE. En les mettant à
TRUE, nous n'avons rien de plus. Du coup, on se retrouve bloqués. Est-ce qu'on aurait loupé
quelque chose ?
Quant à l'erreur qu'on a (error inputbuffer length), celle-ci est générée dans Python. On va
regarder à quelle portion de code elle correspond exactement.
Merci encore ! ;)
Rémi & Aurore
IX
Annexes
Annexe III : Installation de Windows Server 2003
À ce point des expérimentations, l’environnement de travail ne nous convenait plus. En

effet, afin de tester OpenWSN, nous devions lancer un programme en Python, OpenVisualizer,
permettant, entre autre, de visualiser les échanges entre les cartes. Ce dernier ne démarrant pas
sous Debian (nous avions une erreur de segmentation), nous avons donc installé Windows 2003
Server car l’IUT en possède des licences. De plus, nous utilisons une image iso : la même que lors
des travaux pratiques de virtualisation.
La procédure pour créer une machine virtuelle est analogue à celle de Debian. Elle débute
par le choix du type de configuration (‘‘typical’’ ou ‘‘custom’’), de la famille du système
d’exploitation et de sa version (Windows/Windows 2003 Server). Par la suite, nous devons renseigner
la clé CD qui correspond à la licence, donner un nom à la machine virtuelle puis indiquer son
emplacement sur le disque dur de la machine physique.
Figure III.1. : Création de la machine virtuelle.

Source personnelle.
X
Annexes
Une fois la machine démarrée, le processus d’installation commence avec le formatage

automatique du disque. Formater consiste à mettre à 0 l’ensemble des bits* composant la zone du
disque virtuel.
Figure III.2. : Formatage du disque dur.

Source personnelle.
Lorsque le formatage est terminé, la machine virtuelle redémarre et Windows écrit alors ces
fichiers sur le disque.
Figure III.3. : Écriture des fichiers sur le disque.

Source personnelle.
La fin de cette étape correspond à la fin de l’installation. La machine virtuelle redémarre

alors laissant apparaitre le bureau Windows classique.
Figure III.4. : Bureau de Windows.

Source personnelle.
XI
Annexes
Glossaire
Bit Se reporter au glossaire du rapport page 42

Hyperviseur Logiciel de virtualisation. Il permet d’installer virtuellement des
systèmes d’exploitation.
Système d’exploitation Ensemble d’applications servant d’interface entre le matériel et
l’utilisateur.
Exemple : Windows XP, Mac OS X, Debian, …
Système de fichiers Manière d’écrire, lire et organiser les fichiers sur un périphérique
de stockage (disque dur, clé USB, CD/DVD, …).
XII
Les réseaux de capteurs sans
fil sont aujourd’hui utilisés dans de
nombreux domaines : automobile,
médical, militaire, agricole, …
Ces réseaux opèrent sur des

fréquences qu’ils ne sont pas seuls
à utiliser, en particulier la bande
des 2,4 GHz que WiFi et Bluetooth
exploitent eux aussi.
Pour limiter l’impact de ces

technologies sur les transmissions
dans un réseau de capteur sans fil,
une solution existe : le saut de
fréquence. Nous nous sommes
intéressés à cette solution en nous
basant sur les travaux réalisés à
l’Université de Berkeley.
C’est en lisant ce rapport que vous

apprendrez comment mettre en
œuvre le saut de fréquence dans
un réseau de capteurs sans fil.

Le Saut de Fréquence Dans Les Réseaux de Capteurs Sans Fil

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Le Saut de Fréquence Dans Les Réseaux de Capteurs Sans Fil

Uploaded by

Copyright:

Available Formats

Le saut de fréquence dans les

Réseaux de Capteurs Sans Fil

VERGNE Aurore – VOIRIN Rémi

Nous tenons aussi à remercier le LIMOS (Laboratoire d’Informatique, de Modélisation et

Enfin, toute l’équipe pédagogique de la section Réseaux et Télécommunications de

1. Présentation du contexte……………………………………………………………………………………… page 4

2. Déploiement de l’environnement de travail…………………………………………………................ page 8

3. Mise en place du saut de fréquence……………………………………………………………………… page 19

4. Bilan du projet…………………………………..…………………………………………………................ page 38

Questionnaire en anglais…………………………………………………………………………………………….. page 40

Nous nous sommes ainsi posés les questions suivantes :

Les mots suivis de * sont définis dans le glossaire à la page 42

1.1. Les réseaux de capteurs sans fil : une nécessité croissante

Composants d’un nœud capteur sans fil

Un nœud capteur sans fil est caractérisé par différents éléments :

Mécanisme de mise en réseau

Les protocoles* utilisés sont calqués sur le modèle OSI*.

1.1.2. Les besoins en termes de réseau de capteurs sans fil

1.1.3. La nécessité de faire du saut de fréquence

Figure 1.1.3.1. : Logo de WiFi et Bluetooth.

Figure 1.1.3.2. : Schéma des canaux utilisés par les RCSF.

1.2. Réseaux Sans Fil et Sécurité : une formation adaptée

L’Institut Universitaire de Technologie, de par sa licence professionnelle Réseaux Sans Fil et

La démarche décrite ci-dessus peut être résumée grâce au graphique suivant :

Mise en place d'un mini réseau de

2. Déploiement de l’environnement de travail

L’environnement de travail est composé d’un système d’exploitation et d’une suite

2.1. Présentation de TinyOS

Figure 2.1.1. : Logo de TinyOS.

 s’adapter à l’évolution matérielle : le matériel utilisé pour les capteurs évolue

 supporter un maximum de matériels possibles : cet objectif, lié au précédent, a besoin

Nous allons désormais l’installer sur notre machine.

2.2. Installation et test de la configuration de TinyOS

Il est désormais possible d’installer TinyOS :

Figure 2.2.1. : Installation de TinyOS 2.1.1 avec Aptitude.

Nous vérifions en affichant, par exemple, la valeur de TOSROOT :

Figure 2.2.2. : Affichage de la variable TOSROOT.

L’installation et la configuration de TinyOS étant fonctionnelles, nous allons, afin de prendre

2.3. Prise en main de TinyOS et des cartes TelosB

2.3.1. Découverte du matériel

Figure 2.3.1.1. : Schéma d’une carte TelosB.

 Bouton reset : le bouton reset permet de redémarrer la carte sans avoir à la

 Capteurs : éléments matériels de mesure d’un paramètre environnemental. Une carte

2.3.2. Découverte d’applications simples

Figure 2.3.2.1.1. : Affichage de la liste des cartes connectées.

Nous lançons la compilation pour les cartes TelosB :

Figure 2.3.2.1.2. : Compilation de Blink.

Figure 2.3.2.1.3: Flashage de la carte TelosB.

Figure 2.3.2.1.4. : Clignotement des LEDs.

2.3.2.2. Oscilloscope et BaseStation

Nous commençons par nous déplacer dans le répertoire de l’application Oscilloscope :

Nous la compilons pour TelosB :

Nous installons Oscilloscope sur la première carte :

Figure 2.3.2.2.1. : Commande motelist en présence de plusieurs cartes TelosB branchées.

Nous l’installons sur la deuxième carte :

Nous repassons en simple utilisateur et pouvons désormais lancer Serial Forwarder en

Cette commande signifie que nous lançons le programme net.tinyos.sf.SerialForwarder dans

Figure 2.3.2.2.2. : Serial Forwarder.

Cette étape terminée, nous entrons la commande permettant de démarrer l’application :

Figure 2.3.2.2.3. : Application Oscilloscope.

3. Mise en place du saut de fréquence

3.1. Les aspects théoriques du saut de fréquence

Temps Canal 12 Canal 16 Canal 20