Traduit de Anglais vers Français - www.onlinedoctranslator.

com

Consultez les discussions, les statistiques et les profils des auteurs de cette publication sur :https://www.researchgate.net/publication/268691242

MRPL : Booster la mobilité dans l'Internet des objets

ArticledansRéseaux Ad Hoc · Mars 2015

DOI : 10.1016/j.adhoc.2014.10.009

CITATIONS LIT
128 1 175

3 auteurs, y compris:

Hossein Fotouhi Mario Alves

Université Malardalen Instituto Superior de Engenharia do Porto

64PUBLICATIONS793CITATIONS 134PUBLICATIONS3 870CITATIONS

VOIR LE PROFIL VOIR LE PROFIL

Certains des auteurs de cette publication travaillent également sur ces projets connexes :

Systèmes de capteurs intégrés pour Health Plus (ESS-H+)Voir le projet

E-care@home Voir le projet

Tout le contenu suivant cette page a été téléchargé parHossein Fotouhile 06 octobre 2017.

L'utilisateur a demandé l'amélioration du fichier téléchargé.

 mRPL : booster la mobilité dans l'Internet des objets

Hossein Fotouhi, Daniel Moreira et Mario Alves

Institut Polytechnique de Porto, CISTER/INESC-TEC, ISEP

Résumé

Le 6loWPAN (la version allégée d'IPv6) et le RPL (protocole de routage pour

power and lossy links) les protocoles sont devenusde factonormes pour l'Internet des

objets (IdO). Dans cet article, nous montrons que les deux algorithmes natifs

qui gèrent les changements dans la topologie du réseau - le Trickle and Neighbor Discovery

algorithmes–– se comportent de manière réactive et ne sont donc pas préparés

dynamique inhérente à la mobilité des nœuds. De nombreux scénarios d'application IoT

émergents et à venir devraient imposer des données mobiles fiables et en temps réel

collecte, qui ne sont pas compatibles avec la longue latence des messages, le paquet élevé

perte et surcoût élevés présentés par les protocoles natifs RPL/6loWPAN. À

résoudre ce problème, nous intégrons un mécanisme de transfert proactif (surnommé

smart-HOP) dans RPL, qui est très simple, efficace et rétrocompatible avec

le protocole standard. Nous montrons que cet add-on réduit de moitié la perte de paquets et re-

réduit considérablement le délai de transfert à un dixième de seconde, sur les nœuds

mobilité, avec un sous-pourcentage de frais généraux. L'algorithme smart-HOP a

été implémenté et intégré dans la pile Contiki 6LoWPAN/RPL (code source
disponible en ligne [1]) et validée par de nombreuses simulations et expérimentations.

tation.
Mots clés:Réseaux de capteurs sans fil, Internet des objets, Mobilité,
RPL, transfert, banc d'essai.

Adresse e-mail:(mohfg,dadrm,mjf)@isep.ipp.pt (Hossein Fotouhi, Daniel Moreira et Mario

Alves)

Prépublication soumise à Elsevier 12 novembre 2014

 1. Introduction

L'Internet de nouvelle génération, communément appeléInternet des objets(IdO),

dépeint un monde peuplé d'un nombre infini d'appareils intelligents capables de détecter,

de traiter, de réagir à l'environnement, de coopérer et d'intercommuniquer via

5 l'Internet. Depuis plus d'une décennie, la recherche sur les réseaux sans fil à faible puissance contestée

la complexité de l'architecture Internet pour les applications de réseaux de capteurs.

Cependant, au fur et à mesure que l'état de l'art progressait, les efforts académiques et commerciaux

ont inventé de nouvelles abstractions de réseau basées sur l'architecture Internet. LaDans-

Groupe de travail sur l'ingénierie du ternet(IETF) a conçu des protocoles et des adaptations

dix couches qui permettent à IPv6 de s'exécuter sur la couche de liaison IEEE 802.15.4. LaIPv6 sur

Réseaux personnels sans fil à faible consommation(6LoWPAN) groupe de travail [2] a

conçu la compression et la fragmentation d'en-tête pour IPv6 sur IEEE 802.15.4 [3].

L'IETFRoutage sur des réseaux à faible puissance et avec perte(ROLL) groupe de travail

a conçu un protocole de routage, appelé RPL [4], qui est lede factola norme
15 protocole de routage pour 6LoWPAN. Ces protocoles standard basés sur IP sont
donc un élément fondamental de l'IoT.
6LoWPAN en tant que couche d'adaptation est capable de prendre en charge le routage dans le lien

couche et la couche réseau [5, 6]. Deux schémas de routage de mesh-under et

Les routages sont conçus pour prendre en charge respectivement les routages de couche liaison et de

20 couche réseau. Dans une organisation maillée, la couche d'adaptation effectue le routage du maillage

et transmet les paquets à la destination via plusieurs sauts radio. Le maillage-

en cours de conception convient aux réseaux à saut unique, où tous les nœuds se trouvent dans le

portée de transmission les uns des autres. Dans un schéma de routage, la décision de routage est prise

au niveau de la couche réseau, où les nœuds agissent comme des routeurs IP. Chaque couche de lien

25 hop est un saut IP et le routage IP transfère les paquets entre ces liens. La
le routage par routage prend en charge une communication de routage maillé multi-sauts, adaptée

pour les déploiements à grande échelle.

La prise en charge de la mobilité devient une exigence dans diverses applications IdO émergentes.

cations [7, 8, 9], y compris la surveillance des soins de santé, l'automatisation industrielle et

30 réseaux intelligents [10, 11, 12]. De nombreux projets de recherche et études récents ont con-

2
 ont considéré la coopération entre les nœuds de capteurs mobiles et fixes [13, 14, 15, 16]. Dans la

surveillance clinique [17], les patients ont des dispositifs de détection sans fil intégrés

qui rapportent des données en temps réel. Dans les raffineries de pétrole, les signes vitaux des travailleurs sont

collectées en permanence afin de suivre leur situation sanitaire dans des

35 environnements [18]. En fait, de nombreuses applications nécessitent des garanties de rapidité et

de fiabilité pour transmettre les messages critiques de la source à la destination, mais

fournissantQualité de service(QoS) dans les réseaux de faible puissance et mobiles est très

difficile.
Dans ce travail, nous envisageons une application de surveillance clinique sans fil qui collecte

40 les signes vitaux des patients. Les patients sont des nœuds mobiles qui génèrent du trafic

fic et se déplacer librement tout en maintenant leur connectivité avec les nœuds fixes

Infrastructure. Tous les nœuds de notre modèle de système sont de simples nœuds de capteurs dotés

radio CC2420 basse consommation. La figure 1 illustre le modèle du système, où un MN se

déplace du voisinage du nœud 8 vers le nœud 7. Nous proposons un transfert

45 mécanisme qui détecte rapidement les entités mobiles et met à jour localement le routage

arbre.Le transfert est appelé le processus de commutation d'un MN d'un point de

attachement à un autre.Dans ce processus, le routage RPL standard s'exécute normalement tandis que

les nœuds mobiles exécutent un algorithme de transfert. Nous construisons la mobilité

activé RPL basé sur smart-HOP, qui est un mécanisme de transfert dur qui
50 a été conçu et testé dans une architecture de réseau générique, dans un environnement indépendant du protocole

façon [19, 20].

Deux mécanismes principaux sont employés dans RPL et 6LoWPAN qui

faire face à la mobilité. Premièrement, la transmission périodique de paquets de contrôle, programmés

par leFiletalgorithme, peut détecter les changements topologiques. Au cours de ce processus,

55 RPL reprend une mise à jour rapide du routage global qui entraîne une surcharge

élevée. Deuxièmement, leDécouverte du voisin(ND (défini dans la RFC 4861), évalue le

l'accessibilité des voisins de façon régulière. A chaque activation, le protocole ND

inonde l'ensemble du réseau avec des annonces de routeur, entraînant également une forte

aérien. Un intervalle d'activation court (qui réduit la surcharge) entraîne une faible

60 réactivité aux changements de réseau/topologiques. Cependant, dans le ND révisé

mécanisme de 6LoWPAN, les paquets d'annonce de routeur sont transmis sur

3
 1

2 3 Racine

4 6 PA
5
MN
sept 8

MN

Figure 1 : Un exemple d'avoir un nœud mobile dans un arbre RPL, où le MN se déplace du

voisinage dePA8versPAsept.

recevoir des messages de sollicitation de routeur [21].

Pourquoi smart-HOP? Le transfert a été largement étudié dans le domaine cellulaire et sans fil

réseaux locaux [22, 23, 24, 25]. Cependant, il n'a pas reçu le même niveau d'attention dans les

65 réseaux de faible puissance. Les réseaux cellulaires fonctionnent de manière centralisée

décisions de transfert généralement coordonnées par de puissantes stations de base. Contrairement à

Les réseaux cellulaires, les réseaux WiFi ont une architecture distribuée où la main-

off est déclenché lorsque la qualité du service se dégrade. Dans les réseaux de faible puissance,

une approche centralisée n'est pas possible car les points d'accès sont supposés avoir

70 ressources rares. smart-HOP [19, 20] considère les principales caractéristiques de la faible puissance

réseaux, le manque de fiabilité des liaisons et l'existence d'une seule radio de faible puissance

par nœud. Il gère les transferts de manière distribuée et conduit à des temps de

déconnexion très courts.

Pourquoi intégrer smart-HOP dans RPL? Il existe quatre fonctionnalités RPL principales qui

75 nous a motivés à lui accorder une aide à la mobilité : (i) le caractère proactif de RPL

qui génère et maintient des tables de routage stables. Une diffusion périodique de messages de

contrôle entre tous les nœuds maintient les chemins et les états de liaison entre

leur. Dans les protocoles de routage réactif ; comme AODV [26] et DSR [27], les routes

sont établis sur demande, de sorte qu'ils ne répondent pas rapidement aux
80 modifications dues à la mobilité ou à la dégradation de la liaison. RPL maintient l'itinéraire dans le

4
 arrière-plan avec un minimum de frais généraux. De plus, pour une application à

mobilité réduite et nécessitant une infrastructure, RPL est tout à fait adapté, (ii)

contrairement à d'autres protocoles de routage proactifs (par exemple OSPF [28]), RPL échange en local

informations entre voisins pour réparer les incohérences de routage, au lieu de

85 ally advertising control messages, (iii) RPL exécute une structure arborescente qui
convient aux applications WSN de collecte de données, et (iv) l'adresse IPv6-
ing en RPL effectue naturellement l'interopérabilité avec d'autres appareils Internet.

Contributions.En nous appuyant sur nos travaux précédents [19, 20], nous fournissons rapidement

et un support de mobilité fiable dans RPL. La solution de mobilité proposée conserve

90 le protocole RPL standard inchangé tout en offrant une rétrocompatibilité avec

l'implémentation standard, c'est-à-dire que les nœuds standard et compatibles smart-HOP peuvent

coexistent et interagissent dans le même réseau. Les principaux apports de ce

papier sont :

1. mécanisme de transfert efficace pour RPL avec de bonnes performances, délivrant

95 correctement près de 100 % des paquets avec un délai de transfert d'au plus 90 ms et

<1 % de surcharge supplémentaire sur la mobilité des nœuds dans les scénarios de trafic élevé ;

2. intégration fluide et rétrocompatibilité avec le RPL/6LoWPAN standard ;

3. mécanisme d'évitement des collisions (pour éviter les collisions pendant le transfert pro-

tout en collectant les paquets des points d'accès voisins) et un mécanisme d'évitement de boucle

100 (pour éviter les boucles fermées dans le routage RPL lors de la mobilité) ;

4. analyse de simulation (Cooja) et validation expérimentale avec des produits

plates-formes matérielles dans un environnement fiable ;

5. mise en œuvre sur un système d'exploitation SOTA (Contiki), pour lequel le

open source est disponible gratuitement [1].

105 Organisme.La section 2 explique les bases de RPL : les messages de contrôle,

la fonction objective et le processus pour maintenir les routes sur la dynamique des

liaisons. Un bref historique du mécanisme de transfert smart-HOP est présenté dans la Sec-

3. Ensuite, une image générale de la conception mRPL est décrite dans la section 4,

5
 qui est détaillée dans la section 51. La simulation et les montages expérimentaux, suivis des

110 résultats et de la discussion sont présentés dans les sections 6 et 7 respectivement.

activement. Nous catégorisons les travaux connexes sur la prise en charge de la mobilité en faible

réseaux électriques dans la section 8. Quelques comparaisons quantitatives entre mRPL

et les travaux connexes sont également fournis. Enfin, nous concluons le document et décrivons

les résultats les plus pertinents dans la section 9.

115 2. Aspects pertinents du protocole RPL

RPL est un protocole de routage à vecteur de distance IPv6 qui fonctionne au-dessus du

IEEE 802.15.4 couches physiques et de liaison de données et est approprié pour les

réseaux sans fil avec des ressources en énergie et en bande passante très limitées. Le débit de

données est généralement faible (moins de 250 kbps) et la communication est sujette à

120 des taux d'erreur élevés, entraînant un faible débit de données.

RPL organise les nœuds dans unGraphe acyclique orienté vers la destination(DODAG),

illustré à la figure 1. Chaque routeur RPL identifie un ensemble de parents stables, dont

chacun est un saut suivant potentiel sur un chemin vers la « racine » du DODAG. La

le parent préféré est généralement sélectionné pour être celui qui a le rang le plus bas parmi

125 les parents candidats. Un réseau peut englober plusieurs DODAG, qui sont
identifié par les paramètres suivants :

1.RPLInstanceID. Ceci est utilisé pour identifier un ensemble indépendant de DODAG

qui est optimisé pour un scénario donné.

2.DODAGID. Il s'agit d'un identifiant d'une racine DODAG. LaDODAGIDest

130 unique dans le cadre d'unRPLInstanceID.

3.DODAGVersionNumber. Ce paramètre s'incrémente en fonction de certains

événements, comme la reconstruction d'un DODAG.

1Dans le reste du document, les termes « RPL », « RPL standard » et « RPL par défaut » sont utilisés de
manière interchangeable. Il en va de même pour les termes « mRPL », « RPL compatible avec smart-HOP » et «
RPL compatible avec la mobilité ».

6
 4.Rang. Ce paramètre définit la position du nœud par rapport au nœud racine
dans un DODAG.

135 Chaque nœud d'un DODAG se voit attribuer unrangqui augmente en aval
direction du DAG et diminue dans la direction amont. Par exemple, dans la figure 1, le

nœud 8 a un rang plus élevé que le nœud 5 et le nœud 5 a un rang plus élevé

que le nœud 3 et le nœud 2.

Messages de contrôle RPL.Les messages de contrôle RPL sont le nouveau type de

140 Internet Control Message Protocol version 6(ICMPv6) — défini dans RFC 2463. La
spécification RPL définit quatre types de messages de contrôle : (i)DODAG In-
Objet de formation(DIO). La transmission de ce message est émise par la racine

nœud puis multidiffusion par d'autres nœuds. Ce message contient les principales informations

mation pour construire et maintenir un arbre, par exemple le rang actuel d'un nœud,

145 l'instance RPL et l'adresse racine, (ii)Sollicitation d'informations DODAG(DIS). UN

nœud qui nécessite un message DIO des voisins, le demande par multidiffusion

message DIS, (iii)Objet d'annonce de destination(DAO). Chaque nœud propa-

envoie un message DAO vers le haut (le long du DODAG). Ainsi, ce message
active le trafic descendant de la racine via le DODAG vers ce nœud, et (iv)
150 Accusé de réception d'objet de publicité de destination (DAO-ACK). Cette monodiffusion

message est envoyé par un destinataire DAO pour accuser réception de sa bonne réception.

Détection de mobilité en RPL.La mobilité est indiquée comme l'une des principales

sources d'incohérence dans RPL [29]. Généralement, il existe deux approches principales

qui aident à détecter la mobilité ; (i) la transmission de paquets ICMPv6, contrôlée

155 par l'algorithme Trickle et (ii) la transmission de paquets ICMPv6, contrôlée

par le protocole ND, qui sont décrites ci-dessous.

(i) Algorithme RPL Trickle.Les protocoles traditionnels de collecte en faible

les réseaux électriques diffusent généralement des messages de contrôle à un intervalle de temps fixe [30].

Un petit intervalle nécessite plus de bande passante et d'énergie. Un grand intervalle utilise moins

160 la bande passante et l'énergie, mais des problèmes topologiques peuvent survenir en raison de

l'incapacité à faire face à la dynamique du réseau. L'idée de base de l'algorithme Trickle

(défini dans la RFC 6206) consiste à propager des balises en cas de changement de routage

sept
 informations.

RPL réduit le coût de propagation des états de routage en utilisant un système basé sur Trickle

165 minuterie [31]. Trickle est une stratégie de balisage adaptatif visant une récupération rapide et

faible surcharge. Alors que les paquets DIS sont envoyés périodiquement par les routeurs jusqu'à

le premier nœud parent est sélectionné, un temporisateur d'entretien est utilisé pour programmer la

transmission des DIO. Cette minuterie permet aux intervalles DIO d'augmenter de façon exponentielle

lorsque les conditions du réseau sont stables et diminuent rapidement au minimum

170 lorsque des changements notables dans les conditions du réseau sont détectés. Le périodique

Minuterie d'entretientest borné par l'intervalle [jemin, JEmaximum], oùjeminest l'intervalle

minimum défini en millisecondes par une valeur en base 2 (par exemple 212=4096 ms),

etjemaximum=jemin×2jedoublersert à limiter le nombre de fois quejeminboîte

double. En supposantjedoubler=4, l'intervalle maximum est simplement calculé comme

175 jemaximum=4096×24=65536 ms.

L'algorithme Trickle est capable de maintenir la mise à jour de la topologie globalement dans un

courte période de temps. Un nœud qui détecte une incohérence dans un message DIO

(par exemple imposé par la mobilité des nœuds), les ensemblestàjeminet met à jour l'arborescence. Si la

DODAG reste cohérent,test doublé à chaque fois qu'une transmission DIO se produit jusqu'à ce

180 qu'elle atteignejemaximum, en gardant cette valeur constante. Lorsque le réseau est stable,

la minuterie d'entretien converge progressivement vers son intervalle maximum. Lors de la mobilité,

cet intervalle important se traduit par une très faible réactivité du réseau. Après avoir détecté

toute incohérence dans le réseau, la période DIO de tous les nœuds du réseau diminue de

façon exponentielle, affectant la surcharge du réseau.

185 (ii) Approche de découverte de voisins IPv6.RPL peut utiliser le voisin IPv6
approche de découverte [32] pour détecter les changements environnementaux. La basse puissance

liens exploitent une version optimisée de ND, qui a été développée par l'IETF
comme une adaptation de la découverte de voisins pour 6LoWPAN [21]. Le ND
Le protocole permet aux nœuds de détecter l'inaccessibilité du voisin et de découvrir de nouveaux

190 voisins. Ce protocole est supporté par quatre messages de contrôle ICMPv6 : (i)
Sollicitation de voisins(NS) : il détermine l'adresse de couche liaison d'un
voisin et vérifie si un voisin est toujours joignable, (ii)Publicité de voisin(N / A):
il répond au message NS et il est également envoyé périodiquement pour annoncer le lien

8
 Phase de découverte (1) Phase de découverte (m)

Tous les points d'accès

Phase d'émission de données
...

Phase de découverte
Sélectionner

Portion meilleur point d'accès

PA ... et allez à
...
Les points d'accès répondent
... ...
Émission de données
Réponse
Émission de données Réponse Émission de données n balises Phase

MN

RSSI≥Tje RSSI<Tje RSSI>Tje+HM RSSI>Tje+HM

ws

ws m

Figure 2 : Chronogramme du mécanisme smart-HOP.

changements, (iii)Sollicitation de routeur(RS) : il demande au nœud hôte (mobile

195 nœud dans notre modèle de système) à son routeur, demandant des informations, et (iv)Routeur

Publicité(RA) : un routeur envoie périodiquement et en réponse au RS

message qui annonce sa présence (le routeur) avec les informations du lien
et les paramètres Internet.

3. Contexte du smart-HOP

200 Dans cette section, nous fournissons une brève description de la conception de smart-HOP

et les principaux paramètres de transfert impliqués. L'algorithme smart-HOP comporte deux phases

principales : (i)Phase de transmission des donnéeset (ii)Phase de découverte. Une chronologie

de l'algorithme est représenté sur la figure 2. Par souci de clarté, supposons

qu'un nœud est dans lePhase de transmission des données. Dans cette phase, le mobile n ode
205 (MN) est supposé avoir un lien fiable avec un point d'accès (AP), défini comme

Service APEn figueure 2. Le nœud mobile surveille la qualité de la liaison en recevoir ing

Réponsepaquets de le point d'accès de desserte. Dès réceptionnpaquets de données je na gi ven

fenêtre, le servi ng AP répond avec le RSSI moyen (ARSSI) ou S NR de la
npaquets. Si pas de reçus, le point d'accès ne prend aucune mesure. Ce m qui sont je suis en tête à
210 p déconnexions, w résolus grâce à l'utilisation d'un mécanisme de temporisation anisme . Ce
est important pour n remarquez que smart-HOP fil ters out liens asymétriques i mplic jely
t
en utilisant la réponse pa billets à t es phases de transmission de données et de découverte. Si un
PA voisin h comme non actif e liens, cet AP ne fait tout simplement pas partie du processus.

9
 Paramètres de transfert.Le mécanisme smart-HOP englobe trois paramètres
215 principaux2pour peaufiner :
Paramètre 1 :taille de la fenêtre (ws). wsest le nombre de paquets requis pour

calculer l'ARSSI sur un intervalle de temps spécifique, comme illustré à la figure 2.

petitwsfournit des informations détaillées sur le lien, mais augmente le traitement des paquets de

réponse, ce qui entraîne une consommation d'énergie plus élevée et une réduction

220 tarifs de livraison. La livraison de paquets diminue à mesure que le MN opte pour effectuer certains

transferts inutiles. Le transfert est déclenché en détectant des liens de mauvaise qualité,

résultant de la réduction de la force du signal. D'autre part, un grandws

fournit des informations grossières sur le lien et diminue la réponse
tivité du système, qui n'est pas adaptée aux réseaux mobiles avec dynamique
225 changement de lien.

Paramètre 2 :marge d'hystérésis (HM). Ce paramètre est défini comme la

différence entre le seuil ARSSI de démarrage du hand-off (Jje) et le
efJje+SM). Dans les WSN, le
Seuil ARSSI d'arrêt du hand-off (Jré= h

sélection des seuils etmarge d'hystérésiss est dicté par les caractéristiques
230 de la région de transition et la variabilité de la liaison sans fil. Les seuils
doivent être choisis en fonction des limites de la région de transition. La
la région de transition est souvent assez importante en taille et donc un grand nombre

des liens du réseau (plus de 50 %) ne sont pas fiables [33, 34]. Par conséquent,
les nœuds sans fil sont susceptibles de passer la plupart du temps dans la région de transition.

235 Si laJjele seuil est trop élevé, le nœud pourrait effectuer des transferts inutiles

(en étant trop sélectif). Si le seuil est trop bas, le nœud peut utiliser des
liens. Lamarge d'hystérésisjoue un rôle central dans la gestion de la variabilité
de liaisons sans fil à faible puissance. Si lamarge d'hystérésisest trop étroit, le nœud

mobile peut finir par effectuer des transferts inutiles et fréquents entre deux

240 PA (effet ping-pong). Si lamarge d'hystérésisest trop grand, les transferts peuvent prendre

trop long, ce qui finit par augmenter les temps d'inaccessibilité du réseau, et donc

2Nous avons ignoré le paramètre de surveillance de la stabilité à ce stade, car il n'a aucun impact sur les
performances du smart-HOP[19]. La surveillance de la stabilité est le nombre de fois en séquence que le MN
détecte une liaison de haute qualité à partir d'un point d'accès dans lePhase de découverte.

dix
 diminuer le taux de livraison.

Paramètre 3 :surveillance de la stabilité (m).En raison de la grande variabilité de

liaisons sans fil, le nœud mobile peut détecter un point d'accès momentanément au-dessus

245 Jh, mais l'ARSSI peut diminuer peu de temps après le transfert à cet AP. En ordre

pour éviter cela, il est important d'évaluer la stabilité du PA candidat. Après

avoir détecté un AP avec l'ARSSI ci-dessusJh, le MN continuemen outre Dis-
Phases de couverture pour vérifier la stabilité de cet AP. Comme on peut facilement en déduire, le

surveillance de la stabilitéet lemarge d'hystérésisparamètres sont étroitement liés.

250 Un largemarge d'hystérésisnécessite une plus faiblem, et vice versa. [20] montre
qu'un réglage approprié de lamarge d'hystérésismènera àm=1, qui conduit
à un surcoût minimal.

4. Présentation de mRPL

Comme mentionné précédemment, nous intégrons smart-HOP dans RPL dans un

255 manière très simple, efficace et rétrocompatible avec le protocole standard. Dans
ce modèle, le protocole RPL standard est inchangé tout en fournissant
la prise en charge de la mobilité, c'est-à-dire que les nœuds compatibles standard et smart-HOP peuvent coexister

et interagissent dans le même réseau.

La procédure générale d'échange de balises et de données dans smart-HOP intégré

260 dans RPL (mRPL) est similaire à la conception originale de smart-HOP, à l'exception

employant des messages de contrôle RPL (DIS et DIO) comme balises et ajoutant quelques

temporisateurs pour améliorer la fiabilité et l'efficacité. La chronologie de l'algorithme est dé-

illustré à la figure 3. Dans cette approche, le MN reçoit un paquet de réponse (message DIO

unicast) immédiatement après avoir transmis un nombre prédéfini de paquets de données

265 (la taille de la fenêtre). Le message de réponse DIO (qui contient le niveau RSSI moyen),

filtre implicitement les liens asymétriques.

Lors de la détection d'un lien de bonne qualité (à partir du niveau RSSI moyen dans le

message de réponse DIO), le MN continue lePhase de transmission des données. En observant

la dégradation ARSSI, MN commence laPhase de découverte. MN reprend les données

270 communication avec le point d'accès en service jusqu'à trouver un meilleur point d'accès. Après un succès

11
 Phase de transmission des données Phase de découverte

MDT
La taille de la fenêtre

RSSI>Tje RSSI>T je RSSI<Tje RSSI<Th RSSI>Th

MN ... ...

Phase de transmission des données

Canaliser
Libre
préféré
PA ... ...

TDM
points d'accès voisins
0 t

HT

écoute inactive
Rx DIS DIO Rx
transmission de données Émission DIO
réception de données Émission DIS

Figure 3 : Chronogramme mRPL pour lePhase de transmission des donnéesetPhase de découverte.

transfert, le processus d'annulation de l'algorithme RPL est exécuté3.

Pour évaluer les parents potentiels, le MN diffuse une rafale de contrôle DIS
messages. Ensuite, tous les points d'accès voisins répondent au MN sur une base non

conflictuelle (cela sera discuté dans dequeue dans la section 5). La RSSI moyen le niveau est

275 intégré dans la monodiffusion DIO r répondre. Sur re perception o f chaque DIO re pli, MN

compale repos il a Valeur RSSI e esprit h hlev J él. Si ce n'est pas sa c'estfacto ry (ARS SI être bas
J h), McN ontin tues large casjeng DIS btupremiers périodiques un
lly (Wie r t à la
en particulier

Het- minuterie). Sur détecter Ah ah igqualité du lien h ( AB ARSSI plusJh), la

Phase de découvertes'arrête et le MN reprend la communication de données normale (avec

280 un nouveau parent préféré) —Phase de transmission des données.

5. mPR L jen De jusqu'à

un

Cette section détaille la conception mRPL. Nous décrivons d'abord les temporisateurs supplémentaires

qui améliorent l'efficacité et la fiabilité du processus de transfert. Le amélioré

contrôler les paquets de messages et la priorité des paquets de réponse (messages DIO).

3L'annulation du parent est un processus dans lequel le parent préféré est supprimé et lerangest
fixé à l'infini.

12
285 sages des points d'accès voisins) sont ensuite décrits. Le réglage de la minuterie d'entretien (pendant le

transfert) et la sélection des parents sont également abordés.

Minuteries.Nous avons mis en place quatre temporisateurs principaux pour percevoir facilement le lien

dégradation et l'inaccessibilité du parent dans un court laps de temps. L'utilisation de

ces minuteries dans leTransmission de donnéesetPhase de découverteest instancié dans les

290 algorithmes 1 et 2 et décrit brièvement comme suit.

(je)Minuterie de connectivité (JC). Les nœuds mobiles surveillent en permanence le canal

activité pour détecter toute réception de paquet depuis leur point d'accès de desserte. Chaque MN exécute un

temporisateur pour augmenter la réactivité du routage RPL — le temporisateur de connectivité.

La périodicité de la minuterie de connectivité est définie en fonction du Trickle maximum

295 intervalle (jemaximum). Pendant cette période, le MN reste à l'écoute du canal et

surveille les paquets entrants du parent serveur. À l'expirationJC, si
le MN observe un parent silencieux, puis il démarre lePhase de découverte. Lors de la détection de toute

réception de paquet du point d'accès de service (par exemple Trickle DIO, monodiffusion

DIO ou un paquet de données), le temporisateur de connectivité est réinitialisé.

300 (ii)Minuterie de détection de mobilité (JMARYLAND). Balisage DIS périodique du MN

demande un message DIO unicast au point d'accès serveur. Le MN lit le niveau

ARSSI lié au message DIO pour évaluer la fiabilité de la liaison. En mouvement
un nœud ou apparaître un obstacle entre deux nœuds peut entraîner la perte du

paquets de requête ou de réponse. Dans cette situation, le MN lance lePhase de découverte

305 pour trouver un nouveau parent servant. La périodicité du temporisateur de détection de mobilité est établie en

fonction du taux de génération de données au niveau du MN.

(iii)Minuterie de transfert (JHO). Il est primordial de réduire le délai de transfert.

Ce temporisateur gère la périodicité de diffusion des salves de DIS vers le

parents ennuyeux. Cette période doit permettre de s'adapter à la transmission de rafales de

310 DIS avec le débit le plus élevé possible et à la réception de réponses intermittentes de

nœuds voisins. Les réponses DIO sont collectées immédiatement après l'envoi de chaque

éclatement. La séquence d'envoi des réponses par chaque parent est planifiée de telle sorte

moyen de réduire la probabilité de collision.

(iv)Minuteur de réponse (JR). Le parent serveur est censé répondre au MN

315 en monodiffusion d'un message de contrôle DIO à certains instants. Choisir un mauvais

13
 moment de répondre peut provoquer une collision avec les paquets de données, qui à son tour

déclenche lePhase de découverte. Le nœud parent extrait les informations pertinentes

à partir des paquets reçus du MN (par exemple, compteur de paquets de données dans

chaque taille de fenêtre). Le temps de réponse est calculé par (ws − C)×JDIS, oùC
320 représente le compteur de paquets DIS dans chaque taille de fenêtre (ws) etJDIS
indique l'intervalle DIS. Ce temps de réponse change de manière adaptative lors de la réception

nouveaux paquets.

Algorithme 1 :Phase de transmission des données

commencer

sipaquet DIO reçualors

réinitialiserJC;

siARSSI < Tjealors

aller à laPhase de découverte;
autre
continuer laPhase d'émission de données;
fin
sinon siJMARYLANDexpirealors
réinitialiserJMARYLAND;

rafale unicast de DIS ;

aller au début ;
sinon siJCexpirealors
aller à laPhase de découverte;
fin
fin

Messages de contrôle améliorés.Pour intégrer l'algorithme smart-HOP

au sein de RPL, nous avons amélioré les messages de contrôle RPL plutôt que de créer de nouveaux

325 ceux. Cette approche garantit la rétrocompatibilité avec le RPL standard, c'est-à-dire que les

nœuds RPL standard peuvent coexister et interagir avec les nœuds compatibles smart-HOP.

nœuds d'un même réseau.

Les messages de contrôle RPL sont transmis régulièrement ; cependant, pendant

le processus de transfert, ils suivent des règles spécifiques. Dans lePhase de transmission des

330 données, le DIS est envoyé du MN au point d'accès (monodiffusion) et le parent préféré répond

avec un DIO monodiffusion. Le type de DIS et DIO est détecté en lisant un indicateur qui

reflète l'état de chaque nœud (sera expliqué ensuite). Dans lePhase de découverte,

14
 Algorithme 2 :Phase de découverte
commencer

simessage DIS unicast reçualors

stocker les lectures RSSI ;
stocker la contre-valeurCdu dernier paquet DIS ;
réinitialiserJRavec(ws − C)×JDIS;
siJRexpirealors
calculer le RSSI moyen ;
envoyer un message DIO unicast avec RSSI moyen ;
autre
ContinuezPhase de découverte;
fin
autre
poursuivre la phase de transmission de données ;

fin
fin

le MN multidiffuse les messages DIS à tous les points d'accès voisins et reçoit des réponses DIO

unicast.

335 smart-HOP permet de transmettre des messages de contrôle DIS unicast pour sonder le

servant AP afin de s'assurer que le parent est joignable et fiable (RPL trans-
mits les paquets DIS et DIO multicast). Pour faire la distinction entre le mRPL DIS
et le RPL DIS natif, un indicateur d'un bit (F-DIS)est implémenté —voir Fig-
ure 4(a). L'initialisation de ce champ à "0" représente la transmission multicast de

340 le RPL DIS. Au lieu de cela, la définition de ce champ sur "1" reflète la monodiffusion mRPL DIS

transmission. Les deux bits supplémentaires de "C» décrivent le compteur de messages DIS

dans une taille de fenêtre. En mRPL avecws=3, le compteur incrémente jusqu'à

un maximum de 3.

Le message mRPL DIO ajoute deux champs : (1)F-DIOqui représente les drapeaux

345 et (2)ARSSIqui contient la lecture RSSI moyenne au nœud parent potentiel

— voir Figure 4(b). Les deux morceaux deF-DIOdistinguer trois cas : (i)F-DIO=0
correspond au RPL DIO, (ii)F-DIO=1 indique le mRPL DIO dans le
Phase de transmission des données, et (iii)F-DIO=2 reflète le mRPL DIO dans
laPhase de découverte.

350 Affectation prioritaire.Afin de réduire la collision de paquets pendant le

15
 0 1
0123456789012345
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

|RPLInstanceID |Numéro de version|

0 1
0123456789012345678901234
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ - + - + - + - + | Drapeaux | Réservé | Option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2
| Rang |
+-+-+-+-+-+-+-+-+-+-+-+-+-
+ - + - + - |G|0| MOP | Prf | DTSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-
+ - + - + - | Drapeaux | Réservé |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

| |
+ DODAGID +
6789012345 | | 0123456789012345
+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

+ - |F|C|Option(s) … | Option(s)... |F| ARS jeOption(s)…

+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

(un) (b)

Figure 4 : (a) Le format de paquet DIS modifié. Deux champs deF-DISetCsont ajoutés au paquet
RPL DIS, et (b) le format de paquet DIO modifié. Deux champs deF-DIOet ARSSI sont ajoutés au
paquet RPL DIO. Des bits supplémentaires sont appliqués à la partie "Option(s)" du paquet.

Tableau 1 : L'affectation prioritaire

Priorité Gamme de lectures RSSI moyennes

priorité=1 − 85<ARSSI < −80 dBm
priorité=0 ARSSI≥ −80 dBm

Découverte Pha se, nous interdisons à certains points d'accès de répondre au MN ; par ents
avecARSSI < Thsont exclus de l'ensemble des parents possibles et ne
Réponse. A faire lui, chaque parent attribue une priorité en fonction du RSSI moyen

lectures, comme s indiqué dans le tableau 1. L'attribution de priorité programme le DIO

355 transmissions dans différents créneaux. Étant donné que les réseaux de faible puissance sont susceptibles de fonctionner

dans la région de transition, il est plus probable que différents parents choisissent le même

insérer. Une minuterie programme la transmission DIO (tdécalage) après avoir détecté un canal

occupé comme suit.

tdécalage= (ws − C)×JDIS+t2×priorité+rand(t1, t2) (1)

La première partie de cette équation, (ws − C)×JDIS, est le temps d'attente pour

16
360 recevoir les messages DIS complets transmis, ce qui est similaire à laPhase de transmission

des donnéesde l'algorithme smart-HOP. Nous forçons la qualité supérieure

AP (priorité=0) pour transmettre plus tôt (t2×priorité=0 ms) et les points d'accès de qualité inférieure

(priorité=1) transmettre plus tard (t2×priorité=t2Mme). Un délai aléatoire est également ajouté à

réduire la possibilité d'entrer en collision avec les points d'accès de même niveau de priorité enrand(t1, t2

365 ). Il est important de noter qu'avect2×priorité, les liens de qualité inférieure attendent au maximum

pourt2Mme, (maximum((priorité=0)×t2+rand(t1, t2)) =t2), qui est mesuré par

(priorité=1)×t2=t2m / s. La valeur aléatoire réduit également la possibilité de
collision entre les réponses des points d'accès de qualité inférieure et de qualité supérieure. Les

valeurs aléatoires sont définies sur 10 et 15 ms, qui sont au-dessus du maximum possible

370 taux de transmission4. Considérantws=3 etJDIS=15 ms, dans le pire des cas
(c'est à direrand(t1, t2) = 15 ms), il faut au maximum 75 ms au MN pour obtenir toutes les réponses

des points d'accès voisins. Dans notre modèle de système, nous envisageons un déploiement judicieux

des points d'accès afin d'éviter une densité de points d'accès très élevée ou très faible. Notre

les tests fournissent un chevauchement minimal entre les points d'accès contigus qui empêcheraient le

375 possibilité d'avoir plusieurs points d'accès de haute qualité dans une région.

Réglage d'entretien pendant mRPL.Selon l'algorithme Trickle, tous les nœuds

(racines/routeurs) diffusent des messages (DIO) pour échanger des informations avec

les nœuds voisins. L'intervalle de transmission est délimité et agrandi sur

stabilité du réseau. Lorsqu'un nœud se déplace, il interfère avec la stabilité du réseau

380 et donc l'intervalle est fixé à sa valeur minimale (jemin). Nous gardons l'intervalle d'entretien

inchangé pendant le processus de transfert, tout en conservant les transmissions.

horaires indépendants. Comme déjà mentionné, leFFichamps du mes-

sages (F-DISetF-DIO) sont ajoutés pour faire la distinction entre mRPL et RPL
messages.

4Nous utilisons des motes Tmote Sky équipées de la puce radio Chipcon 2420 [35], fonctionnant à 2,4 GHz
avec un débit de données de 250 kbit/s. La taille du paquet dépend de la charge utile des données, qui est
ajoutée à l'en-tête et au pied de page. Étant donné que RPL exécute une stratégie d'adressage IPv6, nous
supposons que la taille du paquet est de 127 octets dans le pire des cas. Compte tenu du débit de données radio
et de la taille des paquets, le nœud est capable de transmettre au plus 246 paquets/s (1 paquet toutes les 4 ms).
Le délai de propagation, la modulation, la démodulation, la fragmentation et la défragmentation prolongent ce
délai approximatif de transmission. Dans les expériences du monde réel, il est sage de choisir des intervalles
supérieurs à 4 ms pour garantir des transmissions réussies.

17
385 Mécanisme d'évitement de boucle.En RPL, lorsqu'un nœud se déconnecte de son

parent, lerangla valeur est définie sur l'infini. Cela permet au MN de se connecter

à n'importe quel nœud voisin, même ceux avec un plus faiblerang. Par exemple, le

MN peut sélectionner un nœud voisin qui était auparavant l'enfant du MN (avant la

transfert) en tant que nouveau parent. Étant donné que le voisin a un niveau inférieur

390 rangpar rapport à l'infini, selon le RPL par défaut, le MN est autorisé à choisir

ce. Comme le montre la figure 5, dans DODAG 1, le nœud 5 a un parent (nœud 2) et

trois enfants (Nœuds 7, 8 et 9). Chaque nœud fournit des données à un nœud de rang inférieur

(écrit à côté de chaque nœud). Lorsque le nœud 5 sort de la plage du nœud

2, selon le routage RPL, DODAG 2 est établi. Dans ce cas, d'abord le
395 Le rang de MN est fixé à l'infini, puis il choisit un voisin avec l'ARSSI le plus élevé

niveau et le niveau de rang inférieur (6). Ainsi, le nœud 7 (l'enfant précédent du nœud 5) est

sélectionné comme parent préféré. Les messages de données du nœud 5 sont transmis au nœud

7, et le nœud 7 est transmis au nœud 5 (son parent), ce qui représente un réseau fermé.

boucle.

400 RPL a quelques mécanismes de détection de boucle ; cependant, les boucles ne peuvent pas être complètement

évitée et peut donc encore se produire. Pour résoudre ce problème, RPL effectue des réparations

globales où l'arbre de routage est reconstruit, mettant à jour le rang de tous les nœuds dans un DODAG.

Ce comportement n'est pas efficace car un MN devra démarrer tout le processus de

retrouver un nouveau parent, ce qui prend beaucoup de temps et d'énergie.

405 Dans ce contexte, nous avons conçu un mécanisme d'évitement de boucle simple mais efficace.

Nous avons analysé deux approches différentes pour éviter l'effet de boucle. Premièrement le

MN reçoit des réponses de tous les points d'accès voisins, puis ignore les messages de

les enfants précédents. Ainsi, après avoir créé l'ensemble des parents alternatifs, le

les enfants sont exclus de l'ensemble. Deuxièmement, les enfants refusent de répondre à la demande

410 d'adhésion du parent précédent. Nous choisissons cette dernière approche car elle conduit à

moins de communication, de traitement et de frais généraux lors d'un transfert. DODAG 3 po

La figure 5 montre un scénario où le nœud 5 se déconnecte du nœud 2 et se connecte

au nœud 6, en évitant de choisir l'un de ses enfants précédents.

surcharge de mémoire.La surcharge de mémoire du RPL standard par rapport à

415 mRPL est illustré dans le tableau 2. smart-HOP a été intégré à environ

18
 DODAG 1

1 R1 2 3

6 R2MN 4

R3 7 R3 8 R3 9

Norme RPL mRPL

DODAG 2 DODAG 3

1 2 3 1 R1 2 3

6 4 6 R2 4

MN R5 MN R3

R4 7 R5 8 9 septR4 8 R4 9

ID de nœud ID parent ID de nœud ID parent

sept 5 (MN) sept 5 (MN)

boucle
5 (MN) sept 5 (MN) 6

Figure 5 : Le DODAG 1 se met à jour lors de la mobilité. Le DODAG 2 se met à jour en appliquant
l'algorithme RPL standard, augmentant en boucle fermée. Le DODAG 3 se met à jour selon mRPL,
en évitant la boucle fermée.

4 Ko de ROM et 1 Ko de RAM supplémentaires, soit seulement 10 % d'encombrement supplémentaire.

6. Analyse de simulation

Nous avons implémenté et testé le protocole avec un simulateur qui se connecte

facilement au matériel du capteur et offre la possibilité d'analyser différents réseaux

420 les conditions. Étant donné que les liaisons sans fil à faible puissance sont très sujettes aux interférences radio externes,

comparaison avec d'autres technologies sans fil fonctionnant dans la bande ISM, des simulateurs

sont généralement incapables de t o fournir un très acc modèle d'interférence radio d'urate. Chaque

environnement intérieur/extérieur onment expositions sp comportements de lien spécifiques qui sont imp ossi-

ble pour imiter la sim environnement réglementé . mRPL a été conçu pour perf orme
425 bien dans les réseaux avec une couverture AP complète et un chevauchement minimal entre voisins

points d'accès. En simulation, nous sommes en mesure d'établir un environnement qui fournit

19
 Tableau 2 : Utilisation de la mémoire en RPL standard par rapport à mRPL

Mise en œuvre ROM (octets) RAM (octets)

RPL (MN) 40 202 7 660
RPL (AP) 40 336 7 606
mRPL (MN) 44 348 8 562
mRPL (AP) 44 022 8 512

ces exigences, mais dans des expériences réelles, les liens peuvent se chevaucher différemment (plus ou

moins). Nous comparerons les résultats de simulation et expérimentaux dans la section 7 pour

montrent la nécessité d'effectuer des tests expérimentaux afin d'enrichir la radio

430 modèles de propagation et d'interférence en simulation.

6.1. Configuration de la simulation

Afin d'implémenter et d'évaluer mRPL, nous avons opté pour le Contiki 2.6.1 [36]

système d'exploitation (OS), qui prend en charge le simulateur Cooja. Les principales raisons

pour sélectionner Contiki sont : (i) la disponibilité d'une implémentation RPL/6LoWPAN

435 raisonnablement mature et largement utilisée, (ii) la facilité de portage du code Cooja sur

les plates-formes matérielles, et (iii) la disponibilité d'un plugin de mobilité dans

Cooja [37], qui permet d'évaluer mRPL dans un environnement reproductible5.

Dans cette section, nous comparons mRPL avec différents paramètres de la norme

RPL, compte tenu de différentes topologies. Ensuite, nous étudions l'impact d'autres

440 paramètres sur les performances de mRPL. Les principaux paramètres qui influent sur la

Les performances RPL sontjeminetjedoublerdans l'algorithme Trickle. Nous avons considéré

quatre scénarios RPL en faisant varier le tuple<jemin, JEdoubler>valeurs, telles que définies

dans le tableau 3. L'évaluation se concentre sur l'impact de ces paramètres de ruissellement

sur les métriques de réseau suivantes :

445 Délai de transfert.Il représente le temps moyen nécessaire pour effectuer la main-

hors processus avec mRPL ou le temps passé à découvrir un nouveau parent préféré dans

5Par défaut, Cooja ne prend pas en charge la mobilité. Néanmoins, sur la base du fait que chaque mote
déployé a son propre emplacement représenté dans un système à deux axes (x, y), un plugin de mobilité Cooja
[37] a été développé qui est capable de charger des fichiers de trace de mobilité spécifiques en utilisant le format
d'intervalle .

20
 Tableau 3 : Description des scénarios RPL

Scénariosjemin jedoubler DIOmin DIOmaximum

(12-8) 12 8 4,096 s 1048,576 s
(12-1) 12 1 4,096 s 8,192 s
(10-2) dix 2 1,024 s 4,096 s
(8-1) 8 1 0,256 s 0,512 s

le RPL standard.
Surcharge totale des paquets.Nous identifions tous les paquets non-données (contrôle mes-

sages) comme surcharge du réseau. RPL utilise des messages de contrôle basés sur ICMPv6 (DIS,

450 DIO et DAO) pour la construction et la maintenance des DODAG. Le mRPL utilise

ces messages de contrôle pour détecter la mobilité et effectuer le processus de transfert.

Taux de livraison des paquets (PDR).Il est défini comme le nombre de succès

paquets reçus sur tous les points d'accès sur le nombre total de paquets envoyés depuis les MN.

Le taux de livraison réussi de mRPL est comparé à différents scénarios RPL

455 en présence de mobilité.
Nombre total de paquets DAO.Pour établir des routes descendantes, les nœuds RPL envoient des

Message DAO vers le haut. La destination du saut suivant d'un message DAO est le

parent préféré. Après être passé au meilleur parent, le nœud enfant informe
le parent précédent sur sa déconnexion et le parent sélectionné sur son
460 accessibilité. Le nombre total de paquets DAO est une indication pour évaluer
la réactivité du routage et le nombre de transferts dans un environnement mobile

réseau.

6.2. RPL contre mRPL

Pour évaluer l'algorithme proposé, nous considérons trois topologies de réseau :

465 (1) avec deux points d'accès, (2) avec quatre points d'accès déployés à la suite et (3) avec huit points d'accès

déployés en deux rangées parallèles. Dans le premier déploiement avec deux points d'accès (nœud 1

et Nœud 2, distants de 10 m —voir Figure 6(a)), le MN parcourt 15 fois entre

PA1etPA2à vitesse constante (v=2 m/s) et une puissance d'émission de
− 25 dBm, tout en générant des données avec un débit de 30 pkt/s. De même, dans les deux
470 autres déploiements (Figures 7(a) et 8(a)), le MN se déplace d'un coin gauche

21
 4 mètres 8m 12m
10000

(Mme)
8000
1 2

6000

Délai de transfert
0
4000

PA MN Racine
2000
80 millisecondes

0
12_8 12_1 10_2 8_1 mRPL
Scénarios
(un) (b)
100 15 200

80
Frais généraux ( %) 150

AD totale O
dix
60
RDP (%)

100
40
5
50
20

0 0 0
12_8 12_1 10_2 8_1 mRPL 12_8 12_1 10_2 8_1 mRPL 12_8 12_1 10_2 8_ 1 mRPL
Scénarios Scénarios Scénarios
(c) (ré) (e)

Figure 6 : Résultats de simulation pour une topologie de réseau avec deux points d'accès. (a) simulation nario,
sce (b) délai de transfert, (c) taux de livraison des paquets, (d) temps système total en termes de contrôle sages,
mes et (e) nombre total de DAO.

vers le coin droit avec la même vitesse constante, puis revient en arrière t o le
point de départ.

La connectivité est garantie en fournissant unet fiable hein et-

hors processus.mRPL est capable de détecter et d'effectuer un transfert dans te ns de

475 millisecondes (80 à 83 ms), ce qui est beaucoup plus rapide que tous les scénarios RPL —voir
Figures 6(b), 7(b) et 8(b). Nous avons estimé le délai de transfert dans le stan-
dard RPL car il n'a pas de mécanisme de transfert.Le « transfert » dans RPL
est supposé commencer au moment où les paquets commencent à se perdre au servir-

parent et se termine lorsque le nouveau parent commence à recevoir des données avec succès

480 paquets du MN.Le taux de génération de données élevé accélère la mise à jour de la

métrique ETX qui conduit à un processus de commutation parent rapide pendant la liaison

dégradation.

Le délai de transfert des scénarios RPL fluctue beaucoup, car la détection de mobilité

dépend de diverses conditions (par exemple débit de données, temporisateur d'entretien et

485 protocole ND) et la réactivité à la dynamique de l'environnement n'est pas garantie.

anté dans RPL. Le délai de transfert moyen des scénarios RPL varie de 2776

22
 x104
2.5

Mme)
4m 8m 12m
2

hors délais (
1 2 3 4
1.5

0 1

Het−
0,5
81 millisecondes

0
12_8 12_1 10_2 8_1 mRPL
Scénarios

(un) (b)
100 35 250

80 30
Surchauffe ré(%) 200
25

AO
RDP (%)

60 150
20

totale D
40 15 100
dix
20 50
5
0 0 0
12_8 12_1 10_2 8_1 mRPL 12_8 12_1 10_2 8_1 mRPL 12_8 12_1 10_2 8_1 mRPL
Scénarios Scénarios Sc narios
(c) (ré) (e)

Figure 7 : Résultats de la simulation pour une topologie de réseau avec quatre s. (a) simulation n scenario,
points d'accès (b) délai de transfert, (c) taux de livraison des paquets, (d) conditions de contrôle moisages,
surcharge totale et (e) nombre total de DAO.

ms à 9776 ms dans ces trois topologies de réseau (Figure s 6(b), 7(b) un nd 8(b)).
En RPL, le nœud mobile bascule entre le nœud parent s dans son parent t set. Dans
Afin de mettre à jour les informations de l'ensemble parent, il Filet et Nré algo-
490 utilise les rithms. L'algorithme Trickle (qui schedules le co ntr ol message e Xchanges)

élargira les intervalles dans un réseau stable. Pour détecter mo bilité dans ce c ition,
deuxième

le nœud RPL attend de recevoir le message NA e ou demandes cette mes-

sage en multidiffusionMessage NS à son voisin UN
Ps. Ces messages
sont pris en charge par le protocole ND pour détecter l'absence de parent un
chabilité. J he mmajeur
495 Les inconvénients de RPL concernant la connectivité réseau sont : (i) les changements soudains

en raison de la mobilité des nœuds ne sont pas détectés rapidement si le réseau est stable depuis

un certain temps, (ii) le protocole ND est initié du côté parent (comme un transfert

passif), ce qui allonge la durée du transfert, et (iii) la reprise du protocole ND

(qui reconstruit les arbres de routage) coûte très cher.

500 mRPL est capable de fournir près de100%taux de livraison des paquets.Un jeûne

Le processus de transfert permet de transmettre la plupart des paquets au point d'accès ciblé. En

RPL, le MN doit attendre les messages de contrôle du point d'accès le plus proche.

23
 15000

Mme)
4m 8m 12m

1 2 3 4
10000

Délai de transfert (
0

5000

1 2 3 4 83 millisecondes

0
12_8 12_1 10_2 8_1 mRPL
Scénarios

(un) (b)
100 50 250

80
Frais généraux (%)
40 200

DAO total
RDP (%)

60 30 150

40 20 100

20 dix 50

0 0 0
12_ 8 12_1 10_2 8_1 mRPL 12_8 12_1 10_2 8_1 mRPL 12_8 12_1 10_2 8_1 mRPL
Scénarios Scénarios Scénarios

(c) (ré) (e)

Figure tuConcernant 8 : Résultats de la simulation pour une topologie de réseau avec huit points d'accès. (a) scénario de
(b) simulation, délai de transfert, (c) taux de livraison des paquets, (d) temps système total en termes de messages de
et contrôle, (e) nombre total de DAO.

Al un retard plus long entraîne plus de pertes de paquets car le MN n'est connecté à aucun

PA . Dans mRPL, le MN est capable d'envoyer des données au parent précédent pendant la
505 DisPhase de couverturejusqu'à trouver un nouveau parent préféré. Ce mécanisme augmente
la chance de livrer la plupart des paquets de données, comme le montrent les figures 6(c), 7(c) et 8(c).

unré
Le surdébit de message de contrôle de mRPL est comparable au
R P Réglages L avec surcharge minimale.En RPL, après avoir créé des DODAG
510 pendant phase d'initialisation, si le réseau reste stable, la périodicité de
les échanges de messages de contrôle convergeront vers sa valeur maximale. Par exemple,

selon le tableau 3, dans le<12,8>Scénario RPL, la périodicité est de 1048.576 s

et avec<8,1>est 0.512 art. Un taux de transmission de messages plus élevé augmente la

surcoût du réseau. Dans mRPL, les paramètres Trickle sont définis en fonction du scénario

515 RPL avec la surcharge la plus faible (<12,8>). Les messages de contrôle supplémentaires

déclenchés par le transfert sont invoqués à la demande. Ainsi, dans un débit de données élevé

réseau, similaire à notre exemple (avec 30 pkts/sec), mRPL a un montant plus élevé

des frais généraux par rapport au RPL. La comparaison de différentes topologies de réseau montre

24
 que l'ajout de nœuds voisins (AP) supplémentaires augmente la surcharge du réseau - voir

520 les figures 6(d), 7(d) et 8(d). Ajouter plus de points d'accès dans le voisinage d'un MN

augmenterait le nombre de paquets de réponse dans lePhase de découverte, finalement

augmentant les frais généraux.

mRPL est très sensible à la dynamique du réseau.Le nombre total de DAO est
un indicateur pour montrer les efforts de création de nouvelles connexions.
525 Étant donné que RPL n'a pas de mécanisme de transfert explicite, un parent qui réussit

la sélection est identifiée par les transmissions DAO. Dans la topologie 1 (avec deux points d'accès),

mRPL a le plus grand nombre de nouvelles connexions, ce qui montre un transfert précis lors de chaque

voyage. L'ajout de points d'accès supplémentaires dans la topologie 2 entraîne la création

plus de connexions en RPL et en mRPL. Dans un déploiement plus dense (Topologie 3),

530 il y a plus de chevauchements entre les liens et donc le nombre total de DAO
réduit le RPL et le mRPL. Cependant, mRPL est toujours capable de basculer en douceur entre les points

d'accès avec seulement 1.4 % de transferts en moins, tandis que RPL réduit les nouvelles connexions

jusqu'à 63 % — voir les figures 6(e), 7(e) et 8(e).

6.3. Évaluations supplémentaires sur la vitesse, le cycle de service et la densité du réseau

535 À ce stade, nous visons à étudier l'impact de la vitesse du nœud mobile et du cycle

d'utilisation du réseau sur les performances en trafic de données élevé et faible dans un

déploiement réseau plus compliqué. L'homme a tendance à marcher à des vitesses allant de

près de 0 m/s à plus de 2 m/s. Dans nos simulations, nous avons appliqué une gamme plus large

des vitesses de 0.5 à 4 m/s. Nous avons également supposé diverses périodes de transmission de

540 données de 50 ms, 100 ms, 500 ms, 1 s, 2 s et 5 s. Nous avons employé un MN et 12 AP

répartis en quatre niveaux de rang, comme illustré à la figure 9(a). MN commence son voyage à partir de

le voisinage dePA1et parcourt tout le réseau à travers les pointillés, puis

s'arrêtant pendant 30 secondes à la position initiale, tandis que la simulation dure deux

minutes.

545 mRPL est efficace pour la gamme de vitesses de marche humaines normales.

Nous définissons l'efficacité lorsque nous avons des outils manuels rapides, légers (faibles frais généraux) et fiables.

à l'arrêt. Les résultats des figures 9(b), (c) et (d) montrent que le délai de transfert et la surcharge

du réseau sont très faibles, dans tous les scénarios. Il y a des fluctuations dans le paquet

25
 100
80

RDP (%)
60
0,5 m/s 1 m/s 2 m/s 3m/s 4m/s Statique
40
0,05 0,1 0,5 1 2 5
4m 8m Période(s) de transmission des données

(b)
100

Het −def Retard (m s)

0,5 m/s 1 m/s 2 m/s 3m/s 4 Mme
12 11 dix

4m
90
sept 8 9

8m
80
0,05 0,1 0,5 1 2 5
6 5 4
Période(s) de transmission des données

PA
(c)

droite un d
1 2 3 MN 800
Racine
0
600

(a) déploiement de nœud jeOvee

un 400
0,5 m/s 1 m/s 2 m/s 3m/s 4m/s Statique
Total

200
0,05 0,1 0,5 1 2 5
Période(s) de transmission des données

(ré)
tu 9 : jemPACt oF Vitesse MN ré sur la performance mRPL mun
Figure concernant nce avec différent netrafic de travail sur ( b)
PACket deliv éry r à io, (c ) un
veuh
age Hanré- rée , un nré(ré) à tal surchauffe ré.
à l'arrêt allonger

r vois
je te
épicerie fine r tio. jen gh trun
salut fficmero
c n ri s, by e jeg mobile non
augmentercomme n rée speeré, the
550 PACket réelrivière y reduc es. F ou Je ntne,
s unc Wie 50 ms un
nré100 Mme
réaap
t euh
je
ods,
PACket réeje
rivière y run o s par≈%un
tio rérp 4 ré≈ 6%r especit vely, quoi
en je
NCe
r asi ng
MN speéd dem 50.m/s tup à 4 m/s .Th e mamanje
n re surestil
tcomme h nge je
n til
Californie

stunje
rt ng un réed
n ng
je mmn
o e ts detil s'enun - ff poe
fout r c ss. Sà moi untap un
ckets dans
hje
gil r speéd scenrun
je m un
os y dropdeo
tu t thesejemn
jeg beha vje ors. B oui
je ering til
555 t
da un trun
nsmisdonc
jen par je
od , t il T ric k
eje
tim r e et the mRPL jemerduce sr e e eir
perio réje
cje
ty à réduquer n etwtravail oe
v tête
r T. hest e ffec t nous
es somoipun
Californie cketd rops
rétue to e e retard réhun
nd- hors processus s. Wi th low données perios,
ré til emballe et devivre très
rajeo With différent NTmobjeje
enœud sp ee réhsun
plus de grippe cttu
uneso s. Succès ufsLP ket courant alternatif

rétous
li r rédépend on performing a h
an -ré
ffo bavant de re courant
salut ng un
n PA. J il Hand-
alternatif à l'arrêt

560 Startdans
instant g réepends sur le t moi
je o s (J
tu ts dele temps euh C un
ndJMARYLAND ). J ONU
ing
these jemers en ln
o ger r
périodes je àc
écoulées iv ity net non
rks cun
nous
es sud den p ket courant alternatif

rérops . La ck de suffi cieNTcontrôle

o mess un
g es dans
faible tr affic scenarpos ios tpsur
es la
hun
nd-off traiter. B y loweuh
ing l'aa ré t peride 100 ms to 5 s, t il uneuh
Vâge
punc ke t delivrée r à je
o ops de 24 % .
docteur

565 mR P L a s le s voertête en bas trun

ffic ne deux
ouk.n
s mRP
je L, mois
billet ité

26
 la détection est fonction de la dégradation de la liaison (ARSSI), du temporisateur de connectivité et du

temporisateur de détection de mobilité. Nous adaptons la minuterie de connectivité en fonction de la

Intervalle d'entretien plus grand et minuteur de détection de mobilité en fonction des données

périodes pour réduire la surcharge du réseau. Intervalles fixes et faibles de ces minuteries

570 dans les scénarios à faible trafic, réduisez la surcharge du réseau. Par exemple, la surcharge dans un scénario de

faible trafic de données (par exemple, transmission de données toutes les 5 s) est inférieure de 30 % à

le scénario de trafic de données élevé (par exemple, transmission de données toutes les 50 ms).

Les scénarios à faible trafic nécessitent des retransmissions de données pour maintenir le réseau

fiabilité.En agrandissant le temporisateur de détection de mobilité dans des scénarios à faible trafic, certains des paquets

575 de données peuvent être abandonnés. En cas de perte de paquets de données, processus de transfert

reprend qui mène au changement de parent. Après un processus de transfert, MN a une bonne

connectivité avec le parent préféré. Par conséquent, nous proposons une retransmission des données

mission sur le nouveau point d'accès immédiatement après le processus de transfert pour maintenir la fiabilité

du réseau.

580 Le délai de transfert est faible quel que soit le trafic réseau et le nœud mobile

la rapidité.Le transfert dans mRPL est un processus qui nécessite un certain nombre d'ex-

changements pour évaluer les points d'accès voisins. Ce processus est très rapide et prend environ 85

ms avec quelques fluctuations dans divers scénarios.

Nous avons également évalué mRPL sans existence de nœud mobile. Figures 9(b) et

585 (d) montrer queun nœud statique est capable de transmettre avec succès presque tous

paquets de données à l'infrastructure fixe.Le surcoût de cette expérience est le minimum,

puisque des messages de contrôle supplémentaires ne sont pas générés de manière statique.

environnement.

La conception MAC à cycle de service (ContikiMAC) réduit la consommation d'énergie.

590 période d'inactivité périodique. Dans ContikiMAC, si une transmission de paquet est détectée

pendant une période de réveil, la radio reste allumée pour recevoir le paquet. Un F-

Après avoir reçu un paquet avec succès, le récepteur envoie un accusé de réception de couche liaison.

Selon ce comportement, dans mRPL, MN continue d'envoyer une rafale de messages DIS

jusqu'à la réception et la réponse par le point d'accès voisin, comme représenté sur la figure 10

595 (a). La radio du récepteur 1 est toujours allumée (NullMAC) et peut immédiatement détecter

les transmissions de paquets du MN, et donc, le processus de transfert est le

27
 le plus court possible. En appliquant une approche de cycle de service, les paquets de demande sont

détectés plus tard et le processus de transfert prend plus de temps (MN continue d'envoyer des rafales

de messages DIS jusqu'à la réception d'une réponse d'un point d'accès voisin). Augmenter la

600 période de sommeil détériore les performances en termes de réactivité (comparer

Récepteur 2 vers Récepteur 3)6.

L'augmentation de la période d'écoute dégrade les performances de transfert.

Nous avons analysé l'approche du cycle de service en modifiant les taux de vérification des canaux

(64, 32 et 8 Hz) et étudié les performances du réseau –voir Figures 10 (b)-

605 (ré). La réduction des taux de vérification augmente les périodes d'écoute, ce qui allonge le

délai de transfert. En augmentant le taux de contrôle de 64 Hz ou 15.625 ms à 8 Hz ou

125 millisecondes (87.5% d'augmentation de la période d'écoute) avec 1 (s) période de transmission de données,

le délai de transfert passe de 115 ms à 156 ms (c'est-à-dire une augmentation de 26 %), ce qui

est raisonnable. Par conséquent, de longs transferts réduisent le taux de livraison des paquets et

610 augmentent la surcharge du message de contrôle. La tendance des performances du réseau

la dégradation par augmentation de la période d'écoute est similaire dans tous les scénarios avec

diverses périodes de transmission de données.

Le délai de transfert est faible dans un scénario de modèle de mobilité aléatoire.Nous avons

créé un scénario dans lequel la vitesse du nœud mobile change par intermittence et le

615 la trajectoire varie, tandis que le nœud mobile se déplace dans la zone de déploiement.

En comparant le scénario aléatoire avec le scénario à vitesse constante (2 m/s) avec

la fréquence de vérification de 64 Hz sur les figures 9 montre que le retard de transfert dans tous les

trafics de données est inférieur à 100 ms. Cependant, il y a des fluctuations dans le PDR et le

surcoût du scénario aléatoire par rapport au scénario à vitesse constante.

620 Les résultats indiquent une différence de PDR entre 1.5 % et 54 % et les frais généraux

différence de 0.2% à 14.2 %. Généralement, nous observons que dans un scénario de vitesse aléatoire,

les performances avec des trafics de données plus élevés se dégradent plus que les plus faibles.

trafic de données, par rapport au scénario à vitesse constante.

6Dans ContikiMAC, il est nécessaire d'obéir à un timing précis entre les transmissions. Il utilise
Effacer l'évaluation du canal(CCA) qui lit la mesure RSSI pour détecter l'activité du canal. L'analyse
temporelle dans [38] montre qu'une taille de paquet minimale de 23 octets est nécessaire pour que le
mécanisme CCA fonctionne correctement. Nous respectons cette limitation dans nos simulations et
expériences car la taille des paquets basés sur IPv6 est normalement beaucoup plus longue.

28
 100
Rafale de transmission DIS 80

RDP (%)
60
40
64Hz 32Hz 8Hz 64 Hz−rand
Expéditeur 20
0,05 0,1 0,5 1 2 5
Période(s) de transmission des données

Récepteur1 (b)
200

y (ms)
Hand−off Del un
Récepteur2
100
64Hz 32Hz 8Hz 64 Hz−rand
Récepteur3
0
0,05 0,1 0,5 1 2 5
Période(s) de transmission des données

Fenêtre d'écoute (c)

Délai de transfert
15000

Total Oje ril a ré

Réception gagnante réaïe 64Hz 32Hz 8Hz 64 Hz−rand
dix000

Transmission DIS sur 5000

0
(a) Exemple de transfert retarder wi e diffèrent fr turé ty 0,05 0,1 0,5 1 2 5
Ce unTransmission Par iode(s)
cycle es.
(ré)
Figure 10 : Je ampct ofn etwoukd Utah y cycli ng on mR Performances PL wça diffère eNT réseau
trafic sur (b) PACkd
et élivoiry ratio, ( c) un
je rage hun
nré- éteint d elay, un ré (ré) t total o veuh
hlire .

300
(pkts)

250

200
Ov h annonce
euhe

150

100
1 2 3 4 5
No. oFneighbors

Figure 11 : Incidence denetnon

rk dn
e sité o NToTal ovoiril un d.

Réseau rk densité a ad directement lutin courantt alternatif

sur le nedeuxrk vo hein
r lire. Dans-

625 froissant l'engourdissement er des points d'accès dans un chanter le broun

dcast dom ain augmente e e chiffre beuh

de DIO répond en th eDécouvrir ry Phase d'unhet-off pr d'oc

ess, comme dép ticed dans F ig-
ure 11. Ceci également dans des plis t poule etdeux rk vo euh
tête de m PR L. Un sage deplym ent
points d'accès dans un vrai ex périment rouge uces t il netwtravailler sur hchd drastique lly.

7. Expérimental Évaluer ion

630 Dans cette section, nous expliquons la configuration du réseau expérimental afin de tester

et comparer RPL et mRPL. Le paramétrage, la configuration topologique

tion et les scénarios sont décrits.

29
 MN

Racine
4 3 2 1

(un) (b)

9 5 2
4
1
sept
3
8 6

(c)
Figure 12 : Évaluation expérimentale, (a) le MN attaché à l'épaule, (b) Configuration expérimentale 1 avec 4
points d'accès et un MN déployés dans une rangée, et (c) Configuration expérimentale 2 avec 9 points d'accès
répartis dans le laboratoire.

7.1. Configuration du réseau

Afin de réaliser des expériences réalistes, nous avons attaché le nœud mobile au

635 corps d'une personne (Figure 12 (a)) et connecté au PC de journalisationseptcollecter

l'information. Les expériences ont eu lieu dans une grande salle avec 80m2taille et

tous les nœuds fonctionnaient avec leur puissance de transmission minimale (−25 dBm).

La figure 12(b) (Configuration 1) montre un scénario où des points d'accès contigus fournissent un

chevauchement minimal. Cette situation a été obtenue en sélectionnant la puissance d'émission la plus faible

640 (niveau de puissance = 1) et localisation des points d'accès avec un 0.Séparation de 3 m. D'une manière plus réaliste

scénario, configuration 2, nous avons déployé au hasard 9 points d'accès dans la pièce (comme illustré dans

Figure 12(c)). Les points d'accès étaient fixés aux murs à 1,5 m de hauteur du sol (pour

garantir une meilleure connectivité). Nous montrerons les résultats plus tard r dans ce

section.

septAu début, nous connections tous les points d'accès à un ordinateur portable avec USB passif câbles et
Concentrateurs USB2.0. Ensuite, nous avons observé une certaine perte de données lors du transfert de données via le port UART.
L'ajout de PC n'a pas complètement résolu le problème. Par conséquent, nous avons réussi à obtenir les données
journal du MN avec le coût d'une personne portant un ordinateur portable pendant l'expérience.

30
 100
50 700
1 paquet/s
1 paquet/s 1 paquet/s
10 paquets/s
80
10 paquets/s 600 10 paquets/s
20 paquets/s
40 20 paquets/s 20 paquets/s

Nombre de DAO
30 paquets/s
30 paquets/sec 500 30 paquets/s

Frais généraux (%)

60 30
RDP (%)

400

40 300
20
200
20 dix
100

0 0 0
12_8 12_1 10_2 8_1 12_8 12_1 10_2 8_1 12_8 12_1 10_2 8_1
Scénarios Scénarios Scénarios

(un) (b) (c)

Figure 13 : Expérimenter Tal S etup 1, C ompardans g rompre tous les RPL cenarios jen termes of (a) paquet
livraison ratio, (b) frais généraux, et (c) n nombre de DAO.

645 RPL configurations.En ge En général, les appareils RPL jouent le rôle d'un routeur ou nous

e. Dans nos expériences,

hochement de tête racine considérons une racine unique qui collecte toutes les données.

Le ca cles points essentiels et les nœuds mobiles sont des routeurs ; les MN génèrent des données et
les points d'accès les transmettre à la racine.

Dans
oAfin de comparer RPL avec mRPL, nous avons créé le meilleur RPL possible pour basculer
650 réglage t rapidement entre les parents lorsqu'un nœud enfant se déplace. Typiquement, dans

RPL, unle nœud enfant doit détecter une valeur ETX élevée pour déclencher un commutateur parent.
Le fr qe uence des mises à jour ETX dépend du trafic réseau en termes de taux
de données / uncontrôler les échanges. Nous avons considéré le débit de données le plus élevé
augmenter se possible pour la réactivité du routage RPL à la dynamique du réseau.

655 7.2. R e résultats et discussion

Configuration expérimentale 1.Nous comparons divers scénarios RPL avec mRPL dans

une topologie de réseau simple présentée à la Figure 12(b), qui fournit un chevauchement minimal entre

les points d'accès contigus. Tous les nœuds exécutent NullMAC (à plein temps), ce qui

est plus utile pour comparer mRPL et mRPL sans effet de paquet
660 les pertes et les retards inhérents à un protocole de cycle de service.

Tout d'abord, nous évaluons le taux de livraison de paquets de divers scénarios RPL (précédemment

définis dans le tableau 3) avec différents débits de données. Notre analyse indique que

un trafic de données plus élevé entraîne un taux de livraison de paquets plus faible.Des valeurs plus petites

de la minuterie d'entretien et du taux de génération de données élevé augmentent le trafic réseau,

31
 100 20
mRPL

Frais généraux (%)

15
RPL mRPL

RDP (%)
50 dix RPL

0 0
12_8 8_1 12_8 8_1
Scénarios Scénarios
(un) (b)

Figure 14 : Comparez RPL et mRPL en termes de (a) PDR et (b) surcharge dans la configuration
expérimentale 1.

665 qui dans taugmentation de l'urneun

voir le c risque de collision de paquets — voir Figure 13(a). La
paquet d rops sont mo re signifi cant dans les minuteries d'entretien plus grandes (par exemple<12,8>), qui
résultats en n début 46 % paquet baisse lors de l'augmentation du débit de données de 1 à 30

paquet/s, w salutje
e le bas r
heure la plus courte sréglage (<8,1>) expositions près de 29 % de baisse.

Sma ll evaleurs r de la La minuterie d'entretien impose des paquets de contrôle plus élevés

670 surchauffe ré en RPL . La vo erhead est calculé en fonction du pourcentage de

l'ICM P v6 paquets s sur e e nombre total de paquets (paquets ICMPv6 + données
paquets) . F Figure 13 ( b) montrer s que les frais généraux de RPL augmentent lorsque vous choisissez

ing sma jele

r Filet valeurs ( < 8,1>sc enario donne plus de message de contrôle

échanger es comparer réavec ot ses scénarios). Un taux de transmission de données inférieur

675 résultats dans un hplus élevé par centage o FCsurmessages de contrôle par rapport au nombre total
de paquet te xchanges .

La réussite de la commutation parent est basée sur le débit de données et le

Réglage du filet.Le nombre de DAO correspond au nombre de nouveaux liens

créés entre un enfant (MN) et un parent voisin. Une donnée élevée
680 le taux de transmission augmente les mises à jour de la valeur ETX. La figure 13(c) montre que

dans tous les paramètres, plus le débit de paquets est élevé, plus les transmissions DAO sont faibles.

De plus, des valeurs de Trickle plus petites augmentent le nombre de paquets DAO.

Les performances mRPL sont indépendantes du paramètre Trickle.En réalité,

mRPL utilise les messages de contrôle RPL comme mécanisme de secours. Nous avons comparé mRPL

685 avec deux scénarios RPL extrêmes (<12,8>et<8,1>). La figure 14(a) montre
que quel que soit le paramètre Trickle, mRPL parvient à fournir correctement

32
 100 700
100 1 paquet/s 1 paquet/s

10 paquets/s 600 10 paquets/s

80
90 20 paquets/s 20 paquets/s

Nombre de DAO
30 paquets/s 500 30 paquets/s

Frais généraux (%)

80 60
400
RDP (%)

1 paquet/s 40 300
70
10 paquets/s

20 paquets/s
200
60 30 paquets/s 20
100

50 0 0
12_8 12_1 10_2 8_1 12_8 12_1 10_2 8_1 12_8 12_1 10_2 8_1
Scénarios Scénarios Scénarios

(un) (b) (c)

Figure 15 :Configuration expérimentale 2, Co mpair g divers scénarios RPL dans une topologie de réseau plus
réaliste je
n termes de (a )p épicerie fine very ratio, (b) overh chdn, und (c) nombre beuh
des DAO.

la plupart o F les données p un

ckets (près je
y 100%) . Noter ta
h t conduire t
concernant he Minuteries d'entretien
diminue eStil mRP L p acquittement ception rmangé par o NLy 2%, comme le réun
ta paquets sont

r
plus de po ne à colli rée avec le csurtrojepaquets. J he tuse de Tri ckle en tant que sauvegarde
690 en mRP L soulève e eo je tête o Ft il Algorit mnje terms d'un réréceio contrôle final
message e des échanges. Hfr ce, dans mR PL ceestrecommend ed à nous ch frais généraux faibles

Filet s réglage ( e. g. < 12, 8 > , un

s réepjeen fa igtu 14(b)).
concernant

Expe rimen t Al S UE
t p 2. O e exteterminé le eet Sts par depl otoing AP comme de-
je Chiffre 12(b) .
illustré m Tout non rées we tunifié à trun
concernant nsmit po wer niveau 3 (−25
695 dBm), w haute cre unt ed h igheuh
voeuh
lap betentre le neighbor APs. UNnœud racine était
placé nje le ce nter opi he room. Jh e portable node w comme attac HD
e à une personne

jele
bras (ao ré HD
e pà un récewun
comme s génère dansp ckets à dff
Géorgie je taux érents.
Ah je
gher vo euh
je
unp of le w ir eless je
je
nks je nra
c e c'est le pcunlivraison de ket
rapport.Apparent ly, yc
b manger
concernant mouet un P crique ravas-y
e v rlappin g, moe
r p acquittements

700 avoir la possibi yoe t th

allumé ch r un e désjenàion. Hoer
w je , an
RPL c n passuport
n reu
haute transmissio à sdernm nosobility, un
est montré dans
F je
gure 15 (a ). C ouNT
plutôt,

expériences rev un
e lechapeau
t je n un eXtreme cn
o dition avec 03 pk/s
t ce Les données

taux, mRPL encore pour

ra
w rds 99.sept% ofd aa
t p acquittement s.
Figure 15(b) shSST
w overh
t e chréoFRLPsce a n Rioswhcediff e euh
NTréun
ta les taux.
705 mil ar à
Les tendances sont si haut e et Ex perimentAl Setup 1. Le meilleur RP L t dans
g avec
Positionner

débit de données est<1 2, 8>, quoi jehl chrés à th e lopoids

essupérieur chré. J o tupdate
m je
les informations de routage ao n, R PL être ne msr
F ole adapter réun
ta comme w bien comme coNTrol mmessage

33
 des échanges. Avec le même paramètre dans une application à débit de données élevé (30 pkt/s), mRPL

a entraîné une surcharge de messages de contrôle supplémentaire de 1 %.

710 Le chevauchement des liaisons supérieures réduit la possibilité de changement de parent.

Le nombre de nouveaux liens est plus petit que pour la configuration expérimentale 1. En comparant

les résultats de la Figure 13(c) et de la Figure 15(c) dans une condition de débit de données élevé, nous

concluons que l'établissement de nouveaux liens (dans une topologie de réseau plus réaliste)

pour<12,8>et<8,1>Les scénarios RPL réduisent respectivement de 14 % et 31 %.

715 Ainsi, nous en déduisons que la connectivité des liens supérieurs retarde le processus de parent

commutation, et donc diminue le nombre de DAO.

Le RPL standard n'a pas de mécanisme de transfert intégré. Par conséquent, il est difficile de

calculer le délai de transfert en RPL. En simulation, nous avons présenté une approximation

estimation du délai de transfert pour différents scénarios RPL. résultats empiriques

720 montrent que mRPL a un processus de commutation parent très rapide avec un délai de transfert d'environ 88

ms, conduisant à un taux de livraison de paquets très élevé même avec des données élevées

taux de transmission.

Un aperçu plus approfondi de la configuration expérimentale 2.Les expériences en intérieur im-

poser certaines limites sur la performance globale. L'emplacement des points d'accès, des

725 meubles, des personnes et des interférences externes affecte les performances de transfert. Dans

Figure 16, les flèches correspondent au basculement parent (d'un point d'accès à un

autre). L'épaisseur des flèches indique la quantité de transfert/s dans le

lien correspondant. Notez que les transferts ne sont pas toujours effectués entre les points d'accès les

plus proches. Cela signifie que la grande variabilité des liaisons sans fil à faible puissance

730 et le comportement dynamique du réseau mobile peut dicter de ne pas choisir le

points d'accès les plus proches. La figure 16 illustre également (avec des cercles) la quantité de paquet ex-

change avec mRPL à chaque point d'accès. Des cercles plus grands signifient plus de paquets

reçus (nœuds 3, 5, 6 et 7). Nœuds dans une région de bonne connectivité (emplacement central)

peut maintenir la connexion plus longtemps que ceux des côtés droit et gauche de

735 la salle (Nœuds 1, 2, 8 et 9) ; donc plus de paquets sont reçus avec succès par
points d'accès "centraux".

La figure 17 montre le taux de livraison des paquets et le RSSI moyen à chaque

AP (liaisons 1 à 9 du MN vers les AP). Il existe une corrélation entre

34
 9 5
2
4
Racine
1
sept
3
MN
6
8

Figure 16 : Représentation du mouvement du nœud mobile dans la configuration expérimentale 2.

100 − 90

95 − 85

RSSI (dBm)
RDP (%)

90 − 80

85 − 75

80 − 70
123456789 123456789
Liens Liens

Image 17 : P le taux de livraison des accusés de réception et la mesure RSSI moyenne de chaque lien dans Experi-
Configuration mentale 2.

la moyenne RSSI et la DPR dans chaque lien (un ARSSI plus élevé conduit à un
740 RDP). Ce s signifie qu'un transfert déclenché dans la région de transition de
les sans fil s lien peut se traduire par une très bonne performance. Garder la moyenne
RSSI et la PRD hg
jeh req tuirrite un véry c ae
r plein d ecision surla mmoment s de
démarrer une d fr chanter un het-o ff: proche r au je
oous heureeshol faisf le transiti surAl
région wou ld r educ e e pac kela charcuterievery dr às ment. Nœud
s 3 et sept mois
sommes concernant

745 bénéficié en tant que tu es PLJ'ai réussi n Suite sttauxgi c place sw avec b etter A RS SI.

7.3. Simulation contre e XPerime NTal res tuje

ts
Nous comparons d le résultats
concernant o F le si moilatio nouveauavec t he expérimenterje suisental test dans til
ensemble de deux réseaux UPS: (je)Experimentun
jeInstaller 1 comme depje t'ai dit n Figure e 12(b) un
nd
(ii) Expérience al Set en haut2 comme réépicte réEn figue ture 12 ( c) ). E e résultat si n Ta ble 4
750 montrer que le p erfor mance je n termes of pac kela charcuterieje ry un rémain- à l'arrêt delay dans

l'expérimentation je teste s sont rel un

activement bplus tard hun e es imule tion.m. J il plus de il un d
dans Setup 2 redu ces d rastical y comme e e lien o verlap être interpolation til ne ighbor UN
PS
est plus élevé que moi Et le simiter ion.m. M orde plus, til ra réje
o mod el de th e simultané à ou

35
 Tableau 4 : mRPL : simulation versus résultats expérimentaux

Scénarios Sim. résultats Exp. résultats

RDP=98,12 % RDP=99,77 %
Configuration 1 (Figure 12(b)) Frais généraux = 18,8 % Frais généraux = 7,63 %
Retard = 81 ms Retard = 92,7 ms
RDP=99,56 % RDP=99,68 %
Configuration 2(Figure 12(c)) Frais généraux = 2,85 % Frais généraux = 2,43 %
Retard = 86,21 ms Retard = 88,2 ms

est imprécis (principalement basé sur la distance entre les nœuds). Cependant, dans

755 le monde réel, divers paramètres physiques et environnementaux affectent la radio

maquette.

8. Travaux connexes

La prise en charge de la mobilité dans les réseaux basse consommation basés sur IP est un sujet de recherche récent.

Le 6LoWPAN a été introduit pour faciliter la transmission des packs IPv6.

760 ets sur des réseaux à faible puissance. Il intègre une couche d'adaptation entre
les couches réseau et liaison de données. Deux schémas de routage sont utilisés
dans 6LoW-PAN, selon la couche qui prend la décision : (i) mesh-under et (ii)
route-over [5, 39]. Des solutions de mobilité sont appliquées sur ces schémas de routage.

Le routage maillé prend en charge la communication dans un seul domaine de diffusion,

765 où tous les nœuds peuvent se joindre en envoyant un seul datagramme IP. Ce schéma

nécessite un routage de couche liaison, car la topologie multi-sauts est abstraite

en utilisant le support IPv6. Le routage de routage prend en charge un maillage multi-sauts

communication, où seuls les voisins immédiats sont joignables dans un même

émission de lien.
770 Dans les sous-sections suivantes, nous abordons certains des travaux connexes sur mo-

prise en charge de la capacité qui se concentre sur les schémas mesh-under et route-over. Nous résumons-

marier ces travaux et leurs principales caractéristiques dans le tableau 58, y compris la solution

8Les performances élevées/faibles des algorithmes basés sur IP activés pour la mobilité sont des
estimations approximatives par rapport à la mise en œuvre mRPL. Les explications sur ces estimations
sont fournies dans les sous-sections 8.1 et 8.2.

36
 nous proposons dans cet article —mRPL— pour la commodité des lecteurs.

8.1. Solutions de mobilité au sein de 6LoWPAN

775 Dans [40, 41] une version allégée de Mobile IPv6 sur 6LoWPAN est évaluée. Dans

Mobile IPv6, la détection de mouvement est basée sur la découverte de voisins, qui est op-

rationnel dans 6LoWPAN [32]. Dans ce travail, les auteurs ont proposé Mobinet qui

repose sur la surécoute dans le voisinage d'un nœud mobile. En détectant tout

changements dans le voisinage, le nœud mobile envoie une sollicitation de routeur afin

780 pour reprendre la découverte du voisin. L'audition nécessite la réception de tous les

paquets nécessaires par les points d'accès voisins, ce qui augmente la surcharge du réseau et par

conséquent la consommation d'énergie.

L'écoute des activités de voisinage du nœud mobile augmente la re-

réactivité pour détecter l'événement de mobilité. Les auteurs affirment que la main-

785 le délai d'arrêt avec la conception légère MIPv6 est≈130 ms (≈85 ms en mRPL), tandis que le délai

de sollicitation pour la sollicitation périodique du routeur est de 1 s. En mRPL, la pe-

riodicité du temporisateur de détection de mobilité qui garantit la connectivité réseau

varie selon les activités du réseau. Dans les réseaux peu connectés, le temps
out s'agrandit, ce qui réduira par conséquent les frais généraux.

790 Dans LowMOB [42], la détection de mobilité est basée sur des trans-
missions à partir des nœuds statiques. Un nœud mobile rejoint le point d'accès avec le plus haut

Niveau RSSI. La prise en charge de la mobilité est basée sur l'IPv6 mobile classique. Ça aussi

prend en compte les points d'accès à cycle de service, où les radios sont éteintes par intermittence. En

observant une faible qualité de liaison au point d'accès actuel, il active le prochain

795 mangé AP. Pour ce faire, le point d'accès actuel exécute un mécanisme de localisation en utilisant

nœuds supplémentaires, appelés points d'appui à la mobilité (MSP), pour trouver la direction

du MN.
Le délai de transfert minimum de LowMOB dans un scénario à saut unique est≈100

ms, ce qui est comparable au délai de transfert en mRPL. Utilisation supplémentaire

800 le matériel pour maintenir le support de mobilité est l'un des inconvénients de Low-

FOULE. Dans mRPL, nous activons le processus de transfert sur les nœuds mobiles sans

ajouter de matériel ni toucher au mécanisme RPL par défaut. Le MIPv6 conventionnel

37
 et l'approche de localisation utilisée dans LowMOB nécessite de nombreux échanges

de paquets afin de détecter la mobilité et de maintenir le routage. Cette approche

805 nécessite du matériel supplémentaire et des capacités de traitement élevées. Ces deux fonctions

tures sont les principales limites des réseaux de faible puissance.

Le réseau de mandataires (NoP) [18] fournit un support de mobilité sans interférer avec le

comportement normal du WSN. Les auteurs utilisent des dispositifs supplémentaires,

qui sont appelés mandataires. Les appareils NoP sont sans contrainte de ressources et gèrent

810 la procédure de transfert (pour le compte des nœuds capteurs). Similaire au LowMOB de-

signe, NoP nécessite du matériel supplémentaire. C'est l'un des principaux inconvénients de la

conception NoP.

Les mandataires sont chargés de surveiller le RSSI des MN et de le partager

informations avec d'autres procurations. En analysant ces informations, les mandataires décident

815 pour le prochain meilleur parent du MN. Le nœud mobile est programmé pour envoyer périodiquement

des paquets ICMP aux mandataires. Ensuite, les proxys communiquent avec chacun

autre pour maintenir la connectivité réseau en effectuant un processus de transfert pendant

mobilité. La nécessité d'une signalisation périodique entre le nœud mobile et un proxy

et également parmi les proxies augmente les frais généraux du réseau et la consommation

820 d'énergie. Dans mRPL, le balisage s'arrête s'il existe une activité dans le support.

De plus, les points d'accès voisins ne répondent que s'il y a un besoin de transfert. Le minimum

le délai de transfert dans NoP est≈117 ms, ce qui est supérieur au transfert mRPL

retard.

8.2. Solutions de mobilité au sein de RPL

825 Dans [43, 44], les auteurs se concentrent sur l'aide à la mobilité en RPL. Le modèle du système

suppose un ensemble fixe de nœuds, tandis que les MN accèdent directement aux nœuds fixes

ou via plusieurs sauts via d'autres MN. La détection de mobilité est obtenue en employant

une minuterie fixe (au lieu de la minuterie d'entretien). Les auteurs ont conclu

qu'avec une transmission DIO plus élevée, la connectivité augmente, au détriment

830 de frais généraux supplémentaires. Pour augmenter la réactivité du réseau, les paquets DIO sont

transmis plus fréquemment. Cette méthode augmente la surcharge du réseau et la

consommation d'énergie. Dans mRPL, la périodicité de la transmission DIO est réglée en fonction

38
 sur la période de transmission des données pour minimiser la surcharge.

Lors de la recherche d'un nouveau voisin, le sondage immédiat met à jour la valeur ETX à

835 sélectionner le parent préféré en temps opportun. Pour éviter les boucles après le transfert, le

les nœuds enfants sont supprimés de l'ensemble parent. Le modèle proposé a un haut

surcoût en termes de balisage fixe et périodique. De plus, il désactive le minuteur

Trickle, ce qui est très utile en l'absence de mobilité. Les évaluations
sont effectuées sur un réseau véhiculaire ad hoc (VANET) avec 24 Mbps
840 taux de transmission et une vitesse minimale de 25 mil/h. Les résultats indiqués

la livraison de paquets d'environ 80 % pour un scénario avec un MN et un AP

(par rapport à≈100 % en mRPL), qui a augmenté à≈100 % jusqu'à 10
MN. L'augmentation du nombre de nœuds mobiles dans une région augmente le réseau

connectivité.
845 ME-RPL [45] suppose que les nœuds mobiles sont identifiés dans les nœuds RPL statiques. En

activant un algorithme d'apprentissage, les nœuds qui changent de parent plus

interrogent souvent leurs voisins avec des intervalles DIS inférieurs. Cela signifie que le DIS

L'intervalle est dynamique en fonction des incohérences du réseau. Cette stratégie est

également utilisé dans mRPL pour ajuster dynamiquement l'intervalle de balisage et réduire la

850 surcharge du réseau et éventuellement la consommation d'énergie. Les MN sélectionnent

nœuds statiques avec des liens de haute qualité comme leurs meilleurs parents.

Dans ME-RPL, les mouvements brusques ne sont pas détectés en temps réel, car un apprentissage

algorithme de calcul est utilisé. Ainsi, le problème de la faible réactivité du routage RPL pour faire

face aux changements environnementaux et aux incohérences existe toujours. Dans

855 mRPL, une minuterie assure la détection en temps opportun des mouvements brusques (c'est-à-dire

temporisateur de détection de qualité). Le réglage de cette minuterie garantit la réactivité du réseau. Dans

ME-RPL, le taux maximal de livraison de paquets est≈85 %, qui est surpassé

par mRPL (environ≈100 % RDP).
MoMoRo [46] prend en charge la mobilité dans un réseau de trafic clairsemé qui exécute RPL. Ce

860 crée une couche supplémentaire entre la liaison de données et les couches réseau pour gérer

détection de mobilité. Après un échec de transmission de paquets, MoMoRo fait une nouvelle

tentative pour atteindre la destination en transmettant un paquet unicast. S'il échoue

encore une fois, MoMoRo commence à chercher un nouvel itinéraire en diffusant des balises et

39
 Tableau 5 : Solutions de mobilité dans les réseaux IP basse consommation

Routage Mobilité Mobilité Supplémentaire

Référence Performance
mécanisme détection la solution Matériel
frais généraux élevés
MIPv6 léger [40, 41] sous-maille entendre par hasard léger MIPv6 non haute énergie
très réactif
périodique frais généraux élevés
FaibleMOB [42] sous-maille balisage MIPv6 oui haute énergie
très réactif
périodique frais généraux élevés
NonP [18] sous-maille balisage MIPv6 oui haute énergie
très réactif
immédiat frais généraux élevés
RPL pour les VANET [43, 44] itinéraire DIO fixe Mise à jour ETX non haute énergie
très réactif
frais généraux faibles

ME-RPL [45] itinéraire Filet DIS adaptatif non batterie faible

peu réactif
immédiat frais généraux élevés
MoMoRo [46] itinéraire perte de paquets balisage non batterie faible
peu réactif
Minuteries immédiat frais généraux faibles

mRPL itinéraire + Filet balisage non batterie faible

+ paquets de données très réactif

recueillir les réponses des voisins. Les résultats des évaluations MoMoRo montrent que

865 il améliore le taux de livraison des paquets jusqu'à 85 %. Cependant, cela augmente le réseau

surcharge de manière drastique, de 6 pkt/min en RPL à 65 pkt/min en MoMoRo. Dans

mRPL, nous avons atteint≈Taux de livraison de paquets de 100 % avec seulement 22 % de surcharge en

plus par rapport au routage RPL.

Dans le modèle MoMoRo, la détection de mobilité dépend uniquement de la perte de paquets.

870 Cette approche passive rend le réseau très peu sensible aux topologies.
changements causés par la mobilité. De plus, dans les réseaux à faible consommation, il est très courant

que la qualité des liens baisse temporairement, provoquant une perte de paquets, donc un transfert

décision basée sur les pertes de paquets impose une maintenance de route inutile qui

augmente par conséquent la surcharge du réseau.

40
875 9.Conclusion

Cet article propose une solution très simple mais efficace pour faire face à mo-

bilité comme l'un des problèmes difficiles pour les futures applications IoT. Nous étendons

RPL, le protocole de routage standard pour les réseaux basse consommation dans l'IoT

architecture — avec une prise en charge de la mobilité rapide et fiable.

880 Nous avons intégré en douceur un mécanisme de transfert (surnommé smart-HOP) dans

RPL de manière à conserver une rétrocompatibilité avec le protocole standard. Le

mécanisme de transfert intelligent-HOP [19, 20] a été appliqué aux nœuds mobiles (MN) par

gérer les horaires des messages de contrôle au sein de l'algorithme Trickle

(DIS, DIO et DAO). Un MN sélectionne un nouveau parent préféré en fonction de la

885 RSSI moyen (ARSSI). Les nœuds voisins au sein de l'ensemble enfant du MN sont ignorés,

pour éviter les boucles de routage.

Nous avons mis en place des minuteries pour augmenter l'efficacité du transfert en réduisant

retards de transfert et congestion du réseau. Nous avons considéré la liaison de faible puissance

caractéristiques et les limites de l'architecture IPv6 pour régler les horaires. Nous avons

890 appliqué des priorités aux points d'accès (selon les niveaux ARSSI) pour minimiser le

probabilité de collisions de paquets pendant le processus de transfert.

L'intégration de smart-HOP dans RPL (surnommé mRPL) a été testée,

affiné et validé par des simulations et des expériences approfondies. Les résultats que

nous avons obtenus indiquent qu'un modèle de propagation radio inexact dans

895 le simulateur impacte les résultats liés à la performance du hand-off : liaisons radio

chevauchement plus important dans les expériences réelles (le simulateur crée un minimum

chevauchement entre points d'accès voisins).

Nous avons également constaté que le meilleur réglage des paramètres RPL pour les applications mobiles

cations conduit à un énorme surcoût d'échange de messages de contrôle. Au lieu de cela, mRPL est

900 capable de maintenir une faible surcharge tout en étant réactif aux changements de réseau (≈85 millisecondes

délai de transfert). De plus, un taux de livraison de paquets de près de 100 % est atteint lors de la

mobilité.

Nous avons étudié l'impact de la variation du trafic réseau, du cycle de service et de la mobilité

vitesse du nœud sur les performances de transfert mRPL. Les résultats ont indiqué que

41
905 dans les réseaux à faible trafic, le processus de transfert est moins réactif. De plus,

l'élargissement des périodes d'écoute affecte les performances en augmentant le transfert

retard. Cependant, la variation de la vitesse des nœuds mobiles (dans la gamme des humains

vitesse de marche) n'affecte pas la performance globale.

Nous avons implémenté et intégré notre mécanisme de transfert dans la pile RPL/6LoWPAN de

910 Contiki, un système d'exploitation répandu pour les réseaux sans fil à faible consommation.

Il est important de noter que nous avons mis le code source gratuitement à la disposition de la communauté internationale.

communauté [1].

Remerciements

Ce travail a été partiellement soutenu par des fonds nationaux à travers FCT (Por-

915 Fondation tunisienne pour la Science et la Technologie) et par ERDF (European Re-

régional de développement) à travers COMPETE (Programme Opérationnel 'Facteurs

Thématiques de Compétitivité'), dans le cadre des projets FCOMP-01-0124-FEDER-

037281 (CISTER), FCOMP-01-0124-FEDER-014922 (MASQOTS), et par le

Financement EU ARTEMIS JU, dans le cadre du projet ARTEMIS/0001/2012, subvention JU nr.

920 332987 (TÊTE DE FLÈCHE); également par le FCT et par le FSE (Fonds social européen) à

travers le POPH (Programme opérationnel portugais pour le potentiel humain), sous

Bourse doctorale SFRH/BD/71823/2010.

Références

[1] mrpl : smart-hop au sein de rpl (2014).

925 URLhttp://www.cister.isep.ipp.pt/masqots/sources.html

[2] G. Mulligan, The 6lowpan architecture, dans : Actes du 4e atelier sur les
capteurs embarqués en réseau, ACM, 2007.

[3] G. Monténégro, N. Kushalnagar, J. Hui, D. Culler, Transmission d'ipv6

paquets sur ieee 802.15. 4 réseaux, Internet propose la norme RFC 4944.

930 [4] T. Winter, Rpl : protocole de routage Ipv6 pour les réseaux à faible consommation et avec perte

(2012).

42
 [5] AH Chowdhury, M. Ikram, H.-S. Cha, H. Redwan, SMS Shams,
K.-H. Kim, S.-W. Yoo, Route-over vs mesh-under routage dans 6lowpan, dans :

Actes de la conférence internationale 2009 sur les communications sans fil

935 et informatique mobile : Connecter le monde sans fil, IWCMC
'09, ACM, 2009, p. 1208–1212.

[6] J. Hui, D. Culler, Extension de l'ip aux réseaux personnels sans fil à faible

consommation, Internet Computing, IEEE 12 (4) (2008) 37–45.doi:10.1109/MIC.

2008.79.

940 [7] Rapport final de l'atelier de la nsf sur les orientations futures des réseaux sans fil

travail (novembre 2014).

URLhttp://ecedha.org/docs/nsf-nets/final-report.pdf?sfvrsn=0

[8] Commission européenne, « Usines du futur 2020 : feuille de route pluriannuelle

pour le ppp contractuel à horizon 2020 », feuille de route de la recherche réalisée

945 par les usines européennes de l'association de recherche du futur (effra) (2014).

URL http://www.effra.eu/attachments/article/129/
Factories%20of%20the%20Future%202020%20Roadmap.pdf

[9] PJ Marron, D. Minder, S. Karnouskos, The Emerging Domain of Coop-

erating Objects, Springer, 2012.

950 [10] J. Caldeira, J. Rodrigues, P. Lorenz, Vers des solutions de mobilité ubiquitaires

pour les réseaux de capteurs corporels sur les soins de santé, IEEE Communications Magazine,

2012, 50 (5).

[11] Smartfactory—vers une usine de choses, Revues annuelles sous contrôle,

2010, 34 (1).

955 [12] G. Wu, S. Talwar, K. Johnsson, N. Himayat, K. Johnson, M2m : De mo-

bile à l'internet embarqué, IEEE Communications Magazine, 2011, 49 (4).

[13] Ginseng : contrôle des performances dans les réseaux de capteurs sans fil (2014).

URLhttp://www.ucc.ie/en/misl/research/previous/ginseng/

43
 [14] Fasys : Usine absolument sûre et saine (2014).
960 URLhttp://www.fasys.es/en/proyecto.php

[15] flexware : Automatisation flexible sans fil dans des environnements temps réel (2014).

URLhttp://www.flexware.at/

[16] J. Martinez-de Dios, A. Jimenez-Gonzalez, A. San Bernabe, A. Ollero,

Architecture de testbed intégrée Conet, dans : A Remote Integrated Testbed
965 for Cooperating Objects, SpringerBriefs in Electrical and Computer En-
gineering, Springer International Publishing, 2014, p. 23–39. Ce travail
a été réalisée au sein du réseau européen Cooperating Objects de
Excellence http://www.cooperating–objects.eu/.

[17] O. Chipara, WG Griswold, AN Plymoth, R. Huang, F. Liu, P. Jo-

970 hansson, R. Rao, T. Chan, C. Buono, Wiisard : Une étude de mesure de
les propriétés du réseau et la fiabilité du protocole lors d'une intervention d'urgence,

dans : MobiSys, ACM, 2012.

[18] R. Silva, JS Silva, F. Boavida, Une proposition de mobilité basée sur le proxy dans

wsns, Elsevier Journal of Computer Communications, 2012, 35 (10).

975 [19] H. Fotouhi, M. Zuniga, M. Alves, A. Koubaa, P. Marrón, Smart-hop : A

mécanisme de transfert fiable pour les réseaux de capteurs sans fil mobiles, dans : EWSN,

2012.

[20] H. Fotouhi, M. Alves, M. Zuniga, A. Koubaa, Transferts fiables et rapides dans les

réseaux sans fil à faible consommation, IEEE Transactions on Mobile Computing,

980 2014.

[21] Z. Shelby, S. Chakrabarti, E. Nordmark, Optimisation de la découverte des voisins

for low power and lossy networks (6lowpan), Work in progress, IETF
draftietf-6lowpan-nd-18.

[22] S. Cho, E. Jang, J. Cioffi, Handover in multihop cellular networks, IEEE

985 Revue Communications, 2009, 47 (7).

44
 [23] I. Ramani, S. Savage, Syncscan : transfert rapide pratique pour les réseaux

d'infrastructure 802.11, dans : INFOCOM, 2005.

[24] A. Mishra, M. Shin, W. Arbaugh, Une analyse empirique de l'ieee 802.11

processus de transfert de couche mac, SIGCOMM 2003.

990 [25] M. Shin, A. Mishra, WA Arbaugh, Amélioration de la latence du 802.11

offs utilisant des graphes voisins, MobiSys, 2004.

[26] CE Perkins, EM Royer, Ad-hoc on-demand distance vector routing, in :

Atelier IEEE sur les systèmes et applications informatiques mobiles, 1999.

[27] DB Johnson, DA Maltz, J. Broch, et al., Dsr : The dynamic source rout-
995 protocole de mise en réseau pour les réseaux ad hoc sans fil multi-sauts, mise en réseau ad hoc,

2001, 5.

[28] M. Pióro, Á. Szentesi, J. Harmatos, A. Jüttner, P. Gajowniczek,

S. Kozdrowski, On open shortest path first related network optimisation
problèmes, Évaluation des performances, 2002, 48 (1).

1000 [29] T. Watteyne, A. Molinaro, MG Richichi, M. Dohler, De manet à

Standardisation du rouleau ietf : Un changement de paradigme dans les protocoles de routage

wsn, IEEE Communications Surveys & Tutorials, 2011, 13 (4).

[30] A. Woo, T. Tong, D. Culler, Apprivoiser les défis sous-jacents d'une

routage multi-sauts dans les réseaux de capteurs, dans : ACM SenSys, 2003.

1005 [31] PA Levis, N. Patel, D. Culler, S. Shenker, Trickle : A self regulation algo-
rithm pour la propagation et la maintenance du code dans les réseaux de capteurs sans fil, 2004,

dans : NSDI.

[32] T. Narten, WA Simpson, E. Nordmark, H. Soliman, Découverte voisine

pour IP version 6 (ipv6), RFC 2461, décembre 1998.

1010 [33] M. Zuniga, B. Krishnamachari, Analyse de la région de transition en basse

puissance des liaisons sans fil, dans : IEEE SECON, 2004.

45
 [34] MZ Zamalloa, B. Krishnamachari, Une analyse du manque de fiabilité et de l'asymétrie

dans les liaisons sans fil à faible puissance, ACM TOSN 3 (2).

[35] T. Instruments, fiche technique Cc2420 (2007).

1015 [36] A. Dunkels, B. Gronvall, T. Voigt, Contiki-un outil léger et flexible-

système de calcul pour de minuscules capteurs en réseau, dans : IEEE LCN, 2004.

[37] Plug-in Mobility cooja (2014).

URLhttps://github.com/contiki-os/contiki/wiki

[38] A. Dunkels, Le protocole de cycle de service radio contikimac, SICS Technical

1020 Rapport, 2011.

[39] J. Vasseur, N. Agarwal, J. Hui, Z. Shelby, P. Bertrand, C. Chauvenet, Rpl :

Le protocole de routage IP conçu pour les réseaux à faible consommation et avec perte,

Internet Protocol for Smart Objects (IPSO) Alliance.

[40] J. Montavont, D. Roth, T. Noël, Mobile ipv6 dans l'internet des objets : analyse,

1025 expérimentations et optimisations, Ad Hoc Netw. 14 (2014) 15–25.

[41] D. Roth, J. Montavont, T. Noel, Évaluation des performances de l'ipv6 mobile

over 6lowpan, dans : Actes du 9e symposium ACM sur l'évaluation des

performances des réseaux ad hoc, de capteurs et ubiquitaires sans fil, PE-
WASUN '12, ACM, 2012, p. 77–84.

1030 [42] G. Bag, MT Raza, K.-H. Kim, S.-W. Yoo, Lowmob : mobilité intra-panoramique

programmes de soutien pour 6lowpan, Sensors 9 (7) (2009) 5844–5877.

[43] K. Lee, R. Sudhaakar, L. Dai, S. Addepalli, M. Gerla, Rpl en mobilité, dans :

Consumer Communications and Networking Conference (CCNC), 2012
IEEE, 2012, p. 300–304.

1035 [44] KC Lee, R. Sudhaakar, J. Ning, L. Dai, S. Addepalli, J. Vasseur, M. Gerla,

Une évaluation complète de la rpl en mobilité, International Journal of
Technologie des véhicules 2012.

46
 [45] I. Korbi, M. Ben Brahim, C. Adjih, L. Saidane, Mobility Enhanced rpl for
wireless sensor networks, in : Network of the Future (NOF), 2012 Third
1040 Conférence internationale sur la, 2012, pp. 1–8.

[46] J. Ko, M. Chang, Momoro : Fournir un soutien à la mobilité pour les câbles à faible

moins d'applications, Systems Journal, IEEE PP (99) (2014) 1–10.

47

Afficher les statistiques de publication