Introduction générale cadre du projet Chapitre : Introduction 7
II- Deuxième partie : Etude comparative de Sensor-MACp, Sensor-MAC et Timeout-MAC
Yüklə 351,87 Kb.
|
- Bu səhifədəki naviqasiya:
- II-2. Description du modèle de simulation MACSimulator
- II-3. Paramétrage du réseau utilisé
- II-4. Paramétrage des protocoles Sensor-MAC, Sensor-MACp et Timeout-MAC
- II-5. Paramétrage des scénarios
- II-6. La simulation des protocoles Sensor-MAC, Sensor-MACp et Timeout-MAC
- II-6.1. Les modèles de communication
- II-6.1.2. Le modèle de communication « Nœud vers Sink »
- II-6.2. Exécution des scénarios
- II-6.3. Les résultats des simulations
- 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.2. Cas du modèle de communication « nœud vers Sink »
II- Deuxième partie : Etude comparative de Sensor-MACp, Sensor-MAC et Timeout-MACII-1. Les simulateurs utilisés dans les RCSFIl 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 (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 MACSimulatorLe 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:
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 » :
…
II-4. Paramétrage des protocoles Sensor-MAC, Sensor-MACp et Timeout-MACII-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énariosDans 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 à :
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 ----------------------------------------------------------------------------------------------------------------- …
…
…
II-6. La simulation des protocoles Sensor-MAC, Sensor-MACp et Timeout-MACPour 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.
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é.
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.
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énariosPour 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)
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 ».
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.
Les trois premiers paramètres seront utilisés par le script « parseenergy.pl » pour générer un fichier nommé « 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 simulationsSuite à 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ésultatsII-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,87 Kb. Dostları ilə paylaş:
|
