Exp´ erimentations

Cette section pr´esente les r´esultats de BD-RPL avec la plateforme Iot-lab. Afin d’´eviter la r´ep´etition, nous allons exclusivement souligner les diff´erences entre les simulations et les exp´erimentations.

Configuration et hypoth`eses

Pour notre exp´erimentation de BD-RPL dans Iot-lab, nous avons consid´er´e 50 nœuds WSN430 statiques. Dans nos exp´eriences, nous avons consid´er´e une radio CC2420, fonc-tionnant `a 2,4 GHz. Le taux de v´erification du canal est fix´ee `a 4 Hz. La puissance d’´emission des nœuds est fix´e `a -1 dBm. Les nœuds commencent `a transmettre leurs paquets de donn´ees au bout de 2 minutes pour laisser le temps au protocole de construire l’arbre. Les nœuds envoient des paquets UDP toutes les deux minutes vers la racine. La racine acquitte chaque paquet de donn´ees re¸cu. Nous executions chaque experimentation 3 heures et nous la r´ep´etons 6 fois avec la mˆeme distribution de nœuds. Le tableau 5.4.5 r´esume les choix de configuration.

R´esultats pour le changement de topologie

La Figure 5.11 compare le changement moyen de parents en fonction de la distance en nombre de sauts au puits. Les r´esultats montrent qu’avec BD-RPL, nous r´eduisons en moyenne le nombre de changements de parent par deux. Nous voyons sur cette figure que, avec BD-RPL, les nœuds qui sont `a un saut de la racine r´eduisent de mani`ere significative leur changement de parents. Cela est dˆu au refus de potentiels nouveaux parents, les for¸cant `

Impl´ementation Configuration D´escription

Plateforme Iot-lab Con¸cue pour faire des exp´erimentation WSN `a large ´echelle

Nœuds WSN WSN430 Nœuds statiques

50 nœuds

Communication CC2420 Op`ere `a 2.4GHZ

radio

Radio 4GHZ Taux de v´erification du canal

toutes les 250 ms

Puissance de −1dBm Haute puissance de transmission

transmission Topologie dense

Trafic 1 paquet/2 min Paquet envoy´e et acquitt´e

Temps 3 heures R´ep´et´ee 6 fois

Figure 5.10 – Tableau r´esumant les choix de configuration pour l’exp´erimentation.

changements de parent n’est pas toujours un bon comportement pour les performances du protocole.

Figure 5.11 – Nombre moyen de changements de parent en fonction de la distance en nombre de sauts.

La Figure 5.12 repr´esente le nombre de changements de parent en fonction du temps. Nous faisons la mˆeme analyse que pour le taux moyen de changements de parent en fonction du nombre de sauts. Nous faisons remarquer en plus que plus nous avan¸cons dans l’exp´erimentation, plus le nombre de changements de parents pour BD-RPL est r´eduit par rapport `a RPL.

R´esultats sur la consommation d’´energie

La Figure 5.13 repr´esente l’´energie consomm´ee par les nœuds pour envoyer et recevoir des paquets en fonction de la distance en sauts jusqu’`a la racine pour RPL et BD-RPL. Dans l’exp´erimentation, la consommation d’´energie est 10 fois plus ´elev´ee que dans la simu-lation pour RPL et BD-RPL. En outre, comme cela a d´ej`a ´et´e montr´e dans la Figure 5.13, la consommation d’´energie dans BD-RPL est r´eduite d’un facteur 2 par rapport `a RPL. On remarque que les nœuds pr`es de la racine r´eduisent leur consommation ´energ´etique `a

98 CHAPITRE 5. PROTOCOLE RPL `A DEGR ´E BORN ´E 0 20 40 60 80 100 120 140 160 180 Time [min] 0 500 1000 1500 2000 2500

Nombre de changements de parent

RPL

BD-RPL

Figure 5.12 – Nombre de changements de parent en fonction du temps.

l’´ecoute parce qu’ils ont moins d’enfants `a g´erer. La consommation d’´energie dans la phase d’´emission est elle aussi r´eduite car il y a moins de collisions entre les messages transmis au parent. Hop 1 2 3 4 Energy consumption [mJ] 0 2000 4000 6000 8000 10000 12000 14000 16000 RPL radio transmit BD-RPL radio transmit

(a) ´Energie radio `a la transmission.

Hop 1 2 3 4 Energy consumption [mJ] 0 5000 10000 15000 RPL radio receive BD-RPL radio receive

(b) ´Energie radio `a la r´eception.

Figure 5.13 – Consommation de l’´energie radio en fonction du nombre de sauts.

R´esultats pour le d´elai de transmission

La Figure 5.14 repr´esente le d´elai moyen de transmission de bout en bout en fonction de la distance en sauts jusqu’`a la racine pour RPL et BD-RPL. Cette figure montre que,

comme avec la simulation, BD-RPL r´eduit le d´elai de bout en bout par rapport `a RPL. Cet effet est plus ´evident pour les nœuds qui sont proches de la racine, car ils ont moins d’enfants `a g´erer et les paquets sont envoy´es sans d´elai d’attente suppl´ementaire.

Hop 1 2 3 4 End-to-end Delay [s] 0 0.5 1 1.5 2 2.5 3 RPL BD-RPL

Figure 5.14 – D´elai de transmission en fonction du nombre de sauts.

R´esultats pour le taux de d´elivrance de paquets

Les r´esultats dans la Figure 5.15 montrent qu’en exp´erimentations, nous am´eliorions le rapport de taux de d´elivrance de paquets ascendants. Ce qui est encore plus important que dans les simulations puisque l’am´elioration est d’environ 10%. Cependant, nous re-connaissons que la perte de paquets dans des exp´erimentations r´eelles est plus importante que la perte de paquets en simulations en raison d’interf´erences du monde ext´erieur qui ne peuvent ˆetre captur´ees par des simulations.

Figure 5.15 – Taux de d´elivrance de paquets en fonction du nombre de sauts.

La Figure 5.16 repr´esente le taux de d´elivrance de paquets en fonction du temps d’exp´erimentation pour RPL et BD-RPL. Nous remarquons dans cette figure que le taux de d´elivrance de paquets est pratiquement similaire en d´ebut d’exp´erimentation. Ensuite, l’´ecart se confirme avec le temps d’exp´erimentation.

100 CHAPITRE 5. PROTOCOLE RPL `A DEGR ´E BORN ´E 0 20 40 60 80 100 120 140 160 180 Time [min] 0 10 20 30 40 50 60 70 80 90 100

Packet Reception Rate upward %

reception upward versus time

RPL RPL bounded

Figure 5.16 – Taux de d´elivrance de paquets en fonction du temps.

5.5 Conclusion

Dans ce chapitre, nous avons propos´e un nouveau protocole : BD-RPL, une solution pour am´eliorer le protocole RPL. Le protocole BD-RPL consid`ere l’instabilit´e des routes dans les r´eseaux LLN en introduisant une borne sur le nombre maximum d’enfants qu’un nœud peut accepter pendant la construction de l’arbre. De plus, BD-RPL traite l’absence de mise `a jour sur les routes descendantes. En particulier, nous utilisons les messages de contrˆole existants fournis par RPL pour limiter le degr´e des nœuds et pour mettre `a jour les routes descendantes. Par cons´equent, BD-RPL ajoute un taux de messages de contrˆole marginal par rapport `a RPL. Nous avons ´evalu´e BD-RPL en utilisant `a la fois le simulateur Cooja et la plate-forme Iot-lab. Les simulations et les exp´erimentations ont prouv´e une am´elioration par rapport `a RPL d’une moyenne de 10% dans le taux de d´elivrance de paquets, de 50% dans la consommation ´energ´etique et de 60% en d´elai de transmission.

Ce travail met en ´evidence la question suivante. Nous avons vu l’absence de m´ecanisme de synchronisation de la communication entre les noeuds au niveau de la couche MAC (puisque nous utilisons la IEEE 802.15.4 non synchronis´ee). D’autre part, il est bien connu que dans un r´eseau de capteurs, les performances d’un protocole de routage d´ependent `a la fois de la couche r´eseau et de la couche MAC. Une perspective naturelle de ce travail serait donc une solution inter-couches entre la couche MAC et la couche r´eseau (ContikiMAC et RPL) afin d’introduire un m´ecanisme pour organiser la transmission des donn´ees des enfants vers leurs parents et par cons´equent r´eduire les collisions et l’´energie consomm´ee. Une fa¸con de faire serait d’utiliser le mˆeme m´ecanisme que notre solution BD-RPL en ajoutant de la synchronisation.

Conclusion

La quantit´e de donn´ees ´echang´ees dans les r´eseaux d’aujourd’hui, la diversit´e des ob-jets qui y sont connect´es (ordinateurs, tablettes, t´el´ephones, robots, capteurs ou tout objet connect´e) et la grande taille des r´eseaux sont autant de raisons qui conduisent naturelle-ment `a des ´etudes sur les protocoles de routage auto-stabilisants. D’autant plus que ces protocoles de routages sont devenus de plus en plus exigeants : support de la dynamicit´e, faible consommation ´energ´etique, passage `a l’´echelle, etc.

Les caract´eristiques des r´eseaux de capteurs sont une faible port´ee de communication, une puissance de calcul limit´ee, une faible capacit´e de m´emoire de stockage, et le plus souvent une batterie `a dur´ee de vie limit´ee. Les caract´eristiques physiques intrins`eques de ces r´eseaux conduisent `a de forts changements de topologie (disparition des capteurs, variabilit´e des liens radio) du r´eseau et ceci tout au long de la dur´ee de vie de ce r´eseau. Ces changements de topologie peuvent entrainer des pertes d’informations.

C’est pourquoi L’auto-stabilisation [Dij74] est l’une des techniques adapt´ee pour main-tenir la disponibilit´e des applications r´eseaux distribu´ees, leur fiabilit´e et leur maintenance. Apr`es l’apparition d’une d´efaillance qui a plac´e les composants du r´eseau dans un ´etat glo-bal arbitraire, l’auto-stabilisation garantit la r´ecup´eration vers un comportement l´egitime en un temps fini sans aucune intervention ext´erieure.

Dans ce contexte, une tˆache essentielle du r´eseau est de r´ecup´erer des communica-tions efficaces. Une fa¸con naturelle pour faire face `a ce probl`eme consiste `a construire un arbre couvrant le r´eseau et d’acheminer les messages entre les nœuds grˆace `a cette struc-ture, qui a l’avantage de fournir une et une seule route entre n’importe quelle paire de nœuds du r´eseau. Dans un r´eseau, il n’existe pas un unique arbre couvrant. En fonction des contraintes environnementales, l’arbre couvrant propos´e peut optimiser des m´etrique diff´erentes. Il existe ainsi, autant de protocoles de construction d’arbres couvrants sous-contraintes que d’arbres couvrants optimisant une certaine m´etrique.

Pour cette raison, il est non seulement important de construire des protocoles de rou-tages qui prennent en compte les exigences de tels r´eseaux mais aussi de construire des algorithmes auto-stabilisants qui minimisent l’utilisation de la m´emoire et qui garantissent une convergence rapide de la structure couvrante. Cette th`ese a propos´e deux contributions dans ce cadre.

102 CHAPITRE 6. CONCLUSION