1. No category

R´
eparation locale
sur des r´
eseaux de capteurs
Julien Coutinho
Rapport pr´esent´e dans le cadre de
l’Introduction a` la Recherche en Laboratoire
Tuteur en laboratoire :
Martin Heusse
[email protected]
´
Equipe
Drakkar
Laboratoire Informatique
de Grenoble
Responsable `
a l’´
ecole :
Marie-Paule Cani
[email protected]
Mai 2015
Remerciements
Je tiens a` remercier tout particuli`erement Martin Heusse et Henry-Joseph Aud´eoud
qui travaillent sur LRP et qui m’ont beaucoup aid´e durant mon IRL. N’ayant pas
suivi de formation plus pouss´e en r´eseau, beaucoup de concepts connus de la majorit´e des personnes dans le domaine m’´etaient inconnus (comme les protocoles de
r´ef´erences et leurs fonctionnement). Grˆace a` leurs connaissances et leurs disponibilit´es, j’ai pu comprendre les contraintes qui s’appliquent dans les r´eseaux de capteurs
et les solutions existantes. Je tiens aussi a` leur dire merci pour leur patience et le
temps qu’ils m’ont accord´e, durant leur travail et aussi pendant leur temps personnel.
Je souhaite aussi dire merci `a l’ensemble des personnes que j’ai pu cˆotoyer, qui
m’ont aid´e, conseill´e et avec qui j’ai ´echang´e sur des domaines tr`es int´eressants de
la recherche, `a savoir Baptiste Jonglez et Bernard Tourancheau.
Table des mati`
eres
1 Introduction
1
2 RPL
3
2.1
Cr´eation de l’arbre . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Envoi de paquets . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.3
Correction des liens . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.4
Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3 LOADng
7
4 TORA
9
4.1
Cr´eation de l’arbre . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
4.2
R´eparation de l’arbre . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
4.3
Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5 LRP
5.1
5.2
11
Fonctionnement normal . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1
Cr´eation de l’arbre . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.2
Envoi et r´eception d’un paquet . . . . . . . . . . . . . . . . . 12
Correction d’un lien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.1
Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.2
Simulations – R´esultat de mon travail . . . . . . . . . . . . . . 14
6 Conclusion
Bibliographie
19
21
Chapitre 1
Introduction
Depuis des ann´ees, les ´evolutions en ´electroniques ont permis de cr´eer des composants de plus en plus petits. Cela a permis de passer des ordinateurs fixes, aux
ordinateurs portables, puis aux notebooks et enfin aux smart-phones. A chacune
de ces pouss´ees technologiques, il a fallu adapter nos syst`emes de communications
(Wifi, 4G...) et bien que nous ayons des protocoles performants pour ces dispositifs,
des chercheurs continuent a` les perfectionner.
R´ecemment, bien que peu connus du grand public, de plus en plus les r´eseaux
de capteurs int´eressent les secteurs public comme priv´e. La recherche s’est pench´ee
sur le probl`eme, et des technologies se mettent en place, mˆeme si une grande partie
du travail reste encore a` faire. Cependant, un seul protocole ne peut pas convenir a`
toutes les utilisations, mais d´epend des contraintes inh´erentes au r´eseau lui-mˆeme.
Le protocole de routage distribu´e ´etudi´e durant mon travail s’int´eresse aux
r´eseaux qui sont :
— mobiles : les capteurs peuvent se d´eplacer au cours du temps ;
— a` multi-sauts : tous les capteurs ne sont pas reli´es directement au puits ;
— ad-hoc : ne n´ecessite pas une infrastructure pr´ealable (un capteur peut apparaˆıtre a` tout moment) ;
— sans-fil : les capteurs utilisent des ondes pour communiquer—pertes possibles ;
— a` faible puissance : la quantit´e d’´energie disponible est limit´ee.
Tous ces capteurs forment un arbre de collecte orient´e vers un sommet particulier,
appel´e le puits du r´eseau (sink ). Dans le cas ´etudi´e, l’arbre de collecte peut contenir
1
Chapitre 1. Introduction
2
plusieurs chemins vers le puits pour un mˆeme capteur. Il est appel´e graphe acyclique
orient´e vers une destination (en anglais DODAG : Destination-Oriented Directed
Acyclic Graphs).
Le protocole ´etudi´e, Lightweight Routing Protocol (LRP), s’inspire de protocoles
existants, a` savoir RPL 1 [1], LOADng 2 [3], TORA 3 [2], que je d´etaillerai dans ce
rapport en expliquant leurs limites et les concepts r´eutilis´es. Pour finir, j’expliquerai
les tests r´ealis´es comme preuve de concept et les r´esultats ainsi obtenus.
1. IPv6 Routing Protocol for Low-Power and Lossy Networks
2. Routing Protocol for Low-Power and Lossy Networks et The Lightweight On-demand Ad
hoc Distance-vector Routing Protocol - Next Generation
3. Temporally-Ordered Routing Algorithm
16 mai 2015
Chapitre 2
RPL
Dans ce chapitre, nous allons expliquer le fonctionnement de RPL. Ce protocole
a ´et´e d´evelopp´e pour des r´eseaux de capteurs mobiles, qui ont une ´energie limit´ee
(batterie) et qui ont un taux de pertes de paquets relativement ´elev´e. De plus, les
connexions sont instables, les liens entre les noeuds peuvent beaucoup changer. Donc
pour ´eviter que des boucles de routages ne se forment, RPL associe a` chaque noeud
un rang qui correspond `a la distance virtuelle de ce dernier au puits.
2.1
Cr´
eation de l’arbre
Comme tout protocole de communication, lors de l’envoi d’un paquet, il faut
que l’´emetteur sache `a qui envoyer son paquet. Dans le cas de RPL, le r´eseau forme
un arbre de collecte. Chaque noeud s’associe a` un successeur pr´ef´er´e (le prochain
saut—next hop), qui lui aussi a un successeur pr´ef´er´e, ainsi de suite, jusqu’`a arriver
au puits. Cependant, a priori, un successeur ne connaˆıt pas ses pr´ed´ecesseurs.
Pour ajouter un nouveau noeud au DODAG, le puits demande p´eriodiquement
a` tous noeuds d’envoyer un DODAG Information Object (DIO). D`es que le nouveau
noeud re¸coit un DIO, il analyse les informations de ce paquet. C’est-`a-dire notamment, le rang de l’´emetteur, la fonction objectif a` utiliser et l’identifiant du DODAG
construit. Il est donc possible qu’un noeud re¸coive plusieurs DIO. Cependant, le
r´eseau doit former un arbre de collecte. Il faut donc qu’il choisisse un noeud qui
minimise la fonction objectif. C’est `a cela que sert le rang de chaque noeud. Dans
3
2.2. Envoi de paquets
4
le cas o`
u la fonction objectif fournie est la distance au puits, un noeud va choisir
comme successeur pr´ef´er´e le noeud qui lui aura fourni un rang minimal. Parmi tous
les successeurs possibles, un seul va minimiser la fonction objectif, mais les autres
successeurs sont aussi gard´es. RPL consid`ere que tous les successeursont le mˆeme
rˆole et peuvent mˆeme ˆetre utilis´es simultan´ement.
Un noeud peut aussi solliciter l’envoi d’un DIO, par l’envoi en broadcast d’un
DODAG Information Solicitation (DIS). De cette fa¸con, un noeud, qui souhaiterait
se rattacher `a l’arbre, n’a pas a` attendre l’envoi d’un DIO (qui peut ˆetre plus ou
moins long, comme sa dur´ee augmente quand l’arbre ne change pas de topologie
pendant longtemps).
Pour ˆetre plus polyvalent (ˆetre applicable sur plus de r´eseaux), RPL permet
de choisir d’autres fonctions objectif. Comme par exemple, optimiser le graphe de
fa¸con `a ce qu’un noeud privil´egie ses communications avec le successeur qui a le plus
d’´energie r´esiduelle, peu importe si le chemin devient plus long. Cette fonction objectif permet de faire tenir plus longtemps certains capteurs qui seraient surcharg´es
(trop de pr´ed´ecesseurs) ou qui seraient tout simplement plus vieux.
2.2
Envoi de paquets
Tout d’abord, il est facile de se rendre compte de la fa¸con dont un noeud peut
communiquer avec le puits. Il transfert a` son successeur son paquet, qui remonte de
pr´ed´ecesseur en successeur jusqu’au puits. Dans ce cas, il n’y a pas de soucis et peu
de paquets sont envoy´es, ce qui n’utilise pas beaucoup d’´energie.
Par contre, concernant l’envoi de paquets a` partir d’un noeud vers un de ses
pr´ed´ecesseurs (direct ou non), le d´eroulement est plus compliqu´e et moins optimis´e.
Tout d’abord, RPL a deux modes, l’un o`
u les messages vers le bas sont autoris´es
et l’autre non. Si les messages descendants sont autoris´es, RPL a mis en place encore
deux autres modes.
Un premier mode o`
u chaque noeud peut contenir suffisamment d’entr´ees dans sa
table de routage pour se rappeler de l’adresse de tous ses pr´ed´ecesseurs. Pour que
tous les noeuds connaissent leurs pr´ed´ecesseurs, il faut que ces derniers envoient un
16 mai 2015
2.3. Correction des liens
5
paquet DAO (Destination Advertisement Object) a` destination du puits. A chaque
r´eception d’un DAO, la table de routage est mise `a jour. Cependant, dans ce mode,
si une table de routage est remplie, tous les noeuds qui viendraient a` se rajouter, endessous de ce noeud, seraient impossible a` atteindre (ce point devrait ˆetre am´elior´e
dans le futur d’apr`es la RFC sur RPL).
Dans l’autre mode de communication vers le bas, le puits se charge de sauvegarder toutes les tables de routage. A priori, ce dernier est moins limit´e et peut
conserver toutes les entr´ees.
Et enfin, il est impossible de m´elanger le mode o`
u chaque noeud a une table de
routage et celui o`
u le puits a toutes les entr´ees dans sa table de routage.
2.3
Correction des liens
Une fois le DODAG en place, chaque noeud continue d’envoyer de fa¸con p´eriodique
des DIOs (algorithme trickle, initi´e par le puits). Si un noeud re¸coit des informations
des autres DIOs qui sont synchronis´ees avec les siennes, par rapport a` ses informations de routage qu’il a d´ej`a, alors il double sa p´eriode d’envoi. Si par contre, les
informations sont d´esynchronis´ees (par exemple si son successeur change de rang),
alors ce noeud r´einitialise sa p´eriode d’envoi a` son minimum.
Cette correction consomme beaucoup, car les DIOs sont en broadcast, ce qui
coˆ
ute le plus en terme d’´energie utilis´ee. Avec une simulation sous ContikiMAC [6],
un broadcast coˆ
ute 7 fois plus que les autres envois (sauf pour le premier unicast).
Le protocole est aussi agressif dans le but de converger le plus vite possible. En
effet, l’arbre bien qu’il change souvent, ne change pas de topologie tout le temps.
Cependant, lorsqu’un noeud change de rang, tous ses pr´ed´ecesseurs vont re-´emettre
en mˆeme temps, leurs messages risquent d’entrer en collision et donc de devenir
incompr´ehensibles pour les noeuds qui sont a` leurs port´ees. Pour la mˆeme raison,
les capteurs peuvent, apr`es plusieurs ´echecs cons´ecutifs, abandonner l’envoi d’un
paquet.
Pour choisir son prochain successeur (apr`es la perte de l’ancien), un noeud peut
choisir un noeud avec un rang inf´erieur au sien. Cependant, il ne peut pas choisir un
16 mai 2015
2.4. Bilan
6
noeud qui a un rang sup´erieur au sien de MaxRankIncrease. Ce noeud risque donc
de choisir un de ses pr´ed´ecesseurs comme successeur. Cela risque donc de cr´eer une
boucle. Pour d´etecter cette boucle, les noeuds, incr´ementant leurs rangs d`es qu’ils
choisissent un pr´ed´ecesseur comme successeur, vont atteindre INFINITE RANK et
le premier a` l’atteindre va informer ses pr´ed´ecesseurs qu’il est d´etach´e de l’arbre.
Donc, aucun autre noeud ne le choisira comme successeur.
2.4
Bilan
Ce que nous pouvons retenir de RPL est la construction de l’arbre, qui permet
de choisir une m´etrique optimale pour diff´erents arbres et aussi de pr´evenir la formation de boucles. Concernant leur proc´ed´e pour communiquer de fa¸con descendante
dans l’arbre, nous ne retiendrons que le mode o`
u une table de routage limit´ee est
plac´ee dans chaque noeud. La solution o`
u le puits contient toutes les informations
de l’arbre n’est pas convenable en terme de communication. Chaque noeud devrait
faire remonter les informations concernant son pr´ed´ecesseur au puits. De plus, ce
mode n´ecessite l’encapsulation des paquets IP, ce qui augmente leurs tailles, alors
que dans ce type de r´eseaux le MTU (Maximum Transmission Unit) est limit´e.
L’envoi de DIO p´eriodique est aussi int´eressant, cela permet de prendre en
consid´eration les modifications de la topologie.
Pour la correction des liens, le fait de choisir un noeud en-dessous de soit peut
cr´eer des boucles. Il peut ˆetre int´eressant de prendre un MaxRankIncrease nul pour
pr´evenir la cr´eation de boucles de routage et d’avoir a` les corriger.
16 mai 2015
Chapitre 3
LOADng
Contrairement `a RPL, LOADng ne met pas en place de DODAG. A chaque
instant, si un noeud a besoin d’envoyer un paquet `a un autre noeud, il inonde
le r´eseau a` sa recherche. Le noeud ´emetteur envoie un Route Request (RREQ) en
broadcast autour de lui `a destination du noeud destinataire. Les noeuds qui re¸coivent
le RREQ, s’ils ne sont pas le noeud destinataire, vont `a leur tour envoyer `a tout
le monde autour d’eux ce RREQ. Si un noeud re¸coit plusieurs fois un RREQ pour
une mˆeme destination, il va analyser la m´etrique de chaque RREQ et choisir comme
route par d´efaut le noeud qui lui a fourni la m´etrique la plus petite (algorithme de
Bellman-Ford). Cependant, chaque noeud retient quand mˆeme une entr´ee pour la
source du paquet re¸cu.
Une fois que le message est arriv´e a` destination. Le noeud concern´e renvoie un
Route Reply (RREP) a` destination du noeud ´emetteur, en passant par le chemin
´etabli lors du RREQ.
Ce protocole est tr`es coˆ
uteux, car il ´emet toujours des broadcasts pour trouver
une route. Cependant, il fonctionne bien pour des r´eseaux avec peu de destinations
ou beaucoup mais qui bougent peu. En effet, un chemin bi-directionnel, `a direction de
tous les noeuds du r´eseau, n’est ´etabli que s’il y a du trafic. La route ainsi d´ecouverte
est maintenue tant qu’il y a des donn´ees envoy´ees par celle-ci. Un contrˆole du trafic
permet de r´eparer l’arbre seulement quand une nouvelle route est n´ecessaire ou
quand une route est perdue. Il n’y a donc pas besoin d’envois p´eriodiques.
Pour un DODAG, nous n’avons pas besoin de ce protocole pour communiquer
7
Chapitre 3. LOADng
8
d’un noeud jusqu’au puits. Cependant, pour communiquer du puits a` un noeud
de l’arbre cette solution, bien que tr`es gourmande, est n´ecessaire, comme il est
impossible de stocker toutes les entr´ees dans chaque noeud.
16 mai 2015
Chapitre 4
TORA
Nous allons maintenant voir comment fonctionne TORA et ses limites. Ce protocole, `a l’instar de RPL, cherche a` former un DODAG.
4.1
Cr´
eation de l’arbre
Un noeud, nouveau dans le r´eseau, doit ´emettre un paquet Query (QRY) en
broadcast, pour signaler aux noeuds voisins qu’il cherche a` se joindre au DODAG.
Les noeuds autour propagent le QRY, s’ils ne font pas partie du DODAG eux-aussi.
Une fois qu’un noeud qui fait partie du DODAG re¸coit un QRY, il r´epond au
noeud qui l’a sollicit´e avec un Update (UPD). Ce paquet contient la distance du
paquet ´emetteur au puits. Ainsi, si un noeud re¸coit plusieurs UPD, il peut, comme
pour l’algorithme de Bellman-Ford, changer de noeud pr´ed´ecesseur pour optimiser
sa route jusqu’au puits.
Apr`es avoir mis a` jour ses informations de routages et sa distance jusqu’au puits,
ce noeud renvoie un UPD en r´eponse au QRY qu’il avait re¸cu. Ainsi de suite, jusqu’au
noeud qui avait fait la requˆete de QRY en premier.
4.2
R´
eparation de l’arbre
La partie la plus importante de ce protocole, pour nous, est la r´eparation des
liens cass´es.
9
4.3. Bilan
10
TORA distingue 3 cas de liens cass´es.
Le premier concerne les liens qui ne changent rien au graphe. En effet, si un lien
est cass´e, mais que le noeud qui n’a plus de successeur a un autre noeud parmi ses
successeurs possibles, alors il va se contenter de le prendre comme next hop.
Le deuxi`eme cas se produit quand un noeud n’a plus d’autres successeurs possibles comme next hop. Dans ce cas, le noeud va d´etecter qu’il n’a que des arˆetes
entrantes, ce qui n’est pas normal comme il n’est pas le puits. Il va donc inverser ses
arˆetes, mettre sa distance jusqu’au puits ´egale a` 0 et envoyer un UPD `a ses nouveaux
pr´ed´ecesseurs. Chaque pr´ed´ecesseur va en faire de mˆeme (sauf pour l’arˆete qui le lie
a` son ancien successeur) et d´ecr´ementer la distance re¸cue de son ancien successeur.
Ce processus va donc s’arrˆeter quand un noeud, dont l’arˆete aura ´et´e invers´ee, est
reli´e au DODAG, ce dernier ne va pas changer sa m´etrique.
Dans le troisi`eme cas, si un lien cass´e isole une partie du graphe (le graphe n’est
plus connexe), alors une boucle est d´etect´ee dans l’envoi des UPD (les arˆetes sont
invers´ees sans arrˆet). Le noeud qui se sera rendu compte du probl`eme (bit reflect),
va arrˆeter de chercher `a r´eparer le graphe, comme cela est impossible, et va envoyer
un paquet Clear (CLR), qui se propagera au reste du graphe connexe d´etach´e du
reste. Un paquet CLR a pour but de supprimer le noeud ´emetteur dans la table
des routages des noeuds le recevant. Le protocole ne se remet pas en route, a` moins
qu’un des noeuds isol´es ait besoin d’´emettre un paquet.
4.3
Bilan
Pour TORA, ce sont toujours les nouveaux noeuds qui sollicitent les autres
noeuds du DODAG pour le rejoindre. Contrairement `a RPL o`
u les nouveaux noeuds
peuvent ˆetre sollicit´es par des noeuds d´ej`a pr´esents dans le DODAG.
La r´eparation locale du DODAG est aussi tr`es int´eressante, car elle limite l’envoi
de broadcasts. Le seul probl`eme de ce protocole est qu’il ne fonctionne plus dans le
cas o`
u un UPD, envoy´e lors du renversement d’une arˆete, est perdu. Dans ce cas, les
deux noeuds vont se prendre mutuellement comme successeur et les paquets vont
boucler.
16 mai 2015
Chapitre 5
LRP
Pour finir, nous allons voir comment les pr´ec´edents algorithmes ont ´et´e repris
et combin´es pour donner le Lightweight Routing Protocol (LRP), sur lequel j’ai
travaill´e.
5.1
Fonctionnement normal
Pour commencer, voyons le d´eroulement normal du protocole, c’est-`a-dire qu’aucun lien ne casse.
5.1.1
Cr´
eation de l’arbre
D`es son arriv´ee, un noeud se comporte comme le protocole TORA le d´efinit, ou
encore RPL avec les DIS. Il va envoyer un paquet Query (QRY) en broadcast, pour
signaler aux noeuds autour de lui qu’il souhaite rejoindre le DODAG. Les noeuds a`
port´ee vont r´epondre avec un DIO, ce paquet contient des informations semblable
a` celles contenues dans un paquet DIO de RPL. Et de la mˆeme fa¸con que RPL, le
noeud recevant plusieurs DIO choisit l’ensemble des noeuds qui peuvent ˆetre son
next hop et les stocke, cela correspond `a l’algorithme de Bellman-Ford distribu´e. Et
au fur et a` mesure que les DIOs sont re¸cus, il met a` jour son next hop. Si un DIO
re¸cu l’informe que le noeud, qui le lui a envoy´e, est un meilleur next hop que le next
hop courant, alors c’est ce dernier qui va devenir son pr´ed´ecesseur pr´ef´er´e. A noter
qu’un noeud choisit parmi les DIO disponibles, ceux qui ont le mˆeme num´ero de
11
5.1. Fonctionnement normal
12
s´equence d’arbre que lui, un num´ero de s´equence de noeud sup´erieur au sien et, si
´egal, une meilleure m´etrique que la sienne ou un plus petit nombre de saut que le
sien pour finir.
Pour la mise `a jour de l’arbre, une fois la topologie ´etablie, chaque noeud envoie
de fa¸con p´eriodique un DIO, pour informer ses voisins d’un possible changement de
topologie.
5.1.2
Envoi et r´
eception d’un paquet
L’envoi vers le puits de paquet est identique a` RPL. Il suffit qu’un noeud envoie
son paquet a` son successeur, qui lui aussi l’enverra a` son successeur. Ainsi de suite,
le paquet arrivera au puits.
Concernant l’envoi de paquet du puits a` un autre noeud, nous diff´erencions deux
cas.
Le premier cas se r´ealise quand le puits cherche a` envoyer un paquet `a un autre
noeud qui ne lui avait pas envoy´e de message auparavant. A ce moment, le protocole
se comporte comme LOADng, un message de Route Request (RREQ) inonde tout
l’arbre `a la recherche de la destination. D`es que la cible est atteinte, elle r´epond
avec un Route Reply et tous les noeuds en chemin mettent `a jour leur table de
routage pour se rappeler du chemin `a suivre pour atteindre la destination, que le
puits veut joindre. Une fois la route ´etablie, le puits renvoie un RACK pour acquitter
la r´eception du RREP.
Dans le deuxi`eme cas, un noeud peut envoyer des paquets `a destination du puits
sans que cela ne lui ait ´et´e demand´e. Avant de commencer a` transmettre, il envoie
un RREP `a destination du puits. C’est ce RREP qui permet aux noeuds en chemin
de savoir qu’ils doivent se rappeler du chemin vers le noeud source du trafic, en cas
de r´eponse. Ensuite, l’envoi se passe comme vu pr´ec´edemment, de pr´ed´ecesseur en
successeur . Ainsi, si le puits doit r´epondre a` ce paquet, il sait par o`
u passer et il n’y
a pas plus de travail. A savoir que comme pour RPL si l’entr´ee est ´ecras´ee, alors le
message ne sera pas d´elivr´e `a son destinataire. Dans ce cas le noeud interm´ediaire,
qui ne contient plus l’entr´ee dans sa table de routage et qui ne sait donc pas quoi
faire du paquet, va renvoyer un paquet RERR pour informer de l’´echec de l’envoi.
16 mai 2015
5.2. Correction d’un lien
13
Un paquet peut aussi ˆetre perdu, si l’arbre a chang´e de topologie, c’est-`a-dire que le
noeud s’est rattach´e ailleurs et n’est plus atteignable par son ancien successeur.
5.2
Correction d’un lien
Mon travail au laboratoire ´etait concentr´e sur ce point du protocole. Apr`es que
plusieurs liens de l’arbre aient cass´es, la r´eparation est-elle performante ? L’indice
de performance ´etudi´e ici est le nombre d’inversions produites.
5.2.1
Fonctionnement
La r´eparation est en deux phases QRY puis BRK. D’abord le noeud essaye de
trouver un nouveau successeur `a qui se relier, sinon il demande a` ses pr´ed´ecesseurs
de trouver un chemin.
Lorsqu’un noeud perd le lien qu’il a avec son successeur, il envoie en broadcast
un paquet QRY. Si parmi les DIOs re¸cus, une r´eponse vient d’un noeud avec un
num´ero de s´equence sup´erieur ou ´egal au sien, alors il le prend comme successeur
automatiquement.
Cependant, il n’y a pas forc´ement un autre noeud qui n’est pas potentiellement
son successeur, c’est-`a-dire qu’il ignore l’identit´e des noeuds de son sous-arbre. Apr`es
un certaine dur´ee, si aucun DIO ne lui convient, il envoie en broadcast, un message
Break (BRK), qui sera trait´e diff´eremment selon si le r´ecepteur est un successeur
de l’´emetteur ou non. Le message BRK permet d’informer les pr´ed´ecesseurs d’un
noeud qu’il ne trouve pas de chemin jusqu’au puits. Ainsi, chaque pr´ed´ecesseur
envoie en broadcast un BRK. Quand un noeud re¸coit un BRK qui ne vient pas de
son successeur, il le place dans son cache. A la r´eception d’un autre BRK qui a une
meilleure m´etrique ou un plus petit nombre de sauts (jusqu’au noeud d´econnect´e),
il remplace le BRK en cache par celui qu’il vient de recevoir.
Apr`es la r´eception d’un BRK qui ne vient pas de son successeur, un noeud va
envoyer, en direction du puits, le BRK qu’il a re¸cu. En effet, s’il ne vient pas de son
successeur, il va donc consid´erer que le BRK provient d’un noeud faisant partie du
sous-arbre d´etach´e et va donc essayer qu’il se rattache a` lui. Une fois que le puits
16 mai 2015
5.2. Correction d’un lien
14
l’a re¸cu, il r´epond en unicast (puisque tous les noeuds ont dans leur cache le BRK
qui rappelle le chemin `a suivre). Le puits r´epond avec un message Update (UPD),
qui incr´emente le num´ero de s´equence de chaque noeud en chemin. Cela permet
d’´eviter les boucles, de prendre un noeud qui se trouverait dans le sous-arbre comme
successeur.
Quand un noeud se rend compte que le UPD qu’il a re¸cu ne vient pas de son
pr´ed´ecesseur, il doit inverser son arˆete, car un plus court chemin jusqu’au puits vient
d’ˆetre trouv´e par un de ses pr´ed´ecesseurs. Pour cela, comme un noeud ne connaˆıt
pas ses pr´ed´ecesseurs, il lui suffit juste de changer de successeur apr`es avoir transmis
le UPD a` son ancien successeur, si ce n’est pas lui qui a propag´e le premier BRK.
5.2.2
Simulations – R´
esultat de mon travail
Mon travail a donc consist´e `a reprendre un programme ´ecrit en python par
Martin Heusse. Ce programme simulait le protocole de r´eparation locale d´ecrit cidessus et affichait les arbres avant et apr`es correction en utilisant igraph. Son objectif
est d’observer le fonctionnement de l’algorithme de r´eparation, principalement le
nombre d’inversions produites. Je n’ai que l´eg`erement modifi´e le code qui s’occupe
de cette partie.
Ce que j’ai mis au point, c’est tout le code de contrˆole, qui v´erifie que les arbre
form´es initialement et apr`es correction sont valides. Puis, sous forme de test unitaire,
qui fait varier les param`etres de la simulation, sauvegarde les arbres sous forme de
sch´ema et le bilan du test (principalement le nombre d’inversions).
Fonctionnement d’une simulation
Pour simuler l’algorithme de r´eparation locale de LRP, quelques simplifications
ont ´et´e r´ealis´ees. Il faut savoir que le syst`eme n’est pas simul´e dans son ensemble.
Par exemple, toute la gestion de tampons, de collisions de paquets... ne sont pas pris
en compte. L’envoi d’un paquet est r´ealis´e par l’ajout dans une liste d’une structure
repr´esentant un paquet. L’envoi est donc imm´ediat et sans perte. Il est important
de garder ces simplifications en m´emoire, car elles ne sont pas analys´es dans ce
rapport. Mon travail n’est qu’une preuve de concept, un premier jet, ayant pour but
16 mai 2015
5.2. Correction d’un lien
15
de voir si le principe de base de l’algorithme de r´eparation locale fonctionne dans
un environnement simplifi´e.
Voici les diff´erentes ´etapes d’une simulation :
1 - Tout d’abord, pour g´en´erer un arbre, il faut choisir (dans le code) un nombre
de noeuds initial, un rayon (port´ee des capteurs), une profondeur maximale pour les
noeuds et un nombre de noeuds a` supprimer.
2 - Une fois ces param`etres choisis, l’algorithme de Bellman-Ford est appliqu´e
une premi`ere fois pour cr´eer un arbre de collecte en direction d’un noeud.
3 - Un certains nombre de noeuds sont supprim´es de l’arbre, ce qui a pour
cons´equence d’isoler une ou plusieurs parties de l’arbre, qui n’est plus reli´e au puits.
4 - Finalement, l’algorithme d´ecrit dans la section pr´ec´edente est appliqu´e (envois
de paquets, r´eparation des liens...).
Cependant, a` chacune de ces ´etapes, comme les points sont plac´es al´eatoirement,
il est possible que des arbres ind´esirables soient g´en´er´es.
Validation d’un arbre g´
en´
er´
e
Tout au long de la simulation, diff´erents tests permettent d’arrˆeter la simulation
si l’arbre n’est pas satisfaisant. Ainsi, les tests unitaires tournent en boucle jusqu’`a
r´ealiser un nombre de simulation fix´e. D`es qu’un cas ind´esirable se produit, le programme de simulation va compter le nombre de fois que cette erreur se produit sur
un ensemble de simulations. Cela permet d’avoir un retour du le nombre d’erreurs
qui se sont produites sur l’ensemble des arbres g´en´er´es.
Un arbre est rejet´e s’il est :
— d´eg´en´er´e : l’arbre a` sa cr´eation n’est pas connexe ou est toujours connexe
apr`es suppression de certains noeuds ;
— trop profond : si un graphe d´epasse la profondeur maximale ;
— compos´e seulement de feuilles : apr`es suppression des noeuds, tous les noeuds
d´econnect´es sont des feuilles, cela ne peut donc pas produire d’inversions ;
— un ´echec : arbres dont aucune partie d´econnect´ee n’a pu ˆetre rattach´ee au
reste de l’arbre ;
Par exemple, voici la sortie d’une simulation de 1000 graphes :
16 mai 2015
5.2. Correction d’un lien
16
Time : 326.460144997
+Graphs : 15816
-Degenerates : 11422
-Only leafs : 3384
-Depth too high : 0
-Failures : 10
=Success : 1000
+Initial size : 40
-Nodes off : 3
=Real size : 37
Method radius : Distance between the two nodes lower than the radius.
Radius : 0.75
Inversions : 19
0 Inversion(s) : 983
1 Inversion(s) : 15
2 Inversion(s) : 2
Maximal depth : 8
Number of graph disconnected : 7
AVG degree : 10.163
16 mai 2015
5.2. Correction d’un lien
17
Analyse des simulations
Grˆace `a un test r´ealis´e en python, j’ai fait varier les param`etres du nombre de
noeuds, leurs rayons et la profondeur maximale. Le rayon a ´et´e vari´e de 0.5 `a 0.85
par pas de 0.5, le nombre de noeuds a pris les valeurs 20, 30 et 40, un nombre
constant de noeuds a ´et´e supprim´e (3) et la profondeur a pris les valeurs 4, 8 et 12.
Nous allons maintenant nous int´eresser `a ces r´esultats.
Pour commencer, dans 5.4 nous avons repr´esent´e le nombre moyen d’inversions
par graphe en fonction du rayon pour 17 (20 - 3 enlev´es), 27(30-3) et 37(40-3) noeuds.
Figure 5.1 – 17 Noeuds
Figure 5.2 – 27 Noeuds
Figure 5.3 – 37 Noeuds
Figure 5.4 – Nombre moyen d’inversions par graphe en fonction du rayon
Sur ces graphique 5.4, nous remarquons, qu’`a part les premi`eres valeurs du rayon
pour 17 noeuds, le nombre d’inversions par graphe d´ecroˆıt de fa¸con presque exponentielle plus le graphe est dense (nombre de noeuds et rayon grands).
Ce r´esultat s’explique par le fait que plus un graphe sera dense, plus les noeuds
auront la possibilit´e de se rattacher a` un autre noeud, qui a un rang inf´erieur au
´egal a` son ancien successeur. Il n’aura donc pas besoin de faire de BRK et donc il
n’y aura pas d’inversions.
Figure 5.5 – 17 Noeuds
Figure 5.6 – 27 Noeuds
Figure 5.7 – 37 Noeuds
Figure 5.8 – Nombre d’inversions en fonction du rayon
16 mai 2015
5.2. Correction d’un lien
18
Ces graphiques 5.8 mettent en ´evidence la forte majorit´e de graphes n’ayant
qu’une ou deux inversions. Cela est plutˆot encourageant quant a` l’efficacit´e de la
r´eparation locale de LRP. Cependant, cela ´etait pr´evisible. Dans la plus grande
partie des graphes g´en´er´es, les noeuds sont assez r´epartis dans l’espace 5.9. De cette
fa¸con, il est plus probable pour eux de trouver un autre chemin en 1 ou 2 inversion.
2
2
4
4
9
9
0
6
0
6
14
14
3
3
1
1
8
11
10
13
8
11
12
10
7
13
12
7
5
5
Figure 5.9 – Exemple d’un arbre r´epar´e
Nous remarquons sur cet exemple, figure 5.9, que l’arbre est d´ej`a tr`es favorable
au retournement d’arˆetes. Cependant, mˆeme dans ce cas il y a seulement deux
inversions. Sur les tests r´ealis´es, il y a tr`es peu de 4 ou 5 inversions, le r´eseau n’est
pas assez grand pour cela. Il faudrait r´ealiser des tests sur de plus grands nombres
de capteurs, avec un r´eseau moins dense (faible rayon ou plus grande surface). De
fa¸con, a` cr´eer des chaˆınes plus longues. Il faudra quand mˆeme s’assurer que ce n’est
pas trop exag´er´e, car en pratique les r´eseaux de capteurs ne sont pas toujours tr`es
grands, cela d´epend du r´eseau encore une fois.
Une limite de la simulation est la topologie des arbres. Les points sont toujours
plac´es de fa¸con al´eatoires. Or sur certaines topologies, nous pourrions remarquer un
grands nombre d’inversions et donc mettre en avant, ce qui pourrait ˆetre une limite
du protocole. Comme par exemple, une topologie sous forme de lignes parall`eles
(comme de longs couloirs qui ne se rejoignent que rarement. Lors de la perte d’un
lien dans un couloir, toutes les arˆetes s’inverseraient.
16 mai 2015
Chapitre 6
Conclusion
D’apr`es les r´esultats obtenus, le protocole LRP ne g´en`ere pas beaucoup d’inversions sur des graphes ayant la forme d’une ´etoile. Nous pouvons nous interroger sur
les r´esultats qu’il fournira sur certaines topologies (comme pour des benchmarks, des
topologies de r´eseau dans un immeuble...).
La r´eparation locale permet de ne g´en´erer que peu de trafic compar´e a` une
r´eparation globale de tout l’arbre. Seulement le sous-arbre d´econnect´e g´en`ere du
trafic en broadcast. Cela permet d’´economiser la batterie des noeuds qui n’ont pas
besoin de r´eparation. La propagation du BRK et sa r´eponse UPD ´etant en unicast,
le coup des communications que le sous-arbre fait supporter au reste est donc tr`es
faible.
Un autre point qu’il faudra prendre en compte, pour des simulations r´eelles (ce
sur quoi travaille Henry-Joseph Aud´eoud), est le nombre d’inversions au cours du
temps. Les simulations, r´ealis´ees durant mon IRL, ne suppriment que 3 noeuds, que
ce passe-t-il au bout d’un certains temps lorsque l’arbre subit plusieurs r´eparations ?
Une proposition des personnes qui travaillent dessus est de r´ealiser une r´eparation
globale avec une certaine fr´equence pour corriger certaines incoh´erences qui pourraient survenir (comme trickle).
Ayant travaill´e dessus durant mon IRL, je me suis rendu compte qu’il est tr`es difficile d’´evaluer l’efficacit´e d’un protocole en r´eseau. Beaucoup de param`etres entrent
en compte, comme le nombre de capteurs, leurs port´ees, la perte de paquets, la
topologie du r´eseau... Cependant, nous pouvons estimer que LRP a montr´e pour
19
Chapitre 6. Conclusion
20
l’instant de bon r´esultat concernant sa m´ethode de r´eparation locale.
16 mai 2015
Bibliographie
[1] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister,
R. Struik, J-P. Vasseur, et R. Alexander, RPL : IPv6 Routing Protocol for
Low-Power and Lossy Networks, RFC 6550 (Proposed Standard), Internet
Engineering Task Force, Mar. 2012. [Online].
Disponible : https://tools.ietf.org/html/rfc6550
[2] Vincent D. Park and M. Scott Corson (1997), A Highly Adaptive Distributed
Routing Algorithm for Mobile Wireless Networks
[3] T. Clausen. (2013) The Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng). Internet draft.
[4] Fabrice Th´eoleyre (2014), it The Lightweight On-demand Ad hoc Distancevector Routing Protocol - Next Generation (LOADng)
[5] Martin Heusse, Henry-Joseph Aud´eoud (2015), The Lightweight Routing Protocol
[6] A. Dunkels (2011), The contikimac radio duty cycling protocol, Technical Report 5128, Swedish Institute of Computer Science.
21