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

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

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