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


// consommée par les cents nœuds



Yüklə 351,68 Kb.
səhifə67/81
tarix09.01.2022
ölçüsü351,68 Kb.
#93754
1   ...   63   64   65   66   67   68   69   70   ...   81
// 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 » 






II-6.3.2. Cas du modèle de communication « nœud vers Sink » 





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.


Yüklə 351,68 Kb.

Dostları ilə paylaş:
1   ...   63   64   65   66   67   68   69   70   ...   81




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2024
rəhbərliyinə müraciət

gir | qeydiyyatdan keç
    Ana səhifə


yükləyin