Professional Documents
Culture Documents
Remerciements
Avant de vous prsenter ce rapport, Je tiens remercier tous ceux qui mont aid raliser ce TPE. Je voudrais en particulier citer : M. Victor MORARU, professeur lInstitut de la francophonie pour linformatique, il ma donn ses commentaires. En plus, il m'a donn beaucoup de conseils pour rsoudre tous les problmes en conception et en programmation. Cest intressant et utiles pour moi. M. LE Van Tuan, chercheur de laboratoire MSI, il ma propos lide de mon travail thorique et pratique. Ces ides mont aid vrifier le but de TPE. Enfin, tous les autres professeurs et amis lIFI, les personnes mont donn des conseils, des remarques et des critiques pour que je puisse amliorer le rsultat.
Page i
2.2.1 Le protocole proactif .................................................................................. 5 2.2.2 Le protocole actif ....................................................................................... 5 2.2.3 Le protocole hybride .................................................................................. 6 2.3 Projets de modle multi-interface multicanaux ................................................ 6 MITF .......................................................................................................... 6 TENS .......................................................................................................... 6 Hyacinth ..................................................................................................... 7 Module-based Wireless Node (MWNode - module de nud sans fil) ...... 7 Modle multi-interface multicanaux de chercheur Ramn Agero Calvo 8
2.4.1 Approche de protocole MAC et couche-lien multicanaux ......................... 8 2.4.2 Approche de protocole de routage multicanaux ......................................... 9 2.4.3 Problmes existants .................................................................................... 9 2.5 Simulation des protocoles de routage de rseaux sans fils dans NS2 ............ 10
2.5.1 Simulation des protocoles de routage....................................................... 10 2.5.2 Problmes existants dans NS2.................................................................. 10 Chapitre 3. 3.1 Ralisation pratique ........................................................................................... 12 Objectif ........................................................................................................... 12 Page ii
3.3.1 Protocole AODV ...................................................................................... 16 3.3.2 Changement de code C++ pour crer un nouveau modle en sadaptant le modle multicanaux multi-interfaces ............................................................................... 17 3.4 Protocole de routage dans le modle multicanaux multi-interfaces MCR ..... 21 3.4.1 Stratgie de lassignement dinterface ..................................................... 22 3.4.2 Changement du code C++ pour limplmentation de commutation de linterface 24 3.5 Chapitre 4. 4.1 Table de changement de code ........................................................................ 28 Exprimentation ................................................................................................. 29 Test de scnario de modle des nuds multi-interfaces ................................ 29
4.1.1 Topologie du rseau ................................................................................. 29 4.1.2 Contenu de scnario ................................................................................. 29 4.1.3 Rsultat :................................................................................................... 29 4.2 Test de scnario de routage de modle des nuds multi-interfaces .............. 30
4.2.1 Topologie du rseau ................................................................................. 30 4.2.2 Contenu de scnario ................................................................................. 30 4.2.3 Rsultat ..................................................................................................... 30 4.3 Deux scnarios de transmission de mme frquence ..................................... 33
4.3.1 Scnario 1 de transmission de mme frquence....................................... 33 4.3.2 Scnario 2 de transmission de mme frquence....................................... 34 4.4 Deux scnario de distance .............................................................................. 36
4.4.1 Scnario 1 de distance .............................................................................. 36 4.4.2 Scnario 2 de distance .............................................................................. 37 4.5 Scnario dimplmentation de commutation de linterface ........................... 38
4.5.1 Topologie du rseau ................................................................................. 38 4.5.2 Contenu de scnario ................................................................................. 39 4.5.3 Rsultat ..................................................................................................... 39 Chapitre 5. 5.1 5.2 Conclusions et perspectives ............................................................................... 40 Conclusion...................................................................................................... 40 Perspectives .................................................................................................... 40 Page iii
Page iv
Chapitre 1. Introduction
1.1 Contexte
Aujourdhui, les rseaux sans fils sont connus pour appliquer transfrer des donnes entre les terminaux mobiles. Il y a beaucoup de technologies de rseaux sans fils comme : Wifi, Wimax, ZegBee, Bluetooth, En consquence, il est difficile de choisir une technologie optimale, et on se propose de les intgrer sur le mme rseau. Dautre part, il y a des problmes de ces technologies comme : renforcer la robustesse du rseau, optimiser lutilisation de bande passante, conomiser lnergie surtout le problme de protocole de routage. Mon sujet qui est un sujet de recherche va concentrer la recherche des protocoles de routage des rseaux multi-radio mobiles. Alors, ce TPE pour but de faire dune tude de routage dans les rseaux multi-radio (multifrquence, multicanaux, etc.) et valuer les caractristiques de ces rseaux comme : la performance, la fiabilit, la latence, etc. De plus, je peux proposer un nouveau protocole ou adapter un protocole existant pour faire du routage et crer les paramtres meilleurs que les rseaux existants.
Page 1
Page 2
Page 3
2.1.4 Bluetooth
Bluetooth est une technologie mergeante qui peut remplacer linterconnexion en cble. Bluetooth permet aux quipements de connecter en distance courte avec la bande nonautorise 2.4 GHz. Il soutient la connexion-oriente et le lien sans connexion. Pour le prix bon march et la popularit de Bluetooth, cette technologie est non seulement un fondement
Page 4
Page 5
TPE - Protocoles de routage dans les rseaux multi-radios mobiles 2.2.2.2 AODV Ad-hoc On Demand Distance Vector Routing
AODV est un protocole de routage. DSR contient les routes de source dans le paquet en-tte. En consquence, les paquets ont le large en-tte et pour dgrader la performance de rseau. Par contre, le protocole AODV essaie de maintenir les tables de routage pour amliorer le DSR, parce que les paquets de donne ne contiennent pas des routes. En plus, AODV retient la fonction de DSR que les routes maintiennent entre les nuds qui ont besoin de la communication.[28].
2.3.1 MITF
Ce projet nest pas actif, ce qui a t ralise lUniversit de Rio de Jainero. Son objectif tait de mise en uvre des interfaces multiples et dadapter le protocole de routage AODV avec NS2 en version 2.28. Toutefois, puisque ce projet arrt, il nest pas possible dvaluer pleinement les rsultats concrets de cette recherche. La plupart des modifications qui ont t faites sur le simulateur avec les fichiers C++. Dans cette approche, il a cr les diffrents modules qui sont une partie de larchitecture MobileNode comme LL, ARP, MAC et les tableaux (listes de variables) . De cette faon, il est possible de se rfrer au module (modle de tableau) en utilisant le canal comme un index pour localiser les target correspondants dans la liste de variables de canaux. En outre, deux nouveaux tableaux ont t crs dans la classe MobileNode pour grer la liste de nuds associs chaque canal, en utilisant le canal comme l'indice d'accs ces deux nouveaux tableaux. D'autre part, limplmentation de code Tcl et de protocole de routage AODV ont t modifis de sorte que la capacit multi-interface pourrait tre exploite par le protocole de routage. Mais le dveloppement de ce projet n'est pas compltement termin.
2.3.2 TENS
Ce projet [24]. a t faite l'Institut indien de technologie de Kanpur, en Inde. Son objectif principal tait d'amliorer la ns-2.1b9a de la mise en uvre du protocole IEEE 802.11 sur les diffrents aspects, comme la couche MAC et le modle physique pour ajouter
Page 6
2.3.3 Hyacinth
Ce projet correspondant a t initialement ralis l'Universit de l'tat de New York pour ns-2.1b9a [25]. , et il y a des informations disponibles sur la faon de l'utiliser sur ns2,29 [26]. [27]. . Son principal inconvnient est qu'il fournit une configuration statique, dans lequel tous les nuds dans le scnario de ncessit d'intgrer jusqu' 5 diffrentes interfaces. En outre, un lagent de routage statique (configuration manuelle) a t mis en uvre pour utiliser la capacit de multicanaux. Mais il nexiste pas les informations disponibles sur la faon de modification les agents de routage comme AODV ou DSDV et de lutilisation de la capacit de multi-interfaces. Aprs avoir dfini jusqu' 11 canaux diffrents (et donc l'mulation de la couche physique IEEE 802.11b) dans le script de simulateur, cinq d'entre eux sont affects chaque nud par la commande node-config. Par consquent, les procdures correspondantes ont t ajoutes dans le fichier ns-lib.tcl. Ensuite, la procdure create-wireless-node qui est dans mme fichier, elle demande 5 fois sur la procdure add-interface, chacun d'eux avec un canal diffrent. Ces segments de code sont toujours excuts, peu importe si l'utilisateur sintresse au nud spcifique avec le nombre de linterface. En regardant les changements qui sont ncessaires au fichier mac-802.cc, il semble que pour garantir un comportement correct, dans un scnario, tous les nuds a de mme nombre d'interfaces (dans ce cas, le nombre dinterface gale 5). Dautre part, ce modle original a t bas sur un statique, un agent de routage manuel qui a t configur (c'est--dire des processus pour ajouter et supprimer des routes) partir du scnario de script. Par consquent, il n'est pas simple de stendre l'utilisation des interfaces multiples aux protocoles de routage diffrents
Page 7
Page 8
2.5 Simulation des protocoles de routage de rseaux sans fils dans NS2
Simulateur NS2 (Network Simulator) est un simulateur des vnements discrets pour but faire de la recherche de rseau. NS2 fournit un soutien substantiel pour simuler le TCP, le routage, le multicast et les protocoles dans les rseaux filaires et les rseaux sans fils (local et satellite). NS2 est crit en C++, et il y a une version oriente-objet de TCL, qui sappelle OTcl.
Page 11
Page 12
Il y a quelques composants dans cette architecture : Routing Agent ; router des paquets next-hop. Aujourd'hui, NS2 soutient 4 protocoles de routage du rseau ad-hoc o AODV Adhoc On-demand Distance Vector o DSDV Destination Sequenced Distance Vector Routing o DSR Dynamic Source Routing o TORA Temporally Ordered Routing Algorithm
Link Layer : Pour mettre l'adresse de destination MAC dans l'en-tete de paquet IP, on cherche l'adresse IP de nud next-hop dans Routing Agent et la rsolution l'adresse entre l'adresse MAC et ARP. ARP Address Resolution Protocol Il reoit des requtes de Link-Layer pour rsoudre ladresse du matriel qui se rfre une table ARP. Sil est possible de trouver une adresse, il est dcrit au en-tte de paquet MAC, Sinon, il y a requte ARP publi. Dans le cas de retrouver une adresse MAC, le paquet va s'insrer la file dinterface. Interface Queue (file dinterface)
Page 13
La diffrence entre 2 architectures est que chaque nud a des formes des couches de lien, ARP, files dinterface, MAC, interface du rseau et des entits de canal. Chaque forme reprsente une interface du rseau sans fils. Dautre part, la nouvelle structure ne change pas le matriel IEEE 802.11. En consquence, il est possible de simuler et dimplmenter la nouvelle architecture dans la ralit.
Page 14
Page 15
TPE - Protocoles de routage dans les rseaux multi-radios mobiles 3.2.4.2 Changement du code C++
Changement de lobjet MobileMode : ns-2.33/common/mobilenode.h NS 2 utilise 2 listes de lien pour grer le nombre de canal. prevX_ - rfrence de nud prcdent ; nextX_ - rfrence de nud prochain. Primitivement, ces listes sont pointeurs aux nuds. Pour changer ces liste, ces listes deviennent des tables de pointeur. comme : nextX_[MAX_CHANNELS], prevX_[MAX_CHANNELS] Changement de ns-2.33/common/mobilenode.cc Ajouter getLoc() pour retrouver la situation dun nud. Changement de ns-2.33/mac/channel.cc Pour changer la liste de gestion dans lobjet MobileNode, on change laccs de chaque nud quand on attache, supprime ou met jours un nouveau nud un canal correspondant un nombre de canal. On remplace de la commande this->index() par les commandes prevX_[this->index] , nextX_[this->index] . Dautre part, dans la fonction affectedNodes(), on ajoute une nouvelle condition pour vrifier que linterface de nud de destination soit connect le mme canal avant la transfert de paquet entre cette interface et lautre interface. Changement de ns-2.33/mac/mac-802_11.cc On modifie la mthode recv() dans la classe MAC 802.11 pour s'enregistrer linterface reue MAC correcte dans len-tte MAC.
Page 16
Ce processus a pour but de mettre jours les routes tablies. Parfois, une route dun nud offre la connectivit des informations par la fonction sendHello() pour diffuser des messages Hello. Chaque fois qu'un nud reoit un message Hello d'un voisin via recvHello(), le nud fait en sorte qu'il y a une route de voisin et en crant une route sil est ncessaire. Le nud courant peut commencer utiliser cette route pour transmettre des paquets. En outre, lorsque la rupture d'un lien est dtecte par un nud, ce nud va appeler sendError() pour notifier au nud de source avec la paquet Route Error(RERR). Ensuite le nud de source initialise un nouveau processus de dcouverte de route.
3.3.2 Changement de code C++ pour crer un nouveau modle en sadaptant le modle multicanaux multi-interfaces
Selon loriginale structure de nud mobile, on a utilis les variables : targetlist et ifqueue. Dans cette nouvelle structure, on utilise 2 tables : targetlist qui stocke des modules
Page 17
//TPE: Gerer l'interface multiple #define MAX_IF 12 // le nombre d'interface d'un noeud //TPE: le variable de nombre d'interface int nIfaces; //le nombre d'interface //TPE: File d'attent stocke le module LL pour chaque interface NsObject *targetlist[MAX_IF]; //TPE: Stoker les files d'attent de toutes interfaces PriQueue *ifqueuelist[MAX_IF];
Ensuite, on modifie la mthode command de classe AODV dans le fichier aodv.cc pour initialiser des valeurs de Tclscript comme : if-queue, target
//TPE: le methode "command" de classe agent routage else if(argc == 4) { if (strcmp(argv[1],"if-queue") == 0){ PriQueue *ifq = (PriQueue *) TclObject::lookup(argv[3]); int temp_ = atoi(argv[2]); if (temp_== nIfaces){ nIfaces++; } ifqueuelist[temp_] = ifq; if (ifqueuelist[temp_]){ return TCL_OK; } else { return TCL_ERROR; } } if (strcmp(argv[1],"target") == 0){ int temp_ = atoi(argv[2]); if (temp_== nIfaces){ nIfaces++; } targetlist[temp_] = (NsObject *) TclObject::lookup(argv[3]); if (targetlist[temp_]){ return TCL_OK; } else { return TCL_ERROR; } } } return Agent::command(argc, argv); }
De plus, un nud doit dcider une interface qui transfre chaque paquet. Cest pourquoi, on utilise une transmission diffuse (comme dans le processus Route Discovery ). Si il y des plus 2 interfaces disponibles, on doit transfrer un paquet diffus aux toutes interface de ce nud. Dans cet agent de routage AODV, on change 4 mthodes : sendRequest, sendError, sendHello, forward. Voici le code de changement suivant :
Page 18
Page 19
En plus, quand un paquet de routage une interface de destination, on doit une transmission unicast pour connaitre cette interface. Cest pourquoi, on stocke les informations dinterface en sortie pour arriver next hop. Dans ce cas, on ajoute un variable rt_interface dans le fichier aodv_rtable.h pour stocker lindice dinterface approprie. Et le processus de transmission unicast va utiliser rt_interface pour choisir une entre de targetlist. Le processus unicast est utilis dans 2 mthodes sendReply et forward :
//fichier aodv_rtable.h // TPE: indice d'interface pour router paquets int rt_interface; //fichier aodv.cc //methode forward // Not a broadcast packet if(delay > 0.0) { if (nIfaces) { printf("n%d\tforward - rt->rt_interface (delay > 0): %d\n\n", (int)index, rt->rt_interface); Scheduler::instance().schedule(targetlist[rt->rt_interface], p, delay); } else { Scheduler::instance().schedule(target_, p, delay); } } //Scheduler::instance().schedule(target_, p, delay); //} else { // Not a broadcast packet, no delay, send immediately // Scheduler::instance().schedule(target_, p, 0.); //TPE: Envoyer un paquet unicast if (nIfaces) { printf("n%d\tforward - rt->rt_interface (else): %d\n\n", (int)index,rt->rt_interface); Scheduler::instance().schedule(targetlist[rt->rt_interface], p, 0); //Scheduler::instance().schedule(targetlist[Iface], pkt, 0); } else { Scheduler::instance().schedule(target_, p, 0); } } } } //methode sendReply //TPE : Envoyer un paquet unicast if (nIfaces) {
Page 20
Pour trouver la valeur rt_interface, on utilise ladresse dinterface entrante qui est un membre de en-tte de paquet commun. Dans ce cas, on trouve la valeur rt_interface dans 2 mthodes recvRequet et recvReply :
//methode recvRequest // TPE : Trouver l'en-tete commun de paquet struct hdr_cmn *ch = HDR_CMN(p); //TPE : trouver l'indice de l'interface entrante if (nIfaces) { printf("n%d\trecvRequest - ch->iface() (rt0 = 0): %d\n", (int)index, ch->iface()); printf("n%d\trecvRequest - ((Mac *)ifqueuelist[0]->target())>addr() (rt0 = 0): %d\n", (int)index, ((Mac *)ifqueuelist[0]->target())>addr()); rt0->rt_interface = ch->iface()-((Mac *)ifqueuelist[0]>target())->addr(); } else { rt0->rt_interface = -1; } printf("n%d\trecvRequest - rt0->rt_interface (rt0 = 0): %d\n\n", (int)index, rt0->rt_interface); } //method recvReply // TPE : Trouver l'en-tete commun de paquet struct hdr_cmn *ch = HDR_CMN(p); if(rt == 0) { rt = rtable.rt_add(rp->rp_dst); //TPE: Trouver l'indice de l'interface if (nIfaces) { printf("n%d\trecvReply - ch->iface() (rt = 0): %d\n", (int)index, ch->iface()); printf("n%d\trecvReply - ((Mac *)ifqueuelist[0]->target())>addr() (rt = 0):%d\n", (int)index, ((Mac *)ifqueuelist[0]->target())>addr()); rt->rt_interface = ch->iface()-((Mac *)ifqueuelist[0]>target())->addr(); } else { rt->rt_interface = -1; } printf("n%d\trecvReply - rt->rt_interface (rt = 0): %d\n\n", (int)index, rt->rt_interface); }
Page 21
Page 22
En gnral, si le nud X transfre au nud Y sur le canal a, linterface commutable de X est commut au canal a pour transfrer au nud Y. Et si linterface commutable de X est canal a, il ny a pas de la commutation de linterface. Cest--dire lexpditeur sadapte le rcepteur par la commutation de linterface commutable qui gale linterface fixe de rcepteur.
Etape 1 : Si un paquet unicast est reu dans la couche de lien de donne (Data Link Layer) : o Le nud cherche le canal fixe de destination de paquet dans la table de voisin. Si lexpditeur a le mme canal fixe de rcepteur, il faut stocker le paquet au canal fixe. Si non, il faut stocker au le canal commutable o Pour diffuser un paquet, le nud copie et donne ce paquet la file de chaque canal. Le paquet est envoy quand le canal commence transfrer des donnes Etape 2 : Linterface commutable change le canal sil y a des paquets dans la file pour lautre canal
pour
limplmentation
de
Page 24
//TPE : Initial de methode MCR //Choisir une interface fixed et une interface switchable interface_fixed = rand() % (temp_+1); if (nIfaces > 1){ do{ interface_switchable = rand() % (temp_+1); } while (interface_switchable == interface_fixed); } //end nIfaces
On doit mettre jour le canal fixe dans le table de voisin et la liste de canaux dusage
//TPE : Ajouter l'interface fixed dans le table de voisin int fixed_channel = ((Mac *)ifqueuelist[interface_fixed]->target())>netif()->channel()->index(); tbl_neighbour[(int)index] = fixed_channel; ls_channel_usage[fixed_channel]++;
//sendRequest //TPE2: Ajouter le canal fixed de ce noeud au packet rq->rq_fixed_channel_used = tbl_neighbour[(int)index]; rq->rq_sender_node_ip = (int)index; rq->rq_neighbour_table = &tbl_neighbour[0]; //sendReply //TPE2: Ajouter le canal fixed de ce noeud au packet rp->rp_fixed_channel_used = tbl_neighbour[(int)index]; rp->rp_sender_node_ip = (int)index; rp->rp_neighbour_table = &tbl_neighbour[0]; //sendHello //TPE2: Ajouter le canal fixed de ce noeud au packet hello rh->rp_fixed_channel_used = tbl_neighbour[(int)index]; rh->rp_sender_node_ip = (int)index; rh->rp_neighbour_table = &tbl_neighbour[0];
Mthode forward()
Le programme traite le paquet reu (RREQ, RREP et Hello) et ajoute le canal fixe dans sa table de voisin
//TPE2: Dans le cas, Expediter le paquet RREQ if(rq->rq_type == AODVTYPE_RREQ){ rq->rq_fixed_channel_used = tbl_neighbour[(int)index]; rq->rq_sender_node_ip = (int)index; rq->rq_neighbour_table = &tbl_neighbour[0]; }
Page 26
Ensuite, si le nombre de canal fixe est grand, on choisit la probabilit 0.5 pour changer le canal fixe. De plus, le nud va transfrer un message Hello pour informer ses voisin sur le nouveau canal fixe.
if (found && !flag ){ if(ls_channel_usage[tbl_neighbour[(int)index]] == ls_channel_usage[channel_usage_highest]){ int probability_switch = rand() % 101; //la probabilite switchable if (probability_switch < 50){ //Si condition de changement = true, on doit changer la liste de cannaux int channel_fixed = ((Mac *)ifqueuelist[interface_fixed]>target())->netif()->channel()->index(); ls_channel_usage[channel_fixed]--; //Choisir un nouveau cannal = canal minimal channel_fixed = channel_usage_lowest; ls_channel_usage[channel_fixed]++; tbl_neighbour[(int)index] = channel_fixed; for (int i = 0; i<nIfaces; i++){ if ( ((Mac *)ifqueuelist[i]->target())->netif()>channel()->index() == channel_fixed){ interface_fixed = i; break; } //end if Mac }//end for sendHello(); }//end probability
Enfin, le nud cherche le canal fixe dans la table de voisin pour assigner ce canal fixe au canal commutable
Page 27
Page 28
Chapitre 4. Exprimentation
4.1 Test de scnario de modle des nuds multi-interfaces
4.1.1 Topologie du rseau
On cre 3 nuds avec la spcification suivant : Nud 0 a 2 interfaces : Interface 0 opre la frquence 2.14 Ghz et Interface 1 opre la frquence 914 Mb. Nud 1 a 1 interface qui opre la frquence 914 MHz Nud 2 a 1 interface qui opre la frquence 2.14 GHz
4.1.3 Rsultat :
Voici le rsultat de dbit de nud 1 et de nud 2 :
Page 29
4.2.3 Rsultat
Voici le rsultat des dbits Dbit de nud immdiate 0 :
Page 30
Page 31
- Ligne rouge : dbit de nud 1 - Ligne vert : dbit de nud 0 Pour le rsultat, on a transfr des donnes entre le nud 1 et le nud 2. Le nud 0 est un rle de nud intermdiaire pour transfrer des donnes du nud 2 nud 1. Cest pourquoi, le nud 1 ne connecte pas directement le nud 2. Parce que le nud 1 a une interface qui opre la frquence 914 MHz, le nud 2 a 1 interface qui opre la frquence 2.14 GHz et la distance entre le nud 1 et nud 2 est 350, cette distance nutilise pas de connecter directement dans la norme 802.11a/b
Page 32
4.3.1.3 Rsultat
Voici le rsultat des dbits
Page 33
- Ligne rouge : dbit de nud 1 - Ligne vert : dbit de nud 3 Dans cette exprience, on utilise la structure originale de nud NS2 avec la mme frquence 914 MHz. De plus, le dbit daucune connexion ninfluence pas dautre connexion. Parce que chaque connexion utilise un canal diffrent et je pense que la structure de nud NS2 utilise une bande de frquence autour de 914 MHz. En plus, la structure NS2 et la standard 802.11 utilisent les canaux orthogonaux. En consquence, ces 2 canaux nont pas linterfrence et le dbit entre 2 canaux est approximatif.
Page 34
4.3.2.3 Rsultat
Voici le rsultat des dbits
- Ligne rouge : dbit de nud 1 - Ligne vert : dbit de nud 0 Dans cette exprience, on a transfr des donnes entre le nud 1 et le nud 2. Le nud 0 est un rle de nud intermdiaire pour transfrer des donnes du nud 2 nud 1. Cest pourquoi, le nud 1 ne connecte pas directement le nud 2. Parce
Page 35
4.4.1.3 Rsultat
Voici le rsultat des dbits
Page 36
Dans cette exprimentation, le dbit de modle original est petit que les autres cas. En consquence, le nouveau modle est meilleur que le modle original.
4.4.2.3 Rsultat
Voici le rsultat des dbits
Dans cette exprience, le dbit entre le nud 0 et le nud n est grand (800 Kbps). Cest pourquoi, la distance entre le nud 0 et nud n (maximal n = 10) = 20 * 10 = 200 m. En consquence, la transmission entre le nud 0 et le nud n est directe.
de
commutation
de
Chaque nud a des 2 interfaces : Interface 0 opre la frquence 914 MHz et Interface 1 opre la frquence 914 MHz. La distance entre 2 nuds est 200 m. Page 38
4.5.3 Rsultat
Voici le rsultat des dbits
Dans cette exprimentation, le dbit de modle original est petit que les autres cas. En consquence, le nouveau modle est meilleur que le modle original.
Page 39
5.2 Perspectives
Dans lavenir, si le projet est continu dvelopper, on pourra amliorer les problmes que je viens de prsenter suivants : On peut construire un autre modle multi-interfaces multicanaux tel que chaque interface est contrl un agent de routage diffrent. En consquence, on peut simuler les quipements qui contiennent des technologies diffrentes comme : Wimax, Wifi et GPRS. On peut amliorer le protocole AODV en sadaptant le modle multi-interface multicanaux pour lever le dbit de rseau et la stabilisation de rseau Ad-hoc Page 40
Page 41
Page 42
Page 43