• Aucun résultat trouvé

3.6 Évaluation des performances

3.6.3 Fiabilité de S OLIST

Considérons en premier lieu la correction et la précision des réponses fournies par chacune des fonctionnalités de SOLIST.

Évaluation de l’anycast La qualité de la primitive d’anycast se mesure selon plusieurs cri- tères : la distance entre l’émetteur d’une requête et le nœud de contact répondu, a fortiori la distance avec le point d’entrée, ainsi que la précision de la réponse. Tout d’abord, la figure 3.5 présente la distance moyenne et l’écart type de celle-ci entre l’émetteur de la requête et le nœud de contact correspondant, en fonction du nombre de cellules dans SOLIST. La borne in-

férieure (Distance du point le plus proche) correspond à la distance moyenne entre l’émetteur de la requête et le nœud le plus proche du type requis. La distance moyenne par l’utilisation de marches aléatoires est également présentée ici. Pour de grande cellules dans SOLIST, cor-

respondant à un nombre restreint de cellules, les nœuds de contact sont situés assez loin de l’émetteur, ceux-ci étant les plus proches des points d’entrée et non de l’émetteur. Mais, plus la taille des cellules diminue, plus les nœuds de contact sont proches. Un effet de bord peut être observé pour un très grand nombre de cellules, la courbe d’anycast dans SOLISTremon-

tant légèrement. En effet, lorsqu’un nœud rejoint un LIGH-t-LAYER, celui-ci informe le point

d’entrée le plus proche de son arrivée. À partir d’une forte diminution de la taille des cellules, d’autres points d’entrées peuvent être plus proche de ce nouveau nœud que de tous les autres de ce LIGH-t-LAYER, mais ils ne seront pas informés de cette arrivée. Contrairement à la création

et à l’élimination d’un LIGH-t-LAYERdont les occurrences sont éparses, nous avons préféré

ne pas inonder les points d’entrées à chaque arrivée, afin de limiter la consommation d’énergie globale du système.

3.6. Évaluation des performances 71 0 10 20 30 40 50 60 70 80 90 100 0 10 20 30 40 50 60 70 80 90 100

Distance (mètres ou sauts)

Nombre de cellules

Distance euclidienne Distance en nombre de sauts

FIG. 3.7 – Distance moyenne entre l’ini-

tiateur et le point d’entrée correspondant.

0 100 200 300 400 500 600 700 800 900 1000 0 5 10 15 20 25 Nombre de noeuds

Distance (mètres ou sauts)

Distance euclidienne Distance en nombre de sauts

FIG. 3.8 – FR de la distance moyenne entre

l’initiateur et le point d’entrée pour une to- pologie à 5 × 5 cellules.

La figure 3.6 présente la fonction de répartition (FR ou CDF pour Cumulative Distribution Functionchez les anglo-saxons) de cette distance sus-citée, considérant SOLISTavec une to-

pologie à 5 × 5 cellules et une approche par marches aléatoires. Ainsi, pour ces simulations, plus de 95 % des nœuds dans le contexte de SOLIST se situent à une distance inférieure à

13,5 mètres, contre seulement 80 % pour l’approche comparative. De surcroît, le queue de la FR pour SOLIST révèle une distance maximale de 62,5 mètres, tandis que celle relative aux

marches aléatoires se situe autour de 89 mètres, correspondant approximativement à la largeur de l’espace de simulation.

D’autre part, afin de comparer un second critère de l’anycast dans SOLIST, la figure 3.7

présente la distance moyenne, et l’écart type de cette dernière, entre tout nœud du système et le point d’entrée le plus proche, en fonction du nombre de cellules dans SOLIST. La distance

euclidienne n’est pas seulement représentée comme en figure 3.5 et 3.6, mais accompagnée du nombre de sauts nécessaires pour contacter un point d’entrée. À l’instar des conjectures préalables, plus les cellules sont petites, plus proches sont les points d’entrées. Cette figure montre que pour les topologies données, à partir de 6 cellules dans SOLIST, le nombre moyen de sauts est inférieur à 3, illustrant la basse consommation d’énergie nécessaire à l’obtention d’un nœud de contact. Comme précédement, la figure 3.8 présente la FR de ces deux distances pour une topologie à 5 × 5 cellules. 1,5 sauts8 seulement sont nécessaires pour aboutir sur

90 % des points d’entrées, et au plus 2,5 sauts pour 98.5 %. Pour cette expérimentation, chaque cellule à une taille de 19, 2 × 19, 2 mètres carrés. Aucun nœud n’est donc situé à une distance supérieure à√2× 19, 2 mètres d’un point d’entrée (la diagonale d’une cellule), mais certains se répartissent entre dans l’intervalle [√2×19,2

2 ;

2× 19, 2] : ces nœuds correspondent à ceux situés sur la bordure du réseau. Ceux-ci ont effectivement un choix moindre de points d’entrées que les nœuds centraux, lesquels ont autour au moins quatre points d’entrées du même type.

Évaluation du broadcast et du k-cast Concernant les primitives de broadcast et k-cast, la fiabilité des résultats est simple à analyser, correspondant à un comportement binaire : si une re- quête entraîne l’obtention d’une réponse, alors respectivement tous ou k nœuds ont été contac-

8Les valeurs sont calculées pour un message aller-retour, puis divisé par 2 afin de prendre en compte les chemins

Opération nAh

Transmission d’un paquet 20,000

Reception d’un paquet 8,000

Écoute sur le médium radio durant 1 milliseconde 1,250 Lecture de données sur mémoire Flash 1,111 Écriture/Suppression de données sur mémoire Flash 83,333

TAB. 3.1 – Coût énergétique typique de diverses opérations sur un nœud Mica c [MCP+02].

tés. Sinon, aucune réponse ne sera renvoyée. Ce dernier cas n’apparaît que rarement : uni- quement si le LIGH-t-LAYERest en cours de maintenance (départ ou défaillance d’un nœud).

Considérant le système en régime stable, le taux de succès d’une requête de k-cast ou de broad- cast est de 100 % au vu des caractéristiques du système présentées au paragraphe 3.2. En cas de maintenance d’un LIGH-t-LAYER, l’avancement de la primitive sera retardé en attendant un retour en régime stable. Le seul cas d’échec d’une requête advient donc uniquement lors- qu’un nœud est défaillant et que son nœud surveillant ne l’a pas encore détecté. Dans ce cas, la requête sera transférée et la réponse attendue indéfiniment. Un délai de garde, ou des accusés de réception de requêtes, peuvent être instaurés pour éviter ce cas de figure. Ces optimisations n’ont pas été incluses dans les simulations présentées dans ce chapitre.