Certains paramètres du modèle sont fixés pour toutes les simulations car leur influence sur la solution ne présente pas d’intérêt particulier. Les autres paramètres sont ceux dont l’impact sur l’efficacité de la solution nous intéresse.
4.2.1 Couche applicative
La taille des paquets de données est simplement tirée des cas concrets en TCP/IP, avec smin = 40octets etsmax = 1 500octets. Quant au paramètreλpde la loi exponentielle des intervalles de temps entre deux générations successives de paquets, sa valeur est déterminante.
En effet, il apparaît qu’une valeur trop grande deλp peut saturer le réseau de paquets de données, puisqu’aucun mécanisme de contrôle de flux n’est mis en place. Il est donc essentiel de régler ce paramètre à une valeur à la fois suffisamment grande pour que les statistiques sur les paquets de données soient pertinentes et suffisamment petite pour que le réseau ne sature pas.
Nous avons empiriquement déterminé qu’une valeur deλp = 20est satisfaisante.
4.2.2 Couche OLSR
Les paramètres par défaut préconisés dans la spécification du protocole OLSR ont été utilisés. Leurs valeurs sont résumées dans le tableau 4.1.
Quant aux paramètres de notre solution (voir le paragraphe 3.2 du chapitre 3), leurs valeurs sont présentées dans le tableau 4.2. En outre, les valeurs des degrés locaux ne sont pas diffusées telles quelles dans les messages TC, mais plutôt le résultat de l’application de la fonction suivante :
Dij 7→
0 siDij <1 1 + lnDji sinon
. (4.4)
TAB. 4.2: Paramètres de la solution
P 2s rI0 1
rI 1 rD0 1
rD 10−4 rA 106
TAB. 4.3: Paramètres de la couche MAC
Seuil RTS/CTS 50 octets Durée d’un Slot 2·10−5 s
Tentatives de backoff max. 7 Durée d’un SIFS 10−5 s
Fenêtre de contention min. 31 slots Durée d’un DIFS 5·10−5 s Fenêtre de contention max. 1 023 slots Durée d’un EIFS 1,7·10−3 s Débit broadcast 11 Mbps Seuil de détection de porteuse -75 dBm
Débit unicast 54 Mbps Seuil de réception -70 dBm
SNRRX 3 dB
Par conséquent, la fonctionf utilisée pour le calcul des poids sur les arcs du graphe topologique est simplement l’identité. De cette façon, le résultat est pratiquement le même mais l’utilisation de plus petites valeurs de degré de suspicion local dans les messages TC permet leur codage simple sur un nombre de bits limités.
4.2.3 Couche MAC
Les paramètres de la couche MAC sont ceux préconisés par le standard IEEE 802.11 et ses amendements. Les valeurs des différentes durées paramétrables sont résumées dans le tableau 4.3.
4.2.4 Couche physique
Les nœuds émettent sur la bande des 2,5 GHz, soit un paramètreλ= 1,2·10−2 m. Ils émettent avec une puissancePt= 50mW, ce qui implique, avec le modèle d’atténuation de (4.3), un rayon de portée de réception d’au mieux environ 214 m et un rayon de portée de détection de porteuse d’environ 380 m.
Les paramètres de mobilité des nœuds sontxmax = 1 000m,ymax = 1 000m,λm = 1/600,vmin = 0m/s etvmax = 1m/s.
TAB. 4.4: Stratégies de triche : manipulation des compteurs en cas de destruction de paquet FD Incrémenter les compteurs comme si le paquet avait été retransmis.
BD N’incrémenter aucun compteur, comme si le paquet n’avait jamais été reçu depuis le nœud précédent.
SD Incrémenter les compteurs sur tous les liens de telle façon que la somme rajoutée totale soit égale à la taille du paquet détruit.
ND Ne pas incrémenter les compteurs sur le lien sortant.
AD AppliquerFD,BD,SDouNDaléatoirement.
4.2.5 Paramètres variables
Le nombre total de nœuds détermine la densité du réseau, puisque la surface reste la même pour toutes les simulations. Nous avons donc lancé des simulations pour un nombre total de nœuds variant entre 30 et 100.
Les nœuds malveillants, appelés icitricheurs, sont paramétrés par leur nombre total, leur probabilité de ne pas retransmettre un paquet de données et leur stratégie de gestion des compteurs dans le cas où le comptage des paquets est mis en œuvre. Lorsqu’un tricheur décide de ne pas détruire un paquet et de le retransmettre correctement, il gère ses compteurs de la même manière qu’un nœud bienveillant. En revanche, lorsqu’il détruit un paquet, des comportements différents sont possibles. En effet, on doit s’attendre à ce qu’un tricheur tâche de masquer d’une manière ou d’une autre ses actions néfastes pour tenter de déjouer le système de détection.
Comportement des tricheurs
Nous avons défini plusieurs stratégies possibles de gestion des compteurs par un nœud malveillant suite à la destruction d’un paquet. Elles sont décrite dans le tableau 4.4. Par ailleurs, dans les scénarios qui mettent en œuvre notre méthode de notation, les tricheurs publient des degrés de suspicion à l’égard de leurs MPR-selectors de 1 000 avec des indices de confiance de 1, ce qui permet d’évaluer à quel point notre méthode est résistante à la diffamation.
Le moyen principal que nous avons choisi pour évaluer les performances de notre méthode est de mesurer le taux d’acheminement des paquets de données de leur source jusqu’à leur destination, tous paquets ou flux de données confondus. Nous pouvons ainsi prendre en compte tous les facteurs de perte de paquets pouvant apparaître dans un réseau ad hoc mobile (manque de route, expiration du TTL, perte au niveau des couches inférieures, pertes intentionnelles).
TAB. 4.5: Simulations-témoins
Présence de tricheurs Routage
NC non OLSR classique
C oui OLSR classique
K oui OLSR muni d’un oracle
Comme l’illustre par ailleurs la figure 4.4, même en l’absence de tricheurs, le taux d’achemine-ment est en général inférieur à 1. Pour apprécier les taux d’achemined’achemine-ment atteints avec notre solution, nous proposons de comparer ceux-ci à ceux de plusieurs simulations-témoins.
Simulations-témoins
Tout d’abord, il est essentiel de comparer le taux d’acheminement d’une simulation à celui atteint par l’utilisation du protocole OLSR classique, à conditions de vitesse maximale et densité des nœuds égales, en l’absence de tricheurs. C’est le témoin qui fixe la borne supérieure absolue du taux d’acheminement dans ces conditions.
Il est ensuite intéressant de comparer ce taux d’acheminement à celui atteint par l’utilisa-tion du protocole OLSR classique en présence des mêmes tricheurs, à condil’utilisa-tions de vitesse maximale et densité des nœuds égales. En un sens, cela donne une idée de la borne inférieure du taux d’acheminement qu’on ne devrait absolument jamais dépasser, autrement l’application de la solution est clairement à proscrire.
Enfin, comme le taux d’acheminement dépend aussi de la topologie du réseau, celle-ci ne permettant parfois pas de trouver des chemins qui évitent les tricheurs, on veut pouvoir le comparer à celui atteint par l’utilisation du protocole OLSR classique auquel on rajoute un oracle qui permet de savoir si un nœud est tricheur. La connaissance des tricheurs par l’oracle permet de modifier les poids sur le graphe topologique afin de trouver des chemin qui contournent les tricheurs quand cela est possible. On peut considérer la performance de ce témoin comme un objectif dont l’application de notre solution cherche à se rapprocher au maximum. En effet, si la solution permettait de détecter parfaitement les tricheurs et seulement eux, ceci en ne gaspillant jamais un paquet de données, alors c’est le taux d’acheminement qu’elle permettrait d’atteindre.
Le tableau 4.5 résume les paramètres des simulations-témoins.