Introduction générale cadre du projet Chapitre : Introduction 7

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

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

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

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

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.

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

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

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’à 2¹⁶ périphériques interconnectés [ZHE 04].


- 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

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]

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

{

...

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

setinternalTimeout (total_preamble_time) ;

sendData ( ) ;

break ;

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 :

setinternalTimeout (total_preamble_time) ;

receiveRts (msg) ;

break ;

case KIND_CTS :

receiveCts (msg) ;

break ;

case KIND_DATA :

if (msg -> local_to != -1) {

receiveData (msg) }

else

setinternalTimeout (total_preamble_time) ;

receiveData (msg) ;

break ;

case KIND_ACK :

receiveAck (msg) ;

break ;

…

}

Projet de fin d’études 2005/2006