Ajout de mouvements déterministes

Dans ce scénario, les routes sont initialement établies et les nœuds occupent les mêmes positions que dans le scénario précédent jusqu’à l’instant t0= 300sec. A t0= 300sec, les nœuds qui sont à un seul saut du JN sont mis en mouvement dans le sens trigonométrique. Au même instant, les nœuds qui sont à deux sauts du JN sont mis en mouvement dans le sens inverse. Chacun de ces nœuds se déplace linéairement à une vitesse de 5m/s vers le nœud suivant se trouvant sur le même cercle que lui même et dans le sens de mouvement choisi.

Les trajectoires ont été pensées de telle sorte que les nœuds du premier et du second sauts commencent à s’éloigner les uns des autres sans se déconnecter définitivement du réseau. A la fin des déplacements, ils se retrouvent placés aux intersections définies précédemment (cf. section 6.5.2).

Au cours du mouvement et lorsque des authentifications sont lancées, les routes sont établies ou calculées à nouveau en cas de changement en employant le protocole de routage AODV [12] (cf. annexe A). Certains nœuds se retrouvent parfois au-delà de la portée du reste des nœuds et deviennent ainsi injoignables. Cela peut arriver si n " 3 et hops " 3. Pour n < 3 et quelle que soit la valeur de hops, tous les nœuds sont situés sur une même droite, donc les nœuds qui entrent en mouvement ne deviennent jamais injoignables. Lorsque n = 1, on a un nœud unique au premier saut et de même au second saut si hops " 2. Lorsque n = 2, il y a deux nœuds au premier saut et de même au second saut si hops "2. Ils sont tous alignés. Chacun des deux nœuds appartenant à un saut se déplace alors vers l’emplacement initial de l’autre nœud, donc il n’y a jamais de rupture de connectivité.

D’autre part, étant donné hops < 3 et quelle que soit la valeur de n, le graphe reste toujours connexe et les nœuds ne se déconnectent donc jamais du réseau. En effet, cela est vrai pour n ∈ {1, 2} comme décrit dans le paragraphe ci-dessus. Le cas n = 3 peut être prouvé grâce à un calcul des distances entre les nœuds ainsi qu’il est décrit ci-dessous. Une fois cela montré pour n ∈ {1, 2, 3}, cela reste vrai pour n > 3 car les angles entre les lignes concourantes en JN et passant par les pairs AAA ne cessent de diminuer lorsque n augmente.

La figure 6.10 illustre le cas où n = 3 et hops = 3. Les nœuds 31, 32 et 33 y désignent les pairs AAA. Au premier saut, les nœuds 11, 12 et 13 se déplacent respectivement vers 12, 13 et 11. Au deuxième saut, les nœuds 21, 22 et 23 se déplacent respectivement vers 23, 21 et 22. Les nœuds se trouvant au delà du deuxième saut, ne se déplacent pas.

Au cours du mouvement, il est clair que le nœud JN ne se déconnecte jamais des nœuds 11, 12, et 13 car ces derniers restent toujours inscrits dans le cercle de centre JN et de rayon 100 mètres (cf. table 6.4). Le calcul des distances séparant

800 900 1000 1100 1200 900 1000 1100 1200 1300 900 950 1000 1050 1100 1150 1200 1250 850 900 950 1000 1050 1100 1150 21 22 23 JN 11 12 13 31 32 33 1200 800 850

Figure 6.10 – Trajectoire des nœuds relais

le nœud 21 des nœuds 11, 12 et 13 démontre que celui-ci ne se déconnecte jamais de ces nœuds donc du réseau. Comme le montre la figure 6.11, la distance minimale entre le nœud 21 et les nœuds 11, 12 ou 13 est toujours inférieure à 150 mètres c.-à-d. la portée maximale du signal. Entre la date égale à 300 s et la date égale à 314 sec, le nœud 11 est le plus proche de 21. Entre les dates 315 s et 334 sec, le nœud 13 devient le plus proche de 21. Enfin, entre les dates 335 s et 368 s, le nœud 12 devient le plus proche de 21. A chaque fois que le nœud le plus proche de 21 changeait, nous avons observé qu’il était rapidement choisi par AODV pour devenir le nœud relais entre le JN et le nœud 21. Pour des raisons de symétrie, ce raisonnement reste valable pour les nœuds 22 et 23. D’autre part, l’étude de l’évolution de la distance entre le nœud 31 et les nœuds 21 et 22, illustrée par le côté droit de la figure 6.11 montre que 31 se déconnecte du réseau entre les instants 312 s et 357 sec. Avant la date 311 sec, le relais des messages entre le JN et le nœud 31 est assuré par le nœud 21. Après la date 358 sec, il est assuré par le nœud 22. Pour des raisons de symétrie, ce raisonnement reste valable pour les nœuds 32 et 33. Ainsi, pour n = 3 et hops = 3, toute authentification lancée entre les dates 312 s et 357 s ne peut qu’échouer parce que le graphe n’est plus connexe dans cette plage là.

6.5 Modèles emboîtés et simulations 145 60 70 80 90 100 110 120 0 10 20 30 40 50 60 70 u 300 310 320 330 340 350 360 730 d (m) 120 110 100 90 80 70 60 t (sec 11 13 12 120 140 160 180 200 220 240 260 0 10 20 30 40 50 60 70 u 300 310 320 330 340 350 360 370 260 240 220 200 160 140 120 180 d (m) t (sec 21 22 150

Figure 6.11 – Influence du mouvement des nœuds relais sur la connectivité du graphe du réseau. A gauche : la distance minimale entre le nœud 21 et les nœuds 11, 12 et 13. A droite : la distance minimale entre le nœud 31 et les nœuds 21 et 22

réseau demeure non connexe est court. Notons aussi que l’état non connexe n’intervient que pour hops " 3 et n " 3.

Performance du protocole Durant les simulations, pour chaque couple de valeurs (n, hops) où n ∈ {1..6} et hops ∈ {1..10} et à chaque seconde entre les moments du début et de la fin du mouvement, une authentification a été lancée par le JN. A la fin des simulations, nous avons calculé le taux de réussite τ défini comme le nombre d’authentifications ayant réussi divisé par le nombre total d’authentifications :

τ= nombre d ′

authentif ications abouties nombre d′_{authentif ications lanc´ees}

Le taux de succès enregistré est de 0.69 soit 69% des authentifications lan- cées qui ont abouti. L’examen des fichiers de traces (en anglais trace files), produits par le simulateur après chaque exécution, montre que le non aboutisse- ment d’une authentification est souvent dû à la déconnexion du graphe comme expliqué ci-dessus. Dans ce cas les messages d’authentification sont supprimés par le nœud source. Un message d’erreur du type NRTE : drop, no route is available est alors écrit dans le fichier de traces selon le format suivant : d -t 319.000000000 -Hs 0 -Hd -2 -Ni 0 -Nx 1000.00 -Ny 1000.00 -Nz 0.00 - Ne -1.000000 -Nl RTR -Nw NRTE -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 0.2 -Id 3.0 -It udp -Il 347 -If 0 -Ii 0 -Iv 30 -Pn udp -Ps 3 -Pa 0 -Pf 0 -Po 0

où d désigne un message supprimé (drop), l’option −Is avec le paramètre 0.i identifie dans nos simulations le JN et l’option −Id avec un paramètre j.0 iden- tifie un pair AAA.

Les authentifications non abouties peuvent aussi avoir pour cause des col- lisions. Le message d’authentification est alors supprimé et tracé sous forme

COL : drop, collision comme ici :

d -t 339.094004956 -Hs 7 -Hd 7 -Ni 7 -Nx 919.10 -Ny 1058.78 -Nz 0.00 -Ne -1.000000 -Nl MAC -Nw COL -Ma 13a -Md 7 -Ms 0 -Mt 800 -Is 0.1 -Id 2.0 -It udp -Il 1711 -If 0 -Ii 0 -Iv 30 -Pn udp -Ps 4 -Pa 0 -Pf 0 -Po 0

Lorsque le nombre de retransmissions d’un message d’authentification atteint sept (cf. annexe D), celui-ci est aussi supprimé, comme prévu par le standard IEEE 802.11 802.11, et tracé par un enregistrement RET : drop, retry count exceeded ainsi que le montre l’exemple suivant :

s -t 339.098445441 -Hs 7 -Hd 13 -Ni 7 -Nx 919.10 -Ny 1058.78 -Nz 0.00 -Ne -1.000000 -Nl MAC -Nw — -Ma 13a -Md d -Ms 7 -Mt 800 -Is 0.1 -Id 2.0 -It udp -Il 1711 -If 0 -Ii 0 -Iv 29 -Pn udp -Ps 4 -Pa 0 -Pf 1 -Po 0

s -t 339.126988442 -Hs 7 -Hd 13 -Ni 7 -Nx 919.10 -Ny 1058.78 -Nz 0.00 -Ne -1.000000 -Nl MAC -Nw — -Ma 13a -Md d -Ms 7 -Mt 800 -Is 0.1 -Id 2.0 -It udp -Il 1711 -If 0 -Ii 0 -Iv 29 -Pn udp -Ps 4 -Pa 0 -Pf 1 -Po 0

s -t 339.185584239 -Hs 7 -Hd 13 -Ni 7 -Nx 919.10 -Ny 1058.78 -Nz 0.00 -Ne -1.000000 -Nl MAC -Nw — -Ma 13a -Md d -Ms 7 -Mt 800 -Is 0.1 -Id 2.0 -It udp -Il 1711 -If 0 -Ii 0 -Iv 29 -Pn udp -Ps 4 -Pa 0 -Pf 1 -Po 0

s -t 339.187391148 -Hs 7 -Hd 13 -Ni 7 -Nx 919.10 -Ny 1058.78 -Nz 0.00 -Ne -1.000000 -Nl MAC -Nw — -Ma 13a -Md d -Ms 7 -Mt 800 -Is 0.1 -Id 2.0 -It udp -Il 1711 -If 0 -Ii 0 -Iv 29 -Pn udp -Ps 4 -Pa 0 -Pf 1 -Po 0

s -t 339.221528837 -Hs 7 -Hd 13 -Ni 7 -Nx 919.10 -Ny 1058.78 -Nz 0.00 -Ne -1.000000 -Nl MAC -Nw — -Ma 13a -Md d -Ms 7 -Mt 800 -Is 0.1 -Id 2.0 -It udp -Il 1711 -If 0 -Ii 0 -Iv 29 -Pn udp -Ps 4 -Pa 0 -Pf 1 -Po 0

s -t 339.234775746 -Hs 7 -Hd 13 -Ni 7 -Nx 919.10 -Ny 1058.78 -Nz 0.00 -Ne -1.000000 -Nl MAC -Nw — -Ma 13a -Md d -Ms 7 -Mt 800 -Is 0.1 -Id 2.0 -It udp -Il 1711 -If 0 -Ii 0 -Iv 29 -Pn udp -Ps 4 -Pa 0 -Pf 1 -Po 0

s -t 339.243102655 -Hs 7 -Hd 13 -Ni 7 -Nx 919.10 -Ny 1058.78 -Nz 0.00 -Ne -1.000000 -Nl MAC -Nw — -Ma 13a -Md d -Ms 7 -Mt 800 -Is 0.1 -Id 2.0 -It udp -Il 1711 -If 0 -Ii 0 -Iv 29 -Pn udp -Ps 4 -Pa 0 -Pf 1 -Po 0

d -t 339.244839564 -Hs 7 -Hd 13 -Ni 7 -Nx 919.10 -Ny 1058.78 -Nz 0.00 -Ne -1.000000 -Nl MAC -Nw RET -Ma 13a -Md d -Ms 7 -Mt 800 -Is 0.1 -Id 2.0 -It udp -Il 1653 -If 0 -Ii 0 -Iv 29 -Pn udp -Ps 4 -Pa 0 -Pf 1 -Po 0

s désigne un message qui a été envoyé.

Seulement pour les authentifications qui ont abouti, nous avons calculé le temps d’authentification puis le rapport ρ pour chaque couple de valeurs (n,hops) où ρ est défini par :

ρ=temps d ′

authentif ication dans le sc´enario sans mouvement temps d′_{authentif ication dans le sc´}

6.6 Conclusion 147 La valeur moyenne que nous avons obtenue pour ρ est 0.23, ce qui signifie qu’une authentification aboutie dans le scénario avec mouvement nécessite ap- proximativement quatre fois plus de temps qu’une authentification dans le cas statique. Le temps induit par le routage est donc trois fois plus important que le temps dû à l’authentification seule.

Les valeurs de τ et de ρ démontrent que l’aboutissement d’une authentifi- cation et le temps qu’elle nécessite pour être achevée sont conditionnés par le processus de routage. Cependant quand une authentification aboutit, le temps de son exécution est inférieur à 1.4 sec.