Raport Final PDF

Sommaire
Introduction générale...................................................................................................................................3
Cadre du projet.............................................................................................................................................4
Chapitre 1 : Introduction.............................................................................................................................. 5
Chapitre 2 : Les réseaux de capteurs sans fil : Une nouvelle génération de réseaux sans fil.........................7
Introduction ............................................................................................................................................. 7
I- Première partie : Les catégories des réseaux sans fil .................................................................................. 7
I-1. Le réseau personnel sans fil (WPAN) ................................................................................................. 8
I-2. Le réseau local sans fil (WLAN) ........................................................................................................ 8
I-3. Le réseau métropolitain sans fil (WMAN) ............................................................................................ 9
I-4. Le réseau étendu sans fil (WWAN) ................................................................................................... 9
II- Deuxième partie : Les réseaux de capteurs sans fil (RCSF)......................................................................... 9
II-1. Définition ..................................................................................................................................... 9
II-2. Les principales caractéristiques des RCSF ....................................................................................... 10
II-3. Comparaison entre les RCSF et les réseaux sans fil classiques ........................................................... 13
II-4. Les domaines d’application ........................................................................................................... 13
II-5. L’architecture d’un nœud capteur .................................................................................................. 14
II-5-1. Architecture matérielle.................................................................................. 14
II-5-2. Architecture logicielle................................................................................... 15
II-6. La pile protocolaire des RCSF ........................................................................................................ 15
II-6-1. La couche physique ...................................................................................... 16
II-6-2. La couche liaison de données ....................................................................... 16
II-6-3. La couche réseau ...........................................................................................17
II-6-4. La couche transport .......................................................................................17
II-6-5. La couche application ................................................................................... 18
II-6-6. Le plan de gestion d’énergie .........................................................................18
II-6-7. Le plan de gestion de la mobilité ..................................................................18
II-6-8. Le plan de gestion des tâches ........................................................................18
Conclusion.............................................................................................................................................. 19
Chapitre 3 :.................................................................................................................................................20
Chapitre 3 L’accès au support dans les réseaux sans fil.................. 20
L’accès au support dans les réseaux sans fil...............................................................................................20
Introduction............................................................................................................................................ 20
I- Première partie : Les techniques de contrôle d’accès dans les réseaux sans fil classiques................................ 20
I-1. L’accès multiple par répartition temporelle (TDMA) ............................................................................ 20
I-2. L’accès multiple par répartition fréquentielle (FDMA) ......................................................................... 21
I-3. L’accès multiple par répartition de codes (CDMA)............................................................................... 22
I-4. L’accès multiple avec écoute de la porteuse/Evitement de collision (CSMA/CA) ...................................... 22
II- Deuxième partie : Les protocoles MAC proposés pour les RCSF.................................................................. 23
II-1. Les raisons d’adoption de nouveaux protocoles MAC pour les RCSF ..................................................... 23
II-2. Les caractéristiques d’un protocole MAC convenable aux RCSF ........................................................... 24
II-3. La consommation d’énergie au niveau de la couche MAC dans les RCSF .............................................. 25
II-4. Le protocole Sensor-MAC .............................................................................................................. 26
II-4-1. Les séquences d’états périodiques “actif” et “endormi” .......................................................... 26
II-4-2. L’évitement de collision .................................................................................................... 28
II-4-3. L’évitement du phénomène d’Overhearing............................................................................ 28
II-4-4. Le « Message Passing » ................................................................................................... 29
II-5. Le protocole TimeOut-MAC ........................................................................................................... 30
II-5-1. Fonctionnement de Timeout-MAC ....................................................................................... 30
II-5-2. La Synchronisation entre les nœuds ................................................................................... 31
II-5-3. Détermination de TA (Timeout-Activity) .............................................................................. 31
II-5-4. L’évitement du phénomène d’Overhearing ........................................................................... 32
II-6. Le protocole Wise-MAC................................................................................................................. 32
II-7. Le protocole TRAMA (Traffic-adaptive medium access protocol)........................................................... 33
II-7.1- Fonctionnement du protocole TRAMA .................................................................................. 33
II-7.2- L’algorithme d’élection adaptée ......................................................................................... 35
II-8. Le protocole Lightweight-MAC ....................................................................................................... 35
II-8-1. La synchronisation des nœuds ........................................................................................... 35
II-8-2. Principe d’émission/réception dans Lightweight-MAC ............................................................. 36
II-8-3. L’évitement de collision .................................................................................................... 36
II-9. Le protocole MAC de la norme IEEE 802.15.4 .................................................................................. 36
III- Troisième partie : Etude comparative de quelques protocoles MAC proposés dans les RCSF.......................... 37
III-1. Les critères de comparaison ............................................................................................................. 37
III-1-1. L’allocation du canal radio ............................................................................................... 38
III-1-2. La notification ................................................................................................................ 38
III-1-3. La gestion d’énergie ....................................................................................................... 39
III-1-4. La qualité de service ....................................................................................................... 39
III-2. Le tableau comparatif.................................................................................................................. 40
Chapitre 3 L’accès
au support dans les réseaux sans fil........................................................................................................... 41
Conclusion : ........................................................................................................................................... 44
Chapitre3 L’accès au support dans les réseaux sans fil.................. 44
Projet de fin d’études 2005/2006 1

Sommaire
Chapitre 4 : Solution proposée et situation par rapport à l’existant............................................................ 45

Introduction............................................................................................................................................ 45
I- Première partie : Présentation de la solution proposée (Sensor-MACp)......................................................... 45
I-1. Principe de Sensor-MACp ............................................................................................................... 45
II-2. L'algorithme d’émission de données................................................................................................ 46
II-3. Algorithme de réception de données............................................................................................... 48
II- Deuxième partie : Etude comparative de Sensor-MACp, Sensor-MAC et Timeout-MAC................................... 49
II-1. Les simulateurs utilisés dans les RCSF ............................................................................................ 49
II-2. Description du modèle de simulation MACSimulator .......................................................................... 51
II-3. Paramétrage du réseau utilisé ....................................................................................................... 52
II-4. Paramétrage des protocoles Sensor-MAC, Sensor-MACp et Timeout-MAC ............................................ 53
II-5. Paramétrage des scénarios ........................................................................................................... 54
II-6. La simulation des protocoles Sensor-MAC, Sensor-MACp et Timeout-MAC ............................................ 55
II-6.1. Les modèles de communication ....................................................................55
II-6.1.1. Le modèle de communication « Point à point » ............................................................. 55
II-6.1.2. Le modèle de communication « Nœud vers Sink » ......................................................... 56
II-6.2. Exécution des scénarios ................................................................................ 56
II-6.3. Les résultats des simulations .........................................................................59
II-6.3.1. Cas du modèle de communication « point à point » ....................................................... 59
II-6.3.2. Cas du modèle de communication « nœud vers Sink » ................................................... 60
II-6.4. Interprétation des résultats ............................................................................ 60
II-6.4.1. Cas du modèle de communication « point à point » ...................................................... 60
II-6.4.2. Cas du modèle de communication « nœud vers Sink » ................................................... 61
Conclusion ............................................................................................................................................. 61
Conclusion générale....................................................................................................................................63
Liste des figures..........................................................................................................................................64
Liste des abréviations.................................................................................................................................65
Bibliographie...............................................................................................................................................66
Annexes......................................................................................................................................................68

Introduction générale
Introduction générale
L’essor des technologies sans fil offre aujourd’hui de nouvelles perspectives dans le domaine des
télécommunications. En comparaison avec l’environnement filaire, l’environnement sans fil
permet aux utilisateurs une souplesse d’accès et une facilité de manipulation des informations à
travers des unités de calcul mobiles (PC portable, PDA, capteur…).
Les réseaux sans fil peuvent être classés en deux catégories : les réseaux avec infrastructure fixe
préexistante, et les réseaux sans infrastructure. Dans la première catégorie, une importante
infrastructure logistique et matérielle est nécessaire pour le déploiement du réseau ; le modèle de
la communication utilisé est généralement le modèle cellulaire (les réseaux GSM par exemple). La
deuxième catégorie est celle des réseaux ad hoc.
Un réseau ad hoc peut être défini comme un ensemble d’entités mobiles interconnectées par une
technologie sans fil formant un réseau temporaire sans l’aide de toute administration ou de tout
support fixe.
Avec les avancées techniques en terme de performances et de miniaturisation, réalisées dans les
microsystèmes électromécaniques (MEMS: microcontrôleur, transceiver RF…) et les
communications sans fil, une nouvelle variante de réseaux ad hoc s’est créée afin d’offrir des
solutions économiquement intéressantes pour la surveillance à distance et le traitement des
données dans les environnements complexes et distribués : Les réseaux de capteurs sans fil.

Cadre du projet
Cadre du projet
Ce projet de fin d’études a été effectué au sein de PRiSM qui est un laboratoire de recherche en
informatique (CNRS UMR-8144) historiquement centré sur les thèmes du Parallèlisme, des
Réseaux, des Systèmes et de la Modélisation.
Il est l’un des premiers laboratoires à s'être implantés sur le campus de l’université de Versailles
Saint-Quentin en Yvelines, dès la fin des années 80.
Profitant de cette ancienneté, il a su tisser des liens avec les équipes nouvelles et accompagner
l'université dans son développement, notamment dans le domaine de la valorisation de la
recherche. Par ses collaborations de recherches avec les laboratoires de Mathématiques, de SPI
ou de STIC, mais aussi par le développement des filières Mathématiques et Informatique et des
diplômes réunissant Informatique et Sciences de l'ingénieur.
Les équipes du laboratoire participent aux deux grands axes de recherches cités dans le contrat
quadriennal : Mathématiques et Informatique d'une part et Conception, Modélisation et
Instrumentation de Systèmes d'autre part. Loin d'être une division illusoire entre théorie et
applications, ces deux axes, au sein de PRiSM, se rejoignent fréquemment comme le montrent les
multiples collaborations (France Télécom, THALES…), et la participation de nombreuses
équipes à ces deux axes.

Chapitre1 Introduction
Chapitre 1 : Introduction
I. Problématique et contribution du projet de fin

d’études d’ingénieur
Les réseaux de capteurs sans fil connaissent actuellement un engouement important dans le
domaine de la recherche, du fait notamment des grands avantages qu’ils promettent en terme de
flexibilité, de coût, d’autonomie et de robustesse. En plus, de tels réseaux trouvent une utilisation
dans une grande variété d’applications, par exemple dans la collecte de données à distance, type
surveillance de climat, activités sismiques, ou dans d’autres domaines tel que la domotique, le
médical… Malheureusement, leurs inconvénients sont à la hauteur de leurs promesses. En effet,
les nœuds capteurs sont soumis à une forte contrainte de consommation d’énergie en raison de
leurs dimensions très réduites ainsi qu’à l’environnement de déploiement. Le remplacement
fréquent des batteries est à exclure dans un terrain qui peut être difficile à accéder. Par
conséquent, le défi principal reste, conséquence de la miniaturisation, réduire la consommation
d’énergie pour maximiser la durée de vie du réseau.
L’objectif de ce projet est de faire une étude approfondie sur la consommation d’énergie dans les
réseaux de capteurs sans fil. Les points d’étude abordés se situent au niveau du protocole d’accès
au support ou protocole MAC.
Cette étude a été faite en deux parties. Dans la première partie, on a effectué une étude
synthétique des travaux de recherche qui ont été fait dans le but d’optimiser la consommation
d’énergie au niveau du contrôle d’accès au médium (MAC) dans les réseaux de capteurs sans fil.
La seconde partie concerne notre contribution qui consiste à améliorer la consommation
d’énergie ainsi que le « throughput » dans le protocole Sensor-MAC.

Chapitre1 Introduction
II. Organisation du document

Ce document est organisé comme suit :
•Dans le chapitre 2, nous apportons, dans un premier temps, une vue d’ensemble des
technologies des réseaux sans fil existantes actuellement. Dans un second temps, nous
allons s’intéresser aux RCSF. On étudiera alors leurs principales caractéristiques, leurs
domaines d’application, l’architecture d’un nœud capteur et enfin les couches de leur pile
protocolaire.
•Dans le chapitre 3, nous verrons dans une première partie les techniques d’accès utilisées
dans les réseaux sans fil classiques. Dans une seconde partie, nous verrons un état de l’art
des principaux protocoles MAC qui ont été proposés pour les réseaux de capteurs sans
fil. Ce chapitre sera clôturé par une troisième partie consacrée à une étude comparative
théorique des protocoles MAC évoqués dans la seconde partie.
•Dans le dernier chapitre, on présentera dans une première partie la solution qu’on a
proposée (Sensor-MACp) et ses algorithmes de base. Dans une seconde partie, nous
allons comparer cette solution, en se basant sur la consommation d’énergie et le
« throughput », par rapport à l’existant tout en citant ses apports et ses faiblesses.

Chapitre 2 Les réseaux de capteurs sans fil : Une nouvelle génération de réseaux sans
fil
Chapitre 2 : Les réseaux de capteurs sans fil : Une

nouvelle génération de réseaux sans fil
Introduction
Ce chapitre est scindé en deux parties. Dans la première partie, nous donnerons une vue
d’ensemble des catégories des réseaux sans fil ainsi que leurs principales spécificités.
Dans la seconde partie, nous présenterons les RCSF, leurs caractéristiques, leur situation par
rapport aux restes des réseaux sans fil, leur pile protocolaire ainsi que leurs domaines
d’applications.
I- Première partie : Les catégories des réseaux sans

fil
Il existe plusieurs catégories de réseaux sans fil qui diffèrent par le périmètre géographique qu’ils
couvrent ainsi que par les types d’applications supportées. Le schéma suivant illustre les
catégories des réseaux sans fil.
Figure 2.1 : Les catégories des réseaux sans fil [1]

fil
I-1. Le réseau personnel sans fil (WPAN)

Il concerne les réseaux sans fil d'une faible portée : de l'ordre de quelques dizaines de mètres. Ce
type de réseau sert généralement à relier des périphériques (imprimante, téléphone portable,
appareils domestiques, PDA…). Il existe plusieurs technologies utilisées pour les WPAN :
- La technologie Bluetooth : Elle est connue aussi sous le nom de la norme IEEE
802.15.1, elle a été lancée par Ericsson en 1994, proposant un débit théorique de 1 Mbps lui
permettant une transmissions de la voix, des données et des images [2], d’une portée
maximale d'une trentaine de mètres[1]. Bluetooth est une technologie peu onéreuse, grâce à
sa forte intégration sur une puce unique de 9 mm sur 9 mm [PUJ 05] ; Elle présente
également l’avantage de fonctionner sur des appareils à faible puissance d’où une faible
consommation d’énergie [3].
- La technologie ZigBee : Elle est connue aussi sous le nom de la norme IEEE 802.15.4 et
permet d'obtenir des liaisons sans fil à bas prix et avec une très faible consommation
d'énergie, ce qui la rend particulièrement adaptée pour être directement intégrée dans de
petits appareils électroniques (capteurs, appareils électroménagers...) [1]. Les réseaux ZigBee
permettent d’offrir des débits jusqu’à 250 Kbits/s dans la bande classique des 2,4GHz. Les
RCSF constituent une des applications que cette norme peut couvrir [ZHE 04].
- Les liaisons infrarouges : Elles permettent de créer des liaisons sans fil de quelques
mètres avec des débits pouvant monter à quelques mégabits par seconde. Cette technologie
est largement utilisée dans la domotique (télécommandes), elle souffre toutefois des
perturbations dues aux interférences lumineuses [1].
I-2. Le réseau local sans fil (WLAN)

C’est un réseau permettant de couvrir une portée d'environ une centaine de mètres. Il permet de
relier entre-eux les terminaux présents dans la zone de couverture. Il existe deux technologies
concurrentes :
- Les réseaux Wi-Fi (Wireless-Fidelity) : Ils proviennent de la norme IEEE 802.11, qui
définit une architecture cellulaire. On y trouve principalement deux types de réseaux sans
fil : Ceux qui travaillent à la vitesse de 11 Mbits/s à 2.4 GHz (IEEE 802.11b) et ceux qui
montent à 54 Mbits/s à 5 GHz (IEEE 802.11 a/g) [PUJ 05].

fil
- Les réseaux HiperLAN 2 (High Performance LAN 2.0) : Ils découlent de la norme
européenne élaborée par l'ETSI (European Telecommunications Standards Institute).
HiperLAN 2 permet d'obtenir un débit théorique de 54 Mbps sur une zone d'une centaine
de mètres dans la gamme de fréquence comprise entre 5 150 et 5 300 MHz [1]. Ce type de
réseau n’a pas reçu autant de succès que la technologie Wi-fi.
I-3. Le réseau métropolitain sans fil (WMAN)

Il est connu aussi sous le nom de Boucle Locale Radio (BLR). Il convient de rappeler que la BLR
permet, en plaçant une antenne parabolique sur le toit d'un bâtiment, de transmettre par voie
hertézienne de la voix et des données à haut débit pour l'accès à l'internet et la téléphonie. Il
existe plusieurs types de réseaux WMAN dont le plus connu est :
- les réseaux Wimax (Worldwide interoperability for Microwave Access) : ils émanent
de la norme IEEE 802.16 et ont pour but de développer des liaisons hertéziennes
concurrentes aux techniques xDSL terrestres et offrent un débit utile de 1 à 10 Mbit/s dans
la bande 10-66 GHz pour une portée de 4 à 10 kilomètres, ce qui destine principalement
cette technologie aux opérateurs de télécommunication [PUJ 05].
I-4. Le réseau étendu sans fil (WWAN)

Il est connu sous le nom de réseau cellulaire mobile et il est le plus répandu de tous puisque tous
les téléphones mobiles sont connectés à un réseau étendu sans fil. Les principales technologies
sont les suivantes : GSM (Global System for Mobile Communication), GPRS (General Packet
Radio Service), UMTS (Universal Mobile Telecommunication System) [1].
II- Deuxième partie : Les réseaux de capteurs sans fil

(RCSF)
II-1. Définition
Un RCSF consiste en un nombre de capteurs connectés entre eux qui sont capables de sonder
l’environnement dans lequel ils se trouvent et remonter l’information vers certains nœuds (Sink)
déployés qui sont en mesure de relayer l’information à grande échelle comme l’illustre le schéma
suivant.

fil
Figure 2.2 : Les RCSF dans leur contexte pratique [AKY 02]
Les RCSF forment une nouvelle génération de réseaux aux propriétés spécifiques, qui n’entrent
pas dans les architectures classiques. Ils présentent un champ d’application très vaste et couvrent
plusieurs domaines à caractère scientifique, logistique, militaire ou de santé.
II-2. Les principales caractéristiques des RCSF

- La consommation réduite d’énergie : Les nœuds capteurs utilisent des batteries de taille
minuscule comme ressources en énergie, ce qui limite leur durée de vie. La spécificité des
applications des RCSF (militaires, sismiques et autres) fait que la recharge ou le remplacement de
ces batteries est une tâche difficile ou presque impossible, ce qui nous mène à déduire que la
durée de vie d’un nœud est essentiellement dépendante de la durée de vie de la batterie. Ainsi, la
méthode de gestion de consommation d’énergie constitue une contrainte majeure dans ce type de
réseau.
- L’auto-configuration des nœuds capteurs : Dans un RCSF, les nœuds sont déployés soit
d’une manière aléatoire (missile, avion…), soit placés nœud par nœud par un humain ou un
robot, et ceci à l’intérieur ou autour du phénomène observé (champ de guerre, surface
volcanique, patient malade…) [AKY 02]. Ainsi, un nœud capteur doit avoir des capacités d’une
part, pour s’auto-configurer dans le réseau, et d’autre part pour collaborer avec les autres nœuds
dans le but de reconfigurer dynamiquement le réseau en cas de changement de topologie du
réseau [HOL 03].

fil
Dans un RCSF, chaque nœud X possède une unité émettrice/réceptrice qui lui permet de
communiquer avec les nœuds qui lui sont proches; En échangeant des informations avec ces
derniers, le nœud X pourra alors découvrir ses nœuds voisins et ainsi connaître la méthode de
routage qu’il va adopter selon les besoins de l’application [CUL 04].
L’auto-configuration apparaît comme une caractéristique nécessaire dans le cas des RCSF étant
donné que d’une part, leur déploiement s’effectue d’une manière aléatoire dans la majorité des
applications, et d’autre part le nombre des nœuds capteurs est très grand.
- La scalabilité : Contrairement aux réseaux sans fil traditionnels (personnel, local ou étendu),
un RCSF peut contenir un très grand nombre de nœuds capteurs (des centaines, des milliers…)
[AKY 02].
Un réseau de capteur est scalable parce qu’il a la faculté d’accepter un très grand nombre de
nœuds qui collaborent ensemble afin d’atteindre un objectif commun.
- La tolérance aux pannes : Dans le cas de dysfonctionnement d’un nœud (manque d’énergie,
interférences avec l’environnement d’observation…) ou aussi en cas d’ajout de nouveaux nœuds
capteurs dans le réseau, ce noeud doit continuer à fonctionner normalement sans interruption
[AKY 02]. Ceci explique le fait qu’un RCSF n’adopte pas de topologie fixe mais plutôt
dynamique.
- Une densité importante des nœuds : Les RCSF sont caractérisés par leur forte densité
[FLE 03]. Cette densité peut atteindre, selon le type d’application, 20 nœuds/m3 [AKY 02].
- La capacité de communication : Elle peut prendre deux aspects : Le multisaut ou à un seul

saut [FLE 03]. Parce que le multisaut est moins énergivore, il reste le type de communication le
plus sollicité par les applications de RCSF qui requièrent une faible consommation d’énergie.
- Les types de communication : Il existe différents types de communication utilisés dans les
RCSF :
Unicast : ce type de communication est utilisé pour échanger des informations entre deux
nœuds sur le réseau.

fil
Broadcast : la station de base ou « Sink » transmet des informations vers tous les nœuds du
réseau. Ces informations peuvent être des requêtes de données bien précises (ex :
la température dans la région A), des mises à jour de programmes ou des paquets de
contrôle…[AKY 02]
Local Gossip : ce type de communication est utilisé par des nœuds situés dans une région
bien déterminée qui collaborent ensemble afin d’avoir une meilleure estimation de
l’évènement observé et d’éviter l’émission du même message vers le nœud « Sink » ce qui
contribue à consommer moins d’énergie.
Convergecast : il est utilisé dans les communications entre un groupe de nœuds et un nœud
bien spécifique (qui peut être le « Sink »). L’avantage de ce type de communication est la
diminution de contrôle d’entête des paquets (« control overhead ») ce qui économise
l’énergie au niveau du nœud récepteur [HOL 03].
Multicast : il permet une communication entre un nœud et un groupe de nœuds. Ce type de
communication est utilisé dans les protocoles qui incluent le « clustering » dans lesquels, le
« Clusterhead » s’intéresse à communiquer avec un groupe de nœuds [AKY 02].
- Une architecture « data-centric » : Du fait que le remplacement ou la recharge des batteries

des nœuds capteurs est une tâche non pratique et difficile à réaliser, alors il est d’usage normal
qu’on trouve des nœuds capteurs redondants (effectuant la même tâche dans la même région) ;
L’importance d’un nœud particulier est, par conséquent, réduite par rapport à l’importance
attribuée aux données observées par les nœuds.
Ce type d’architecture diffère des architectures « node-centric » adoptées par les réseaux
traditionnels où les nœuds possèdent une place importante (Exemple : un utilisateur qui veut
connecter son laptop au serveur web X) [HOL 03].
- Une collaboration entre les nœuds : Les contraintes strictes de consommation d’énergie
mènent les nœuds capteurs à détecter et traiter les données d’une manière coopérative afin
d’éviter le traitement redondant d’une même donnée observée, source de la perte d’énergie [6].
- La bande passante (ou capacité du canal) : c’est une caractéristique beaucoup plus
importante dans les réseaux cellulaires (GSM) et les réseaux locaux sans fils (WLAN), que dans
les RCSF ; le débit étant en effet un objectif secondaire pour les RCSF [DEM 03]

fil
II-3. Comparaison entre les RCSF et les réseaux sans fil classiques
Le tableau suivant illustre une comparaison entre les RCSF et les réseaux sans fil classiques. Cette
comparaison s’appuie sur cinq critères : le nombre de nœuds, l’importance de consommation
d’énergie, l’importance de la QoS, l’identification des nœuds et les types de communication.
RCSF Réseau WLAN Réseau Réseau WPAN

cellulaire
Nombre de Très élevé Diminué Elevé 1 nœud maître
nœuds avec 7 nœuds
esclaves (Cas de
Bluetooth)
L’importance Très élevé. Diminué du fait Diminué du fait Diminué
de la que les nœuds que les nœuds
consommation peuvent être peuvent être
d’énergie rechargés rechargés
facilement. facilement.
Importance de Diminué Elevée Elevée Elevée
la qualité de
service
Identification Dépend de Existe Existe Existe
des nœuds l’application
(généralement
pas de
mécanismes
d’identification
pour éviter
l’overhead)
Type de broadcast, Point à point Du mobile vers Du nœud maître
communication multicast, la station de base vers le nœud
Convergecast… et vice versa. esclave.
II-4. Les domaines d’application

Les RCSF couvrent un champ d’applications très vaste et varié. En effet, leurs spécificités lui ont
permis de supporter des applications qui sont inappropriés pour d’autres types de réseaux sans fil.
Parmi les domaines d’application de ce type de réseau, on peut citer les domaines militaire,
médical, la sécurité civile, la domotique et autres.
Les RCSF sont utilisés dans le domaine militaire, pour la surveillance, la reconnaissance, la
détection des mouvements de l’ennemi et autres.
Dans le domaine médical, ils peuvent être utilisés pour le monitoring des états de santé des
patients… [AKY 02].

fil
Dans le domaine de la sécurité civile, ils sont utilisés pour la détection des attaques biologiques,
chimiques, nucléaires; comme dans la surveillance des grandes surfaces commerciales… [6].
Dans le domaine de l’environnement, ils peuvent être utilisés pour le monitoring des
changements au niveau des forêts, des océans, des activités sismiques ...
Dans le domaine de la domotique (« home automation »), et avec la norme IEEE 802.15.4, il est
possible que les appareils électroniques équipés de capteurs puissent communiquer ensemble.
Ainsi, l’utilisateur pourra configurer son réseau domestique de façon que l’intensité de la lumière
diminue dès que le poste de télévision commence à fonctionner, ou le poste de télévision se met
en mode « mute » dés que le téléphone commence à sonner…[ZHE 04].
II-5. L’architecture d’un nœud capteur

II-5-1. Architecture matérielle
La principale tâche d’un nœud capteur dans un RCSF est de détecter, traiter et transmettre des
données.
Un nœud capteur est un ensemble de quatre composants essentiels [AKY 02] qui sont:
- L’unité de capture ou « sensing unit » : elle se compose du capteur et du convertisseur
analogique/numérique (ADC). En effet, le signal analogique produit par le capteur suite à
un phénomène observé va être transformé par l’ADC en un signal numérique.
- L’unité de traitement ou « Processing unit » : elle est composé d’un processeur
(microcontrôleur) et d’une unité de stockage de faible taille. Elle permet au nœud la
gestion des procédures de collaboration avec les autres nœuds dans le but d’accomplir la
tâche demandée.
- L’unité émettrice-réceptrice ou « transceiver unit » : elle permet de connecter le nœud
à l’ensemble du réseau. Grâce à cette unité, le nœud pourra émettre et recevoir des
messages des autres nœuds.
- L’unité d’énergie ou « power unit » : elle constitue la source d’énergie du nœud capteur.
Elle peut être associée ou alimentée par une unité génératrice d’énergie comme les cellules
solaires.
Il existe des applications dont les besoins nécessitent d’autres composants qui s’ajoutent à ceux
décrits précédemment, comme :
- Le système de localisation pour déterminer la position des nœuds.
- Le mobilisateur ou « mobilizer » pour déplacer un nœud d’un lieu à un autre.

fil
Le schéma suivant illustre l’architecture matérielle d’un nœud capteur :
Figure 2.3 : L’architecture matérielle d’un nœud capteur [AKY 02]
II-5-2. Architecture logicielle

L’un des systèmes d’exploitation les plus connus dans le domaine des RCSF est « TinyOS ». Il
est libre et est utilisé par une large communauté de scientifiques dans des simulations pour le
développement et le test des algorithmes et protocoles réseau.
II-6. La pile protocolaire des RCSF

Il est à noter qu’aucune pile protocolaire destinée aux RCSF n’a été standardisée. Cependant, la
majorité des articles scientifiques, qui traitent la thématique des RCSF, se basent sur la pile
protocolaire qui a été proposée par Akyildiz et al., et qui sera traitée dans la suite du document.
Cette pile consiste se compose de :
- Une couche physique
- Une couche de liaison de données
- Une couche réseau
- Une couche transport
- Une couche application
- Un plan de gestion d’énergie
- Un plan de gestion de mobilité
- Un plan de gestion de tâches

fil
Figure 2.4 : La pile protocolaire des RCSF [AKY 02]
II-6-1. La couche physique

Elle est responsable de la sélection de fréquence, la génération de la fréquence porteuse, la
détection du signal, la modulation/démodulation et le cryptage/décryptage des informations.
La consommation d’énergie au niveau de la couche physique peut être affectée par
l’environnement de l’application, le choix du type de la modulation ou la bande de fréquence
utilisée.
Il est avantageux en matière d’économie d’énergie que le concepteur de la couche physique
choisisse une transmission à multi-sauts plutôt qu’une transmission directe qui nécessite une
puissance de transmission très élevée [AKY 02].
II-6-2. La couche liaison de données

Elle est responsable de la détection des trames de données, le contrôle d’accès au support (MAC)
et le contrôle d’erreurs. Elle maintient aussi la fiabilité des connections point à point ou
multipoints dans les RCSF.
La couche liaison de données contient deux sous-couches qui sont :
- La sous-couche MAC : Dans un réseau RCSF, la couche MAC doit accomplir deux
principales tâches qui sont celles de :
- établir des liaisons de communication entre les nœuds capteurs pour effectuer le
transfert des données et permettre au réseau la capacité de s’auto-organiser.
- décider du moment et de la manière dont les nœuds capteurs peuvent accéder au
canal avec un minimum de perte d’énergie [AKY 02].

fil
- La sous-couche de contrôle d’erreurs : La technique de contrôle d’erreurs la plus
utilisée dans les réseaux RCSF est le « Forward error correction » (FEC) ; Cette technique
comporte de simples mécanismes de codage et de décodage (codes de contrôle d’erreurs
simples) [AKY 02].
II-6-3. La couche réseau
La couche réseau gère les échanges (et éventuellement les connexions) au travers du RCSF.
Elle gère entre autre l’adressage et l’acheminement des données.
Les applications des réseaux RCSF requièrent le plus souvent des protocoles de routage à multi-
sauts entre le nœud émetteur, le ou les nœuds relais et le nœud « Sink ».
Les protocoles de routage traditionnels des réseaux ad hoc ne peuvent pas être utilisés dans les
réseaux RCSF puisqu’ils ne satisfont pas les critères de conservation d’énergie et de scalabilité
[LWA 04].
Les métriques considérées par les chercheurs pour déterminer la route la plus optimisée dans les
réseaux RCSF sont :
- L’énergie nécessaire pour transmettre le paquet d’une manière fiable.
- L’énergie disponible dans chaque nœud capteur.
Les algorithmes de routage peuvent alors sélectionner les routes entre le nœud émetteur et le
nœud «Sink» en se basant soit sur le maximum d’énergie disponible au niveau des nœuds
intermédiaires, soit sur la route qui consomme le moins d’énergie pour transmettre d’un nœud
vers un autre. [AKY 02]
Le type d’adressage le plus utilisé dans les RCSF est l’adressage géographique, c'est-à-dire que
chaque nœud capteur est identifié dans le réseau par sa localisation. D’ailleurs, l’adressage
géographique est employé surtout dans les applications de monitoring (« environmental
monitoring »…) [HOL 03].
II-6-4. La couche transport

Le rôle de cette couche intervient essentiellement lorsqu’on va accéder à partir de notre RCSF
vers un autre RCSF ou vers Internet.
Le protocole de transport utilisé entre le nœud émetteur et le nœud « Sink » peut être UDP. Il
importe de mentionner que l’utilisation du protocole TCP est impossible vu la taille limitée des
mémoires des nœuds capteurs qui ne leur permet pas d’enregistrer de grandes quantités
d’informations pour la gestion des communications (mécanismes de fenêtres).

fil
Les communications entre l’utilisateur et le nœud « Sink » peuvent être gérées par TCP ou UDP
via Internet ou satellite.
II-6-5. La couche application

Il existe plusieurs protocoles applicatifs qui ont été proposés. Parmi lesquels, on peut citer le
SMP (Sensor Management Protocol) qui permet à l’utilisateur d’exécuter des tâches
administratives telles que la configuration du RCSF, la mise en marche/fermeture des nœuds, la
synchronisation entre les nœuds, le déplacement des nœuds capteurs…
En plus du protocole SMP, on trouve SQDDP (Sensor Query and Data Dissemination Protocol)
qui permet à l’utilisateur à travers des interfaces d’interroger le réseau en se basant non pas sur
un système d’adressage particulier (interroger un nœud bien particulier) comme tel est le cas des
réseaux sans fil classiques mais plutôt sur la localisation des nœuds [AKY 02].
Exemple de requête : « quelles sont les localisations des nœuds qui captent des températures
supérieures à 70° »…
II-6-6. Le plan de gestion d’énergie
Il gère la manière dont le nœud utilise son énergie. Par exemple, si le nœud capteur est faible en
énergie, il pourra informer ses nœuds voisins par multicast qu’il ne pourra pas participer dans le
routage des paquets [AKY 02].
II-6-7. Le plan de gestion de la mobilité

Il détecte les mouvements des nœuds et indique leurs placements.. De cette manière, chaque
nœud peut connaître les nœuds qui lui sont voisins (il pourra alors balancer ses tâches vers un
autre nœud au cas où il manque d’énergie). Il doit aussi maintenir à n’importe quel instant la route
séparant le nœud mobile du nœud « Sink » [AKY 02].
II-6-8. Le plan de gestion des tâches

Il assure un ordonnancement des tâches de capture dans une région bien déterminée tout en
évitant la redondance des tâches de capture à un même instant, et ceci dans le but d’économiser
de l’énergie sur le réseau [AKY 02].
L’intérêt de ces trois plans réside dans le fait qu’ils assurent une gestion optimale de la
consommation d’énergie, de la mobilité et des tâches au niveau de chaque nœud capteur.

fil
Conclusion
Les RCSF possèdent des caractéristiques particulières qui les différencient des autres types de
réseaux sans fil. Ces spécificités telles que la consommation d’énergie réduite, la scalabilité
ou le routage incitent le besoin de concevoir de nouveaux protocoles d’accès au support, de
routage, de transport ou d’application, qui s’adapteront aux caractéristiques des RCSF.

Chapitre 3 L’accès au support dans les réseaux sans fil
Chapitre 3 :
L’accès au support dans les réseaux sans fil
Introduction
Dans ce chapitre, nous aborderons les techniques d’accès utilisées dans les réseaux sans fil
classiques. Nous donnerons ensuite une description de quelques protocoles MAC proposés dans
les RCSF ; Enfin, nous brosserons une étude comparative des protocoles susmentionnés, fondée
sur les critères d’allocation du canal, de notification, de gestion d’énergie et de QoS.
I- Première partie : Les techniques de contrôle

d’accès dans les réseaux sans fil classiques
Un défi important dans les réseaux sans fil est la gestion des collisions dues à un transfert de
données simultané entre deux nœuds sur le même support.
Les protocoles de contrôle d’accès au support (MAC) ont été développés essentiellement pour
essayer d’éviter ce genre de collisions en aidant les nœuds à décider quand et comment ils
peuvent accéder au support.
A ce propos, nous allons essayer de dégager les diverses techniques d’accès au médium dans les
réseaux sans fil qui sont :
- TDMA (Time Division Multiple Access).
- FDMA (Frequency Division Multiple Access).
- CDMA (Code Division Multiple Access).
- CSMA (Carrier Sense Multiple Access).
I-1. L’accès multiple par répartition temporelle (TDMA)

Cette technique est basée sur un multiplexage temporel (cas de la téléphonie) qui consiste à dire
que les utilisateurs utilisent la même fréquence tout en occupant des slots de temps différents.
Chaque nœud utilise toute la bande passante allouée par le système de transmission durant le slot
(c’est lui seul qui occupe le support).

L’analyse énergétique de la technique TDMA :
Le fait que chaque nœud connaît d’avance le slot de temps qu’il va occuper, va lui permettre de
passer à l’état « endormi » durant les slots inactifs. Ainsi, la perte d’énergie qui est due aux états de
« sur-écoute » (Overhearing) et « écoute passive » (Idle) va être évitée.
Toutefois, le système TDMA demande un maintien constant des horloges de synchronisation à
travers le réseau car une erreur introduite dans l’une des horloges peut entraîner des collisions ;
La station de base doit en effet, émettre périodiquement des paquets de synchronisation aux
différents nœuds qui doivent impérativement les intercepter pour mettre à jour leurs horloges.
Cette réinitialisation de l’horloge effectuée à chaque fois par le nœud consomme une quantité
considérable d’énergie malgré que le nœud ne transmette pas d’informations.
I-2. L’accès multiple par répartition fréquentielle (FDMA)

La technique FDMA est basée sur un multiplexage fréquentiel celà signifie que le spectre est
divisé en canaux fréquentiels (ou bandes de fréquence). Chaque canal fréquentiel est affecté à un
seul utilisateur.
La bande passante est partagée entre les différents canaux auxquels sont affectés les nœuds.
Dans un système FDMA pur, tous les utilisateurs peuvent transmettre leurs signaux
simultanément.
L’analyse énergétique de la technique FDMA :
La technique FDMA élimine en fait le temps d’attente (dû à la réinitialisation de l’horloge de

synchronisation) nécessaire au noeud avant qu’il puisse accéder au support (cas du TDMA) étant
donné que dans un tel système, les nœuds peuvent communiquer simultanément.
Cette élimination du temps d’attente entraîne une sauvegarde d’énergie.
Les collisions sont minimisées puisque chaque nœud occupe sa propre bande de fréquence.
Cependant, en partageant la bande passante totale sur plusieurs nœuds, chaque nœud va avoir
une assez étroite bande passante ce qui entraîne un temps de transmission élevé d’où
l’augmentation de la consommation d’énergie.

I-3. L’accès multiple par répartition de codes (CDMA)

La technique CDMA (utilisé dans la norme IS95) est basée sur la technique du spectre étalé
obtenu au moyen d’un code aléatoire unique à chaque utilisateur.
L’Analyse énergétique de la technique CDMA :
Dans un système CDMA, le nœud émetteur émet ses données à travers le canal de transmission
en utilisant son code unique. Le nœud récepteur va alors regrouper les données reçues et essayer
d’extraire seulement les données provenant du nœud émetteur.
Ce type d’échange peut réduire la bande passante du canal de transmission (Exemple : A émet à B
5Mbits de données, la ligne est à 1Mbits/s, il lui faut normalement 5s. On suppose qu’il y a
15Mbits de données émise par d’autres nœuds. Le canal transporte alors 20Mbits en total, il nous
faudra alors un temps =20s) d’où l’augmentation du temps de transmission qui entraîne une
augmentation de la consommation d’énergie.
I-4. L’accès multiple avec écoute de la porteuse/Evitement de

collision (CSMA/CA)
Contrairement aux techniques TDMA, FDMA et CDMA qui sont des techniques « programmées
d’avance » [YE 03] et dans lesquelles les noeuds sont assignés à des canaux partitionnés (temps,
fréquence, code) pour éviter les collisions, CSMA/CA constitue une technique aléatoire dans
laquelle chaque nœud doit rester à l’écoute du médium avant de transmettre ses données.
En effet, les terminaux d’un même BSS (groupe de terminaux munis d’une carte d’interface
réseau 802.11 et interconnectés entre eux) peuvent écouter l’activité de toutes les stations qui s’y
trouvent. Lorsqu’une station envoie une trame, les autres stations l’entendent et, pour éviter les
collisions, mettent à jour un « Timer », appelé NAV permettant de retarder toutes les
transmissions prévues. Le NAV est calculé par rapport à l’information située dans le champ
durée de vie, ou TTL contenu dans les trames qui ont été envoyées. Les autres stations n’ont la
capacité de transmettre qu’après la fin du NAV [PUJ 05].
L’analyse énergitiqe de la technique CSMA/CA :
L’utilisation de CSMA/CA oblige les nœuds d’être éveillés pour l’écoute du médium ce qui
accroît leur consommation d’énergie. En outre, si on utilise cette technique dans un réseau à
haute densité de nœuds comme les RCSF, on peut accroître le risque de collisions dans ce réseau,

provoquer la perte des données transmises et engendrer d’avantage de consommation d’énergie

lors de la retransmission.
II- Deuxième partie : Les protocoles MAC proposés

pour les RCSF
II-1. Les raisons d’adoption de nouveaux protocoles MAC pour les

RCSF
Les caractéristiques des RCSF qu’on a décrites précédemment, ainsi que les techniques d’accès
MAC utilisées dans les réseaux sans fils classiques et qui sont non adaptées aux besoins des
applications des RCSF, ont poussé la communauté des chercheurs à proposer de nouveaux
protocoles MAC spécifiques aux réseaux.
En effet, l’objectif essentiel du protocole MAC dans un réseau cellulaire est de fournir une bonne
qualité de service avec une bande passante efficace. Cependant, l’économie d’énergie dans un tel
réseau ne constitue pas une contrainte importante prise en compte par le protocole MAC étant
donné que l’utilisateur peut recharger les batteries de son combiné lorsqu’il le voudra.
Pour le cas de Bluetooth, il adopte une topologie en étoile dans laquelle un nœud « master »
interagit avec sept nœuds « slave » pour former un « Piconet ». La technique d’accès utilisée par
chaque « Piconet » est TDMA. La puissance de transmission est de l’ordre de 20dBm et la portée
de transmission est de l’ordre d’une dizaine de mètres [AKY 02].
Dans MANET (Mobile Adhoc Network), l’objectif essentiel est de maintenir une bonne qualité
de service dans un environnement mobile. Quant au critère d’économie d’énergie, il occupe une
place moins importante dans les objectifs du protocole MAC de MANET du fait que la recharge
ou le remplacement des batteries des nœuds est réalisable par l’utilisateur.
Contrairement à ces systèmes sans fils, le RCSF possède un nombre plus grand de nœuds, la
puissance de transmission est de l’ordre du 0dBm, la portée des transmissions est très inférieure à
celle de Bluetooth et l’économie d’énergie constitue l’objectif primordial des RCSF.

Toutes ces caractéristiques nous mènent à déduire que les protocoles MAC de Bluetooth, de
MANET ou du GSM ne peuvent pas être utilisés directement par les RCSF.
La question qui se pose alors est la suivante :
Quelles doivent être les caractéristiques d’un protocole MAC convenable aux RCSF ?
II-2. Les caractéristiques d’un protocole MAC convenable aux

RCSF
Afin de concevoir le protocole MAC le mieux adapté aux spécificités des RCSF, on doit prendre
en considération les propriétés suivantes [DEM 03] :
- L’optimisation d’énergie : cette propriété est la plus importante de toutes dans le cas des
RCSF. En effet, le fait qu’il est difficile de changer ou de recharger les batteries des nœuds,
constitue un vrai handicap qui limite leur durée de vie.
Comme la couche MAC contrôle les activités de la couche radio qui à son tour consomme le plus
d’énergie, alors on peut déduire que la couche MAC peut gérer cette consommation en essayant
d’empêcher les pertes de cette énergie.
- L’évitement des collisions : Cette caractéristique constitue la mission principale de tous les
protocoles MAC qu’ils s’agissent des réseaux filaires ou des réseaux sans fil.
- L’adaptation au changement : Les RCSF sont des réseaux dynamiques au niveau de leur
taille, leur densité ou leur topologie ; Alors dans ce cas, un protocole MAC efficace doit gérer
rigoureusement ces changements sans qu’il y ait un dysfonctionnement du réseau.
- Le « Throwghput » : c’est la quantité de données transmises avec succès entre un émetteur et

un récepteur dans un temps bien déterminé. Il constitue une caractéristique assez importante
dans le cas des applications qui requièrent un bon « throughput ».
- L’équité (Fairness) : Elle reflète la capacité des nœuds capteurs à partager le canal d’une façon
équitable. Dans le cas des RCSF, cette propriété n’est pas prise en considération puisque tous les
nœuds collaborent ensemble, indépendamment de la quantité d’informations émises par les
différents nœuds, afin de remplir une tâche commune.

Cette propriété reste cependant très importante dans les réseaux sans fil classiques du fait que
chaque nœud désire avoir la même chance que les autres noeuds pour l’émission ou la réception
des données.
- Le temps d’attente ou latence : C’est le délai entre l’instant d’émission d’un message et
l’instant de sa réception avec succès. L’importance de cette caractéristique est dépendante du type
d’application.
Pendant que les protocoles MAC classiques sont conçus de telle sorte qu’ils maximisent le
« throughput », minimisent la latence et assure une égalité des chances de transmission (fairness).
La conception du protocole MAC des RCSF se focalise essentiellement sur la minimisation de la
consommation d’énergie [VAN 03].
La question qui se pose alors est la suivante: Comment est consommée l’énergie au niveau de la
couche MAC dans les RCSF ?
II-3. La consommation d’énergie au niveau de la couche MAC

dans les RCSF
On essayera dans ce qui suit d’analyser les raisons de perte d’énergie au niveau de la couche MAC
dans les RCSF [Ye 03]:
- Les collisions : dans le cas d’une collision entre 2 ou plusieurs paquets, ces derniers vont être
rejetés et par conséquent retransmis par leurs émetteurs. Cette retransmission va augmenter la
consommation d’énergie des nœuds capteurs émetteurs.
- Le phénomène d’ « idle-listening » ou écoute passive : Il apparaît quand le nœud reste à

l’écoute du médium pour recevoir des données possibles. Il est très coûteux en énergie
notamment dans le cas des applications qui ne nécessitent pas pratiquement un grand échange
de données.
Le coût de la consommation d’énergie dans les communications de type radio dépend à la fois
du matériel d’émission/réception et de la distance. En effet, si cette distance est grande, (Cas
des WLAN, WWAN) le coût de consommation dû à l’écoute et à la réception est négligeable
comparativement à celui dû à la transmission.

Cependant, dans les RCSF là où la distance est petite, le coût de consommation d’énergie dû à
l’écoute passive est presque du même ordre de grandeur que celui dû à la réception et à
l’émission [Ye 03].
- Le phénomène d’« Overhearing » ou « Sur-écoute » : cela signifie que le nœud reçoit des
paquets qui sont normalement destinés à d’autres nœuds. Ce phénomène peut constituer une
cause importante de perte d’énergie dans le cas d’une zone à forte densité avec un trafic assez
volumineux.
- Le phénomène d’« overemitting » ou « Sur-émission » : il est causé par la transmission

d’un message vers un nœud qui n’est pas encore prêt à recevoir des données.
La synthèse de cette partie nous amène à déduire que pour les RCSF qui se caractérisent
généralement par leur forte densité et leur trafic non important, le phénomène d’« idle listening »
ou écoute passive constitue la cause principale de la perte d’énergie dans les nœuds capteurs.
II-4. Le protocole Sensor-MAC

Sensor-MAC est un protocole MAC spécialement conçu pour les RCSF. Il a été proposé par Ye
et al. à l’université de Californie à Los Angeles.
L’objectif majeur de ce protocole est de réduire les pertes d’énergie dues aux causes que l’on a
identifiées précédemment.
Il supporte les quatre mécanismes suivants :
- Les états périodiques “actif” et “endormi”
- L’évitement de collision
- L’évitement du phénomène de « sur-écoute »
- Le “Message passing”.
II-4-1. Les séquences d’états périodiques “actif” et “endormi”
D’après notre analyse sur la consommation d’énergie au niveau de la couche MAC dans les
RCSF, nous avons constaté que l’écoute passive constitue la cause principale de perte d’énergie.
L’idée apportée par Sensor-MAC pour limiter au maximum cette écoute passive est d’entraîner
les nœuds dans un état endormi périodique [HEI 02] en se basant sur un « duty-cycle » fixe (égale
au rapport de la durée de la période « listen » sur la somme des périodes « listen » et « sleep »).

En effet, chaque nœud s’endort pendant un laps de temps puis se réveille et se met à l’écoute
pour voir s’il y a un autre nœud voulant initier une communication avec lui ou s’il veut lui-même
initier une communication. Durant l’état endormi, le nœud éteint sa « radio » et déclenche un
temporisateur pour son réveil plus tard.
Figure 3.1 : Principe des états périodiques “actif” et “endormi” [HEI 02]
La durée des états « listen » et « sleep » varie d’une application à une autre.
Chaque nœud est libre de choisir sa propre séquence d’état « actif/endormi ». Toutefois, pour
réduire le temps d’attente, chaque noeud doit synchroniser sa séquence d’états « actif/endormi »
avec les nœuds qui lui sont proches [Ye 03].
Avant que chaque nœud ne commence une séquence d’états périodiques, il doit d’abord choisir
sa propre séquence et l’échanger avec ses voisins ; Il doit maintenir alors une table de séquences
qui enregistre les séquences des nœuds voisins.
Afin de choisir sa propre séquence et établir la table des séquences, chaque nœud doit suivre les
étapes suivantes :
- Le nœud commence par écouter le support, s’il n’intercepte aucune séquence d’un nœud
voisin alors il va choisir immédiatement sa propre séquence et va l’émettre dans un
paquet SYNC vers tous les nœuds voisins.
- Si un nœud A reçoit une séquence d’un nœud voisin B avant qu’il choisisse et annonce sa
propre séquence, alors A doit adopter la séquence de B. Une fois la séquence a été
choisie, le nœud A doit émettre cette séquence vers les nœuds voisins [Ye 03].
Si un nœud A reçoit une séquence, d’un nœud voisin B, différente de la sienne. Deux cas peuvent
se produire :
- Si A n’admet que B comme voisin alors A doit détruire sa propre séquence et
suivre la séquence de B.
- Si A admet un ou plusieurs voisins avec lesquels il a déjà échangé une séquence,
alors A doit adopter à la fois sa propre séquence et la séquence de B. Ainsi, le
nœud A sera réveillé pendant les intervalles « actif » des deux séquences [HEI 02].

II-4-2. L’évitement de collision
Si plusieurs nœuds voisins veulent communiquer avec le même nœud en même temps, ils vont
essayer d’émettre leurs données quand ce nœud entamera sa période « listen ». Cette opération va
entraîner une collision de leurs requêtes.
Le principe d’évitement de collision dans Sensor-MAC est le même que celui utilisé dans DCF
(Distributed Coordinated Function) pour le cas de IEEE 802.11 qui utilise l’échange de
RTS/CTS et l’écoute virtuel/physique de la porteuse.
En effet, dans chaque paquet transmis, il existe un champ qui indique le temps de transmission
restant. Dans ce cas, si un nœud reçoit un paquet destiné à autrui, il va connaître grâce à ce
champs, le temps qu’il restera silencieux. Il enregistrera cette valeur dans son compteur NAV et
déclenchera un temporisateur. Le NAV sera alors décrémenté jusqu’à ce qu’il atteigne la valeur
zéro.
Si cette valeur diffère de zéro alors le nœud conclura que le support est occupé. Cette opération
est dite écoute virtuelle de la porteuse [HEI 02].
II-4-3. L’évitement du phénomène d’Overhearing
Etant donné que les RCSF sont caractérisés par leur forte densité, alors il est évident qu’un nœud
reçoit de ses nœuds voisins des paquets qui ne lui sont pas destinés.
Le phénomène d’ « Overhearing » peut entraîner une importante perte d’énergie, surtout lorsque
le trafic est très chargé.
Sensor-MAC essaie de remédier à cet inconvénient en entraînant les nœuds voisins dans une
phase « sleep » juste après qu’ils « sur-entendent » un paquet RTS ou CTS.
Dans la figure suivante, les nœuds A, B, C, D, E et F forment un réseau à multi-saut dans lequel
chaque nœud ne peut entendre que les nœuds qui lui sont immédiatement voisins.
Figure 3.2 : L’évitement du phénomène d’Overhearing [HEI 02].

On suppose que A est entrain d’émettre un paquet DATA à B, quels sont alors les nœuds qui
doivent s’endormir durant cette transmission ?
Comme les collisions ne se passent qu’au niveau du récepteur, alors le nœud D doit s’endormir
puisqu’une transmission émanant de lui peut interférer avec le paquet reçu par B à partir de A.
Les nœuds E et F ne produisent pas d’interférence donc ils n’ont pas besoin de s’endormir.
Concernant le nœud C qui est à deux sauts de B, il peut transmettre vers E et A sans se soucier
d’une interférence avec la transmission reçue par B. Cependant, C ne doit pas recevoir de requête
émanant de E car une telle requête va entrer en collision avec celle (paquet DATA) émanant de A
vers C. En plus, après que A finit son émission vers B, il va attendre l’acquittement (ACK) de B.
A ce moment, une transmission de C vers A peut entrer en collision avec l’ACK de B.
 C doit s’endormir car ses transmissions n’ont aucun effet [HEI 02].
Pour récapituler, les nœuds immédiatement voisins à l’émetteur et au récepteur doivent

s’endormir dès qu’ils entendent un paquet RTS ou CTS respectivement de l’émetteur ou du
récepteur. Ils ne pourront émettre des données que lors de leur prochain état « listen » avec un
compteur NAV à 0.
II-4-4. Le « Message Passing »
La transmission d’un long message en un seul paquet peut coûter beaucoup d’énergie à son
émetteur car, en cas où des erreurs surviennent lors de cette transmission, l’émetteur doit
retransmettre tout le paquet.
Cependant, dans le cas où on transmet ce long message en plusieurs petits paquets, on aura un
retard de transmission important car, les paquets RTS et CTS sont obligatoires pour chaque petit
paquet envoyé.
L’approche utilisée dans Sensor-MAC est de fragmenter le long message en de petits fragments
qui seront transmis ensemble en utilisant un seul RTS et un seul CTS grâce auxquels le support
va être réservé pendant toute la transmission de ces fragments.
Chaque petit fragment envoyé par l’émetteur doit être acquitté par le récepteur. Dans le cas
échéant, l’émetteur doit réémettre ce petit fragment non acquitté, et augmenter le temps de
transmission.

Les paquets RTS et CTS contiennent chacun un champ qui indique le temps nécessaire pour
transmettre les petits fragments de données et les paquets ACK.
Ainsi, dans le cas où un nœud voisin entend un paquet RTS ou CTS, il connaîtra
automatiquement la période durant laquelle il restera endormi. Cette période n’est autre que le
temps nécessaire pour transmettre les petits fragments de données et les paquets ACK.
Ce mécanisme de « Message Passing » constitue donc une source d’économie d’énergie au niveau
des nœuds capteurs [HEI 02].
II-5. Le protocole TimeOut-MAC

La description de ce protocole est basée sur un article publié par Tijs Van DAM et al. [VAN 03].
Le protocole TimeOut-MAC est un protocole qui a été conçu afin de remédier aux faiblesses du
protocole Sensor-MAC en matière de charge de trafic variable.
L’idée que le protocole TimeOut-MAC a apportée est de réduire le phénomène d’écoute passive
en rendant le « duty-cycle » variable et dépendant du volume du trafic, contrairement au
protocole Sensor-MAC qui adopte un duty-cycle fixe.
II-5-1. Fonctionnement de Timeout-MAC

Chaque nœud se réveille périodiquement pour communiquer avec ses voisins puis retourne à son
état endormi jusqu’au début de la prochaine séquence. Entre temps, les messages destinés à leur
récepteur seront stockés dans son « buffer ».
Pendant la période « active », un nœud reste à l’écoute du support et pourrait potentiellement
transmettre des paquets durant cette période.
La période « active » se termine quand il n’y a plus aucun événement de réception de message
pendant une durée TA (Timeout Activity) qui détermine la durée d’écoute par séquence
actif/endormi. Par conséquent, la période active est adaptée à la charge du trafic.
Les nœuds communiquent entre eux en utilisant les paquets RTS, CTS, DATA et ACK
La figure suivante illustre le fonctionnement de TimeOut-MAC qu’on a décrit précédemment :

Figure 3.3 : le fonctionnement du protocole TimeOut-MAC [VAN 03]
II-5-2. La Synchronisation entre les nœuds

La synchronisation des séquences s’est inspirée de la méthode décrite dans le protocole
Sensor-MAC.
Le schéma de synchronisation décrit avec Sensor-MAC et adapté par TimeOut-MAC pousse les
nœuds à former des clusters de telle sorte que chaque cluster est décrit par une séquence d’états.
Ceci permet une communication efficace entre les nœuds et évite un maintien d’informations
pour chaque nœud.
II-5-3. Détermination de TA (Timeout-Activity)

Un nœud ne doit pas s’endormir pendant que ses voisins communiquent puisqu’il peut être à tout
moment le récepteur d’un message.
Du fait qu’un nœud C peut ne pas entendre, en raison de la portée limitée d’émission, un paquet
RTS émis par un nœud A, l’intervalle TA doit être suffisamment large pour que C puisse recevoir
au minimum la date de l’émission du paquet CTS (entre la réception d’un paquet et la date de son
émission, il y a une différence du fait que le récepteur est à l’écoute du support).
Figure 3.4 : Choix du paramètre TA dans le protocole Timeout-MAC [VAN 03]
La figure précédente nous montre que la longueur de l’intervalle TA doit vérifier l’inégalité
suivante :
TA > C + R + T
Avec C : longueur de l’intervalle de contention

R : durée de transmission du paquet RTS

T : intervalle de temps (très petit) entre la fin de réception du paquet RTS par B et le
début d’émission du paquet CTS par B.
Le fait de choisir un intervalle TA très large peut avoir des conséquences négatives puisque
l’augmentation du TA implique une augmentation de la phase d’écoute passive donc une
augmentation de la consommation d’énergie.
II-5-4. L’évitement du phénomène d’Overhearing
Le protocole TimeOut-MAC quant à lui, considère l’évitement de la « sur-écoute » comme une

option dont il peut ne pas tenir compte du fait qu’il peut perturber les communications entre les
nœuds dans le cas d’applications qui requièrent le maximum de « throughput ».
En effet, pendant la période où le nœud A va entrer en phase « endormi », il peut manquer la
réception de paquets RTS ou CTS destinés vers lui et va donc perturber les communications avec
autrui lors de son réveil. Par conséquent, le « throughput » va diminuer.
II-6. Le protocole Wise-MAC

Wise-MAC utilise la technique de « Preamble Sampling » pour minimiser la perte d’énergie due à
l’écoute passive.
La technique de « Preamble Sampling » consiste à écouter le canal périodiquement pendant des
périodes assez courtes pour vérifier s’il y a une activité sur le canal.
Si le canal est occupé, le récepteur continue son écoute périodique dans l’attente d’un paquet qui
lui est destiné ou jusqu’à ce que le canal retourne à son état libre [DEC 03].
Au niveau de l’émetteur, un préambule « Wake up » est transmis avant chaque message pour
s’assurer que le récepteur sera à un état « actif » lorsque le message va lui arriver.
Ce préambule « Wake up » va consommer de l’énergie que ce soit au niveau de l’émetteur ou du

récepteur alors que le transfert de données n’a pas encore commencé [DEC 03].
Afin de remédier à cette perte d’énergie, Wise-MAC offre une méthode qui permet de déterminer
dynamiquement la longueur de ce préambule de telle sorte qu’il soit le plus petit possible. Cette
méthode consiste à connaître les séquences « endormi » des voisins directs de l’émetteur.
En connaissant ainsi la séquence « endormi » du destinataire, l’émetteur va émettre son
préambule « Wake up » pendant une période minimum Tp juste avant que le récepteur débute sa
nouvelle période d’écoute [DEM 03].
La figure suivante montre et explique le fonctionnement de base du protocole Wise-MAC :

Figure 3.5 : Le fonctionnement de base du protocole Wise-MAC [HOI 04]
Chaque nœud maintient une table contenant les séquences « endormi » des voisins directs, qui
sera lue et mise à jour par le nœud lui-même et ceci grâce au paquet ACK qui lui est renvoyé et
qui non seulement acquitte son envoi mais aussi contient la durée restante au récepteur pour
débuter son prochain écoute [HOI 04].
Pour éviter les collisions, Wise-MAC utilise une technique CSMA non persistent avec un choix
aléatoire du préambule « Wake up » [DEM 03]
II-7. Le protocole TRAMA (Traffic-adaptive medium access

protocol)
La description de ce protocole figure dans un article publié par Rajendran V. et al [RAJ 03].
TRAMA a été conçu dans le but de réduire la consommation d’énergie dans les RCSF.
Il se base sur une approche TDMA qui consiste à partager le temps en plusieurs slots qui ne
seront alloués qu’aux nœuds qui ont des informations à transmettre ce qui diminue le temps
d’attente des autres nœuds.
II-7.1- Fonctionnement du protocole TRAMA

TRAMA utilise un algorithme d’élection distribué basé sur l’état du trafic au niveau de chaque
nœud. Cet algorithme, qui sera traité par la suite, permet de sélectionner les récepteurs potentiels
selon les « schedules » annoncés par les émetteurs.

Les nœuds utilisant le protocole TRAMA échangent les « schedules » de transmission (spécifiant
les récepteurs potentiels des messages à émettre, dans un ordre chronologique ainsi que des
informations sur le trafic à émettre) ainsi que des informations sur leur voisinage, avec leurs
homologues situés à deux sauts d’eux.
Grâce à ses informations échangées, le protocole TRAMA va déterminer les nœuds susceptibles
d’émettre ou de recevoir des données durant chaque slot de temps.
La figure suivante illustre l’organisation des slots de temps dans le protocole TRAMA :
Figure 3.6 : Organisation des slots de temps dans le protocole TRAMA [RAJ 03]
D’après cette figure, on remarque qu’il existe deux types d’accès au support en fonction des slots
de temps :
- Un accès aléatoire (possibilité de collision) lors des slots de temps destinés à la
signalisation.
- Un accès déterministe (pas de collision) lors des slots de temps destinés à la transmission.
Le protocole TRAMA se décompose de trois composants :

- Le protocole voisin ou Neighbor Protocol (NP).
- Le protocole d’échange de « schedule » ou Schedule Exchange Protocol (SEP).
- L’algorithme d’élection adaptée ou Adaptive Election Algorithm (AEA).

Les deux premiers protocoles NP et SEP permettent à un noeud d’échanger des informations sur
son voisinage ainsi que son « schedule » avec ses voisins situés à deux sauts de lui.
Quant à l’algorithme AEA, il utilise les informations échangées (Schedule et informations sur le
voisinage) afin de sélectionner les émetteurs et les récepteurs pour le slot de temps courant, et
permet aux autres noeuds d’entrer ainsi en mode « low-power ».
II-7.2- L’algorithme d’élection adaptée

Durant les slots de temps destinés pour l’émission de données (accès déterministe), AEA va
sélectionner les émetteurs et les récepteurs.
Un nœud est sélectionné pour transmettre s’il possède la priorité la plus grande dans la série de
tous ses nœuds voisins s’étendant jusqu’au deuxième saut.
La priorité d’un nœud d’identité « u » lors d’un slot de temps t est défini comme étant la fonction
pseudo-rando hash de la concaténation de « u » et de t.
Prio (u,t) = MD5 (u+t)
A n’importe quel slot de temps t pendant la période d’accès déterministe, un nœud d’identité « u »
peut avoir trois états possibles : TX : transmission, RX : réception, SL : endormi.
Pour un slot donné, un nœud « u » est à l’état TX s’il a la plus grande priorité Prio(u,t) entre la
série de tous ses nœuds voisins du deuxième saut, ou s’il est entrain de transmettre
Chaque nœud exécute l’algorithme AEA pour décider de son état courant qui est lié à sa priorité
par rapport aux autres (deuxième saut) mais aussi aux « schedules » de ses voisins.
II-8. Le protocole Lightweight-MAC
La description de ce protocole est basée sur un article publié par Van Hoesel L. et al. [HOE04].
Le protocole Lightweight-MAC est basé sur la technique TDMA. Le temps est divisé en des slots
de temps qui peuvent être utilisés par les nœuds pour transmettre des données sans avoir à
écouter le canal.
A chaque slot de temps, Lightweight-MAC assigne un nœud qui sera le contrôleur de ce slot de
temps.
II-8-1. La synchronisation des nœuds

Quand le réseau est initialisé (mise en marche), tous les nœuds sont désynchronisés. La passerelle
appelé aussi « Sink » commence par le contrôle de son propre slot de temps et elle émettra un

message de contrôle grâce auquel les nœuds voisins de la passerelle vont pouvoir synchroniser
leurs séquences. Ensuite, ces nœuds vont choisir aléatoirement leurs slots de temps qu’ils vont
contrôler.
Une fois les slots de temps seront choisis, ces nœuds vont émettre leurs messages de contrôle
pour continuer le processus de synchronisation.
II-8-2. Principe d’émission/réception dans Lightweight-MAC

Durant un slot de temps, le nœud contrôleur de ce slot transmet un message qui contient deux
sections qui sont :
- Le message de contrôle qui porte l’identifiant (ID) du contrôleur du slot de temps ainsi
que l’identifiant (ID) du slot de temps utilisé. Il contient les informations suivantes : la
distance (en nombre de sauts) séparant le nœud de la passerelle, l’adresse du destinataire
et la longueur de l’unité de données.
- L’unité de données qui contient les données à transmettre.
Tous les nœuds reçoivent les messages de contrôle de leurs nœuds voisins. Deux cas se posent :
- Si un nœud n’est pas adressé dans le message de contrôle transmis, il prendra alors l’état
« endormi » et ne se réveillera qu’au prochain slot de temps.
- Si un nœud est adressé, il écoutera alors l’unité de données transmise et retournera ensuite
à son état « endormi » juste après la réception du message.
II-8-3. L’évitement de collision

Afin d’éviter les collisions, les nœuds maintiennent des tables contenant les identifiants des slots
alloués aux nœuds situés dans un périmètre de trois sauts.
Il existe une possibilité (probabilité faible) du même choix du slot de temps entre deux ou
plusieurs nœuds. Dans ce cas, les nœuds informent leurs voisins qu’une collision entre les
messages de contrôle a eu lieu.
Les nœuds qui ont émis ces messages de contrôle vont alors stopper leur contrôle aux slots
utilisés et rechoisir aléatoirement d’autres slots (à part ceux qui ont été choisis) après un temps
back-off dépendant de l’identifiant (ID) du nœud.
II-9. Le protocole MAC de la norme IEEE 802.15.4

Dans la partie « Annexes », nous avons présenté un aperçu sur cette norme.

En ce qui concerne le protocole MAC de cette norme, il est responsable des tâches suivantes
[ZHE 04] :
- La synchronisation par la génération de « network beacons » : le coordinateur envoie
périodiquement des « beacons » pour synchroniser les périphériques qui lui sont attachés.
Cette synchronisation est importante pour l’économie de l’énergie au niveau des nœuds capteurs.
Dans le mode « beacon enabled », une structure de « superframe » est utilisée. Laquelle
« superframe » est bornée par deux « beacons » et est divisée, dans sa partie active, en un nombre
de slots égal à 16 par défaut.
- L’auto-configuration : Pour supporter l’auto-configuration, le protocole MAC de la norme
IEEE 802.15.4 emploie les fonctions d’association et de dissociation utilisées dans les réseaux
WPAN.
- L’accès au canal : le mécanisme utilisé pour accéder au canal est CSMA/CA. Cependant, le
nouveau standard n’inclut pas les mécanismes RTS et CTS en raison du principe du faible débit
utilisé dans les LR-WPAN.
- Le maintien du mécanisme de GTS (Guaranteed Time Slot) : Lorsqu’il fonctionne en
mode « beacon-enabled », un coordinateur peut allouer des portions de la partie active du
« superframe » à un device. Ces portions sont appelées des GTS.
- L’assurance d’une liaison fiable : Afin d’assurer des communications fiables entre les
différentes entités, le protocole MAC de la norme IEEE 802.15.4 emploie des mécanismes tels
que l’accusé de réception, la retransmission de la trame ou la vérification des données en utilisant
le 16-bit CRC (utilisé dans CSMA/CA).
III- Troisième partie : Etude comparative de

quelques protocoles MAC proposés dans les RCSF
III-1. Les critères de comparaison
Pour réaliser cette étude comparative, nous nous sommes basés sur les quatre critères suivants :
- L’allocation du canal radio.
- La notification
- La gestion d’énergie
- La qualité de service.

III-1-1. L’allocation du canal radio
Dans les communications radio fréquence, s’il existe plus qu’un nœud qui veut transmettre des
données sur le même canal et en même temps, alors des problèmes de communication tels que
les collisions ou la distorsion, peuvent surgir.
Afin d’éviter de tels problèmes, une partie de la bande passante est allouée à chaque nœud.
Cette allocation peut être soit statique, soit dynamique :
- Allocation statique : cette technique d’allocation divise la bande passante en N parties.

Chaque partie est allouée à un nœud. Les techniques de multiplexage utilisées pour diviser la
bande passante ont été décrites dans la première partie de ce chapitre et sont : TDMA,
FDMA et CDMA.
En général, les protocoles MAC dans les RCSF, qui emploient une allocation statique du
canal, utilisent la technique TDMA du fait que FDMA et CDMA ne rencontrent pas les
contraintes de consommation d’énergie imposées dans les nœuds capteurs.
Cette technique requiert une synchronisation entre les nœuds afin de permettre à chaque
nœud d’identifier ses slots de temps.
La synchronisation dans le cas des RCSF est de type distribué où chaque nœud ou groupe de
nœuds génère sa propre séquence d’états qui sera ajusté périodiquement.
La synchronisation centralisée n’est pas applicable dans les RCSF car ce genre de réseau
souffre d’un temps d’attente élevé et une perte de paquets assez fréquente.
Donc, dans le cas d’un retard ou d’une perte du signal de synchronisation, le réseau sera
perturbé.
- Allocation dynamique : Dans cette technique d’allocation, il n’existe pas de bande

passante allouée d’une manière prédéfinie pour chaque nœud. Tout nœud voulant accéder au
canal doit gagner la contention. Avec ce type d’allocation, il existe une forte probabilité de
collision.
III-1-2. La notification
Afin de réussir la communication entre émetteur et récepteur, ce dernier doit être à l’écoute du
canal au moment où la transmission commence. Ainsi, il sera notifié de l’existence d’une
transmission sur le canal. Cette notification peut être classée en deux types :

- Par réservation : Ce type de notification est utilisé par les protocoles basés sur une
allocation statique du canal, là où les nœuds possèdent des slots prédéterminés pour
l’émission ou la réception. Lightweight-MAC est un exemple de protocole qui emploie ce
type de notification.
- Par écoute du canal : Dans les protocoles utilisant une allocation dynamique
du canal, il n’existe pas de slots prédéterminés pour émettre ou recevoir des données.
Un nœud peut être toujours à l’écoute du canal en attente de recevoir une transmission qui lui
est destinée. Malgré que cette méthode d’écoute pourrait augmenter les chances de réception
du message, cette méthode est trop coûteuse en énergie.
Afin d’éviter de telles pertes, les nœuds changent périodiquement d’états « endormi » et
« actif ». L’écoute du canal peut être synchrone ou asynchrone :
- Synchrone : la séquence d’états « actif/endormi » est déterminé par un échange de
messages de synchronisation. Chaque nœud connaît quand est-ce que ces nœuds voisins
sont à l’état actif. Ainsi, le nœud émetteur attend jusqu’à ce que le récepteur entre en état
actif pour lui transmettre son message.
Sensor-MAC et TimeOut-MAC sont des protocoles qui emploient une écoute synchrone
du canal.
- Asynchrone : Les nœuds ne connaissent pas quand est-ce que leurs voisins sont
actifs. Ils se mettent alors périodiquement à l’écoute du canal pour vérifier s’il y a
une transmission qui va avoir lieu. Cette méthode est connue sous le nom de « Preamble
Sampling ». Wise-MAC utilise ce type d’écoute du canal.
III-1-3. La gestion d’énergie

Ce critère sera traité en présentant les avantages et inconvénients en matière de gestion d’énergie,
de chaque protocole MAC décrit auparavant.
III-1-4. La qualité de service

Contrairement aux réseaux classiques là où les composantes de base de la qualité de service sont
la bande passante, l’équité et le temps d’attente. Ces composantes sont, pour la majorité des
protocoles MAC proposés pour les RCSF (à l’exception du protocole MAC de la norme IEEE
802.15.4), sacrifiées aux dépens de l’optimisation de la consommation d’énergie des nœuds
capteurs.

Cela ne veut pas dire que la qualité de service n’est pas tenue en compte dans ce type de réseau,
sauf qu’elle est dépendante essentiellement du type d’application qui tourne au niveau du RCSF.
En effet, les concepteurs de Sensor-MAC, Time-Out MAC ou Wise-MAC avaient pour premier
objectif, la réduction de consommation d’énergie pour maximiser la durée de vie du réseau ce qui
convenait avec les applications qu’ils utilisaient (militaire...).
Cependant, et pour le cas du protocole MAC de la norme IEEE 802.15.4 (norme utilisée à des
fins d’applications pour le grand public), la bande passante et le temps d’attente par exemple sont
des paramètres de qualité de service fortement tenus en compte.
III-2. Le tableau comparatif

Le tableau suivant illustre une classification des protocoles MAC proposés pour les RCSF, selon
les quatre critères qu’on a décrit précédemment (L’allocation du canal radio, La notification, La
gestion d’énergie, La qualité de service).

Protocole Allocation du Notification Avantages Inconvénients Qualité de

canal radio Service
Dynamique Ecoute - protocole économique en - Les périodes « endormi » et « actif » Absente

basée sur synchrone du consommation d’énergie sont prédéfinies à l’avance, ce qui
CSMA canal grâce aux séquences limite l’efficacité de l’algorithme
périodiques « endormi ». Sensor-MAC dans le cas d’une
Sensor- charge de trafic variable => un faible
MAC Throughput en cas de forte charge
de trafic.
- Les paquets de données de type

« Broadcast » n’utilisent ni RTS, ni
CTS ce qui augmentent la probabilité
de collision dans ce genre de
transmission.
- Problème du « early sleeping » : Le

nœud s’endort avant la réception des
données qui lui sont destinées.
=> Le temps d’attente devient
important. En plus, il s’accumule à
chaque fois qu’on passe d’un saut à
un autre.
Dynamique Ecoute - protocole économique en - Problème du « early sleeping ». Absente

basée sur synchrone du consommation d’énergie
TimeOut- CSMA canal grâce aux séquences
MAC périodiques « endormi ».
- Les périodes « endormi » et
« actif » sont déterminés en

fonction du trafic :
TimeOut-MAC ajuste sa
consommation d’énergie,
dans le contexte d’un trafic
variable, grâce au Time-Out
Timer (TA).
=> Adaptation au trafic.
Absente
Dynamique Ecoute - L’ajustement dynamique de - L’utilisation de préambule « Wake-
basée sur asynchrone du la longueur du préambule (de up » va consommer de l’énergie
CSMA canal telle sorte qu’il soit le plus (Overhead) que ce soit au niveau de
petit possible) permet des l’émetteur ou du récepteur alors que
économies de consommation le transfert de données n’a pas
Wise-MAC d’énergie. encore commencé.
Statique à Par - Protocole basé sur la - Lors du choix aléatoire du slot de Absente
synchronisation réservation technique TDMA temps, il y a une chance que deux ou
=> probabilité de collision plusieurs noeuds choisissent le même
Lightweight centralisée, faible. slot. A ce moment, ils doivent
basée sur
MAC TDMA supprimer leurs premiers choix et
rechoisir une deuxième fois ce qui
consomment plus d’énergie.
- Les nœuds doivent être toujours à
l’écoute lors des sections de
contrôles.

Statique à Par - protocole basé sur la - Pour chaque slot de temps, le nœud Absente
synchronisation réservation technique TDMA calcule les priorités de ses nœuds
distribuée, => probabilité de collision voisins situés jusqu’au deuxième saut.
TRAMA faible. => traitement interne élevé au
basée sur
TDMA - Les nœuds qui n’ont pas à niveau du capteur => consommation
transmettre ou à recevoir des d’énergie élevée.
données vont fermer leurs
« radio » et entrer en mode
« sleep ».
=> Pas de période d’écoute
passive => Gain d’énergie.
Protocole Dynamique Ecoute Pour le cas de RCSF de petite La gestion d’énergie s’effectue, d’une Présente
MAC de basée sur asynchrone du taille, la consommation manière centralisée (Le coordinateur
IEEE 802.15.4 CSMA canal d’énergie est réduite tout en gère la consommation d’énergie de
gardant de bonnes capacités tous les nœuds), contrairement aux
de transmission. protocoles MAC décrits ci-dessus là
où la gestion d’énergie est effectuée
d’une manière répartie au niveau de
chaque nœud.

Chapitre3 L’accès au support dans les réseaux sans fil
Conclusion :
Dans ce chapitre, nous avons essayé de faire une synthèse de quelques protocoles MAC proposés
dans les RCSF. Cette synthèse a été clôturée par une étude comparative qui nous a permis d’avoir
une vision globale regroupant leurs principales caractéristiques, leurs avantages et inconvénients.

Chapitre 4 Solution proposée et situation par rapport à l’existant
Chapitre 4 : Solution proposée et situation par

rapport à l’existant
Introduction
Dans ce chapitre, on se propose dans une première partie de présenter la solution qu’on a
proposé (Sensor-MACp) et ses algorithmes de base. Dans une seconde partie, nous allons
comparer cette solution, en se basant sur la consommation d’énergie et le « throughput », par
rapport à l’existant tout en citant ses apports et ses faiblesses.
I- Première partie : Présentation de la solution

proposée (Sensor-MACp)
I-1. Principe de Sensor-MACp

Dans cette partie, nous allons s’intéresser à l’amélioration du protocole Sensor-MAC qui, comme
on l’a constaté d’après l’étude comparative théorique, consomme plus d’énergie que Timeout-
MAC, et se caractérise par un throughput assez faible lors de l’augmentation de la charge du trafic
en raison de son « duty-cycle » fixe (rapport de la période active sur la somme de la période active
et la période « endormi ») qui entraîne le problème de l’ « early-sleeping ».
Notre contribution consiste à intégrer, le principe du mécanisme de « preamble sampling » qui a

été utilisé dans le protocole Wise-MAC, au niveau de l’implémentation du protocole Sensor-
MAC, afin d’améliorer la consommation d’énergie et le throughput au niveau des nœuds
capteurs.
En effet, les périodes « actif » d’écoute qui sont normalement de taille fixe dans le protocole
Sensor-MAC vont être, pour le cas de Sensor-MACp, :
- réduites avec une taille fixe égale au (1/2) de la période adoptée par Sensor-MAC lors d’une
écoute passive « idle listening ».
- prolongées avec une taille fixe de longueur égale à la période adoptée par Sensor-MAC lors
d’une émission ou réception de données :

De cette manière, nous aurons trois types de séquences d’états « actif/endormi » possibles :
II-2. L'algorithme d’émission de données

Cet algorithme concerne les types de données (SYNC, RTS, CTS, DATA, ACK) qu’un nœud
pourrait émettre selon le mode de transmission « unicast » ou « broadcast ». En effet, un nœud ne
peut émettre des données que s’il est à l’état actif, que son compteur NAV (vecteur d’allocation
réseau) est à 0 et que l’indicateur de puissance du signal reçu est supérieur à 0.5.
Avant l’émission de paquet SYNC (paquet de synchronisation), de paquet RTS ou de paquet
DATA en mode « broadcast », un nœud doit impérativement contentionner le canal pendant une
durée égale TYPE_CONTEND_TIME avec TYPE = {SYNC, RTS, CTS, DATA}.

Pour le cas d’émission de paquet SYNC, le nœud reste en écoute passive de durée égale à
passive_preamble_time.
Pendant l’émission de paquet RTS, CTS et DATA (mode « broadcast »), la période active est
égale à 3 fois la valeur de « passive_preamble_time » car, lors d’une telle émission, de nouvelles
transmissions de données vont être initiées.
Pour le cas d’émission de paquet DATA en mode « unicast » ou de paquet ACK, le nœud n’a pas
besoin de contentionner le canal.
L’algorithme d’émission de données est le suivant :
Début
Si (l'état du noeud est “actif”)
alors
Si la variable NAV est à zéro alors
Si ((l'indicateur de puissance du signal reçu) > 0,5) alors
Rester à l’écoute passive (passive_preamble_time)
Sinon
Selon l'état du noeud faire
1er Cas : le noeud contentionne le canal (PROTO_STATE_CONTEND)
Selon le prochain état du nœud (next_state) faire :
1er sous-cas: Si le noeud se prépare à envoyer un paquet SYNC

(état PROTO_STATE_SEND_SYNC) alors il commence par contentionner le canal
pendant une durée SYNC_CONTEND_TIME.
rester à l’écoute passive (passive_preamble_time) et émettre le paquet SYNC
2ème sous-cas: Si le noeud se prépare à envoyer un paquet RTS

(état PROTO_STATE_SEND_RTS) alors il commence par contentionner le canal
pendant une durée RTS_CONTEND_TIME.
lancer une période d’écoute active (3 * passive_preamble_time) et émettre le paquet RTS
le nœud va changer d’état (état PROTO_STATE_WFCTS) pour montrer qu'il sera en
attente du paquet CTS pendant une durée égale à TIMEOUT_WFCTS.
3ème sous-cas: Si le noeud se prépare à envoyer un paquet DATA en mode

broadcast (état PROTO_STATE_SEND_DATA) alors il doit commencer par
contentionner le canal pendant une durée DATA_CONTEND_TIME.
lancer une période d’écoute active et émettre le paquet DATA.
4ème sous-cas: Si le noeud se prépare à envoyer un paquet CTS (état

PROTO_STATE_SEND_CTS) alors il doit commencer par contentionner le canal
pendant une durée CTS_CONTEND_TIME.
Le nœud va changer d’état (état PROTO_STATE_WFDATA) pour montrer qu'il sera
en attente du paquet DATA pendant une durée égale à TIMEOUT_WFDATA.
FinSelon

2ème cas : Si le noeud se prépare à envoyer un paquet DATA en mode unicast

(état PROTO_STATE_SEND_DATA) alors émettre le paquet DATA et
changer d’état (état PROTO_STATE_WFACK) pour montrer qu'il sera en attente du
paquet ACK pendant une durée égale à TIMEOUT_WFACK.
3ème cas: Si le noeud se prépare à envoyer un ACK (état

PROTO_STATE_SEND_ACK) alors émettre le paquet ACK.
FinSelon
Finsi
Fin
II-3. Algorithme de réception de données

Si un nœud reçoit des paquets alors qu’il est à l’état endormi, ces paquets vont être rejetés.
Dans le cas où un nœud est à l’état actif et qu’il n’existe pas de nœuds voulant initier des
communications avec lui alors il doit lancer une période d’écoute passive.
Dans le cas où un nœud récepteur est à l’état actif et il existe un deuxième nœud voulant initier
une communication avec lui, alors selon le type du paquet reçu, le nœud récepteur doit agir de la
manière suivante :
- En cas de réception d’un paquet de synchronisation SYNC, le nœud doit lancer une
période d’écoute passive.
- En cas de réception d’un paquet RTS, le nœud récepteur doit lancer une période d’écoute
active.
- En cas de réception d’un paquet DATA, si le mode de transmission est point à point alors
ne rien faire sinon le nœud doit lancer une période d’écoute active.
L’algorithme de réception est le suivant :
Début
Si le nœud est à l’état « endormi » alors
rejeter le paquet reçu (return)
Sinon
Si (l’indicateur de puissance du signal reçu < 0.5) alors lancer une période d’écoute
passive de durée égale à passive_preamble_time
Sinon

Selon le type de paquet reçu faire
Si le paquet est de type « SYNC » alors

Lancer une période d’écoute passive de durée (passive_preamble_time)
recevoir le paquet SYNC
Finsi
Si le paquet est de type « RTS » alors

Lancer une période d’écoute active de durée (3*passive_preamble_time)
recevoir le paquet RTS
Finsi
Si le paquet est de type « CTS » alors

recevoir le paquet CTS
Finsi
Si le paquet est de type « DATA » alors

Si (mode unicast) alors recevoir le paquet DATA
Sinon lancer une période d’écoute active (3*passive_preamble_time)
Et recevoir le paquet DATA.
Finsi
Si le paquet est de type « ACK » alors

recevoir le paquet ACK
Finsi
Finselon
Finsi
Finsi
Fin
II- Deuxième partie : Etude comparative de Sensor-

MACp, Sensor-MAC et Timeout-MAC
II-1. Les simulateurs utilisés dans les RCSF

Il existe plusieurs simulateurs de RCSF. Parmi lesquels, on peut citer TOSSIM, SensorSim,
SENS, nrlSimulator. Cependant, le problème avec ces simulateurs réside dans le fait qu’ils
implémentent tous le protocole MAC de la norme 802.11, qui ne s’adapte pas en réalité avec les
contraintes des nœuds capteurs en matière de consommation d’énergie.

Nous avons essayer alors de chercher des simulateurs qui implémentent des techniques d’accès
propres aux RCSF. Nous avons alors trouvé les trois simulateurs suivants :
- Le simulateur NS2.
- Le simulateur Avrora.
- Le simulateur OMNET++.
Le simulateur NS2 (Network Simulator 2) :

C’est un outil de simulation à évènements discrets des réseaux informatiques. C’est un simulateur
à usage libre, orienté objet, multi-plateformes (FreeBSD, Linux, Windows…).
A partir de sa version 2.27, Il implémente un modèle de simulation pour les RCSF incluant le
protocole Sensor-MAC comme technique d’accès au support.
On n’a pas opté pour ce simulateur car il n’implémente que Sensor-MAC comme protocole
d’accès pour les RCSF.
Le simulateur AVRORA :
C’est un ensemble d’outils d’analyse et de simulation de programmes en langage assembleur
destinés à tourner sur des microcontrôleurs AVR présents dans les nœuds capteurs de type Atmel
et Mica2. Il offre un outil d’analyse d’énergie qui permet d’étudier la consommation d’énergie au
niveau des nœuds capteurs ainsi que la durée de vie possible de la batterie utilisée [6].
Grâce à ce simulateur, on peut évaluer les performances de Sensor-MAC et de Berkeley-MAC qui
sont en effet implémentés par défaut dans le système d’exploitation TinyOS tournant sur le
simulateur AVRORA.
On n’a pas opté pour ce simulateur étant donné que son utilisation requiert des connaissances en
langage assembleur spécifique aux types de matériels supportés.
Le simulateur OMNET++ :
C’est un environnement de simulation Open source à évènements discrets, qui a été développé
par Andras Varga. Il est orienté objet, écrit en C++ et est utilisé dans plusieurs domaines : la
modélisation de trafic dans les réseaux de télécommunications, la modélisation des protocoles, la
modélisation des systèmes matériels distribués et multiprocesseurs, l’évaluation des performances
des systèmes logiciels complexes [7]…
Il existe plusieurs modèles de simulation Open source qui fonctionnent sur la plateforme de
simulation OMNET++ et qui sont publiés. Parmi lesquelles, on peut citer
- INET Framework pour la modélisation des protocoles IP, TCP, UDP, MPLS…
- IPv6Suite pour la modélisation de IPv6, PPP, Ethernet et 802.11

La particularité d’un modèle de simulation OMNET++, c’est qu’il consiste en un ensemble

d’entités appelées « Modules » qui communiquent entre elles en échangeant des « Messages » qui
seront émis à travers des « Connections » et des « gates ».
OMNET++ est devenu rapidement une plateforme de simulation populaire que ce soit pour la
communauté des scientifiques ou des industriels.
Nous avons opté pour ce simulateur (la version 3.2) parce qu’il permet d’offrir un modèle de
simulation destiné à évaluer l’énergie dans les nœuds capteurs au niveau des protocoles Sensor-
MAC et Timeout-MAC.
II-2. Description du modèle de simulation MACSimulator
Le modèle de simulation MACSimulator qu’on a utilisé a été implémenté au niveau du simulateur

OMNET++. Il est spécifiquement conçu pour simuler La couche MAC dans les RCSF. Il permet
de modéliser chaque couche de la pile protocolaire d'un réseau de capteur sans fil et consiste en
un ensemble de modules indépendants qui sont [DAM 03] :
Le module radio : Il effectue les tâches suivantes:

– reçoit et transmet les trames de données,
– rejeter les trames de données défectueuses,
– effectuer les statistiques de consommation d'énergie.
Ce module peut avoir trois états possibles : transmission, réception ou endormi.
Le module MAC : Ce module est dédié au protocole MAC. L'implémentation du protocole
MAC est définie dans un fichier de configuration (.ini) qui caractérise chaque protocole MAC
qu'on va utiliser (Sensor-MAC ou Timout-MAC) lors des scénarios de simulation.
Ce module assure d'une part l'échange de paquets de données avec le module AppSelector, et
d'autre part, l'échange de trames de données avec le module radio.
Le module Pattern : il concerne le type de communication qui va être utilisé par le noeud, que
ce soit en mode point à point , ou en mode noeud vers sink.
Le module AppSelector : Il joue le rôle d'un Buffer pour stocker les paquets de données à
transmettre. Il permet la redirection des messages reçus vers le module Pattern correspondant.
Par exemple, dans le cas d'un relayage à multi-saut de messages, le module AppSelector va
s'assurer que le message émis par le module Pattern d'un noeud émetteur va arriver vers le
module pattern correspondant au niveau du noeud récepteur.

Le module Node : C'est un module composé. Son unique rôle est de contenir les modules
simples qu'on a décrits précédemment. Chaque noeud possède un ID (identificateur) et une
position.
Le module PropagationModel : Il achemine les messages “radio” d'un noeud vers un autre, il a
aussi un rôle de notification. En effet, en cas où un noeud X va entrer en état “transmission”
(radio à l'état Transmitting), le module PropagationModel va informer les noeuds voisins du
changement d'états du noeud X.
Le module AreaManager : Ce module modélise l'environnement réel de la simulation en

choisissant la taille du réseau, la durée de vie des évènements...
Le schéma suivant illustre la structure du modèle de simulation MACSimulator :
Figure 4.1 : La structure du modèle de simulation MACSimulator [DAM 03]
II-3. Paramétrage du réseau utilisé

Le réseau qu’on va utiliser pour exécuter toutes les simulations des différents scénarios, se
compose de 100 nœuds disposés en maille (GRID), avec une durée de simulation égale à 60
secondes.

Tous ces paramètres ont été configurés dans le fichier « omnetpp.ini » :
-----------------------------------------------------------------------------------------------------------------
…
[Run 1]
sim-time-limit = 60s
...
[Parameters]
Net.grid_cx = 10
Net.grid_cy = 10
…
-----------------------------------------------------------------------------------------------------------------
II-4. Paramétrage des protocoles Sensor-MAC, Sensor-MACp et

Timeout-MAC
II-4.1. Le protocole Sensor-MAC

Sensor-MAC a été configuré avec une longueur de frame (la somme de la période « actif » et la
période « endormi ») égale à 1 seconde et une longueur de la période « actif » qu’on a fixé à
200 ms. Cette configuration est effectuée au niveau du fichier « smac.ini » :
-----------------------------------------------------------------------------------------------------------------
[Parameters]
net.which_mac = “Smac”
net.mac1 = 200 // La période active là où le noeud est en état d’écoute
net.mac2 = 1000 // La longueur du frame qui définit la somme de la période active et
// la période endormi.
...
-----------------------------------------------------------------------------------------------------------------
II-4.2. Le protocole Sensor-MACp

Sensor-MACp utilise un fichier de configuration « smacp.ini » semblable à celui de Sensor-MAC,
et il est de la forme suivante :

-----------------------------------------------------------------------------------------------------------------
[Parameters]
net.which_mac = “Smacp”
net.mac1 = 200 // La période active là où le noeud est en état d’écoute
net.mac2 = 1000 // La longueur du frame qui définit la somme de la période active et
// la période endormi.
...
-----------------------------------------------------------------------------------------------------------------
II-4.3. Le protocole Timeout-MAC

Timeout-MAC a été configuré avec une longueur de frame égale à 615 ms et une longueur de la
période TA (Timeout Activity) égale à 15 ms (valeurs tenus en compte lors de l’implémentation
de Timeout-MAC dans les nœuds EYES)
La configuration de ce protocole est effectuée au niveau du fichier « tmac.ini » :
-----------------------------------------------------------------------------------------------------------------
[Parameters]
net.which_mac = “Tmac”
net.mac1 = 15
net.mac2 = 615
...
-----------------------------------------------------------------------------------------------------------------
II-5. Paramétrage des scénarios

Dans le modèle de simulation de OMNET++ qu’on a utilisé, la définition d’un scénario
s’effectue à travers le fichier « test.scen » et consiste à :
- définir le type de communication utilisé dans le réseau : point à point ou Sink-to-node

- Définir la longueur du message
- Définir le débit utilisé en nombre de messages par seconde (msg/s).
Une fois ces trois paramètres vont être édités dans le fichier « test.scen », le fichier
« omnetpp.ini » va charger le scénario paramétré par l’utilisateur lors de l’exécution de la
simulation.

Le fichier omnetpp.ini
-----------------------------------------------------------------------------------------------------------------
…
[Parameters]
…
net.scenario.inputfile = « test.scen »
…
-----------------------------------------------------------------------------------------------------------------
II-6. La simulation des protocoles Sensor-MAC, Sensor-MACp et

Timeout-MAC
Pour simuler les protocoles Sensor-MAC, Sensor-MACp et Timeout-MAC, nous avons choisi en
premier lieu le modèle de communication « point à point » et dans un second lieu le modèle de
communication « Nœud vers Sink ».
Pour chaque type de communication, nous allons varier le débit de transmission et on relèvera à
chaque fois le « throughput » et la valeur de l’énergie consommée par l’ensemble du réseau. Cette
valeur sera divisée par 100 pour connaître la consommation d’énergie par nœud capteur.
La longueur d’un message sera fixée à 20 octets.
II-6.1. Les modèles de communication
Les simulations vont être effectuées selon les deux modèles de communication suivants :
II-6.1.1. Le modèle de communication « Point à point »
Dans ce cas, on s’intéresse au trafic entre les nœuds voisins. Le choix du nœud émetteur
s’effectue d’une manière aléatoire, il émet alors les messages vers un ou plusieurs voisins situés
autour de lui.
La définition de ce modèle de communication s’effectue dans le fichier « test.scen » en
choisissant l’option « LocalUC ». Ainsi lors de l’exécution d’un scénario, le module « LocalUC »
va être lancé.

Figure 4.2 : Modèle de communication point à point
II-6.1.2. Le modèle de communication « Nœud vers Sink »
Dans ce cas, tous les nœuds émettent des messages d’une manière périodique vers le nœud
« Sink ». La définition de ce modèle de communication s’effectue dans le fichier « test.scen »
en choisissant l’option « ToSink », le nœud qui va jouer le rôle du « Sink », le nombre
maximum de sauts entre le noeud source et le « Sink » et le mode d’aggrégation de messages.
Figure 4.3 : Modèle de communication Nœud vers Sink
Pour ce modèle de communication, on choisira le nœud numéro 0 comme « Sink » et le mode

d’aggrégation égale à 0 (sans aggrégation de messages).
II-6.2. Exécution des scénarios
Pour exécuter les différents scénarios, on doit se situer sous le dossier d’installation
« omneteyes », et taper la ligne de commande suivante :
./omneteyes –f NOM_PROTOCOLE_MAC.ini –f omnetpp.ini
Avec NOM_PROTOCOLE_MAC : smac, smacp ou tmac.
Afin de varier les scénarios, on modifiera le fichier « test.scen » selon le scénario qu’on veut
simuler. La structure de « test.scen » varie d’un modèle de communication à un autre.
- Pour le cas du modèle de communication « Nœud vers Sink », il est structuré de la manière
suivante :
i/a ToSink msg msgps sinknode= ? ttl=? Aggmode= ?

Avec i/a : le nœud peut prendre un état actif ou endormi.

ToSink : le modèle de communication est « Nœud vers Sink »
Msg : la taille d’un message
Msgps : le débit de transmission en nombre de messages par seconde.
Sinknode : le nœud qui jouera le rôle du Sink, il est identifié par un numéro qui détermine
sa localisation dans le réseau.
Ttl : le nombre maximum de sauts du nœud source vers le nœud Sink.
Aggmode : définit le mode d’agrégation des messages du nœud source vers le nœud Sink
Dans nos simulations, ce paramètre sera fixé à 0 (pas d’agrégation de messages)
- Pour le cas du modèle de communication « point à point », il est structuré de la manière

suivante :
i/a LocalUC msg msgps
Avec i/a : le nœud peut prendre un état actif ou endormi.

LocalUC : le modèle de communication est « point à point »
Msg : la taille d’un message
Msgps : le débit de transmission en nombre de messages par seconde.
Pour les simulations des trois protocoles dans les deux modèles de communication, seul le
paramètre « msgps » va varier dans la structure du fichier « test.scen ».
- Les fichiers « collectstats.pl » et « parseenergy.pl » :
Grâce à ces deux fichiers présents sous le dossier /omneteyes/scripts, on a pu récupérer la

consommation d’énergie ainsi que le throughput au niveau de l’ensemble du réseau (100 Nœuds)
pour chaque simulation effectuée.
En effet, le script « collectstats.pl » va organiser les traces fournis par l’exécution de la ligne de
commande « ./omneteyes -f NOM_PROTOCOLE_MAC.ini -f omnetpp.ini » .
La nouvelle ligne de commande deviendra alors :

« ./omneteyes -f NOM_PROTOCOLE_MAC.ini -f omnetpp.ini | ./collectstats.pl »

Le résultat de l’exécution de cette ligne de commande est un ensemble de paramètres qu’on

pourra visualiser (voir les traces de collectstats.pl). Parmi ces paramètres, on va s’intéresser
aux cinq paramètres suivants :
radio_sleep, radio_tx, radio_rx : qui indiquent successivement le temps total passé par les
cents nœuds en état « endormi », en état de transmission et en état de réception.
app_tx, app_rx : qui indiquent successivement le nombre d’octets transmis et reçus dans le
réseau. Ces deux paramètres nous permettront à chaque scénario de calculer le « throughput » sur
le réseau.
Throughput = (app_rx)/(app_tx)
Les trois premiers paramètres seront utilisés par le script « parseenergy.pl » pour générer un
fichier nommé « <type_mac><msglen> » qui contiendra la valeur de la consommation d’énergie
globale dans le réseau.
La ligne de commande à taper est alors :

« ./omneteyes -f NOM_PROTOCOLE_MAC.ini -f omnetpp.ini | ./collectstats.pl |
./parseenergy.pl »
Le calcul de la consommation d’énergie globale s’effectue comme l’indique l’instruction présente

dans le script parseenergy.pl de la manière suivante :
-----------------------------------------------------------------------------------------------------------------
$sleep_cost = 0.02 // Le coût de consommation d’énergie en mA/s par capteur à l’état « endormi »
$rx_cost = 4.0 // Le coût de consommation d’énergie en mA/s par capteur à l’état « réception »
$tx_cost = 10.0 // Le coût de consommation d’énergie en mA/s par capteur à l’état « transmission »
…
($rsleep) = m/radio_sleep=([\d.]*); // Variable qui va contenir le paramètre radio_sleep
($rrx) = m/radio_tx=([\d.]*) ; // Variable qui va contenir le paramètre radio_tx
($rtx) = m/radio_rx=([\d.]*) ; // Variable qui va contenir le paramètre radio_rx
...
$etotal = $sleep_cost * $rsleep + $rx_cost * $rrx + $tx_cost * $rtx //Energie totale
// consommée par les cents nœuds.
-----------------------------------------------------------------------------------------------------------------

Remarque : Les trois premières valeurs de sleep_cost, rx_cost et tx_cost sont définis à l’avance et
caractérisent en fait l’aspect matériel du capteur. Dans le cas du modèle de simulation utilisé, il
s’agit de capteurs EYES [DAM 03].
II-6.3. Les résultats des simulations
Suite à l’exécution des scénarios décrits précédemment, nous avons collecté les différentes valeurs
de consommation d’énergie et du « throughput » comme suit :
II-6.3.1. Cas du modèle de communication « point à point »
Consommation d'énergie dans le modèle de communication "point à

point"
d'énergie/noeud (mA)
0,7
consommation
0,6 Sensor-MAC
0,5
0,4 TimeoutMAC
0,3 Sensor-MACp
0,2
0,1
0
0 50 100 150 200
Nom bre d'octets/noeud/sec
Throughput dans le modèle de communication "point à point"
1,2
1
Throughput
0,8
Sensor-MAC
0,6
TimeoutMAC
0,4
Sensor-MACp
0,2
0
0 20 40 60 80 100 120 140 160 180

II-6.3.2. Cas du modèle de communication « nœud vers Sink »
Consommation d'énergie dans le modèle de communication

"nœud vers Sink"
d'énergie/noeud (mA)
1,5
consommation
1 Sensor-MAC
TimeoutMAC
0,5 Sensor-MACp
0
0 1 2 3 4 5 6 7
Throughput dans le modèle de communication "nœud vers Sink"
0,8
Throughput
Sensor-MAC
0,6
TimeoutMAC
0,4
Sensor-MACp
0,2
0
0 1 2 3 4 5 6 7
II-6.4. Interprétation des résultats

II-6.4.1. Cas du modèle de communication « point à point »
On remarque que Sensor-MACp consomme nettement moins d’énergie que Sensor-MAC. Si on

compare Sensor-MACp avec Timeout-MAC, on peut constater que Sensor-MACp consomme
plus d’énergie que Timeout-MAC.

Concernant le throughput, Sensor-MACp s’avère meilleur que Sensor-MAC étant donnée que sa
valeur ne commence à descendre au-dessus des 90 % qu’à partir d’un trafic de 120
octets/nœud/s alors que c’est 80 octets/nœud/s pour le cas de Sensor-MAC.
Il est à noter que le throughput de Sensor-MACp est meilleur que celui de Timeout-MAC.
II-6.4.2. Cas du modèle de communication « nœud vers Sink »
A faible trafic (<= 2 octets/nœud/s), les nœuds utilisant le protocole Sensor-MAC possède un
throughput >= 90 %. Cependant, et en augmentant le trafic, on remarque que le throughput
diminue d’une manière brusque. Ceci est dû au fait que Sensor-MAC adopte un duty-cycle fixe
(le rapport : active/frame) que ce soit en émission, en réception ou à l’état d’écoute passive. Ce
« duty-cycle » ne permet pas une adaptation avec la charge du trafic donc il y aura forcément une
perte de données.
Pour le cas de notre solution, on remarque que Sensor-MACp consomme plus d’énergie que
Sensor-MAC, celà est dû au fait que dans le modèle de communication « nœud vers Sink », les
100 nœuds capteurs sont susceptibles d’envoyer périodiquement des données vers le nœud Sink
donc à chaque envoi, le nœud émetteur va adopter un duty-cycle qui sera égale à 1.5 * la valeur
du « duty-cycle » adopté par Sensor-MAC. En revanche, on remarque que le throughput pour le
cas de Sensor-MACp est meilleur que celui de Sensor-MAC et de Timeout-MAC (la valeur du
throughput ne descend sous les 90 % qu’à partir d’un trafic de 6 octets/nœud/s). Ceci est dû au
fait qu’en augmentant la charge du trafic, Sensor-MACp possède un duty-cycle plus grand que
celui de Sensor-MAC, qui lui permet d’accueillir ou d’émettre des données avec un minimum de
perte de données.
Le problème de l’ « early-sleeping » qui apparaît à partir de 3 octets/nœud/s pour le cas de

Sensor-MAC et à partir de 4 octets/nœud/s pour le cas de Timeout-MAC (Throughput < 0.9), a
été limité dans le cas de Sensor-MACp. En effet, le Throughput de Sensor-MACp ne descend
sous le seuil des 90 % qu’à partir des 5 octets/nœud/s.
Conclusion
Suite aux résultats obtenus, on remarque qu’on a pu améliorer la consommation d’énergie et le

« Throughput » pour le cas d’un modèle de communication « point à point ». Cependant, et pour

le cas du modèle de communication « Nœud vers Sink », notre amélioration n’a touché que le
« Throughput ».

Conclusion générale
Conclusion générale
Au cours de ce projet de fin d’études, on a eu l’occasion d’approfondir nos connaissances dans le

nouveau domaine des réseaux de capteurs sans fil qui, d’après le MIT’s technology Review,
constitue l’une des dix nouvelles technologies qui bouleverseront le monde et notre manière de
vivre et de travailler.
Nous avons essayé d’analyser grâce à une étude comparative à plusieurs critères les principaux
protocoles MAC destinés aux RCSF.
Nous avons pu découvrir et manipuler le simulateur OMNET++ qui est aussi convoité, dans
différents domaines, par la communauté des scientifiques que celle des industriels.
Nous avons réussi à améliorer le protocole Sensor-MAC en rendant la période « active »
dépendante de l’état du nœud (émission/réception ou écoute passive), plutôt que fixe. Les
résultats qu’on a obtenus suite à notre apport par rapport à Sensor-MAC ont été :
- Un gain en matière de consommation d’énergie et du throughput pour un modèle de

communication point à point.
- Un gain en matière de throughput pour un modèle de communication Nœud vers Sink
Sur le côté personnel, j'ai eu la chance de travailler dans un grand laboratoire, tel qu'est le PRiSM,
et dans une équipe très ambitieuse. La discussion continue sur tous les niveaux de mon projet m'a
permis d'améliorer mes capacités de communications et d'adaptation aux idées des autres. En
outre, le stage m'a permis de découvrir un domaine passionnant qui est celui de la recherche.
Dans les travaux futurs, on se propose dans un premier plan de rendre la période d’écoute active
(lors d’une émission ou réception) totalement dépendante du trafic généré car, même si notre
solution a apporté des gains en énergie pour le modèle « point à point » et des gains en
« Throughput » pour les deux modèles de communication, on remarque que la variation de la
période d’écoute active dans notre solution est statique, c'est-à-dire que lors d’une émission ou
réception de données, la période d’écoute est fixée d’avance et elle est non dépendante du trafic
généré. Donc, notre objectif sera de rendre la variation de la période d’écoute active dynamique
et proportionnelle au trafic généré.
Dans un second plan, on va proposer de tester notre solution sur la plateforme de RCSF « Motes
Berkeley » [8] basée au sein des trois laboratoires de recherche LIP6 de l’université Paris 6, LIFL
de l’université de Lille1 et LAAS de l’INSA de Toulouse.

Liste des figures
Liste des figures

Figure 2.1 : Les catégories des réseaux sans fil [1]
Figure 2.2 : Les réseaux de capteurs sans fil dans leur contexte pratique [AKY 02]
Figure 2.3 : L’architecture matérielle d’un nœud capteur [AKY 02]
Figure 2.4 : La pile protocolaire des RCSF [AKY 02]
Figure 3.1 : Le principe des états périodiques “actif” et “endormi” [HEI 02]
Figure 3.2 : L’évitement du phénomène d’Overhearing [HEI 02].
Figure 3.3 : Le fonctionnement du protocole TimeOut-MAC [VAN 03]
Figure 3.4 : Le choix du paramètre TA dans le protocole Timeout-MAC [VAN 03]
Figure 3.5 : Le fonctionnement de base du protocole Wise-MAC [HOI 04]
Figure 3.6 : Organisation des slots de temps dans le protocole TRAMA [RAJ 03]
Figure 4.1 : La structure du modèle de simulation MACSimulator
Figure 4.2 : Modèle de communication point à point
Figure 4.3 : Modèle de communication Nœud vers Sink

Liste des abréviations
Liste des abréviations

ACK : Acknowlegment
BSS : Basic Service Set
CDMA : Code Division Multiple Access
CSMA/CA : Carrier Sense Multiple Access/Collision Avoidance
CTS : Clear To Send
FDMA : Frequency Division Multiple Access
NAV : Network Allocation Vector
RCSF : Réseau de capteurs sans fil
RTS : Request To Send
TDMA : Time Division Multiple Access
TRAMA : Traffic-adaptive medium access protocol
WLAN : Wireless Local Area Network
WMAN : Wireless Metropolitan Area Network
WPAN : Wireless Personal Area Network
WWAN : Wireless Wide Area Network

Bibliographie & webographie
Webographie
[1] http://www.commentcamarche.net, site de documentation informatique, Septembre 2005.

[2] http://www.francetelecom.com/rd, site de la division R&D de Francetelecom, Septembre 2005.
[3] http://www.epfl.ch, site de l’école polytechnique fédérale de Lausanne, Septembre 2005.
[4] http://www.technologyreview.com, Technology Review, Février 2003.
[5] http://www.nist.gouv.us, Septembre 2005.
[6] http://compilers.cs.ucla.edu/avrora, site d’informations sur le simulateur Avrora, Novembre 2005.
[7] http://www.omnetpp.org, site officiel du simulateur OMNET++
[8] http://www.lifl.fr/sensor/Main/Platforms, site du projet national CNRS intitulé RECAP,
Novembre 2005.
Bibliographie
[PUJ 05] Pujolle G., « Les réseaux Editions 2005 », éditions Eyrolles, 2005.
[ZHE 04] Zheng J., Myung L., « Will IEEE 802.15.4 make ubiquitous networking a reality ? »,
The city college of CUNY, IEEE Communications Magazine, juin 2004.
[AKY 02] Akyildiz I., Su W., Sankarsubramaniam Y., Cayirci E., «A Survey on Sensor Networks»,
Georgia Institute of Technology, IEEE Communications Magazine, Aout 2002.
[HOL 03] Holger K., Willig A., « A short survey of wireless sensor networks », Technical
university Berlin, Telecommunication Networks Group, Octobre 2003.
[CUL 04] Culler D., Estrin D., Srivastava M., « Overview of sensor networks », University of
California, Berkeley, IEEE Computer Society, Aout 2004.
[FLE 03] Fleury E., Chelius G., Mignon T., « minimisation de l'énergie dans les réseaux de
capteurs », Laboratoire CITI/INSA de Lyon, 2003.
[DEM 03] Demirkol I., Ersoy C., Alagöz F., « MAC Protocols for Wireless Sensor Networks: a
Survey », 2003
[LWA 04] Lwakabamba B., « Performance analysis experiments for the wireless sensor networks
integrated into the C6 virtual reality environment », Iowa State University, 2004.
[HEI 02] Heidemann J., Ye W., Estrin D., « An Energy-Efficient MAC Protocol for Wireless
Sensor Networks », IEEE Infocom, Juin 2002.
[VAN 03] Van Dam, Langendoen K., « An Adaptive EnergyEfficient MAC Protocol for
Wireless Sensor Networks », Faculty of Information Technology and Systems, Delft University
of Technology, Pays-Bas, 2003.
66
Bibliographie & webographie
[YE 03] Ye W., Heidmann J., « Medium Access Control in Wireless Sensor Networks”, USC/ISI
Technical Report ISI-TR-580, Octobre 2003.
[DEC 03] Decotignie J. D., El-Hoiydi A., Enz C., Le Roux E., « WiseMAC, an Ultra Low
Protocol for the WiseNET Wireless Sensor Network », ACM SenSys’03, Los Angeles, USA,
Novembre 2003.
[HOI 04] El-Hoiydi A., Decotignie J.D., « WiseMAC : An Ultra low power MAC Protocol for
the downlink of Infrastructure Wireless Sensor Networks », IEEE Symposium on Computers
and Communication, pages 244-251, Egypte, Juin 2004.
[HOE 04] Van Hoesel L.F.W., Havinga P.J.M., « A Lightweight Medium Access Protocol
(LMAC) for Wireless Sensor Networks: Reducing Preamble Transmissions and Transceiver State
Switches », INSS, Japan, Juin 2004.
[RAJ 03] Rajendran V., Obraczka K., Garcia J.J., « Energy-efficient, Collision-Free Medium
Access Control for Wireless Sensor Networks”, ACM Sensys’03, Los Angeles, Novembre 2003.
[DEL 05] Delye de Mazieux A., Gauthier V., Marot M., Becker M., « Etat de l’art sur les réseaux
de capteurs », Rapport de recherche INT N_05001RST, UMR5157 SAMOVAR, Institut
National des Télécommunications, Evry, France.
[DAM 03] Van Dam J. M., « An Adaptive Energy-Efficient MAC Protocol for Wireless Sensor
Networks », Master thesis, TU Delft, Juin 2003.
67
Annexes
Annexes
Le standard IEEE 802.15.4
IEEE 802.15.4 est un nouveau standard qui définit les spécifications de la couche physique et la
sous-couche MAC pour les réseaux personnels sans fil à faible débit (Low Rate Wireless Personal
Area Networks (LR-WPAN’s)) entre autre les réseaux de capteurs. L’objectif de ce standard est
d’assurer une faible consommation d’énergie pour les nœuds interconnectés (capteurs…), une
interconnexion sans fil à faible coût et un faible débit ne dépassant pas les 250 Kbits/s [ZHE 04].
Pourquoi un nouveau standard pour les réseaux sans fil ?
L’augmentation du débit dans les séries du standard IEEE 802.11 paraît très nette (initialement,
IEEE 802.11 offrait des débits allant de 1 à 2 Mbits/s et actuellement les standards IEEE
802.11a et IEEE 802.11g offrent jusqu’à 54 Mbits/s).
Bluetooth (IEEE 802.15.1) quant à lui, est le premier standard conçu pour les applications à
faible débit dans les réseaux personnels sans fil (WPAN). Malgré le succès de cette technologie
sur le marché, il s’est avéré qu’elle a des inconvénients :
- manque de flexibilité dans ses topologies.
- complexité (les efforts de bluetooth à couvrir le maximum d’applications possibles et offrir
une meilleure QoS ont diminué sa simplicité) qui l’a rendu cher et inapproprié pour
certaines simples applications à faible consommation d’énergie..
- problème de scalabilité dans les topologies pair à pair de Bluetooth (scatternet).
Les inconvénients de Bluetooth cités précédemment, l’apparition de périphériques de haute

qualité à faible coût et l’émergence de nouvelles applications ont mené au développement de
deux nouvelles générations de réseaux WPAN qui sont :
- les réseaux WPAN à haut débit IEEE 802.15.3a connu sous le nom de Ultra WideBand
(UWB) ou HR-WPAN’s.
- les réseaux WPAN à faible débit IEEE 802.15.4 [ZHE 04].
68
Annexes
Spécificités de IEEE 802.15.4
Il se distingue des autres standards de réseaux sans fil par plusieurs spécificités telles que son
faible débit, sa faible consommation d’énergie, son faible coût, sa capacité de s’auto-organiser, sa
flexibilité, sa faible portée de transmission…
Domaines d’applications
Les spécificités de la norme IEEE 802.15.4 lui ont permis de supporter des applications qui sont
inappropriés pour d’autres standards.
Avec la possibilité de connecter de simples périphériques variés au réseau, IEEE 802.15.4
a permis à l’utilisateur plus que jamais une interconnexion ubiquitaire.
Parmi les applications utilisés grâce à ce standard, on peut citer :
- Monitoring (suivi) : santé, environnement, surveillance…
- Automatisation et contrôle : entreprise, maison…
- Divertissement : jeux éducatifs, jouets intéractifs… [ZHE 04]
Vue d’ensemble du standard IEEE 802.15.4
- Les topologies supportées :

On trouve deux types de topologies réseau supportés par ce standard:
- la topologie en étoile à un saut ou « one hop-star » utilisée lorsque la portée des
communications ne dépasse pas les 10m.
- la topologie pair à pair à multi-sauts ou « multihop peer-to-peer » utilisée lorsque la portée
des communications dépasse les 10m. [ZHE 04]
- L’adressage :
Un noeud dans un réseau LR-WPAN peut utiliser deux types d’adresses :
- Une adresse IEEE à 64bits.
- Une adresse à 16bits.
Un réseau 802.15.4 peut supporter jusqu’à 216 périphériques interconnectés [ZHE 04].
69
Annexes
- Bandes de fréquences et Débit :

Les liaisons sans fil dans un réseau IEEE 802.15.4 opèrent dans trois bandes de fréquences ISM
(à licences libres) :
- 2.4GHz partagée en 16 canaux et offrant un débit de 250Kbits/s.

- 915MHz (Amérique du nord) partagée en 10 canaux et offrant un débit de 40Kbits/s.
- 868MHz (europe) à un seul canal et offrant un débit de 200Kbits/s (20Ksym/s).
=> IEEE 802.15.4 opère sur 27 canaux qui lui sont alloués [ZHE 04].
- Flexibilité et économie d’énergie :

Les différents débits possibles dans ce standard offrent aux applications un meilleur choix en
terme de coût et d’économie d’énergie.
Exemple : 250Kbits/s est un débit nécessaire lorsque les nœuds interconnectés sont des
périphériques informatiques. Cependant, pour le cas d’une application de réseau de capteurs (ou
de smart tags, cosumer electronics), un débit de 20Kbits/s satisfait amplement les besoins de
l’application [ZHE 04].
Notion de « Supertrame »
Le standard IEEE 802.15.4 utilise la méthode Slotted CSMA-CA qui elle même utilise des
“supertrames”; Celle ci sont définies par le coordinateur, et ont pour principal avantage de
permettre la synchronisation de l’ensemble des éléments entre eux, et ainsi d’économiser l’énergie
de chacun des noeuds du réseau. Les supertrames sont tout d’abord divisées en deux parties :
Une partie active et une partie inactive; durant la partie inactive le coordinateur n’interagit pas
avec le réseau et se place en mode veille. Chaque supertrame commence par un beacon qui est
envoyé par le coordinateur du réseau, et qui permet la synchronisation entre les noeuds et le
coordinateur.
Le « beacon » est immédiatement suivi par une zone appelée “Contention Access Period” (CAP),
qui permet à chaque élément du réseau d’envoyer ou de recevoir des trames de commandes et de
données.
L’accès au canal durant la période CAP suit le mécanisme CSMA-CA : l’émetteur écoute le canal
pendant une durée aléatoirement tirée (algorithme de backoff) puis émet si le canal est libre.
Une autre zone optionnelle disponible dans la supertrame (CFP) est utilisée pour les
transmissions nécessitant de la qualité de service. Le CFP est divisé en slots, dont le coordinateur
70
Annexes
gère l’allocation en fonction des besoins. Une station qui se voit attribuer un slot est assurée
qu’aucune autre station ne transmettra durant cette période.
L’allocation d’un slot fait suite à une négociation entre un noeud et le coordinateur. Si la
négociation aboutit, le coordinateur informe le noeud en plaçant une information (stream index)
dans le prochain beacon (l’algorithme d’allocation n’est pas défini dans le standard).
Le mode de communication utilisant les supertrames garantit un très faible taux utilisation des
ressources (souvent inférieur à 10%), car les noeuds formant le réseau ont un temps de veille
garanti très long (les noeuds ne sont actifs que durant la période CAP).
En conclusion ce mode de communication est l’un des plus économiques qui soit au niveau de la
sauvegarde de l’énergie de chacun des éléments du réseau [DEL 05].
Figure A : Structure d’une « supertrame » [DEL 05]
71
Annexes
Les modifications apportées aux fichiers du modèle de simulation
Pour que le simulateur OMNET++ puisse prendre en charge la solution qu’on a proposé,
certains fichiers sources auxquels l’implémentation de Sensor-MAC fait appel, doivent être
modifiés :
-----------------------------------------------------------------------------------------------------------------
Le fichier Sensor-MAC.h :
class Sensor-MAC : public BasicMac {

Module_class_Members (Sensor-MAC, BasicMac, 0) ;
protected :
double passive_preamble_time ; //variable qui va recevoir la valeur du préambule

// à l’état d’écoute passive.
double total_preamble_time ; //variable qui va recevoir la valeur du préambule
//total selon l’état du nœud capteur.
void startContending (int time) //commencer la contention du canal pendant « time »

…
------------------------------------------------------------------------------------------------------------------------
Le fichier Sensor-MAC.cc :
------------------------------------------------------------------------------------------------------------------------
#define SYNC_CONTEND_TIME 5
#define RTS_CONTEND_TIME 5
#define CTS_CONTEND_TIME 5
#define DATA_CONTEND_TIME 5
#define TIMEOUT_WFACK 5
#define TIMEOUT_WFDATA 5
#define TIMEOUT_WFCTS 5
...
Define_Module_Like (Sensor-MAC, Mac ) ;
void Sensor-MAC : : init ( )

{
72
Annexes
...
passive_preamble_time = par(“mac1”) / 2 ; // la variable « passive_preamble_time » est
//initialisée à une valeur égale au (1/2) de la longueur de la période d’écoute de Sensor-MAC
total_preamble_time = 3 * passive_preamble_time ; // la variable « total_preamble_time » est

//initialisée au triple de la valeur de la longueur de la période d’écoute passive dans Sensor-
//MACp
total_frame_time = par (“mac2”) ;
sleep_time = total_frame_time – passive_preamble_time ;

…
}
void SMac : : txFrame ( )

{…
assert (nav_state == NAV_STATE_CLEAR)
if (rssi ( ) > 0.5)

{…
setinternalTimeout (passive_preamble_time)
setIdle ( ) ;
return ;
}
else {
switch (proto_state) {
case PROTO_STATE_CONTEND :
switch (next_state) {
case PROTO_STATE_SEND_SYNC :
startContending (SYNC_CONTEND_TIME) ;
setinternalTimeout (passive_preamble_time) ;
sendSync ( ) ;
break ;
case PROTO_STATE_SEND_RTS :
startContending (RTS_CONTEND_TIME)
setinternalTimeout (total_preamble_time) ;
sendRts ( ) ;
proto_state = PROTO_STATE_WFCTS ;
setProtocolTimeout (TIMEOUT_WFCTS) ;
break ;
case PROTO_STATE_SEND_DATA :
startContending (DATA_CONTEND_TIME) ;
sendData ( ) ;
break ;
73
Annexes
case PROTO_STATE_SEND_CTS :
sendCts ( ) ;
proto_state = PROTO_STATE_WFDATA ;
setProtocolTimeout (TIMEOUT_WFDATA) ;
break ;
}
break ;
case PROTO_STATE_SEND_DATA :
sendData ( ) ;
proto_state = PROTO_STATE_WFACK ;
setProtocolTimeout (TIMEOUT_WFACK) ;
break ;
case PROTO_STATE_SEND_ACK :
sendAck ( ) ;
} break ;
} return ;
}
...
void SMac : : rxFrame (Packet * msg)

{ ...
if (sched_state == SCHED_STATE_SLEEP)
return ;
else
if (rssi < 0.5) {
setinternalTimeout (passive_preamble_time) }
else
switch (PKT_KIND (msg)) {
case KIND_SYNC :
setinternalTimeout (passive_preamble_time) ;
receiveSync (msg) ;
break ;
case KIND_RTS :
receiveRts (msg) ;
break ;
case KIND_CTS :
receiveCts (msg) ;
break ;
case KIND_DATA :
if (msg -> local_to != -1) {
receiveData (msg) }
else
74
Annexes
receiveData (msg) ;
break ;
case KIND_ACK :
receiveAck (msg) ;
break ;
…
}
75

Raport Final PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Raport Final PDF

Uploaded by

Copyright:

Available Formats

Sommaire

Projet de fin d’études 2005/2006 1

Chapitre 4 : Solution proposée et situation par rapport à l’existant............................................................ 45

Projet de fin d’études 2005/2006 2

Projet de fin d’études 2005/2006 3

Projet de fin d’études 2005/2006 4

I. Problématique et contribution du projet de fin

Projet de fin d’études 2005/2006 5

II. Organisation du document

Projet de fin d’études 2005/2006 6

Chapitre 2 : Les réseaux de capteurs sans fil : Une

I- Première partie : Les catégories des réseaux sans

Figure 2.1 : Les catégories des réseaux sans fil [1]

Projet de fin d’études 2005/2006 7

I-1. Le réseau personnel sans fil (WPAN)

I-2. Le réseau local sans fil (WLAN)

Projet de fin d’études 2005/2006 8

I-3. Le réseau métropolitain sans fil (WMAN)

I-4. Le réseau étendu sans fil (WWAN)

II- Deuxième partie : Les réseaux de capteurs sans fil

Projet de fin d’études 2005/2006 9

II-2. Les principales caractéristiques des RCSF

Projet de fin d’études 2005/2006 10

- La capacité de communication : Elle peut prendre deux aspects : Le multisaut ou à un seul

Projet de fin d’études 2005/2006 11

- Une architecture « data-centric » : Du fait que le remplacement ou la recharge des batteries

Projet de fin d’études 2005/2006 12

RCSF Réseau WLAN Réseau Réseau WPAN

II-4. Les domaines d’application

Projet de fin d’études 2005/2006 13

II-5. L’architecture d’un nœud capteur

Projet de fin d’études 2005/2006 14

Figure 2.3 : L’architecture matérielle d’un nœud capteur [AKY 02]

II-5-2. Architecture logicielle

II-6. La pile protocolaire des RCSF

Projet de fin d’études 2005/2006 15

Figure 2.4 : La pile protocolaire des RCSF [AKY 02]

II-6-1. La couche physique

II-6-2. La couche liaison de données

Projet de fin d’études 2005/2006 16

II-6-3. La couche réseau

II-6-4. La couche transport

Projet de fin d’études 2005/2006 17

II-6-5. La couche application

II-6-6. Le plan de gestion d’énergie

II-6-7. Le plan de gestion de la mobilité

II-6-8. Le plan de gestion des tâches

Projet de fin d’études 2005/2006 18

Projet de fin d’études 2005/2006 19

L’accès au support dans les réseaux sans fil

I- Première partie : Les techniques de contrôle

I-1. L’accès multiple par répartition temporelle (TDMA)

Projet de fin d’études 2005/2006 20

L’analyse énergétique de la technique TDMA :

I-2. L’accès multiple par répartition fréquentielle (FDMA)

L’analyse énergétique de la technique FDMA :

La technique FDMA élimine en fait le temps d’attente (dû à la réinitialisation de l’horloge de

Projet de fin d’études 2005/2006 21

I-3. L’accès multiple par répartition de codes (CDMA)

L’Analyse énergétique de la technique CDMA :

I-4. L’accès multiple avec écoute de la porteuse/Evitement de

L’analyse énergitiqe de la technique CSMA/CA :

Projet de fin d’études 2005/2006 22