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

Aurore VERGNE – Rémi VOIRIN Licence Professionnelle Réseaux Sans Fil et Sécurité Tuteur : Gérard CHALHOUB 2010-2011

1

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.



2

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



3

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



4

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.



5

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*.

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.

Application

Présentation

Session

Transport

Réseau

Liaison de données

Physique

ZigBee

802.15.4

Sens de

lecture



6

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.



7

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 :

Figure 1.3.1. : Schéma de la démarche.

Source personnelle

Mise en place d'un mini réseau de noeuds capteurs faisant du saut de

fréquence

Test du code

Etude du code

permettant de faire du

saut de fréquence

Installation machine

virtuelle et TinyOS



8

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.



9

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.



10

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.



11

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.



12

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.



13

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.



14

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



15

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



16

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 : $ make telosb reinstall bsl,/dev/ttyUSB0

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.



17

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.



18

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.



19

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.

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.

Canal 12 Temps

Ch

an

ne

l Off

set

Canal 16 Canal 20



20

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.



21

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.

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.

Application

Présentation

Session

Transport

Réseau

Liaison de données

Physique 802.15.4-2006

Sens de

lecture 802.15.4E

RPL

TCP, UDP

6LoWPAN

sensor.network



22

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.



23

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.

listefichier="" Initialisation de la variable

‘‘listefichier’’ à chaîne vide.

echo "Chaîne à rechercher ?" Affichage de ‘‘Chaîne à

rechercher’’. read chaine Lecture de la réponse.

find $TOSROOT/apps/OpenWSN/ -name "*.h" > result

find $TOSROOT/apps/OpenWSN/ -name "*.c" >> result

find $TOSROOT/apps/OpenWSN/ -name "*.nc" >> result

Écriture des noms de tous les fichiers

source d’OpenWSN dans un fichier

‘‘result’’.

>> permet de ne pas écraser le

fichier mais d’écrire à la suite.

for i in `cat result`; do Parcours du fichier ‘‘result’’ créé

précédemment.

if ( cat $i | grep $chaine ); then

Ouverture de chaque fichier source

et vérification de la présence de la

chaîne recherchée.

listefichiers="$listefichiers $i"

Si la chaîne est trouvée dans un

fichier alors le nom de ce dernier est

ajouté à ‘‘listefichiers’’ fi Fin de la boucle if done Fin de la boucle for

geany $listefichiers Les fichiers contenant la chaîne

voulue sont ouverts dans geany*. rm result Le fichier ‘‘result’’ est supprimé.

exit 0 Le script quitte en retournant 0 ce qui

signifie qu’il n’a pas fait d’erreur.



24

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



25

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

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.

TOS_NODE_ID



26

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/



27

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



28

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.



29

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).



30

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

$ make telosb reinstall bsl,/dev/ttyUSB0

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.



31

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.



32

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.



33

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.



34

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.



35

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



36

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.



37

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.



38

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.



39

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.



40

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.



41

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.



42

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.



43

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.



44

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/

http://www.debian.org/

http://igm.univ-mlv.fr/~dr/XPOSE2006/Bunel/

http://tice.utc.fr/moodle/file.php/498/support-SIT60.pdf

http://docs.tinyos.net/index.php/Main_Page

http://fr.wikipedia.org/wiki/TinyOS

http://www.ieee802.org/15/pub/TG4e.html

http://wiki.wireshark.org/



45

Le saut de fréquence dans les Réseaux de Capteurs Sans Fil Annexes


I

Sommaire

Annexe I : Installation de Debian………………………………………………………………………………… page II

Annexe II : Communication avec l’équipe de développement OpenWSN de l’Université de

Berkeley………………………………………………………………………………………………………………..

page VII

Annexe III : Installation de Windows Server 2003………………………………………...……………………. page X

Glossaire………………………………………………………………………………………………………………. Page XII



II

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



III

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.



IV

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.



V

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.



VI

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.



VII

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 ([email protected]) 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 ([email protected])

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



VIII

Envoyé à Fabien Chraim ([email protected]) 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 ([email protected])

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



IX

Réponse le 6 février de Fabien Chraim ([email protected])

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



X

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.



XI

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.



XII

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, …).

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.

Documents

Le saut de fréquence dans les Réseaux de Capteurs sans Fil