Simulation du protocole de routage binary waypoint sur WSNet · • Les réseaux locaux sans fils...

Simulation du protocole de routage binary waypoint sur WSNet

Travaux d’études et de recherche

Par Selma BELHADJ AMOR

Le 18 Mai 2010

Tuteur : M. Franck Rousseau

1 Selma BELHADJ AMOR – rapport TER

Table des matières :

Chapitre I : PRESENTATION GENERALE1. Introduction 2. Présentation du laboratoire et de l'équipe 3. Sujet

Chapitre II : CONTEXTE SCIENTIFIQUE ET PROBLEMATIQUE

1. La simulation et la recherche dans le domaine des réseaux

Chapitre III : LE SIMULATEUR WSnet1. Présentation2. Génération des topologies3. Configuration4. Programmation des modules

Chapitre IV : MESURE DE PERFORMANCES, DIMENSIONNEMENT ET SIMULATION DU CAS IDÉAL

1. Scénario2. Choix des paramètres de configuration3. Simulation et interprétation des résultats4. Comparaison avec les résultats de ballistic

Chapitre V : MESURE DE PERFORMANCES, DIMENSIONNEMENT ET

SIMULATION DU CAS REEL 1. Scénario2. Choix des paramètres de configuration3. Simulation et interprétation des résultats

Chapitre VI : PROTOCOLE BWP ROUTING1. Résultats validés dans le cas idéal2. Améliorations attendues

Chapitre VII : CONCLUSION1. Bilan 2. Références


CHAPITRE I PRESENTATION GENERALE

I) Introduction :Le module de travaux d’études et de recherche consiste à réaliser un petit travail de recherche en

laboratoire . L’objectif majeur est d'initier l’étudiant à la recherche scientifique et de voir la particularité du métier de chercheur qui a comme vocation principale l'innovation dans la conception et la création de connaissance, de techniques et de procédures. D'autre part, il donne lieu à la rédaction d'un rapport de recherche.

Ce document est la synthèse de l’étude faite durant les trois mois de stage effectué au laboratoire LIG équipe DRAKKAR, sous la tutelle de M. Franck Rousseau. Ce stage portait sur les simulations de protocoles pour la validation croisée des propositions à grande échelle, de différents simulateurs et modèles de réseaux.

L'objectif principal de cette étude était de pouvoir simuler un protocole Binary Waypoint Routing [1], qui a été développé par l'équipe, précédemment évalué sur un simulateur maison permettant de simuler des très grands réseaux, en se limitant à la couche réseau, sur des modèles plus réalistes et à grande échelle.

II)Présentation du laboratoire et de l'équipe :L’équipe Drakkar mène ses activités de recherche sur les différents aspects des protocoles réseaux

et de multimédia avec un thème central lié aux réseaux mobiles sans fil. Les objectifs de la recherche proviennent de l'observation que les communications sans fils ne correspondent pas très bien à l'état actuel d'Internet : le schéma d'adressage,la hiérarchie du routage figé qu'offrent les réseaux filaires, ne permettent pas une utilisation efficace des mobiles, et aussi l'infrastructure du réseau coeur ne satisfait pas le dynamisme et la spontanéité de l'opération. L'orientation principale de l'équipe est de fournir des solutions à ces problèmes. Les principaux axes de recherche sont :

• Les réseaux locaux sans fils (802.11, Bluetooth, protocoles MAC avancés)

• Les réseaux maillés (protocoles MAC avancés, protocoles de routage, interactions intercouches)

• Mobilité homogène(locationidentity separation, location service).

• Sensor and actuator networks (protocoles à conservation d'énergie, 802.15.4ZigBee, Internet of Things),

Cette équipe regroupe 9 chercheurs permanents, 11 doctorants et d'autres collaborateurs. Elle fait partie du laboratoire LIG : laboratoire informatique de grenoble.

Ce projet est encadré par M. Franck Rousseau qui est maître de conférences à GrenobleINP(ENSIMAG).

III) Sujet :

L'objectif du projet est d'implanter le protocole BWR dans le simulateur WSNet pour évaluer ses performances en présence de couches MAC et PHY non idéales, et comparer les résultats, qualitativement mais aussi en terme de taille de réseaux simulables et de performances, à ceux obtenus avec le simulateur maison. WSNet fournit déjà le support pour le routage géographique


http://www.liglab.fr/

glouton classique, qui servira de point de départ.

Les objectifs de ce stage sont :

• Comparaison des performances entre notre simulateur et WSNet avec un réseau idéal.

• Comparaison du comportement de l'algorithme de routage entre un environnement idéal et un plus réaliste.

• Un module BWR pour WSNet, qui sera validé face à notre simulateur.

• Validation croisée des simulateurs, en glouton et en BWR sur les mêmes réseaux.

Dans ce rapport, la première section présente l'importance de la simulation dans la recherche dans le domaine des réseaux, la seconde section s'intéresse au simulateur Wsnet, les sections suivantes illustrent les mesures de performances que j'ai effectuées durant ce stage...

VI) Remerciements :Je tiens à remercier l’équipe DRAKKAR pour son accueil, et en particulier mon encadreur

Franck Rousseau pour l’aide précieuse qu’il m'a apportée et pour le temps qu’il a consacré pour m’aider à mener à bien mon stage au laboratoire.

Je remercie aussi MohamedNazim Abdeddaïm et Bogdan Pavkovitch de l'équipe DRAKKAR pour m'avoir aidée, et Elyes Ben Hamida et Guillaume Chelius de CEALETI pour avoir répondu à mes questions.


Wsnet Realiste

MAC/PHY

Ballistic Ideal

40000 noeuds

Wsnet Ideal

40000 noeuds

CHAPITRE IIContexte scientifique et problématique :

1. La simulation comme méthode de validation dans le domaine des réseaux

L'évolution des systèmes de télécommunications actuels, vers l'intégration de plusieurs de services, l'amélioration de la qualité de service, et le déploiement à grande échelle, a rendu leur étude et leur modélisation très complexes. D'autres part, ces systèmes se doivent d'être de plus en plus performants pour satisfaire à la fois les avancées technologiques et les demandes grandissantes des opérateurs. Or la complexification des réseaux a un impact inévitable sur les performances. De plus, faire des études analytiques ou expérimentales à des échelles aussi grande est très difficile, voire impossible à réaliser en pratique à cause du coût élevé et de la difficulté de la mise en œuvre. C'est pourquoi les simulations sont considérées dans ce cas comme la méthodologie la plus adéquate pour évaluer les performances et étudier le comportement des infrastructures à grande échelle.

Dans le domaine des réseaux sans fils, la simulation comme méthode de validation possède des atouts incontournables. Elle nous offre la possibilité d'isoler ce qu'on veut et de bien maîtriser les variables de l'environnement. Mais lorsque l'on vise des modèles de plus en plus réaliste et de plus en plus grand, garantir la cohérence des résultats n'est plus très évident pour les simulateurs. En effet, la complexité des phénomènes physiques qui constituent le canal radio impose de faire un compromis entre la « justesse » du modèle et le coût de la simulation [4][5]. Ceci est problématique dans la mesure où dans les simulateurs déployés actuellement NS2, GloMoSim, JiST/SWANS, GTSNetS, etc. qui offrent tous des environnements de simulation très développés, mais des choix d'implémentation très différents pour la couche physique. Ceci engendre une énorme variabilité des résultats des simulations du même modèle suivant le simulateur utilisé. Et par conséquent, cela constitue une entrave à la validation des résultats. Le simulateur WSNet est un framework très flexible [5] et modulaire pour la simulation de la couche PHY qui offre une large gamme de choix pour la modélisation de la couche physique qui vont des modèles idéalistes permettant d'étudier le dimensionnement des réseaux, au modèles pseudoréalistes pour l'étude des performances comme on peut le lire dans « Scalable versus Accurate Physical Layer Modeling in Wireless Network Simulations » et « On the Complexity of an Accurate and Precise Performance Evaluation of Wireless Networks Using Simulations » [4][5].

2. Algorithmes de routage : Binary Way PointC'est un nouvel algorithme de routage géographique conçu dans l'équipe [1] dont l'idée est de

retenir et maintenir des routes amenant à un petit ensemble de noeuds appelés binary waypoints, sont placés dans des sousespaces résultants d'une partition binaire de l'espace de départ. Cet algorithme de routage a été évalué sur un simulateur maison, permettant de simuler des très grands réseaux mais qui se limite à la couche réseau. Ce protocole offre potentiellement une bonne garantie de délivrance des messages envoyés, de l'ordre de celle garantie par l'utilisation du chemin le plus court mais sans avoir besoin d'une vision globale du réseau. Il permet aussi de contourner les faiblesses routage géographique classique, qui exige des graphes « planaires » pour bien fonctionner etc.


Chapitre III : LE SIMULATEUR Wsnet

1. PrésentationWSNet est un simulateur de réseaux de capteurs à événements discrets développé, à l'origine, au

laboratoire CITI. Il reste assez similaire aux autres simulateurs à événements discrets comme NS2, GloMoSim, JiST/SWANS, GTNetS ou Omnet++ dans ses objectifs. Cependant, il se différencie des autres dans sa capacité à modéliser très précisément le medium radio sans toutefois empêcher la simulation de réseaux de plusieurs centaines de noeuds.

WSNet fonctionne sous Linux et il a l'avantage d'être gratuit (sous licence CeCILL).

L'architecture de WSNet [fig1][fig2] est modulaire, ce qui lui permet de recevoir des extensions développées par les utilisateurs :

• Simulator core : L'ordonnancement des événements (file d'événements, management de la mobilité , ordonnancement des paquets (file de paquets) , etc.

• Librairies dynamiques : qui implémentent les noeuds , les « mediums », l'environnement et les modèles.

Pour une simulation donnée, on doit préciser le choix des modèles et des structures à utiliser. Ceci est fait à l'aides des fichiers de configuration XML.


Fichier de configuration

XMLWSNET

Modules programmés en C chargés dynamiquement

Res= f (config,modèle)

Fig1 : Principe de fonctionnement de WSnet

http://www.cecill.info/

Les nœuds, l'environnement et le canal radio sont représentés par des blocs indépendants dans des bibliothèques dynamiques. Par conséquent, l'ajout de nouveaux modèles ne nécessitent pas de modifier la « base de WSNet » et peut donc être réalisé facilement. Ces caractéristiques confèrent au simulateur une très grande extensibilité.

Wsnet offre une palette d'outils composée de :• wsnettopogen: un générateur de topologies • wsnetreplay: un outil utile permettant de visualiser graphiquement les résultats d'une

simulation• map2png: un script Matlab générant une carte sous le format image PNG (par exemple, la

carte d’énergie) • maps2video: un script Matlab générant une vidéo en format "avi" d'une séquence de cartes

(par exemple, la carte d’énergie de la séquence) • «avi»: un script shell qui exécute une série de simulations d'un même scénario ou plusieurs

scénarios. Pour plus d'information concernant l'installation et la prise en main de Wsnet, référez vous à la

page web de l'Inria [3] consacrée au projet.


Fig2 : Architecture de Wsnet [6]

2. Génération des topologies

Pour générer une topologie avec wsnet il faut utiliser la commande wsnettopogen.Cette commande supporte plusieurs options et s'utilise comme suit, à titre d'exemple, pour une

topologie carré de coté 500, de distribution uniforme de paramètre 0.01 avec topologie.data comme fichier de sortie et avec représentation graphique :

wsnettopogen topo square 500 20 distribution uniform 0.01 o topology.data gpDurant le projet, M. Franck Rousseau a développé une extension à topogen qui améliore

l'affichage des noeuds et la mise en échelle, calcule le nombre moyen et la liste des noeuds voisins étant donné un rayon, ce qui améliore énormément les performances de la modélisation des liens entre les noeuds.

La commande à utiliser devient : java jar dev_wsnet/Topogen/dist/Topogen.jarVoici un exemple de fichier de sortie :

Non seulement, cet outil nous permet de choisir les dimensions et le type de la distribution probabiliste des noeuds, mais aussi de rajouter des imperfections dans les topologies. Ce qui peut être d'une très grande importance pour détecter les faiblesses des algorithmes de routage en rapprochant les conditions de simulation de plus en plus de la réalité (Nonhomogénéité des topologies, discontinuités, trous …)


TOPOGENType,Taille

Portée, Distribution

Effets

Topo.data : 0 148.427 54.330 01 368.821 237.280 02 202.109 363.953 03 319.671 86.659

Fig3 : Fonctionnement de topogen

# format: WSNET2# options: t square,50,30 d static,4 f wsnet2 o g1.data p z 2 g g1 # width: 50# height: 50# topo_radius: 30.0# nbNodes 40 19.27245288218672 0.6159813446108553 01 19.325604902205967 40.16319432988377 02 3.8059813166354095 35.036283170185136 03 22.566607355054654 18.266264030852298 0

Fig4 : Exemple de fichier généré par Topogen et graphe correspondant

J'ai aussi rajouté un module effect_hole.c qui permet de rajouter d'autres types d'irrégularités, comme les trous rectangulaire. Ce module prend en paramètre un fichier *.data, une option « r » et les dimensions b et c.

3. Configuration

Le simulateur WSNet utilise un fichier XML pour configurer une simulation. Ce fichier décrit les paramètres de la simulation, par exemple le nombre de noeuds à simuler, les librairies utilisées pour modéliser les noeuds et le canal radio et l'application désirée.

Il faut définir les paramètres globaux :<simulation nodes="number-of-nodes" duration="simulation-duration" x="size"

y="size" z="size" />

On peut définir des entités qui sont des instanciation des librairies dynamiques. <entity name="entity-name" library="dynamic-library-name" > <init parameter-name="value" parameter-name="value" ... />

<default parameter-name="value" parameter-name="value" ... /> </entity >


Fig 4.c : Exemple de topologie avec un trou rectangulaire

Fig 4: Exemples de topologies générées par topogena. topologie uniforme régulièreb. topologie uniforme avec une irrégularité

Il faut également définir l'environnement avec les entités de propagation, d'interférences et de modulation définies précédemment.

Une fois toutes les entités et l'environnement définis, il reste définir l'architecture du nœud dans le bundle.

<bundle name="bundlename" default="{true,false}" birth="time" /> <mobility entity="entity-name"/><with entity="entity-name" > <up entity="entity-name" />

<...> <down entity="entity-name" />

</bundle>

La difficulté majeure consiste dans le choix des modèles et des paramètres, pour la cohérence et la validité de la simulation. Puisqu'il y a beaucoup de paramètres qui sont passés par défaut au simulateur, il faut vérifier sur les modèles les valeurs exigées et les préciser si elles diffèrent des valeurs par défaut.

4. Programmation des modulesUn module de wsnet est un fichier *.c qui doit contenir les fonctions suivantes :

int init(call_t *c, void *params) : Cette fonction initialise l'entité application et parse le fichier xml de configuration pour récupérer les paramètres globaux de la simulation.

int destroy(call_t *c) : Cette fonction est appelée à la fin de la simulation pour détruire l'entité application.

int setnode(call_t *c, void *params) : Cette fonction est utilisée pour relier l'entité application à un nœud. Elle parse le fichier xml, pour récupérer les paramètres spécifiques au nœud qu'elle stocke dans une structure _node_data spécifiée au début du fichier et résumant les caractéristiques du nœud qu'on désire pour notre application.

int unsetnode(call_t *c) : Cette fonction est appelée à la mort du nœud pour dissocier l'application du noeuds.

int bootstrap(call_t *c) : C'est la fonction appelée automatiquement à la naissance d'un nœud

void rx(call_t *c, packet_t *packet) : C' est une fonction utilisée lorsque l'application reçoit un paquet de données

application_methods_t methods = {rx} : C'est une structure de données qui décrit les fonctions exportées pour les couches plus basses.

L'implémentation et l'installation sont détaillées dans le tutoriel du simulateur [3].


Chapitre IV : MESURE DE PERFORMANCES, DIMENSIONNEMENT ET SIMULATION DU CAS IDÉAL

1. Scénario :Pour les simulations on veut un scénario simple :

Le module correspondant est greedy_pdr.c. Les structures utilisées sont :

Pour les fonctions requises par Wsnet :➢ INIT : Dans notre cas, les paramètres significatifs que nous avons définis sont :

"nb_packets" et "startup_delay" qu'on doit spécifier dans le fichier de configuration xml. On récupère également le nombre total des noeuds qui sera mis dans une variable globale.

➢ DESTROY : Puisque cette fonction est appelée à la fin de la simulation, nous y intègrons les statistiques résultantes de la simulation à savoir nombre de paquets envoyés tx, le nombre

de paquets reçus rx et le packet delivery ratio PDR défini par :PDR=rx/tx➢ SETNODE : Nous avons besoin de la position uniquement.➢ UNSETNODE : Dans notre cas, il suffit de récupérer les données que renferme la structure

passée en paramètre, et désallouer le nœud.➢ BOOTSTRAP : Cette fonction récupère dans un tableau les paramètres de l'entité au

dessous, construit une nouvelle structure où elle précise le Noeud, la source et la destination, récupère la taille de celleci pour permettre le bon étiquetage. Au bootstrap du dernier nœud, le scheduler (…..) est appelé avec délai suffisemment long nécessaire à l'établissement du routage.

➢ RX : A la réception d'un paquet, la couche application récupère l'entête du paquet pour vérifier qu'il lui est bien destiné. Cette vérification est nécessaire parce que le routage greedy


rcv < 0itérer nb fois { choisir une source au hasard dans la topologie choisir une destination au hasard dans la topologie router un paquet de la source à la destination si le paquet est arrivé sur la destination alors incrémenter le nombre de paquets reçus rcv.}pdr = rcv / nb;

struct _app_header {

nodeid_t src;

nodeid_t dst;

};

struct _node_data {

int size;

position_t pos;

int overhead;

};

remonte les paquets rejetés à la couche application. Si la destination correspond au numéro du noeud le paquet est bon, on le désalloue et on incrémente rx. Et on reschedule un nouveau paquets si le nombre de paquets n'a pas été dépassé.

Fonctions rajoutées pour les spécificités du cas: • schedule_next_sender

Cette fonction tire un noeud au hasard, puis met en place le scheduler [fig 5] qui appelle send_packet_to_rand_dst.

• send_packet_to_rand_dst : A chaque appel par le scheduler, cette fonction crée un paquet, remplit son entête avec les bonnes adresses et l'envoie.

2. Choix des paramètres de configuration

Pour isoler le niveau du routage, il faut prendre des couches MAC et PHY « vides ». Wsnet offre les modèles suivant :• mac_idealmac :

Ce modèle représente une couche MAC idéale, transparente. Pour cette représentation, tant que les noeuds peuvent être atteints (connexité du graphe), les paquets sont correctement acheminés. Il faut préciser le « range » ou la portée des antennes. C'est une caractéristique de la topologie.

 <entity name="mac" library="mac_idealmac" >

<init range="70"/> </entity>

• propagation_range, interferences_none, modulation_none : Pour la couche physique, c'est inutile parce que la couche MAC est idéale. Mais, on doit tout de même définir une couche physique pour satisfaire à la norme de WSnet.

 

<entity name="prop" library="propagation_range" ></entity> <entity name="itf" library="interferences_none"></entity> <entity name="mod" library="modulation_none"></entity>

• greedy_ideal : Pour la couche application, c'est la librairie correspondante au module précédemment programmé. On doit préciser le nombre de paquets, et le délai nécessaire à l'établissement du routage.

 <entity name="greedy_ideal" library="application_greedy_pdr" >

<init nb_packets="100000" startup_delay="1500000000"/> </entity>

• mobility_filestatic : Cette librairie peut porter les positions des noeuds met d'importer les positions des noeuds à partir d'un fichier *.data. Il faut faire attention à bien ajuster les dimensions de la zone de simulation et le nombre de noeuds à ceux de la topologie.

<entity name="file" library="mobility_filestatic" >

<init file="s11.data"/> </entity>

3. Simulation et interprétation des résultats :J'ai voulu faire des graphes mais les simulations que j'ai faites jusqu'à maintenant n'illustraient pas

très clairement les variations à étudier, et il faudrait les refaire en choisissant les paramètres de telles façon à avoir de meilleurs graphes mais les simulations prennent beaucoup de temps. J'ai préféré avoir des relevés cohérents qui illustrent assez clairement les premiers résultats

A) temps de simulation :Plus le nombre de noeuds augmente, plus la simulation nécessite du temps. En effet, pour des

graphes avec quelques centaines de noeuds, le temps de simulation est très court. Par exemple : à titre comparatif, en prenant des graphes uniformes ayant pratiquement le même

nombre moyen de voisins mais des tailles et un nombre de noeuds différents.

NOMBRE DE NOEUDS

TEMPS DE SIMULATION

TEMPS SIMULE SPEEDUP

326 372023000 1783269740 4.600322

1299 3280205000 1906759052 0.581293

2770 2106264500 14452903000 0.145733

5102 47298956000 2297557012 0.048575

7834 103362459000 1503280800 0.014544

D'après ce tableau, on voit bien que le temps effectif de simulation augmente au fur et à mesure que le nombre de noeuds augmente (c'est le temps système). En ce qui concerne le temps logique simulé, il augmente mais pas avec les mêmes proportions que le temps de simulation.

Le speedup de la simulation défini comme étant le rapport entre le temps logique simulé et le temps de la simulation. C'est bien clair que le speedup diminue très vite. Pour des graphes plus grands, il est quasi nul. Ceci explique bien l'intérêt de la simulation par rapport à une étude expérimentale se basant sur le temps physique.

Ceci dit, pour des graphes à grande échelle, (70000 noeuds par exemple) le temps devient très pénalisant même si les conditions sont idéales ( 8517460308000 ) .

B) PDR : Il s'agit d'un modèle idéal, théoriquement le PDR ne doit dépendre que de la connexité du réseau.

Ceci est vérifié puisque dès que le nombre de voisins traduisant le degré de connectivité dans le réseau est suffisamment grand, le pdr atteint rapidement 1 pour les petites topologies.

Plus le graphe est grand, plus le degré de connectivité doit être élevé. Avec Wsnet, j'ai réussi à simuler 100000 noeuds dans le cas idéal et le pdr était relativement

acceptable à condition d'avoir des connectivités élevées.

NOMBRE MOYENS DE VOISINS

NOMBRE DE NOEUDS PDR

3 335 0.04

11 307 0.97

25 326 1

3 2812 0.01

11 2768 0.86

26 2770 1

149 44997 0.94

49 44944 0.50

Si le graphe contient des imperfections, le pdr se dégrade notamment dans le cas des trous concaves.


Chapitre V : MESURE DE PERFORMANCES, DIMENSIONNEMENT ET SIMULATION DU CAS REEL

1. Scénario :

Nous utilisons un scénario similaire au précédent [cf. Chapitre III.1 ]. Mais, pour ce cas on envoie un paquet toute les secondes et on n'attend pas que celui qui le précède soit reçu pour que notre scénario soit plus réaliste.

Le module correspondant est real_greedy_pdr.c.

2. Choix des paramètres de configuration :

• REAL_GREEDY : La librairie correspondante au module real_greedy_pdr.c. Ici aussi on doit spécifier le nombre de paquets et le délai de mise en place du routage.

• MAC : Wsnet offre plusieurs choix de modèles pour la couche MAC. Mais apparemment ce modèle est le plus réaliste. C'est une implémentation de 2400MHz oqpsk 802.15.4 csma ca.

 <entity name="mac" library="libmac_802_15_4_2400_oqpsk_u_csma_ca.la" >

</entity>

• PHY : Le choix de la couche MAC nous impose de choisir une couche physique adéquate et compatible. ( modulation oqpsk, couche radio 802.15.4...)

 <entity name="prop" library="propagation_freespace" >

</entity> <entity name="interf" library="interferences_orthogonal">

</entity> <entity name="o-qpsk" library="libmodulation_oqpsk.la">

</entity>



<entity name="omnidirectionnal" library="antenna_omnidirectionnal" > </entity>

<entity name="radio" library="radio_802_15_4_2400_oqpsk" > <default sensibility="-85" dBm="-20" channel="0"/>

</entity>

3. Simulation et interprétation des résultats :

Les simulations dans le cas réels sont beaucoup plus encombrantes en temps. Même avec des graphes moyens, le temps de simulation explose rapidement. Pour ces simulations, le nombre de sauts maximal est rapidement atteint, il faut le choisir en fonction de la taille de la topologie.

NOMBRE DE NOEUDS

TEMPS DE SIMULATION cas

ideal

TEMPS DE SIMULATION cas reel

PDR

326 372023000 42610663000 0.90

1299 3280205000 148373272000 0.69

Le PDR est très dégradé par rapport au cas idéal à cause des imperfections du milieu, des interférences et sur toutes les simulations que j'ai faites, cela dépasse rarement le taux de 70% même si, dans le cas idéal et sur les mêmes topologies cela donnait facilement 100%.

Chapitre VI : PROTOCOLE BWP ROUTING

1. Résultats validés dans le cas idéal :

La publication [1] illustre les résultats obtenus par l'équipe en simulant avec le simulateur maison.

2. Améliorations attendues : On s'attend à ce que BWP améliorent les PDR obtenus par greedy dans le cas réel, puisque ce

protocole présente des améliorations permettant de diminuer les effets de l'imperfection du réseau.Malheureusement cette partie n'a pas été traitée à cause des retards accumulés sur les parties

précédentes et à cause des difficultés conceptuelles et logicielles que j'ai rencontrées en utilisant WSNET.


Chapitre VII : CONCLUSION

1. Bilan :

En guise de conclusion, l'impact de la couche physique est rapidement palpable sur les performances du système. Et les dégradations qu'elle engendre sur la capacité ne doit pas être négligées. Les simulations que j'ai effectuées m'ont permis de valider partiellement deux de mes objectifs car la simulation comme preuve de validation, comme l'explique bien Ivan Stojmenovic est un processus très difficile à mettre en œuvre et à exploiter. J'aurais aimé fournir des résultats plus riches mais faute de temps cela m'a été impossible.

Ce travail donne une bonne base pour tester le module BWP sur WSNET, car les modèles utilisés ont été bien étudiés pour correspondre aux hypothèses à valider.

2. Références

[1] Eryk Schiller, Paul Starzetz, Franck Rousseau, Andrzej Duda : Binary Waypoint Geographical Routing in Wireless Mesh Networks

In Proceedings of ACM MSWiM 2008. Vancouver, Canada, 2731 October 2008

[2] Simulations in Wireless Sensor and Ad Hoc Networks: Matching and Advancing Models, Metrics, and Solutions Ivan Stojmenovic, University of Birmingham and University of Ottawa

[3] http://wsnet.gforge.inria.fr

[4] On the Complexity of an Accurate and Precise Performance Evaluation of Wireless Networks Using Simulations Elyes Ben Hamida, Guillaume Chelius, and JeanMarie Gorce Université de Lyon, INRIA INSALyon, CITI, F69621, France

[5] Scalable versus Accurate Physical Layer Modeling in Wireless Network Simulations Elyes Ben Hamida, Guillaume Chelius and JeanMarie Gorce ARES INRIA / CITI, INSA Lyon, F69621, France

[6] Guillaume Chelius


http://wsnet.gforge.inria.fr/

Simulation du protocole de routage binary waypoint sur WSNet · • Les réseaux locaux sans fils...

Documents

Transcript of Simulation du protocole de routage binary waypoint sur WSNet · • Les réseaux locaux sans fils...