Table des matières

Table des figures vi

Liste des tableaux viii

Introduction générale 1

1 Généralités sur les réseaux de capteurs sans fil 3

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Capteurs intelligents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Architecture de base . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Architecture en couches d’un RCSF . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 La couche application . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 La couche transport . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3 La couche réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.4 La Couche liaison de données . . . . . . . . . . . . . . . . . . . . . . 6
1.3.5 La couche physique . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.6 Plan de gestion de l’énergie . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.7 Plan de gestion de la mobilité . . . . . . . . . . . . . . . . . . . . . . 6
1.3.8 Plan de gestion des tâches . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Caractéristiques spécifiques aux réseaux de capteurs sans fil . . . . . . . . . 7
1.4.1 Caractéristiques liées aux capteurs intelligents . . . . . . . . . . . . . 7
1.4.2 Caractéristiques liées au réseau : . . . . . . . . . . . . . . . . . . . . . 8
1.5 La Consommation d’énergie . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.1 Techniques de minimisation de la consommation d’énergie . . . . . . 10

i
 1.6 Le routage dans les RCSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6.1 Protocoles de routage basé sur établissement de route . . . . . . . . 11
1.6.2 Protocoles de routage basé sur la structure réseau . . . . . . . . . . 14
1.7 Domaine d’application des RCSF . . . . . . . . . . . . . . . . . . . . . . . . 15
1.7.1 Applications militaires . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.7.2 Applications agricoles . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.7.3 Applications médicales . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.7.4 Applications commerciales . . . . . . . . . . . . . . . . . . . . . . . . 18
1.7.5 Contrôle de la pollution . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.7.6 Surveillance environnemental . . . . . . . . . . . . . . . . . . . . . . 19
1.8 Systèmes d’exploitation pour les réseaux de capteurs . . . . . . . . . . . . . 19
1.8.1 Contiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.9 problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.10 conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2 Normes technologiques 22
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 La norme IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.1 Topologie et fonctionnements de la norme IEEE 802.15.4 . . . . . . . 23
2.2.2 L’architecture IEEE802.15.4 . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 6LOWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1 IPV6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.2 La couche d’adaptation 6LOWPAN . . . . . . . . . . . . . . . . . . . 34
2.3.3 Routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3 Simulation et implémentation 41
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2 Système d’exploitation Contiki . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3 Simulateur Cooja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.1 Programmer le LBR . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

ii
 3.3.2 Programmer les autres capteurs . . . . . . . . . . . . . . . . . . . . . 44
3.4 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4.1 Choix du matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.5 Création du programme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.5.1 Étape d’implémentation d’un programme . . . . . . . . . . . . . . . 55
3.6 Stockage des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.6.1 plateforme IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Conclusion générale 66

Bibliographie 67

Annexe 69

iii
Table des figures

1.1 Exemple d’un RCSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Architecture d’un CI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Pile Protocolaire dans les RCSF . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Rayon de communication et de sensation . . . . . . . . . . . . . . . . . . . . 8
1.5 Différence entre broadcast et multicast . . . . . . . . . . . . . . . . . . . . . 9
1.6 Les techniques de conservation d’énergie . . . . . . . . . . . . . . . . . . . . 11
1.7 Méthodes de protocoles proactifs . . . . . . . . . . . . . . . . . . . . . . . . 12
1.8 Routage hiérarchique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.9 Application militaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.10 Applications agricoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.11 Applications médicales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.1 Topologies possibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2 Bande de fréquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 CSMA/CA non slotté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4 CSMA/CA slotté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Structure de la supertrame . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6 RS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.7 RA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.8 Pile 6LOWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.9 Schéma de routage 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.10 Les graphes DAG et DODAG . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.11 L’envoie des messages DIO et DAO et la construction de DODAG . . . . . . 39

iv
3.1 Démarrage du Instant Contiki . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2 Implémentation du programme rpl-border-router . . . . . . . . . . . . . . . . 44
3.3 Ajout des motes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4 Choisir le nombre capteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5 Creation d’un pont entre le réseau RPL et la machine locale . . . . . . . . . 47
3.6 Affichage de l’adresse ipv6 de LBR . . . . . . . . . . . . . . . . . . . . . . . 48
3.7 Openmote-cc2538, OpenBattery et l’OpenBase . . . . . . . . . . . . . . . . . 49
3.8 Fonctions nécessaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.9 Code html . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.10 Affichage des nœuds connectés . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.11 Affichage des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.12 Code d’affichage des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.13 Code source du capteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.14 Affichage locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.15 Réinitialisation de la carte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.16 Stockage des données dans un fichier local . . . . . . . . . . . . . . . . . . . 57
3.17 Variation de température . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.18 Variation d’humidité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.19 Variation de lumière . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.20 Exécution du code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.21 Affichage sur Ubidots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.22 variation de la lumière au cours du temps . . . . . . . . . . . . . . . . . . . 62
3.23 Signal avec SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.24 Signal avec email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.25 Affichage de l’application mobile . . . . . . . . . . . . . . . . . . . . . . . . 64

v
Liste des tableaux

3.1 Comparaison entre les motes . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.2 Comparaison des plateformes IoT . . . . . . . . . . . . . . . . . . . . . . . . 60

vi
Liste des symboles

6LBR 6lowpan border router

6LoWPAN IPv6 over Low-Power Wireless Personal Area Networks

ADC convertisseur analogique-numérique

CAP Contention access period

CCA Clear Channel Assessment

CFP contention free period

CSMA/CA Carrier Sense Multiple Access With Collision Avoidance

DAG graphe orienté acyclique

DAO Destination Advertisement Object

DAO-ACK Destination Advertisement Object Acknowledgment

DIO DODAG Information Object

DIS DODAG Information Solicitation

DODAG Destination Oriented Directed Acyclic Graph

DODAG ID DODAG Identifier

ED Energy Detection

FFD full function device

GTS Guaranteed Time Slots

ICMPv6 nternet Control Message Protocol for the Internet Protocol Version 6

vii
IEEE Institute of Electrical and Electronics Engineers

IETF L’Internet Engineering Task Forc

IPsec Internet Protocol Security

IPv6 Internet Protocol version 6

LBR Low Power and Lossy Network Border Router

LLN Low power and Lossy Network

LQI Link Quality Indication

MAC Mediam Access Control

NDP Neighbor Discovery Protocol

PHY pysique

RCSF réseau de capteurs sans fil

RFD Reduced function device

ROLL Routing Over Low-power and Lossy networks

RPL Routing Protocol for Low Power and Lossy Networks

SMP Sensor management protocol

UART niversal Asynchronous Receiver Transmitter

URL Uniform Resource Locator

WSN Wireless Sensor Network

viii
Introduction générale

Les capteurs traditionnels, mesurant une grandeur physique, sont présents depuis long-
temps dans divers domaines comme l’industrie, l’aéronautique ou l’automobile. Ils sont géné-
ralement connectés à la base de traitement par des fils. La nouveauté des réseaux de capteurs
est qu’ils ont la possibilité de communiquer par des ondes radio avec d’autres capteurs proches
de quelques mètres, ce qui constituent une nouvelle catégorie de réseaux bien distincte des
autres catégories des réseaux sans fils et qui sont conçus pour répondre à des problématiques
de communications où l’homme est souvent un acteur principal. Les WSN offrent des moyens
de communication très souvent spontanées entre objets autonomes, généralement sans au-
cune intervention humaine.
Les réseaux des capteurs sans fil sont utilisés dans divers domaines militaire ( surveillance
de zones tactiques, espionnage ), environnement ( surveillance de l’écosystème, prévention
des risques sismiques ), commerce ( gestion de stocks, identification des colis), médical (as-
sistance aux personnes), bâtiment (surveillance des infrastructures), transport (identification
des bagages), médecine ( suivi des patients à distance ).
La mise en œuvre des différentes applications liées aux réseaux de capteurs nécessite l’utili-
sation des techniques utilisées dans les réseaux sans fil ad hoc. Cependant, la multitude de
protocoles proposés pour les réseaux ad hoc traditionnels ne peut pas être appliquée direc-
tement aux réseaux de capteurs, à cause des caractéristiques uniques de ces réseaux, et des
exigences imposées par leurs applications ( l’exigence de fonctionnement à faible consomma-
tion d’énergie est l’une de ces contraintes importantes ). Plusieurs recherches sont engagées
dans le développement des protocoles qui satisfont aux exigences des réseaux de capteurs.
Dans le cadre de notre projet, nous présentons une étude sur les réseaux de capteurs sans
fils et son protocole de communication. Puis, nous allons créer un système de surveillance

1
environnementale en utilisant des capteurs réels de type openmote-cc2538.
Notre projet est structuré en trois chapitres :
Le premier chapitre introduit le sujet en donnant une idée générale sur les réseaux de cap-
teurs sans fil où nous avons présenté son architecture en détaillant le rôle de chaque couche
de l’architecture. En outre, nous montrons quelques caractéristiques des RCSF et certains
systèmes d’exploitation qui ont été conçus pour ce type de réseau.
Le deuxième chapitre sera une étude de la norme IEEE 802.15.4 et la technologie 6lowpan
ainsi son protocole de routage.
Le dernier chapitre donne les informations sur notre environnement de travail et les outils et
paramètres utilisés dans la simulation et présente les codes utilisés ainsi que tous les résul-
tats pertinents obtenus. Par ailleurs, une implémentation sur une plateforme réelle de type
openmote-cc2538 sera mise en place.
Enfin, ce travail se termine par une conclusion générale dans laquelle nous synthétisons l’objet
de ce projet.

2
Chapitre 1

Généralités sur les réseaux de capteurs

sans fil

1.1 Introduction
L’internet des objets (ou IoT) est une technologie qui permet de connecter n’importe
quels ensemble d’objets du monde physique entre eux à travers l’internet et /ou des réseaux
locaux comme les réseaux de capteurs sans fil (WSN).
Ces derniers, sont des réseaux ad hoc spécifiques qui ne possèdent pas une infrastructure pré-
existante ou fixe. Ils sont constitués d’un ensemble de capteurs appelés capteurs intelligents
capables de surveiller des conditions physiques (température, humidité, pression...)
Ce chapitre sera une introduction sur les réseaux des capteurs sans fils. Nous présentons tout
d’abord les capteurs intelligents et leurs architectures. Puis, nous détaillerons l’architecture
en couches de ce type de réseau et nous caractériserons les RCSF. Ensuite, on analysera le
problème de consommation d’énergie et on montrera certains techniques pour la minimiser.
Nous présentons aussi le routage dans les RCSF en classant les protocoles des routages. fina-
lement, nous énumérons quelque domaines d’application et certains systèmes d’exploitation
conçus pour les réseaux de capteurs sans fil.

3
1.2 Capteurs intelligents
Comme indiqué ci-dessus, le RCSF est constitué d’un ensemble des capteurs intelligents
autonomes disséminés dans un espace donné et communicant entre eux via une liaison sans
fil. En effet, cet appareil collecte des données physiques et les traite localement grâce à un
microcontrôleur puis il les transmet vers une (ou plusieurs) station(s) de base comme indique
la figure 1.1.

Figure 1.1 – Exemple d’un RCSF

1.2.1 Architecture de base

Un capteur intelligent est composé quatre éléments montrés dans la figure 1.2 ci-dessous.

Figure 1.2 – Architecture d’un CI

Unité d’acquisition : se compose d’un capteur pour mesurer les grandeurs physiques et
d’un ADC pour convertir les signaux analogiques en données numériques et les transmettre
à l’unité de traitement.
Unité de traitement : comporte un microcontrôleur qui exécute un programme et traite

4
les données stockées dans l’unité de stockage.
Unité de communication : est généralement un émetteur-récepteur radio.
Batterie : appelée aussi unité source d’énergie fournie énergie suffisante pour effectuer des
tâches spécifiées.

1.3 Architecture en couches d’un RCSF

L’architecture en couches ou la pile protocolaire est constituée de cinq couches[1]. La
figure 1.3 suivante explique le rôle de chaque couche.

Figure 1.3 – Pile Protocolaire dans les RCSF

1.3.1 La couche application

Cette couche assure l’interface avec les applications[15], constituée de plusieurs protocoles
qui exécutent les applications du réseau. Citons l’exemple du protocole de gestion des cap-
teurs SMP qui permet d’effectuer variété des taches tels que échanger des données liées à
l’emplacement et synchroniser les nœuds de capteur.

5
1.3.2 La couche transport

Couche responsable à la transmission des données entre les nœuds des capteurs et le/les
station(s) de base, de les découper en paquet et du contrôle de flux.

1.3.3 La couche réseau

Elle gère l’adressage et le routage des données et établit les routes entre les nœuds capteurs
et le nœud puits. Elle sélectionne aussi le meilleur chemin en termes d’énergie et délai de
transmission.

1.3.4 La Couche liaison de données

Cette couche est responsable du multiplexage et du contrôle d’erreurs.

1.3.5 La couche physique

Le rôle de cette couche est la réception, la modulation et l’émission des données.

1.3.6 Plan de gestion de l’énergie

Les fonctions intégrées à ce niveau incluent la gestion de l’énergie consommée par le

capteur, car le capteur peut fermer immédiatement son interface de réception après avoir
reçu des messages de nœuds voisins pour éviter de recevoir des éléments en double. De plus,
lorsque le niveau d’énergie d’un nœud est faible, il peut envoyer des messages à d’autres
capteurs, pour ne pas participer aux tâches de routage.

1.3.7 Plan de gestion de la mobilité

Ce niveau détecte et enregistre tous les mouvements des nœuds capteurs, d’une manière
à leur permettre de garder continuellement une route vers l’utilisateur final, et maintenir
une image récente sur les nœuds voisins, cette image est nécessaire pour pouvoir équilibrer
l’exécution des tâches et la consommation d’énergie.

6
1.3.8 Plan de gestion des tâches

Selon la nature du capteur et son niveau d’énergie, les nœuds capteurs ne fonctionnent pas
de même rythme. Pour cela ce niveau équilibre et répartit les tâches sur les différents nœuds
du réseau dans le but d’assurer un travail coopératif et efficace en terme de consommation
d’énergie, prolongeant ainsi la durée de vie du réseau.

1.4 Caractéristiques spécifiques aux réseaux de capteurs

sans fil
Les réseau des capteurs sans fil présentent des divers caractéristiques classés comme suit :

1.4.1 Caractéristiques liées aux capteurs intelligents

? L’énergie :
Elle est l’une des contraintes des capteurs puisqu’ils fonctionnent généralement avec des bat-
teries non rechargeables. Dans la plupart des cas, ces derniers sont déployés dans des zones
hostiles ou difficiles d’accès, et la récupération est hautement improbable. Aussi, étant donné
que leur nombre est très grand ( milliers ), nous ne pouvons pas correspondre à chaque nœud
de capteur un par un. Au vu de ce constat, tout programme dédié au fonctionnement sur des
nœuds capteurs doit prendre en compte cette problématique de gestion de l’énergie. Surtout
pendant le temps de transmission, car la communication sans fil est l’une des opérations les
plus consommatrices d’énergie.
? Portée de transmission :
La portée de transmission est limitée par la capacité de rayonnement des antennes utilisées
et la puissance du signal mises en jeu. Par exemple, la communication entre les nœuds se fait
correctement si la distance entre eux n’est pas très importante. Ainsi plus que cette distance
est grande, plus le coût énergétique est élevé.
Le capteur possédé deux zones l’une de communication et l’autre de perception ou de sensa-
tion comme montre la figue 1.3.

7
 Figure 1.4 – Rayon de communication et de sensation

1.4.2 Caractéristiques liées au réseau :

Parmi les caractéristiques les plus importantes pour effectuer des tâches assignées aux
applications citons :
? L’auto-configuration :
Dans RCSF, chaque nœud A possède une unité émetteur / récepteur, lui permettant de
communiquer avec les nœuds voisins. En échangeant des informations avec eux, le nœud A
peut alors découvrir ses voisins et ainsi connaître la méthode de routage qu’il utilisera en
fonction des besoins de l’application. Dans le cas du RCSF, la configuration automatique
semble être une fonctionnalité nécessaire, car d’une part, leur déploiement est effectué de
manière aléatoire dans la plupart des applications, et d’autre part, le nombre de nœuds de
capteurs est important.
?La qualité de service(QoS) :
Le niveau de qualité de service est défini par un ensemble d’attributs, tels que le délai, la bande
passante et la perte de paquets. Pour les RCSF La quantité et la qualité des informations
extraites du puits doivent être appropriées.
?Les types de communication : Mentionnons quelque type de communication pour les RCSF :
-Unicast : Ce type de communication permet d’échanger des informations entre deux nœuds
du réseau.
-Broadcast : La station de base transmet des informations à tous les nœuds du réseau.En
effet, Le paquet est transmis à tous les hôtes connectés au réseau.

8
-Multicast : Il permet une communication entre un nœud et un groupe de nœuds.Le paquet
est donc transmis uniquement aux destinataires prévus dans le réseau.
La différence entre broadcast et multicast est figurée dans le schéma 1.5 :

Figure 1.5 – Différence entre broadcast et multicast

?Scalabilité :
Contrairement aux réseaux sans fil traditionnels (personnels, locaux ou étendus), le RCSF
peut contenir un grand nombre de nœuds de capteurs (centaines, milliers ...). Le réseau de
capteurs est scalable ou évolutif car il peut accepter un grand nombre de nœuds qui travaillent
ensemble pour atteindre un objectif commun.
?Tolérance aux pannes :
La tolérance aux pannes est la capacité d’assurer la continuité de fonctionnement du réseau
sans interruption due aux erreurs dans un ou plusieurs capteurs. Cela est dû au fait que
certains capteurs peuvent mal fonctionner ou ne plus fonctionner en raison d’un manque
d’énergie ou de problèmes physiques Ces problèmes n’affecte pas le reste du réseau.

1.5 La Consommation d’énergie

L’économie d’énergie est l’un des principaux problèmes des réseaux de capteurs. Le cap-
teur doit économiser autant d’énergie que possible pour pouvoir fonctionner. La transmission
de données entre les nœuds consomme beaucoup d’énergie, en particulier lorsqu’un nœud

9
tombe en panne et que le réseau doit être réorganisé.
Pour bien analyser ce problème il est nécessaire de savoir que l’énergie consommée par un
capteur est divisée en trois catégorie selon la tâche exécutée par ce dernier [13].
-Énergie de capture : la consommation se fait lors de l’exécution des opérations d’échan-
tillonnage,de la conversion analogique-numérique, le traitement de signal et d’activation de
la sonde de capture.
-Énergie de traitement : se compose elle même de deux types d’énergie :
• Énergie de commutation qui est déterminée de la tension d’alimentation n et la capacité
totale commutée au niveau logiciel (en exécutant un logiciel).
• Énergie de fuite correspond à l’énergie consommée par l’unité de calcul lorsque aucun trai-
tement n’est effectué.
- Énergie de communication : provient de trois parties :l’énergie de réception, l’énergie de
l’émission et l’énergie en état de veille. Cette énergie est produite par La quantité de données
à communiquer, la distance de transmission, et Les propriétés physiques du module radio.
Ce type d’énergie représente La plus grande partie de l’énergie consommée par un capteur.

1.5.1 Techniques de minimisation de la consommation d’énergie

Après l’explication des causes de la consommation énorme d’énergie dans les RCSF, il
est nécessaire de présenter quelques techniques de minimisation de cette consommation. Ces
dernier sont applicable au niveau de la couche liaison ou de la couche réseau.
-Pour l’énergie de capture les solutions sont soit de supprimer les captures inutiles soit de
réduire les fréquences et les durées de captures.
-Pour l’énergie de traitement l’optimisation se fait par deux techniques :
• Dynamique Voltage Scaling : cette approche consiste à ajuster la tension d’alimentation
et la fréquence de microprocesseur pour économiser la puissance de calcul sans perdre les
performances.
• L’approche de partitionnement de système qui repose sur le transfert du calcul vers la sta-
tion de base qui n’a pas de contraintes énergétiques et a une grande puissance de calcul[13].
-Pour l’énergie de communication :il existe plusieurs protocoles de minimisation de la consom-
mation pour la couche réseau. Ces protocoles ont le but de réduire le nombre d’émission/ré-

10
ception des messages.
La figure 1.6 donne un aperçu global de ces techniques :

Figure 1.6 – Les techniques de conservation d’énergie

1.6 Le routage dans les RCSF

Le routage est un mécanisme par lequel des chemins sont sélectionnés dans un réseau pour
envoyer les données d’un nœud à un autre. Il a donc deux fonctions, l’une est de construire des
routes pour certaines destinations, l’autre consiste à acheminer des données sur ces routes.

1.6.1 Protocoles de routage basé sur établissement de route

Il existe trois méthodes de ce type de protocoles :

-Les protocoles proactifs qui consistent à établir le routage à l’avance selon l’échange pério-
dique de la table de routage.
-Les protocoles réactifs qui cherchent les routes à la demande.
-Les protocoles hybrides qui sont à la fois proactifs et réactifs.

11
Protocoles proactifs

Le principe de fonctionnement du protocole de routage proactif est que chaque nœud doit
toujours connaître la route vers n’importe quelle destination sur le réseau. Par conséquent,
un protocole de routage proactif signifie le calcul des routes avant qu’il n’y en ait besoin.
De cette manière, le nœud peut transmettre des données à la destination après avoir consulté
sa table de routage sans provoquer de retard supplémentaire.
Afin de maintenir cette table de routage avec des informations efficaces, ces protocoles doivent
être mis à jour périodiquement et en permanence. Ces mises à jour sont implémentées par
des messages envoyés par les nœuds du réseau. La fréquence de transmission doit être suffi-
samment élevée pour tenir compte rapidement des changements dans la topologie du réseau,
mais elle doit être suffisamment basse pour que ces messages de contrôle ne surchargent pas
le réseau.
Il existe plusieurs protocoles proactifs classés selon deux méthodes présentées dans le schéma
1.7 :

Figure 1.7 – Méthodes de protocoles proactifs

12
Après avoir classer les protocoles de routage proactifs, mentionnons maintenant les protocoles
plus connus figurant :
? OLSR (Optimized Link State Routing) : c’est un protocole à état de lien qui utilise le
chemin le plus cours.
Dans l’état de lien, chaque nœud déclare son lien direct avec ses voisins vers l’ensemble
du réseau. Pour OLSR, le nœud utilise le technique des relais multipoints pour déclarer
uniquement les sous-parties de ses voisins. Ce protocole ignore essentiellement un ensemble
de Liens et voisins directs, qui sont redondants pour le calcul des routes de plus court chemin.
En effet, seulement un sous-ensemble des ces voisins est considéré liés. Ils sont sectionnés afin
qu’ils puissent couvrir tous voisins à deux sauts ( tous les voisins des voisins ). Cet ensemble
est appelé l’ensemble des relais multipoints.
Ces deniers, sont utilisés pour diminuer le trafic dû à la diffusion des messages de contrôle
dans le réseau.
?DSDVG( Destination Sequence Distance Vector ) : protocole à vecteur distance où ses tables
de routage continent :
-Toutes les destinations possibles.
-Le nombre de nœuds nécessaire pour atteindre la destination.
-Le numéro de séquences qui correspond à un nœud destination. Il est utilisé pour distinguer
les anciennes et les nouvelles routes, afin d’éviter la répétition des parcours.
? RPL ( IPv6 Routing Protocol for Low power and Lossy Networks )ce qui nous intéresse
et nous le détaillerons dans le chapitre 2.

Protocoles de routage réactifs

Le protocole réactif fonctionne en construisant des routes à la demande et en les main-

tiennent uniquement lorsqu’elles sont utilisées. Par rapport à la méthode proactive, l’avantage
est que lorsqu’il n’y a pas ou peu de trafic, il n’y a pas besoin d’entretenir la route, ce qui
réduit la consommation de ressources. Cependant, comme il n’y a pas de route avant son uti-
lisation, un court temps d’attente est introduit avant la construction de la route. Par rapport
aux protocoles proactifs, ces protocoles sont plus conservateurs en termes d’énergie, mais en
raison de retards, ces protocoles ne sont pas adaptés aux applications temps réel.

13
Protocoles de routage hybrides

Ces protocoles sont une combinaison des deux protocoles précédents. En effet, ils utilisent
les proactifs pour les voisinages à deux ou trois sauts. Au-delà du voisinage, le routage devient
réactif. Ils fusionnent les avantages des deux autres méthodes car ils réduisent la taille de la
table de routage et réduisent encore le temps d’attente causé par l’établissement des routes.

1.6.2 Protocoles de routage basé sur la structure réseau

Le protocole est attribué en fonction de la structure du réseau, ce qui est très impor-
tant pour le fonctionnement requis. Selon leurs fonctions, les protocoles contenus dans cette
catégorie sont divisés en trois sous-catégories. Ces protocoles sont :

Routage plat

Ce type est utilisé lorsque le nombre des nœuds est énorme et que ces nœuds jouent le
même rôle dans le réseau. Comme indiqué pour un grand nombre des nœuds il sera difficile
d’attribuer un ID à chaque capteur. Par conséquent, tous les nœuds sont considérés identiques.
Cela signifie qu’ils effectuent la même tache, sauf pour la station de base qui Collecte toutes
les informations de chaque nœud de capteur afin de les transférer à l’utilisateur final. La
décision du nœud d’acheminer le paquet vers L’autre dépendra de sa position.

Les protocoles de routage hiérarchique

Ces protocoles fonctionnent en attribuant des rôles différents aux nœuds du réseau. Sé-
lectionnez certains nœuds pour exécuter des fonctions spécifiques. Un nœud Par exemple, il
peut s’agir d’une passerelle pour un groupe de nœuds. Le routage devient donc plus simple
car il s’agit de passer par les passerelles pour atteindre le nœud destination qui lui est direc-
tement attaché.
Ils présentent les avantages spéciaux d’une communication efficace. Par exemple, ils sont uti-
lisés pour effectuer un routage économe en énergie. Un exemple est donné par la figure 1.8 :
Pour que les paquets générés par le nœuds 1 atteignent le nœud 5, ils doivent passer par les
passerelles 2, 3 et 4. En effet, le capteur 1 sait que si le capteur 5 (le destinataire) est loin, il

14
suffit d’envoyer ces paquets au passerelle( capteur 2) puis elle transmettra cette requête vers
le capteur ciblé.

Figure 1.8 – Routage hiérarchique

Les protocoles de routage avec localisation géographique

Dans ce type de routage, on suppose que chaque nœud du réseau connaît sa localisation
et la localisation de ses voisins. Le routage se base donc sur la position des capteurs.
pour faire ce type de routage il faut que :
-Tous les nœuds possèdent un moyen de localisation tel qu’un système natif comme le GPS
ou un protocole de localisation.
-Le nœud source connaît toujours l’emplacement du nœud cible.
Le principe général est de forcer les nœuds qui ne se trouvent pas dans le chemin de route
sélectionné à passer en mode veille pour économiser de l’énergie.

1.7 Domaine d’application des RCSF

Les réseaux de capteurs sans fil peuvent avoir des nombreuses applications, répertoriant
les éléments suivants :

15
1.7.1 Applications militaires

Le déploiement rapide, l’auto-organisation et la tolérance aux pannes sont des caracté-

ristiques qui rendent les réseaux de capteurs efficaces sur le plan militaire. Plusieurs projets
ont été lancés pour aider les unités militaires sur le champ de bataille ansi pour protéger les
villes contre les attaques telles que les menaces terroristes. L’armée américaine a mené des
tests concluants dans le désert californien. Le projet DSN (Distributed Sensor Network) au "
Defense Advanced Research Projects Agency "(DARPA), qui a été l’un des premiers projets
avec cette fonction dans les années 1980 utilisant des réseaux de capteurs pour collecter des
données distribuées. L’image 1.9 illustre un exemple d’une application militaire où soldat fait
la surveillance à distance.

Figure 1.9 – Application militaire

1.7.2 Applications agricoles

Dans l’agriculture, les capteurs peuvent être utilisés pour répondre de manière appropriée
au changement climatique, comme le processus d’irrigation lors de la détection de zones
sèches illustré dans la figure 1.10 :

16
 Figure 1.10 – Applications agricoles

1.7.3 Applications médicales

Les réseaux de capteurs sont également largement utilisés dans le domaine médical comme
indique la figure 1.11 ci-dessous. Cette catégorie comprend les applications suivantes : fournir
une interface d’aide aux personnes handicapées, collecter des informations physiologiques
humaines de meilleure qualité, facilitant ainsi le diagnostic de certaines maladies et surveiller
en permanence les patients. On peut aussi implémenter des capteurs vidéo sous la peau
pour recevoir des images en temps réel de parties du corps en environ 24 heures sans aucune
intervention chirurgicale. Par conséquent, il est possible de suivre la progression de la maladie
ou la reconstruction musculaire.

17
 Figure 1.11 – Applications médicales

1.7.4 Applications commerciales

Ces applications consiste à intégrer les nœuds de capteur dans le processus de stockage et
de livraison et de former un réseau qui peut être utilisé pour connaître l’emplacement, l’état
et la direction des petits colis ou marchandises. De cette manière, les clients en attente de
réception du colis peuvent recevoir une notification de livraison en temps réel et connaître
l’emplacement actuel du colis. Pour les entreprises de fabrication, le réseau de capteurs per-
mettra l’ensemble du processus de production, des matières premières à la livraison finale du
produit.

1.7.5 Contrôle de la pollution

Distribuez des Capteurs au-dessus du site industriel peut fournir la possibilité de détecter
et de contrôler les fuites de gaz ou de produit chimique. Ces applications peuvent émettre
une alerte dans le temps enregistré, et Capable de suivre l’évolution de la catastrophe.

18
1.7.6 Surveillance environnemental

Cette application consiste à découvrir les catastrophes naturelles. Ce travail est basé sur
cette application que l’on présentera en détaille dans la problématique.

1.8 Systèmes d’exploitation pour les réseaux de capteurs

Comme on a détaillé que les capteurs sont caractérisés par LEURS faibles performances(mémoire
réduite et faible source d’énergie ...), il est nécessaire donc de créer des logiciels légers pour
s’adapter a cette faiblesse. Parmi ces logiciels, le système d’exploitation qui est l’élément
fondamental pour faire fonctionner le capteur.
Il existe plusieurs systèmes d’exploitation pour les réseaux de capteurs sans fils. Citons par
exemple :

TinyOS :

TinyOS est un système d’exploitation open source développé par l’Université de Berkeley
pour les capteurs sans fil. Les composants sont programmés avec NesC, qui est un langage
de programmation dérivé de C. De nombreuses plateformes peuvent être directement pro-
grammées, comme tmote ou MicaZ (les deux modèles sont compatibles avec ZigBee). Tout
programme en NesC peut être compilé pour être exécuté dans TOSSIM, qui est un simula-
teur de capteurs pour les programmes TinyOS, afin que le comportement d’un ou plusieurs
capteurs puisse être simulé et programmé.

MOS

De même, Mos est open source pour les RCSF développé par le groupe MANTIS à l’uni-
versité du Colorado. La langage de programmation utilisé est le c.

LiteOS

LiteOS fournit un environnement comparable à unix adapté aux capteurs en réseau. Li-
teOS possède un système de gestion des fichiers et des commandes en mode terminal distante

19
semblable au commandes unix pour gérer les capteurs. Un langage de programmation orienté
objet C++ est disponible pour développer des programmes et permettre leur déploiement
sur les capteurs.

1.8.1 Contiki

Contiki est un système configurable modulaire pour réseaux de capteurs. Contiki est
organisé en modules.
Contiki est un OS conçu pour prendre le moins de place possible, avec une faible mémoire.
Pour cela, le code est écrit en C. Ainsi, le système complet est supposé pouvoir tourner sans
problèmes avec 2 ko de RAM et 40 ko de ROM. Ce qu’on l’utilisera dans le chapitre 3.

1.9 problématique
Déployez un grand nombre de nœuds capteurs sans fil de taille réduite et qui sont capables
de mesurer des grandeurs physiques et de les traiter et les transmettre à un centre de décision
distant, a permis l’émergence de nombreux domaines d’applications à base des RCSF. Parmi
ces domaines, on citera le domaine militaire, de la santé (les réseaux corporels), de l’industrie
et agriculture et de l’environnement. Les applications basées sur les RCSF sont classées en
deux catégories : surveillance et suivi.
Par exemple, les capteurs peuvent être déployés dans une zone hostile dans le cadre d’une
application de surveillance, fixés aux moyens de transport d’une grande ville pour suivre les
conditions de circulation ou pour estimer le niveau de pollution par endroit dans la ville[11].
Dans ce travail on s’intéresse à la surveillance environnementale qui est la solution radicale
pour les feux de forêts.
Nous espérons créer un réseau autonome en dispersant les nœuds dans la nature, afin de
pouvoir surveiller la température et émettre des alertes en cas de changements anormaux de
cette grandeur.

20
1.10 conclusion
Dans ce premier chapitre, nous avons présenté au premier temps le réseaux de capteurs
sans fil en générale, son architecture de base et son architecture en couche. Deuxièmement,
nous avons présenté les principales caractéristiques des RCSF et nous avons introduit l’une
des grande contrainte(la consommation d’énergie) en proposant les techniques de minimisa-
tion. Puis on a classé les protocoles de routage dans les RCSF.
Ensuite, on a figuré l’importance des réseaux de capteurs qui apparaît principalement dans
divers domaines d’applications qui ne cessent d’évoluer.
Au dernier lieu on a présenté aussi les différents systèmes d’exploitation utilisé pour pro-
grammer et gérer les réseaux de capteurs sans fil.
Le chapitre suivant sera consacré pour faire une étude des normes technologiques des RCSF.

21
Chapitre 2

Normes technologiques

2.1 Introduction
Dans la majorité des réseaux de capteurs actuellement commercialisés, les deux premières
couches de la pile de protocoles (physique et MAC) sont basées sur la norme IEEE 802.15.4.
Au-delà de cette dernière, plusieurs autres protocoles ( 6LoWPAN par exemple ) peuvent
être utilisés pour assurer les fonctions d’interconnexion des réseaux. A cause de notre intérêt
aux réseaux sans fil avec des contraintes de ressources ( CPU, mémoire, énergie ), nous allons
détailler dans ce chapitre le protocole IEEE 802.15.4, la couche d’adaptation 6LoWPAN qui
permet aux paquets IPv6 d’être envoyés et reçus par les couches physique et MAC normalisées
par IEEE 802.15.4. Finalement, nous allons décrire le protocole de routage RPL.

2.2 La norme IEEE 802.15.4

Le protocole IEEE 802.15.4 ne s’applique qu’aux deux premières couches du modèle OSI,
à savoir la couche physique et la couche liaison de données. Ce standard a été conçu pour
assurer une fiabilité maximale du transfert de données, être opérationnel à court terme, être
peu coûteux et optimiser la consommation d’énergie. La conception reste simple et flexible
[18]. Voici quelques caractéristiques générales du réseau :
-Il propose des débits de données trop faible de 250 kb/s, 40 kb/s et 20 kb/s.
-Basse consommation énergétique (inférieure à 0,01 mA en mode veille).

22
-Distance maximale entre deux nœuds : 100 mètres.
en raison de ses caractéristiques l’IEEE 802.15.4 a été choisi comme l’un des supports de
communication utiliser pour les RCSF. Car elles ont été développées pour les applications de
surveillance et de contrôle à faible débit de données et pour les utilisations à faible consom-
mation d’énergie à longue durée de vie.

2.2.1 Topologie et fonctionnements de la norme IEEE 802.15.4

Ce protocole a proposé deux types de capteurs :

-FFD : ils peuvent jouer trois rôles : coordinateur, routeur ou équipement finaux.
-RFD : ils font des fonctions limités. En effet, ils peuvent être seulement des équipement
finaux.
Le FFD peut dialoguer avec des RFD et des FFD, tandis que le RFD dialogue avec un FFD
uniquement. Pour communiquer sur un même réseau, il faut au moins un FFD [14]. L’IEEE
802.15.4 fonctionne selon l’une des trois topologies : la topologie étoile, la topologie maillée
ou la topologie en arbre comme l’illustre la figure 2.1 où le nœud coordinateur ou router sont
des FFD alors que le nœud terminal ne peut être qu’un RFD. [16]

Figure 2.1 – Topologies possibles

Topologie en étoile : Le réseau est contrôlé par un seul coordinateur. Elle impose une

23
communication bidirectionnelle uniquement entre le coordinateur et les nœuds se trouvant
dans sa portée radio.
Topologie maillée : Les noeuds communiquent entre eux. Ce type permet d’avoir un réseau
plus étendus.
Topologie en arbre : C’est un cas particulier de la topologie maillée. La seule différence
est que dans cette topologie les routeurs utilisent un routage hiérarchique pour transmettre
des données en effet les nœuds terminaux communiquant uniquement avec leur sous-maître.
La norme IEEE 802.15.4 ne définit pas la méthode de création de la topologie, Il définit
uniquement la topologie qui peut être utilisée.

2.2.2 L’architecture IEEE802.15.4

Comme indiqué précédemment, l’architecture IEEE 802.15.4 est implémentée sur deux
couches : la couche physique (PHY) et la couche de contrôle d’accès au support (MAC).
Chaque couche est responsable d’une partie de la norme et fournit des services pour les
autres couches.

La couche physique

Elle fournit deux services :

-Le service de données PHY : assure la transmission et la réception des données.
-Le service de gestion PHY : assure la gestion du réseau.
Cette couche est divisée en deux sous couches fonctionnant en trois bandes de fréquences
différentes : 868 MHz (1 canal de 2 MHz à 868,3 MHz), 915 MHz (10 canaux de 2 MHz entre
902 et 928 MHz) et 2,4 GHz (16 canaux de 3 MHz espacés de 5 MHz). La bande 868 MHz est
destinée à l’Europe, tandis que la bande 915 MHz concerne des pays tels que les Etats-Unis
et l’Australie. La bande 2,4 GHz est utilisable partout dans le monde [2] comme le montre
la figure 2.2.

24
 Figure 2.2 – Bande de fréquence

Les rôles de la couche PHY sont :

• L’activation et la désactivation de l’émetteur-récepteur radio.
• La détection d’énergie.
• L’indication de la qualité de la liaison.
• La sélection du canal.
• L’évaluation de la clarté du canal.
Pour évaluer la performance de la couche physique il faut savoir les deux paramètres l’IQL
et l’ACC :
• LQI : est utilisé dans les réseaux de capteurs pour indiquer la solidité du lien de commu-
nication. LQI est une valeur calculée, basée sur la puissance du signal reçu ainsi que sur le
nombre d’erreurs reçues. La valeur LQI est un nombre entier allant de 0x00 à 0xff, où les
valeurs minimales et maximales doivent être associées aux signaux IEEE 802.15.4 les plus
bas et les plus élevés détectables par le récepteur.
• CCA : est une fonction logique située dans la couche physique pour déterminer l’état actuel
d’utilisation d’un support sans fil. Le CCA signale un canal occupé dès la détection d’une
énergie supérieure au seuil d’ED, ou un signal présentant des caractéristiques connues, par
exemple les caractéristiques de modulation et d’étalement, ou un signal connu dont l’énergie
est supérieure au seuil d’ED.

25
La couche MAC :

C’est la sous couche la plus importante de de la couche liaison de données. En effet, elle
gère tout l’accès à la chaîne de radio physique et est responsable des tâches suivantes [12] :
-Mise en place de balises réseau si le dispositif est un coordinateur.
-Synchronisation des balises réseau.
-Soutien des mécanismes de sécurité nécessaires à la protection des données. -Utilisation du
mécanisme CSMA-CA pour l’accès aux canaux.
-Validation des trames et livraison de trames reconnues.
Elle Utilise le mécanisme CSMA/CA pour gérer l’accès aux canaux radio[17]. selon la confi-
guration du réseau ,il existe deux versions de ce mécanisme :
- CSMA/CA sans slot ou non beacon : dans ce mode, la station décide tout d’abord
d’envoyer des données. Puis elle s’assure que le canal est libre, s’il est occupé elle doit at-
tendre un temps aléatoire appelé temps de back-off, et envoie une demande d’émission. En
effet, elle envoie un message appelé Ready To Send contenant des informations sur la trame.
Le récepteur répond un Clear To Send. Ensuite, ce dernier envoie un accusé de réception
pour dire que la voie est à nouveau libre.
L’inconvénient de cette solution est que le récepteur est activé en permanence pour attendre
des messages.
L’organigramme 2.3 explique ce mécanisme

26
 Figure 2.3 – CSMA/CA non slotté

Avec NB est le nombre de fois l’algorithme CSMA/CA fait backoff durant la tentative de
transmission en cours.
- CSMA/CA slotté ou avec beacon :ce type exige que le coordinateur envoie périodi-
quement une balise(beacon) pour confirmer son présence aux autres nœuds du réseau. Il est
besoin d’être activé uniquement au moment où un équipement final quelconque envoie une
balise.
les étapes suivantes explique le déroulement de ce mécanisme :
1- décision d’envoi
2-NB=0 et CW=2 avec NB est un compteur et CW est un paramètre de synchronisation.
3-tester si le canal est libre :
• si oui :accès au canal. NB=NB+1,CW=CW-1
• si non :attendre un temps aléatoire.
4-tester si CW=0 :
• si oui :passant à l’étape suivante
• Si non :attendre un temps aléatoire.

27
5-tester la collision :
• si oui : si NB>macMaxCSMABackoffs (qui est égale à 3 )échec d’envoi ,si NB <= 3 il faut
attendre un temps aléatoire.
• Si non : succès d’envoi.
cet algorithme est décrit par l’organigramme 2.4 ci-dessous.

Figure 2.4 – CSMA/CA slotté

Dans ce mode chaque beacon est suivi d’une période active et d’une période inactive comme
le montre la figure 2.5 ci-dessous. La communication se déroule dans la partie active. Dans
la partie inactive, les transmetteurs s’arrêtent pour conserver l’énergie. La partie active de
supertrame est devisé en 16 slots.

28
 Figure 2.5 – Structure de la supertrame

-L’utilisation de trames balises dans le réseau peut garantir des intervalles de temps(Guaranteed
Time Slots – GTS)
Le beacon est transmis au début du slot 0. Il contient des informations sur la supertrame et
d’autres informations relatives au PAN.
La supertrame peut avoir 3 types de périodes[3] :
? la période d’accès à la contention (CAP) :
- les dispositifs peuvent communiquer entre eux en utilisant le CSMA/CA et envoient les
données seulement à partir d’un nouveau slot.
- Les trames de commandes MAC sont envoyés pendant cette période.
– Pas de GTS
- La transmission est limité par la taille de la CAP qui peut contenir entre neuf et au seize
slots. Si le capteur n’a pas émit durant la CAP ,il doit attendre la prochaine supertrame pour
accéder au canal.
?La période libre de contention (CFP) :
– Les nœuds n’ont pas besoin d’utiliser CSMA-CA pour accéder au médium.
– Il fournit des GTS.
– On peut avoir jusqu’à 7 GTS dans un CFP Les nœuds peuvent réserver des slots dans le
CPF Le coordinateur peut accepter ou refuser la demande de réservation. La demande d’une
réservation ce fait pendant la CAP. Durant la CFP le dispositif peut transmettre ou recevoir
des données de la part du coordinateur.
? Période inactive :

29
– Permet aux nœuds d’entrer en Power Saving Mode.
– Dans cette période, le coordinateur peut éteindre ses circuits d’émission-réception.
L’intervalle entre deux balises (BI) est déterminé par la valeur de l’attribut macBeaconOrder
(BO) et la constante aBaseSuperframeDuration :
BI = aBaseSuperframeDuration x2BO (symboles)
MacBeaconOrder peut avoir une valeur entre 0 et 14. Une valeur de 15 indique que le réseau
n’utilise pas le système de beacons [10]. La longueur de la période active (Superframe Dura-
tion - SD) peut être calculé par SD = aBaseSuperframeDuration x 2SO (symboles)
SO = macSuperframeOrder
SO <= B0

2.3 6LOWPAN
Un réseau 6LOWPAN est un réseau de communication simple et peu coûteux qui offre une
connectivité sans fil grâce à l’adaptation du protocole IPV6. Les équipements constituant ces
réseaux sont compatibles avec la norme IEEE 802.15.4 ( caractérisée par une courte portée,
un faible débit, une faible mémoire et un faible coût ). Comme indique le nom "IPv6 over
Low-Power Wireless Personal Area Networks" 6LoWPAN est une technologie de réseau ou
une couche d’adaptation qui donne à chaque nœud la possibilité de posséder une adresse
IPv6.

2.3.1 IPV6

Avec la croissance actuelle d’Internet et le désir de connecter les objets de notre vie quoti-
dienne (Internet des objets), le nombre d’adresses IPv4 disponibles s’épuise très rapidement.
Car l’adressage dans l’IPV4 se fait sur 32 bits, en faisant le calcul 232 = 429496729 c’est
un nombre limité des adresses. Par rapport à IPv4, IPv6 multiplie la taille des adresses par
4, passant de 32 bits à 128 bits. On obtient ainsi 3,4 ×1028 adresses. La découverte du ré-
seau IPV6 se fait par le protocol NDP qui fonctionne en multicast pour déterminer des autres
hôtes sur le même réseau, de leurs adresses et de l’identification des routeurs présents. Chaque
périphérique qui utilise NDP découvre son voisin, pour découvrir tous les périphériques du

30
réseau un autre protocole Internet est utilisé, connu sous le nom de ICMPv6 (« Internet
Control Message Protocol for the Internet Protocol Version 6 »), qui est généralement utilisé
comme transmetteur pour les messages d’erreur et d’information, mais il est aussi utilisé par
le NDP sous la forme de cinq différents types ICMPv6[4].
•Type 1 : Router Solicitation (RS)
Sont des messages qu’un hôte peut envoyer pour demander à tous les routeurs du réseau d’en-
voyer des Router Advertisement afin qu’il l’enregistre dans sa liste de voisins. Ce procédure
est simplifié par la figure 2.6.

Figure 2.6 – RS

•Type 2 : Router Advertisement(RA)

Ce message permet au routeur d’avertir de sa présence. Il émettra ce paquet de manière
périodique, ou en réponse à un paquet "Router Solicitation". La figure 2.7 est un exemple
explicatif du RA.

Figure 2.7 – RA

•Type 3 : Neighbor Solicitation (NS)

Les clients du réseau envoient des Neighbord Solicitation (NS) afin de connaitre l’adresse

31
MAC de l’hôte cible, en envoyant éventuellement leur propre adresse en retour.
• Type 4 : Neighbor Advertisement (NA)
Les périphériques réseau envoient des Neighbor Advertisement à la fois en réponse à des
Neighbord Solicitation, mais aussi de manière non sollicité pour informer d’autres participants
sur les changements dans la configuration de l’adresse.
•Type 5 : Redirect
Ce message permet au routeur d’informer l’hôte que le chemin vers une destination spécifique
est meilleur que le chemin habituel[5]. En conclusion, le NDP est responsable aux taches
suivante :
-Découvert des routeur(RS/RA).
-Découverte des adresse mac(NS/NA).
-La découverte du meilleur chemin.
-Éviter le doublement d’adresse en utilisant la procédure DAD(Duplicate Adress Detection).

adressage IPV6

La représentation textuelle d’une adresse IPv6 est obtenue en divisant le mot de 128 bits
de l’adresse en 8 mots de 16 bits, séparés par deux points ( :), Chaque champ doit contenir
un nombre hexadécimal. Par exemple :
2001 :0DF9 :010B :0001 :0000 :0000 :0000 :0CAD
Cette adresse peut être simplifié comme suit :
• Les zéros de tête peuvent être omis, la séquence de 0000 peut être représentée comme 0 ou
même rien.
• Si les élements d’une séquence tous égaux à 0, peuvent être représentée par " : :". Cette
représentation simplifiée ne peut se produire qu’une seule fois dans l’adresse.
En tenant compte de ces règles, l’adresse indiquée ci-dessus est écrite :
2001 :DF9 :10B :1 : :CAD
L’adresse IPV6 est constituée de trois parties :
-Le préfixe du site constitué de 48 premiers bits. Il est donné par le fournisseur.
-Le ID de sous réseau contient 16 bits. C’est privé et interne au site c’est à dire il est
définit par l’administrateur du réseau.

32
-L’ID d’interface contient 64 bits et configuré soit automatiquement à partir de l’adresse
MAC de l’interface, soit manuellement.varient de 0000 :0000 :0000 :0000 à ffff :ffff :ffff :ffff.
IPv6 définit trois types d’adresse :
Unicast : connexion point à point.
Multicast : connexion à plusieurs destinations. La connexion brodcast n’existe plus dans
l’IPV6 elle a été remplacée par anycast qui signifie one to nearst c’est à dire la connexion
ce fait avec le nœud le plus proche.

Avantage d’IPV6

Parmi les avantages d’adresser en IPV6 citons :

-Garantir un espace d’adressage plus grand.
-Accessibilité et flexibilité.
-Auto-configuration.
-Plug and play
-Entête simplifié c’est à dire simplification des adresses car elles sont très longues(128 bits).
-Utilise l’IPsec comme protocole de sécurité.
Pour les réseaux 6LOWPAN , il existe trois types d’équipement :
-le 6LBR est la racine de réseau ou le coordinateur. Il relie le réseau a l’Internet, il est
responsable aussi de la propagation des préfixes IPv6 dans le réseau.
-Le router 6LR :appelé aussi parent, est un équipement intermédiaire ayant son but est de
prolonger le réseau.
-le host ou le fils est l’équipent final du réseau.
Afin d’assurer la compatibilité entre les paquets IPv6 et les trames IEEE 802.15.4, qui existent
ensemble dans les réseaux sans fil IPv6, l’IETF a défini une couche d’adaptation. Cette couche
d’adaptation est placée entre la couche MAC et la couche réseau. La figure 2.8 illustre la pile
6LoWPAN, qui est composée de cinq couches à côté de la couche d’adaptation (6LoWPAN)

33
 Figure 2.8 – Pile 6LOWPAN

2.3.2 La couche d’adaptation 6LOWPAN

Les paquets IPV6 ont une Unité de transmission maximale MTU de 1280 octets alors que
l’IEEE802.15.4 ne supporte qu’une MTU de 127 octets, il est nécessaire donc de spécifier une
couche d’adaptation pour gérer ce décalage. Pour cela le groupe de travail de l’IETF (Internet
Engineering Task Force) a crée une couche d’adaptation 6lowpan utilisant la fragmentation
et la compression.

Compression d’en-tête

La couche d’adaptation 6LoWPAN est responsable de la compression de l’en-tête IPv6

de 40 octets et de l’en-tête UDP de 8 octets de la couche réseau et de son envoi à la couche
liaison.
Nous pouvons distinguer trois scénarios de communication possibles pour illustrer l’impor-
tance de ce mécanisme :

34
-Solution 1 : en utilisant des adresses locales de liaison, la communication entre deux péri-
phériques dans le même réseau 6LoWPAN peut compresser l’en-tête IPv6 en 2 octets. C’est
le meilleur des cas.
-Solution 2 : la communication avec un périphérique en dehors du réseau 6LoWPAN et le
préfixe du réseau externe sont connus, où l’en-tête IPv6 peut être compressé à 12 octets.
-Le troisième cas : similaire au deuxième cas, mais cette fois le préfixe du périphérique externe
n’est pas connu, et dans le pire des cas, il en résultera un en-tête IPv6 de 20 octets.
On remarque que même dans le pire des cas, on est quand même réussi à réduire de moitié la
taille de l’en-tête IPv6. Si malgré ce mécanisme, la taille du datagramme(paquet de données)
est toujours plus grande que la taille de la trame, alors un autre mécanisme est recommandé.

Fragmentation et réassemblage

Afin de réduire la langueur des datagramme IPv6, la couche 6LoWPAN fragmente les
paquets venus de la couche réseau et les envoie sous forme des trames de petites tailles à son
équivalent sur l’équipement distant qui se charge de les réassembler. Chaque fragment est
précédé d’un en-tête de fragmentation

2.3.3 Routage

Le routage est la possibilité d’envoyer un paquet de données d’un appareil à un autre. Selon
la couche où se trouve le mécanisme de routage, deux catégories de routage sont présentées
dans l’illustration 2.9 suivante :

35
 Figure 2.9 – Schéma de routage 6LoWPAN

Le routage "mesh under" ou le routage "route over" utilise les adresses de la couche deux
( couche liaison ) (adresse MAC) pour transmettre les paquets de données, permet d’avoir
un délai de transmission plus court, tandis que le routage supérieur utilise les adresses de la
couche trois (couche réseau).
Dans un réseau de capteurs, les nœuds du réseau sont soumis à de fortes contraintes d’énergie
et de mémoire. C’est pour cette raison qu’un nouveau protocole de routage appelé RPL a été
développé. Dans le paragraphe suivante, nous détaillerons le protocole RPL.

RPL

L’IETF a formé un nouveau groupe de travail appelé ROLL en 2008 avec l’objectif de
spécifier des solutions de routage pour les réseaux à faible puissance et à pertes LLN. Le
groupe ROLL a donc été chargé de concevoir un nouveau protocole de routage appelé RPL
(Routing Protocol for Low-power and Lossy Networks). Qui est un protocole de routage IPv6
avec un vecteur de distance pour construire un graphique acyclique dirigé orienté vers la
destination DODAG, en utilisant une fonction objectif composée de métriques(Les métriques
de routage sont utilisées par les protocoles de routage pour calculer les chemins les plus courts

36
et peuvent être statiques ou dynamiques) et/ou de contraintes.
Propriétés de la topologie : Le protocole RPL a formé une topologie de routage logique
appelée DODAG.
-DAG est un graphe orienté qui ne possède pas de circuit. Il décrit les liens orientés entre les
nœuds, se terminant à un ou plusieurs nœuds racines.
DODAG est un DAG a une seule destination à la racine c’est-à-dire à une seule racine DAG[6].
La figure 2.10 suivante présente la différence entre eux

Figure 2.10 – Les graphes DAG et DODAG

- Racine : également connue sous le nom de LBR. Elle joue le rôle le plus important dans le
réseau. La racine est le nœud qui lance la construction du DODAG. Elle gère également les
tables de routage pour atteindre chaque nœud du DODAG
- Parent : ( routeurs) un nœud parent a au moins un enfant. Le nœud parent assure la cir-
culation de l’information entre ses enfants et la racine.
- Fils : ce type n’a pas d’enfant. Il est uniquement connecté à son nœud parent, qui transmet
les informations depuis la racine du DODAG.
-DODAG ID : chaque DODAG a un IPv6 (128 bits). Il n’est donné qu’à sa racine. Cet ID
a un préfixe qui est utilisé par les autres nœuds du DODAG.
- Instance DODAG : également appelée Instance RPL. Est un ensemble d’un ou plusieurs
DODAG qui partagent un RPL Instance ID.
-Rang est une valeur de 16 bits donnée à un nœud pour déterminer sa position relative à la

37
racine DODAG.
Message de controle dans RPL :
-Les messages DIO : sont envoyés en multidiffusion par des nœuds RPL (initiés par le LBR
et retransmis en multidiffusion par ses voisins) pour faire la publicité d’un DODAG et de ses
caractéristiques. Les DIO sont donc utilisés pour la découverte, la formation et la mainte-
nance des DODAG.
-Messages DAO : envoyés par les nœuds fils à leurs parents. Ils sont utilisés pour propager
les informations de destination le long du DODAG dans le sens ascendant afin de remplir les
tables de routage des nœuds.
- Les messages DIS : peuvent être envoyés par tous les nœuds sauf le LBR. Ils sont utilisés
pour découvrir les DODAG et pour solliciter un DIO de leurs voisins.
- Les messages DAO-ACK : sont envoyés sous forme de paquet unicast par un destinataire
DAO (un parent DAO ou une racine DODAG) en réponse à un message DAO unicast (ré-
ponse sur demande de jointure).
le protocole RPL offre deux modes de fonctionnement[16].
-La fonction objectif : elle est décidée par le programmeur ou le concepteur du réseau. Elle
aide les nœuds à sélectionner les meilleurs parents et ensuite à sélectionner un itinéraire d’op-
timisation dans une instance RPL.
-Mode de fonctionnement du stockage : Un nœud de stockage est un nœud qui dispose
d’une mémoire suffisante pour conserver sa propre table de routage. Ainsi, pour ce mode, les
nœuds intermédiaires sont capables de rediriger les données reçues vers la bonne destination
en consultant les informations de routage.
-Mode de fonctionnement hors stockage : Les nœuds non stockés sont de simples nœuds qui
ne stockent pas une table de routage entière et qui ne connaissent que leurs parents. Dans
ce mode, tous les messages sont transmis à la racine. Chaque nœud transmet le message à
son parent direct jusqu’à ce qu’il atteigne la racine, qui l’achemine à nouveau vers la bonne
destination.
Ces messages permettant la construction et la maintenance du graphe logique DODAG pré-
senté par l’exemple suivant.
• Un exemple pas à pas pour la construction du DODAG :

38
Le processus de construction du DODAG est illustré par la figure 2.11, qui montre et explique
comment le DODAG est construit à partir d’une topologie de réseau physique donné.

Figure 2.11 – L’envoie des messages DIO et DAO et la construction de DODAG

Étape 1 : les nœuds commencent à envoyer des messages aléatoires pour chercher LBR.
Étape 2 : le LBR envie un message DIO pour se connait. Après recevoir le message, les
noeuds de rang1 sélectionnent LBR comme racine de DODAG et lui envoient des information
concernant l’adressage, la position les caractéristique ...
Étape 3 : Les nœuds informent les parents de leur présence et de leurs liens vers leurs enfants
avec des messages DAO.
Étape 4 : DAO-ACK
• Maintenance de la topologie : en cas de rupture d’un lien, le DODAG peut être réparé
de deux manières :
- maintenance globale : la racine lance une reconstruction complète de DODAG avec des
messages DIO, le numéro de série est utilisé pour distinguer les nouveaux et les anciens
DODAG.
- Maintenance locale : Recherchez le nouveau nœud parent dans le nœud affecté, DOGAG

39
n’est plus le meilleur choix, un seul Les réparations globales permettront une optimisation
supplémentaire.

l’algorithme Trickle Timer

RPL utilise le Trickle Timer pour réduire la surcharge des messages de contrôle. En effet,
la transmission des mises à jour ne démarre que lorsque des incohérences sont détectées dans
le réseau. Si un capteur entend des mises à jour DIO de ses voisins qui sont cohérentes avec sa
propre compréhension de la topologie de réseau, un compteur de redondance est incrémenté.
Si le nombre de mises à jour cohérentes entendues dans un intervalle de temps particulier
dépasse le nombre de redondances, le nœud ne transmet aucune mise à jour et la période
d’écoute est doublée. Toutefois, si une mise à jour incohérente est entendue, Trickle Timer
est réinitialisé et une mise à jour est rapidement propagée[19].

2.4 Conclusion
Dans ce chapitre, nous avons présenté les principales caractéristiques de la norme IEEE
802.15.4, en insistant sur la couche physique et la sous-couche MAC où il est implémenté le
protocole d’accès CSMA-CA en ses deux versions. Ensuite nous avons décrire la technologie
6lowpan en expliquant le protocole IPV6 son adressage et son fonctionnement et ses avantage.
Puis, nous avons examiné la couche d’adaptation 6LoWPAN qui optimisait le transport des
paquets IPv6 dans les trames IEEE 802.15.4 et qui permet la prise en charge des mécanismes
de fragmentation nécessaires compte tenu du MTU limité de IEEE 802.15.4.
Ensuite, pour parler du routage, la dernière section a été entièrement consacrée au RPL, le
nouveau protocole de routage pour les réseaux 6LOWPAN développé par le groupe de travail
ROLL de l’IETF. Pour le RPL, nous mentionnons également l’algorithme Trickle, qui est un
algorithme optimisé pour la transmission de messages de contrôle (messages DIO) dans le
cadre du fonctionnement du protocole RPL.

40
Chapitre 3

Simulation et implémentation

3.1 Introduction
Les réseaux de capteurs sont considérés comme des systèmes à ressources limitées. Par
conséquent, les outils logiciels conçus pour les ordinateurs ne sont plus adaptables à ce type
de système. Il existe des outils logiciels légers spécifiquement dédiés aux réseaux de capteurs,
qu’il s’agisse de systèmes d’exploitation ou de langages de programmation. Dans ce contexte,
plusieurs systèmes d’exploitation et langages, présentées dans le chapitre précédent, ont été
développés pour exploiter les réseaux de capteurs. Dans ce chapitre, nous concentrons sur
Contiki qui est considéré comme un système d’exploitation complet et réputé. Ensuite, nous
utiliserons le simulateur Cooja qui est basé sur Contiki pour créer un réseau de capteurs
responsable à la surveillance environnemental d’un endroit. Finalement, on va implémenter
ce travail sur une plateforme réelle de type openmote-cc2538.

3.2 Système d’exploitation Contiki

Contiki OS est un système d’exploitation pour les nœuds à ressources limitées appelés
LLN. Il est largement utilisé dans les réseaux de capteurs, il intègre déjà la couche d’adapta-
tion 6LoWPAN permettant au protocole IEEE 802.15.4 d’envoyer et de recevoir des paquets
IPv6. Cet OS intègre un simulateur de réseau appelé Cooja qui permet d’évaluer différents
paramètres d’un réseau de capteurs[7]. Par conséquent, il propose ContikiMAC qui est un

41
mécanisme conçu pour désactiver le capteur s’il n’a pas des données à transmettre ou à
recevoir. Ce système d’exploitation est un logiciel très complexe, ce qui rend l’installation
difficile. Avec Instant Contiki, il est plus facile à installer et à démarrer avec Contiki OS.
Les étapes d’installation sont les suivantes :
-téléchargez Instant Contiki (InstantContiki2.6.zip) depuis https ://sourceforge.net/projects/contiki/
- décompressez le fichier.
-téléchargez et installez VMWarePlayer depui https ://www.clubic.com/telecharger-
fiche121950-vmware-workstation.html.
Une fois l’installation terminée, nous aurons Instant Contiki opérationnel comme dans la
l’illustration 3.1, pour connecter il faut utiliser le mot de passe"user".

Figure 3.1 – Démarrage du Instant Contiki

3.3 Simulateur Cooja

Pour développer des programmes au sein de Contiki, le système fournit un simulateur
appelé Cooja programmé en java. Ceci est particulièrement utile pour tester les programmes
avant de les flasher dans des nœuds réels. Les données collectées par la station de base via sa
sortie standard peuvent être stockées dans des fichiers ou lues par un logiciel qui peut ensuite
traiter et présenter les données à l’utilisateur.

42
Pour lancer Cooja, il faut d’abord ouvrir une fenêtre de terminal et ensuite entrer la com-
mande cd contiki-2.6/tools/cooja pour aller au répertoire Cooja. Puis exécuter sudo
ant run pour le démarrer. On lance ensuite une nouvelle simulation et on choisit sky mote
qui est le type le plus simple des motifs utilisés dans une simulation WSN. On implémente
finalement le programme voulu et on le compile. Dans ce contexte , on veut implémenter un
programme permettant de surveiller la température et la lumière capturées par les nœuds.
En effet, les capteurs doivent envoyer ces grandeurs à la station de base.
Pour réaliser cette mission, il est nécessaire de programmer tout d’abord le LBR(le coordi-
nateur) pour recevoir les données mesurées par les nœuds fils.

3.3.1 Programmer le LBR

Le corps du programme border-router est basé sur les instructions suivantes :

-les en-têtes (header) C du Contiki qui sont nécessaires pour inclure les bibliothèques et les
définitions de Contiki :
#include "contiki.h"
#include "contiki-lib.h"
#include "contiki-net.h"
Par la suite, on déclare le processus Contiki qui est composé de deux parties :
- un bloc de contrôle :contenant des informations sur chaque processus, telles que son nom
textuel et un pointeur vers le processus thread.
- processus thread : contenant le code du processus.
Il faut envisager qu’un bloc de contrôle est une structure interne utilisée par l’ordonnanceur
pour invoquer le processus thread et lancer son exécution[8].
La structure d’un bloc de contrôle de processus est la suivante :

PROCESS( b o r d e r _ r o u t e r _ p r o c e s s , " Border r o u t e r p r o c e s s " ) ;

Pour lancer le processus automatiquement lors du démarrage du système, il faut ajouter

l’instruction suivante :

AUTOSTART_PROCESSES(& b o r d e r _ r o u t e r _ p r o c e s s ) ;

Le processus thread se déclare par :

43
PROCESS_THREAD( b o r d e r _ r o u t e r _ p r o c e s s , ev , data )

Notez bien que ev est un identificateur d’événement envoyé au processus thread lors de
l’invocation et data est un pointeur vers les données transmises au thread lors de l’invocation.
Le code du processus est définit entre les deux macros :

PROCESS_BEGIN ( ) e t PROCESS_END ( )

il suffit d’implémenter ce programme comme indique la figure 3.2

Figure 3.2 – Implémentation du programme rpl-border-router

Une fois le code se compile sans erreurs on clique sur "create" pour créer les nœuds, dans ce
cas un seul mote est suffisant.

3.3.2 Programmer les autres capteurs

Pour exécuter le programme, on doit suivre les étapes suivantes détaillés par les figures :

44
 1-Ajouter des nouveaux motes :

Figure 3.3 – Ajout des motes

2-Implémenter le programme voulu :

Il faut inclure les bibliothèques correspondantes aux capteurs et les fonctions qui les activent.
3-Choisir le nombre des nœuds (4 nœuds)

45
 Figure 3.4 – Choisir le nombre capteurs

4-Connecter le LBR au réseau crée[9]

Nous devons créer un pont entre le réseau RPL simulé sur Cooja et la machine locale. Cela
peut se faire en cliquant avec le bouton droit de la souris sur le mote qui est programmé
comme routeur frontalier. Sélectionnez "Autres outils pour le routeur frontalier", puis "Prise
série (SERVER)". Vous obtiendrez le message suivant lorsque cette étape sera terminée avec
succès : "Écoute sur le port 60001" indiqué dans la figure 3.5

46
 Figure 3.5 – Creation d’un pont entre le réseau RPL et la machine locale

Nous devons maintenant connecter le réseau RPL à un réseau externe. Pour ce faire, nous uti-
liserons l’utilitaire Tunslip fourni dans Contiki. Dans cet exemple, tunslip crée un pont entre
le réseau RPL et la machine locale. tunslip6.c peut être trouvé dans /contiki-2.6/tools.
Compiler le code de tunslip6 par la commande make tunslip6 et sudo ./tunslip6 -a
127.0.0.1 aaaa : :1/64
Si cette commande est exécutée avec succès, le terminal affiche :

47
 Figure 3.6 – Affichage de l’adresse ipv6 de LBR

On remarque que les nœuds envoient les données au capteur numéro 1 et que le terminal
affiche deux adresses correspondentes au LBR. L’une commence par fe80 qui est une adresse
locale, l’autre est globale commence par aaaa. Dans la suite on s’intéresse à l’adresse globale.
Au premier temps, nous avons essayé d’exécuter ce programme sur le simulateur cooja.
Puisqu’il est exécutable, passant maintenant à la partie implémentation.

3.4 Implémentation
Nous devant créer un programme similaire à celui précédemment exécuté adaptable au
capteur réel choisi en gardant le même programme pour la station de base.

3.4.1 Choix du matériel

Comparaison entre les motes

Le tableau 3.1 suivant présente une comparaison entre les plateformes les plus utilisées
dans le domaine des RCSF et prouve qu’il est raisonnable de choisir l’openmote-cc2538 grâce
à ses hautes performances.

48
 Type micro vitesse RAM stockage voltage capteurs
contrôleur d’horloge /batterie
Openmote- Cortex-M3 32MHZ 32KB 512KB de 2V à 3.6 température, humidité lu-
cc2538 v, 2 X AAA mière , accéléromètre
TelosB TI 8MHZ 10KB 48KB de 2.1V à 3.6 température, humidité lu-
MSP43DF1611 v, 2 X AA mière
WASPMOTE Atmel ATmega 14.7MHZ 8KB 128KB de 3.3v à 4.2 température, humidité lu-
pro 1281 mière, accéléromètre

Table 3.1 – Comparaison entre les motes

Openmote-cc2538

OpenMote-CC2538 est conçu et développé par OpenMote Technologies, fabricant de ma-

tériel à source ouverte pour l’industrie de l’IoT. Il dispose du matériel suivant(on les détaille
dans l’annexe ) :
- Quatre LEDS qui sont utilisées pour le débogage
- Bouton de réinitialisation "RESET" pour réinitialiser la carte.
-Bouton d’utilisation "USER" pour la mettre en mode en veille
- En-tête XBee
-Vingt pins pour connecter le mote à une carte d’interface.
Le mote choisi peut s’interfacer avec l’OpenBattery l’OpenBase et l’OpenUSB présentés dans
la figure 3.7.

Figure 3.7 – Openmote-cc2538, OpenBattery et l’OpenBase

49
Open Base
Cette carte fournit un RJ-45, deux mini-ports USB, un en-tête JTAG et des en-têtes à deux
broches permettant d’accéder aux pins du microprocesseur. Par exemple, les broches DOUT
/ DIN permettent d’accéder respectivement à l’UART Tx / Rx. L’ UART est le composant
utilisé pour réaliser une transmission asynchrone. Il se connecte au port USB.
Open Battery
Open Battery fournit des capacités de détection de base. Il est composé d’un support de pile
pour 2 piles AAA, un interrupteur marche/arrêt, et trois capteurs : un capteur de tempéra-
ture/humidité ( SHT21 ), un accéléromètre à 3 axes, utilisé pour la détection de mouvement
dynamique ou statique ( ADXL346 ) et un capteur de lumière ( MAX44009 ).
Dans notre implémentation, nous avons utilisé la plateforme openmote-cc2538.

3.5 Création du programme

Comme tout programme il faut appeler les modules nécessaires :

#include "contiki.h"
#include "httpd-simple.h"
#include "dev/sht21.h"
#include "dev/max44009.h"

Après cette étape, on définit les variables à utiliser, on doit écrire trois fonctions pour lire la
température, l’humidité et la lumière capturé par l’openbattery. Ces fonctions sont illustré
par la figure 3.8.

50
 Figure 3.8 – Fonctions nécessaires

Pour afficher ces données sur une page web, on écrit le code html suivant(figure 3.9)

Figure 3.9 – Code html

51
Pour flasher le code on tape :
sudo make TARGET=openmote-cc2538 openmote-websence.upload
avec openmote-websence est le nom du programme. Déconnectant maintenant tous les motes
sauf la station de base et exécutant le code border-router.c( détaillé auparavant ). Comme
on a mentionné dans la partie simulation qu’en lancement du programme le terminal affiche
deux adresses et qu’on s’intéresse uniquement à l’adresse globale. On copie cette adresse et
on la colle dans la barre de recherche du navigateur Mozilla Firefox. L’affichage est montrée
dans la figure 3.10.

Figure 3.10 – Affichage des nœuds connectés

Cette étape consiste à afficher les nœuds connectés au réseau. Pour faire paraitre les données
collectées par un tel nœuds, il suffit de refaire la même procédure. La figure 3.11 présente les
mesures capturées en temps réel par l’openbattery.

52
 Figure 3.11 – Affichage des données

Finalement, on a exécuté le script python(figure 3.12) pour afficher ces données localement(sur
notre machine)

53
 Figure 3.12 – Code d’affichage des données

Commentaires du code :
La première ligne importe le module urlib qui permet de lire les URL des capteurs.
La fonction find permet de chercher le caractère désiré depuis le code source du capteur(figure
3.13)

54
 Figure 3.13 – Code source du capteur

Les données sont affichées dans le terminal comme suit :

Figure 3.14 – Affichage locale

3.5.1 Étape d’implémentation d’un programme

Pour réussir a flasher un programme à l’openmote-cc2538 il faut suivre les étapes sui-
vantes :

55
1- Installer le paquet : gcc-arm-none-eabi qui est un outil pour programmer les processeurs
ARM Cortex-A/R/M . L’installation ce fait par l’exécution de la commande suivante :
sudo apt-get install gcc-arm-none-eabi
2- A chaque fois avant d’implémenter un nouveau programme, on doit réinitialiser la carte :court-
circuitez la broche ON/SLEEP à GND comme indique la figure 3.15, ensuite, appuyez sur le
bouton "RESET".

Figure 3.15 – Réinitialisation de la carte

3- Pour afficher les résultats sur le terminal on doit taper make PORT=/dev/ttyUSBx
login avec x est le numéro du port utilisé puis appuyez sur le bouton "Reset".
Certains programmes ne comporte pas un module d’affichage , en cas d’utilisation d’instruc-
tion login il affiche une erreur. Pour résoudre ce problème, nous devons ouvrir le dossier
rpl-border-router (fourni par contiki), puis taper make TARGET = openmote-cc2538
connect-router.

3.6 Stockage des données

Les capteurs ne sont que des collecteurs des données.Par conséquent, Elles doivent être
stockées dans un dossier local ou dans le cloud. La première méthode consiste à sauvegarder
les donner dans un fichier.csv comme indique la figure 3.16.

56
 Figure 3.16 – Stockage des données dans un fichier local

Pour faire cette étape on ajoute les instruction suivante dans le script python présenté pré-
cédemment.

m o n _ f i c h i e r = open ( " f i c h i e r . c s v " , "w" )

m o n _ f i c h i e r . w r i t e ( " dat e ; temps ; t e m p e r a t u r e ; humidity ; l i g h t " )
m o n _ f i c h i e r . w r i t e ( "\ n " )
timeo1=s t r ( d a t e t i m e . now ( ) )
m o n _ f i c h i e r . w r i t e ( timeo )
mon_fichier . write ( " ; " )
mon_fichier . write ( s t r ( k ) )
mon_fichier . write ( " ; " )
mon_fichier . write ( tra )
mon_fichier . write ( " ; " )
mon_fichier . write ( tr1a )
mon_fichier . write ( " ; " )
mon_fichier . write ( trha )
m o n _ f i c h i e r . w r i t e ( "\ n " )
timeo1=s t r ( d a t e t i m e . now ( ) )
mon_fichier . c l o s e ( )

les figures 3.17, 3.18 et 3.19 illustrent les variations des température, humidité et lumière.

57
Figure 3.17 – Variation de température

Figure 3.18 – Variation d’humidité

58
 Figure 3.19 – Variation de lumière

Compte tenu de l’énorme quantité de données, la première méthode (stockage local) n’est
pas recommandée.A chaque fois, après la collection des données , elles sont transmises sur
une plateforme connectée au Cloud qui va permettre de les stocker et de les analyser.

3.6.1 plateforme IoT

Il existe plus de 300 plateformes dans le marché IoT citons les plateformes présentées
dans le tableau 3.2 :

59
 Plateforme Stockage de Visualisation Intégration d’événement Tarification
données données de services
Gestion
Temboo non oui non oui 49 $ par mois
Carriots oui oui non oui 2$ par mois(par
device)
Ubidots oui oui oui oui Gratuit pour
moins de 5
devices
AWS IoT oui oui non oui Gratuit 1an puis
5$ par million de
messages
Microsoft oui oui oui oui Essais gratuits –
Azure IoT cout par service
IBM IoT oui oui oui oui Essai 1 mois
Watson gratuit

Table 3.2 – Comparaison des plateformes IoT

Dans ce travail, on va envoyer des données(la température et la lumière), à partir de n’importe

quel appareil connecté à Internet, au cloud à l’aide de la plateforme Ubidots. Nous pouvons
ensuite configurer des alertes basées sur nos données en temps réel.
le script python qui exécute cette tâche est le suivant :
#import requests
#import urllib

TOKEN = "BBFF−JjV6ieuWgQ57CvKF6ZRi53kl51N9bb"
DEVICE_LABEL = "RanaPFE"
VARIABLE_LABEL_1 = " Temperature "
VARIABLE_LABEL_2 = " l u m i e r e "
d e f build_payload ( v a r i a b l e _ 1 , v a r i a b l e _ 2 ) :
w h i l e ( True ) :
u r l ="http : / / [ f d 0 0 : : 2 1 2 : 4 b00 : 6 0 d : 9 b46 ] / "
r e s=u r l l i b . u r l o p e n ( u r l )
r=r e s . read ( )

60
 j=r . f i n d ( " eg " )
.
.
.
payload = { v a r i a b l e _ 1 : t r , v a r i a b l e _ 2 : t r h }\\
r e t u r n payload

Commentaires du code :
La première ligne importe le module requests qui permet d’utiliser le protocole http(qui
garantit un transfert de fichiers localisés entre un navigateur (le client) et un serveur Web).
La deuxième import correspond à un module pour lire les URL(Uniform Resource Locator)
des capteurs.
La troisième ligne est l’identifiant cloud qu’on a obtenu lors de la création du compte Ubitots.
L’instruction res=urllib.urlopen(url) permet de lire l’URL.
Exécutant maintenant ce code en tapant python ubidots.py sur le terminal, avec ubidots
est le nom du programme implémenté, l’affichage est décrite par la figure 3.20.

Figure 3.20 – Exécution du code

61
Après l’exécution de ce code les données sont envoyées à Ubidots. Cette plateforme crée
"device" contenant les variables et la position du capteur, affichées dans la figure 3.21.

Figure 3.21 – Affichage sur Ubidots

On peut consulter les différentes valeurs d’une variable comme indique la figure 3.22

Figure 3.22 – variation de la lumière au cours du temps

Afin d’effectuer une surveillance correctement, lorsque un changement anormal de tempéra-

ture ou de lumière se produit, nous recevrons un événement d’alarme.Il existe plusieurs façons
d’envoyer un signal : si la température augmente soudainement, nous choisissons d’envoyer

62
un message texte présenté dans la figure 3.23, si la lumière dépasse une certaine valeur, nous
choisissons d’envoyer un email affiché dans l’illustration 3.24 ci-dessous.

Figure 3.23 – Signal avec SMS

Figure 3.24 – Signal avec email

Ubidots propose une application mobile nommée Ubidots Explorer qui permet aux
utilisateurs d’explorer, à tout moment, leurs données de capteur.
Dans le but de faciliter le contrôle des données , nous avons crée des tableaux de bord ou
Dashboards , affichés dans l’interface de l’application comme illustré dans la figure 3.25 ci-
dessous, où un dashboard est une représentation visuelle des informations les plus importantes

63
en temps réel.

Figure 3.25 – Affichage de l’application mobile

3.7 Conclusion
Afin de rendre notre travail assez clair, ce chapitre donne une idée globale de l’environne-
ment de travail et des outils qui y sont utilisés dans un premier temps. Nous avons présenté
le système d’exploitation "Contiki" avec certaines de ses caractéristiques, le "simulateur Co-
oja" et son installation. Ensuite, nous avons passé à la partie simulation.À ce stade, on a
programmer le LBR et les autres capteurs en appliquant le processus de construction du
DODAG qu’on a déjà détaillé dans le chapitre précédent. Nous avons aussi implémenté notre
programme orienté à collecter la température, humidité et lumière et nous avons présenter
les outils qu’on a utilisé (outils logiciels et matériels). Globalement nous avons présenté la
démarche à suivre pour programmer un mote réel sous Contiki. Enfin, on a stocker les don-
nées collectées par les capteurs, en premier temps, dans un fichier.CSV puis dans le cloud à

64
l’aide de la plateforme Ubidots. Par la suite, on a contrôlé et analysé ces données par une
application mobile proposée par cette dernière( la plateforme ). On a aussi envoyé des alertes
lors d’un changement anormal de données.

65
Conclusion générale

Les réseaux de capteurs sans fil sont une nouvelle technologie qui a surgi après les grands
progrès technologiques concernant le développement des capteurs intelligents, des processeurs
puissants et des protocoles de communication sans fil. Ce type de réseau composé de cen-
taines ou de milliers d’éléments, a pour but la collecte de données de l’environnement, leur
traitement et leur dissémination vers le monde extérieur.
Le but de notre travail est de réaliser un système de surveillance environnemental à base
d’un RCSF . Pour ce faire on a commencé par introduire le RCSF, son architecture et son
protocole de communication. Ensuite, on a tester le programme sur le simulateur cooja. Puis
on l’implémente sur des capteurs réels de type openmote-cc2538. Finalement, nous avons
stocké les mesures collectées dans le cloud à l’aide de plateforme ubidots.
Dans le cadre de ce projet, nous avons utilisé Contiki comme système d’exploitation, le lan-
gage C pour programmer les capteurs et le langage python pour stocker les données sur le
cloud.
A la fin de ce travail plusieurs perspectives directs s’annoncent et on cite à tire illusratif les
point suivantes :
• L’ajout d’une technique d’optimisation d’energie.
• La mise en place d’une application réelle à base de la plateforme openmote-cc2538

66
Bibliographie

[1] https://www.memoireonline.com/08/10/3831/m_Approche-distribuee-pour-la-securite-dun-
html. consulté le 12/06/2020.

[2] https://ieeexplore.ieee.org/document/6012487/. consulté le 06/07/2020.

[3] http://infotechplus.free.fr/zig_mac.inc.php. consulté le 07/07/2020.

[4] https://www.ionos.fr/digitalguide/serveur/know-how/
quest-ce-que-le-neighbor-discovery-protocol-ndp/. consulté le 02/08/2020.

[5] https://fr.wikipedia.org/wiki/Neighbor_Discovery_Protocol. consulté le

02/08/2020.

[6] http://e-biblio.univ-mosta.dz/bitstream/handle/123456789/6254/MINF189.
pdf?sequence=1&isAllowed=y. consulté le 11/07/2020.

[7] http://www.contiki-os.org. consulté le 20/06/2020.

[8] https://anrg.usc.edu/contiki/index.php/Processes. consulté 11/07/2020.

[9] https://anrg.usc.edu/contiki/index.php/RPL_Border_Router. consulté le

12/07/2020.

[10] Hayfa Ayadi, Ahmed Zouinkhi, Boumedyen Boussaid, M Naceur Abdelkrim, and Thierry
Val. Energy efficiency in wsn : Ieee 802.15. 4. In 2016 17th International Conference on
Sciences and Techniques of Automatic Control and Computer Engineering (STA), pages
766–771. IEEE, 2016.

[11] Ali Benzerbadj. Approche inter-couches pour l’économie d’énergie et la fiabilité dans les
Réseaux de Capteurs Sans Fil dédiés aux Applications Critiques de Surveillance. PhD
thesis, Brest, 2018.

67
[12] Frank Itoua Engoti. Réalisation d’une plate-forme pour l’optimisation de réseaux de
capteurs sans fil appliqués au bâtiment intelligent. PhD thesis, 2018.

[13] GAYE Malick. Etat de l’art sur les wsn (wireless sensor network). Université Cheikh
Anta DIOP de Dakar, 2014.

[14] Mr MA MESSAOUDI and Mr A BENZERBADJ. Optimisation du routage dans les

réseaux llns.

[15] Diery Ngom. Optimisation de la durée de vie dans les réseaux de capteurs sans fil sous
contraintes de couvertureet de connectivité réseau. PhD thesis, Mulhouse, 2016.

[16] Aishwarya Parasuram, David Culler, and Randy Katz. An analysis of the rpl rou-
ting standard for low power and lossy networks. Electrical Engineering and Computer
Sciences University of California at Berkeley, 2016.

[17] Stanislav Safaric and Kresimir Malaric. Zigbee wireless standard. In Proceedings ELMAR
2006, pages 259–262. IEEE, 2006.

[18] Coleri Ergen Sinem. Zigbee/ieee 802.15. 4 summary, 2004.

[19] Tim Winter, Pascal Thubert, Anders Brandt, Jonathan W Hui, Richard Kelsey, Philip
Levis, Kris Pister, Rene Struik, Jean-Philippe Vasseur, Roger K Alexander, et al. Rpl :
Ipv6 routing protocol for low-power and lossy networks. rfc, 6550 :1–157, 2012.

68
Annexe

69
 Product Sample & Technical Tools & Support &
Folder Buy Documents Software Community

CC2538
SWRS096D – DECEMBER 2012 – REVISED APRIL 2015

CC2538 Powerful Wireless Microcontroller System-On-Chip for 2.4-GHz IEEE 802.15.4,

6LoWPAN, and ZigBee® Applications
1 Device Overview

1.1
1
Features
• Microcontroller • Peripherals
– Powerful ARM® Cortex®-M3 With Code Prefetch – µDMA
– Up to 32-MHz Clock Speed – 4 × General-Purpose Timers
– 512KB, 256KB or 128KB of In-System- (Each 32-Bit or 2 × 16-Bit)
Programmable Flash – 32-Bit 32-kHz Sleep Timer
– Supports On-Chip Over-the-Air Upgrade (OTA) – 12-Bit ADC With 8 Channels and Configurable
– Supports Dual ZigBee Application Profiles Resolution
– Up to 32KB of RAM (16KB With Retention in All – Battery Monitor and Temperature Sensor
Power Modes) – USB 2.0 Full-Speed Device (12 Mbps)
– cJTAG and JTAG Debugging – 2 × SPI
• RF – 2 × UART
– 2.4-GHz IEEE 802.15.4 Compliant RF – I2C
Transceiver – 32 General-Purpose I/O Pins
– Excellent Receiver Sensitivity of –97 dBm (28 × 4 mA, 4 × 20 mA)
– Robustness to Interference With ACR of 44 dB – Watchdog Timer
– Programmable Output Power up to 7 dBm • Layout
• Security Hardware Acceleration – 8-mm × 8-mm QFN56 Package
– Future Proof AES-128/256, SHA2 Hardware – Robust Device for Industrial Operation up to
Encryption Engine 125°C
– Optional – ECC-128/256, RSA Hardware – Few External Components
Acceleration Engine for Secure Key Exchange – Only a Single Crystal Needed for Asynchronous
– Radio Command Strobe Processor and Packet Networks
Handling Processor for Low-Level MAC • Development Tools
Functionality – CC2538 Development Kit
• Low Power – Reference Design Certified Under FCC and
– Active-Mode RX (CPU Idle): 20 mA ETSI Regulations
– Active-Mode TX at 0 dBm (CPU Idle): 24 mA – Full Software Support for Contiki/6LoWPAN,
– Power Mode 1 (4-µs Wake-Up, 32-KB RAM Smart Grid, Lighting, and ZigBee Home
Retention, Full Register Retention): 0.6 mA Automation With Sample Applications and
– Power Mode 2 (Sleep Timer Running, 16-KB Reference Designs Available
RAM Retention, Configuration Register – Code Composer Studio™
Retention): 1.3 µA – IAR Embedded Workbench® for ARM
– Power Mode 3 (External Interrupts, 16-KB RAM – SmartRF™ Studio
Retention, Configuration Register Retention): – SmartRF Flash Programmer
0.4 µA
– Wide Supply-Voltage Range (2 V to 3.6 V)
1.2 Applications
• Smart Grid and Home Area Network • Wireless Sensor Networks
• Home and Building Automation • Internet of Things
• Intelligent Lighting Systems

An IMPORTANT NOTICE at the end of this data sheet addresses availability, warranty, changes, use in safety-critical applications,
intellectual property matters and other important disclaimers. PRODUCTION DATA.