MULTI DOMICILIATION DANS LINTERNET DES OBJETS

UNIVERSITE NATIONALE DU VIETNAM, HANOI INSTITUT FRANCOPHONE INTERNATIONAL NGUYN QUANG DUY MULTI-DOMICILIATION DANS L'INTERNET DES OBJETS Mễ HèNH A MNG CH TRONG ô INTERNET KT NI VN VT ằ MẫMOIRE DE FIN D'ẫTUDE DU MASTER INFORMATIQUE Hanoù 2015 UNIVERSITE NATIONALE DU VIETNAM, HANOI INSTITUT FRANCOPHONE INTERNATIONAL NGUYN QUANG DUY MULTI-DOMICILIATION DANS L'INTERNET DES OBJETS Mễ HèNH A MNG CH TRONG ô INTERNET KT NI VN VT ằ Spộcialitộ : Rộseaux et Systốmes communicants Code : Programme pilote MẫMOIRE DE FIN D'ẫTUDE DU MASTER INFORMATIQUE Sous la direction de : Dr Julien MONTAVONT MCF, Universitộ de Strasbourg Hanoù 2015 ATTESTATION SUR LHONNEUR Jatteste sur lhonneur que ce mộmoire a ộtộ rộalisộ par moi-mờme et que les donnộes et les rộsultats qui y sont prộsentộs sont exacts et nont jamais ộtộ publiộs ailleurs La source des informations citộes dans ce mộmoire a ộtộ bien prộcisộe LI CAM OAN Tụi cam oan õy l cụng trỡnh nghiờn cu ca riờng tụi Cỏc s liu, kt qu nờu Lun l trung thc v cha tng c cụng b bt k cụng trỡnh no khỏc Cỏc thụng tin trớch dn Lun ó c ch rừ ngun gc Signature de l'ộtudiant : NGUYEN Quang Duy i Remerciements Au laboratoire ICube, oự j'ai rộalisộ mon stage : Je tiens exprimer toute ma reconnaissance mon encadrant de stage, Monsieur Julien MONTAVONT, pour la soutien, l'aide, l'orientation, la guidance qu'il m'a apportộes durant mon stage, ainsi que tout au long de la rộalisation de cette mộmoire Sans lui, cette mộmoire n'aurait jamais vu le jour Je tiens ensuite remercier le directeur de l'ộquipe Rộseaux du laboratoire ICube, Monsieur Thomas NOậL, pour m'avoir donnộ cette occasion de stage J'adresse aussi mes remerciements tous les professeurs, les doctorants, les stagiaires de l'ộquipe Rộseaux et la personnel au laboratoire ICube pour vos accueilles et vos gentillesses pendant ma durộe de stage l'Institut Francophone International (IFI), oự je fais mes ộtudes de Master : Je souhaite exprimer ma sincốre gratitude tous mes professeurs de lInstitut Francophone International, qui m'ont si bien enseignộ, soutenu et encouragộ accomplir jusqu'ici toutes les ộtapes de ma formation Je rộserve spộcialement mes sincốres remerciements aux Messieurs NGUYEN Hong Quang et HO Tuong Vinh, les responsables des ộtudes l'IFI, pour leurs enthousiasme, support et responsabilitộ Enfin, je remercie tous mes amis, les secrộtaires et la personnel l'Institut Francophone International pour la compagnon, la confiance et l'aide pendant tout au long de mes trois ans des ộtudes l'IFI ii Rộsumộ Internet des Objets est un scộnario oự les objets physiques qui sont munis de capteurs et/ou d'actionneurs peuvent collecter et s'ộchanger d'informations depuis l'environnement, ainsi d'ờtre capable d'accộder l'internet Les rộseaux locales dans l'internet des objets ne peuvent pas utiliser les protocoles de routage classiques de la pile TCP/IP cause des limitations imposộes des dispositifs de capteurs embarquộs RPL est un protocole de routage IPv6 vecteur de distance pour les rộseaux basse puissance et avec perte (LLN), qui peut rộpondre cette problộmatique Par contre dans le protocole RPL, il n'y a gộnộralement qu'une racine et donc qu'un routeur de bordure qui connecte aux autres rộseaux Pour cette raison, lorsque le nombre de nuds dans le rộseau augmente, cette racine risque d'ờtre surchargộe Deuxiốme nouvelle problộmatique posộe, si jamais cette racine tombe en panne, tout le rộseau d'objets se retrouve dộconnectộ Dans ce stage, nous avons utilisộ la technique de multi-domiciliation dans l'internet des objets En outre, nous avons conỗu une solution protocolaire ô Syn-RPL ằ afin de rộpondre aux deux problộmatiques mentionnộes (la surcharge et la panne du routeur de bordure) en utilisant un point de synchronisation et une racine virtuelle qui permet de synchroniser plusieurs routeurs de bordure dans un rộseau locale J'ai mis en place une campagne d'expộrimentations avec trois phases de travail (phase de dộmarrage, phase de rộparation du DODAG et phase de gestion de la panne d'un routeur de bordure) afin de mesurer les performances de ce protocole Le modốle Syn-RPL rộponde deux problộmatiques proposộes avec le grand taux de rộussit iii Abstract Internet of Things (IoTs) is a scenario in which the physical objects embedded sensors and/or actuators collect and exchange the informations from the environment, and they can also accesse internet Local networks in IoTs can not use traditional routing protocols like thoses in TCP/IP stack because of the limitations of the embedded devices RPL is a distance-vector routing protocol IPv6 designed for Low-power and Lossy Networks (LLN), which is adapted for the mentioned limitations However in the RPL protocol, there is usually only one root/edge router which connects to other outsided networks For this reason, when the number of nodes in the local network increases, the root may be overloaded Second problem found is when this root fails by some reason, the entire network of Things is also disconnected In this thesis, we used the multi-homing technique in IoTs Moreover, we designed a protocol which called "Syn-RPL" to meet the two mentioned problems (overload and failure of the edge router) using a synchronization point and a virtual root which allows to synchronize multiple edge routers in a local network We have set up a plan of experiments with three different phases (starting phase, repairing phase of DODAG and management phase of the failure of an edge router) to measure the performance of this protocol The Syn-RPL model resolve the proposed problems with the high rate of success iv Table de matiốres Attestation sur l'honneur i Remerciements ii Rộsumộ iii Abstract iv Liste de figures vii Liste des tableaux viii Introduction 1.1 Problộmatique 1.2 Motivation 1.3 Objectifs et contributions 1.4 Environnement de stage Contexte 2.1 Internet des Objets 2.1.1 Pile de protocoles dans l'Internet des Objets 2.1.2 Rộseaux de capteurs 2.1.3 IEEE 802.15.4 2.1.4 IPv6 2.1.5 6LowPAN 11 2.1.6 RPL 11 2.2 Multi-domiciliation dans l'Internet des Objets 13 2.2.1 Multi-domiciliation 13 2.2.2 Multi puits de collecte dans les rộseaux d'objets 14 v Contribution pour la multi-domiciliation dans l'Internet des Objets 16 3.1 Approche de la multi-domiciliation dans l'internet des objets 17 3.2 Racine virtuelle 18 3.3 Point de synchronisation 19 3.4 Protocole Syn-RPL 20 3.4.1 Messages du protocole Syn-RPL 21 3.4.2 Phase de dộmarrage 22 3.4.3 Phase de rộparation de DODAG 23 3.4.4 Arrivộe d'un nouveau routeur lors d'une phase de rộparation 24 3.4.5 Phase de gestion de panne du routeur de bordure 25 Expộrimentation et analyse 26 4.1 ẫquipements 26 4.1.1 Contiki 27 4.1.2 Cooja 27 4.1.3 TelosB 28 4.1.4 Foren6 28 4.1.5 Radvd 29 4.2 Expộrimentation 29 4.2.1 Scộnario expộrimental 30 4.2.2 Expộriences 32 4.2.3 Configurations 33 4.3 Analyse 35 4.3.1 Phase de dộmarrage 35 4.3.2 Phase de rộparation du DODAG 36 4.3.3 Phase de gestion de panne d'un routeur de bordure 38 Conclusion et perspectives 40 Annex A Installation de Contiki 42 Annex B Installation et configuration de Foren6 43 Rộfộrences 45 vi Liste de figures 1.1 FIT/IoT-lab et quelques ộquipements utilisộs 2.1 Pile d'un modốle du rộseau d'objets 2.2 Exemple d'un rộseau de capteurs 2.3 Unicast adresses locale de lien et globale 2.4 Une exemple de la construction d'une adresse d'interface EUI-64 10 2.5 En-tờte IPv6 10 2.6 Scộnario ô chaque hụte connecte aux routeurs ằ 14 2.7 Deux approches de multi puits de collecte dans les rộseaux d'objets 15 3.1 Multi-domiciliation dans le rộseau d'objets avec m routeurs de bordure et n nuds 17 3.2 Exemple d'un rộseau d'objets avec la racine virtuelle 18 3.3 Dộmarrage des connexion entre PS et BRs 22 3.4 Rộparation d'un DODAG 23 3.5 Connexion d'un nouveau routeur de bordure pendant une phase de rộparation du DODAG associộ 24 3.6 Traitement de panne du routeur de bordure 25 4.1 Simulateur COOJA 27 4.2 TelosB 28 4.3 Interface de foren6 29 4.4 Scộnario expộrimental 31 4.5 Comparaison entre RPL et Syn-RPL dans la phase de dộmarrage 35 4.6 Comparaison entre RPL et Syn-RPL dans la phase de rộparation 37 4.7 Gestion de panne du routeur de bordure 38 B.1 Fenờtre ô Manage Sniffers ằ pour la configuration de renifleur dans foren6 44 vii Liste des tableaux 2.1 Messages du protocole RPL 12 3.1 Informations synchronisộes 19 3.2 Informations dans table d'association 20 3.3 Messages du protocole synchronisộ 21 viii Chapitre Expộrimentation et analyse 4.2.2 Expộriences On fait des expộriences sur trois phases de travail dans ce scộnario, ce sont : phase de dộmarrage, phase de rộparation, phase de gestion de la panne du routeur de bordure Phase de dộmarrage Phase de dộmarrage commence dốs qu'on lance les routeurs de bordure TelosB jusqu' lors que le nud N2 est rộussi recevoir les donnộes partir du nud N1, ỗa veut dire que les deux sous-DODAG sont bien construits Pour expộrimenter cette phase, nous suivrons les ộtapes suivantes : Lancer le programme de serveur sur le point de synchronisation (routeur 1) et les programmes de client sur deux ordinateurs PC1 et PC2 Allumer le renifleur (nud N3) Puis, lancer le programme foren6 sur l'ordinateur PC1 Allumer le routeur de bordure BR2 et le nud N2, donc le sous-DODAG mettre en place Aprốs avoir installộ des paramốtres signalộes sur le routeur de bordure BR1 et lordinateur PC1, nous allumons le routeur de bordure BR1 et le nud N1 Ces paramốtres signalộes sont l'objectif pour afficher sur l'ộcran des annonces des ộmergences de messages HPS, DBR, DIO et donnộe Grõce ces annonces signalộes, nous obtenons le temps d'implộmentation de ce systốme Lors que le nud N2 reỗoit les donnộes du nud N1, nous terminons cette expộrience Si la route des donnộes est depuis le nud N2 vers le nud N1 en passant deux routeurs de bordures BR1 et BR2, l'expộrience est juste Cette phase peut ờtre expộrimentộe en utilisant le simulateur cooja Phase de rộparation Phase de rộparation commence dốs qu'on pousse le bouton sur un routeur de bordure pour demander la reconstruction de DODAG jusqu' lors qu'un routeur de bordure reỗoit le message VBR avec la version nouvelle du DODAG (qui est plus grande que la version ancienne du DODAG) Pour expộrimenter cette phase, nous suivrons les ộtapes suivantes : Tout d'abord, il faut rộaliser la phase de dộmarrage Nous avons installộ des paramốtres signalộes sur le routeur de bordure BR1 et l'ordinateur PC1 pour 32 Chapitre Expộrimentation et analyse reconnaợtre les ộmergences de messages RPS, VBR, VCK, PBR, DIO et donnộe On pousse le bouton sur le routeur de bordure BR1 Grõce aux annonces signalộes, nous obtenons le temps d'implộmentation de ce systốme Lors que le routeur de bordure BR1 reỗoit le message VBR qui contient la version du DODAG plus grande que la version du DODAG ancienne, nous terminons cette expộrience Si la route des donnộes est depuis le nud N2 vers le nud N1 en passant deux routeurs de bordures BR1 et BR2, l'expộrience est juste Cette phase peut ờtre expộrimentộe en utilisant le simulateur cooja Phase de gestion de panne du routeur de bordure Phase de panne du routeur de bordure commence dốs qu'un routeur de bordure est dộconnectộ (en panne) jusqu' lors que le nud N2 est rộussi recevoir les donnộes partir du nud N1, ỗa veut dire qu'il y a une nouvelle route depuis entre deux nuds N1 et N2 Pour expộrimenter cette phase, nous suivrons les ộtapes suivantes : Tout d'abord, il faut rộaliser la phase de dộmarrage Nous avons installộ des paramốtres signalộes sur le routeur de bordure BR1 et l'ordinateur PC1 pour reconnaợtre les ộmergences de messages CHR, CCK, DIO, DAO et donnộe Nous dộconnectons le routeur de bordure BR2 Flux de donnộes sera donc coupộ Lors que le nud N2 reỗoit les donnộes du nud N1, nous terminons cette expộrience Avant la dộconnexion du routeur de bordure BR2, la route des donnộes est depuis le nud N2 vers le nud N1 en passant deux routeurs de bordures BR1 et BR2 La nouvelle route des donnộes est depuis le nud N2 vers le nud N1 en passant le routeur BR1 4.2.3 Configuration Scộnario expộrimental proposộ ne marche pas encore Nous faisons les configurations globales afin qu'il fonctionne comme ce qu'on veut Auto-configuration sans ộtat Dans ce scộnario expộrimental, les appareils qui ont besoin de diffuser les prộfixes d'adresse IPv6 sont le routeur 1, le routeur 2, le routeur 33 Chapitre Expộrimentation et analyse de bordure BR1 et le routeur de bordure BR2 Routeur diffuse le prộfixe d'adresse IPv6 au routeur Le routeur diffuse le prộfixe d'adresse IPv6 aux ordinateurs PC1 et PC2 Les routeurs de bordure BR1 et BR2 diffusent ces prộfixes d'adresse IPv6 ses sous-DODAG Dans ces quatre appareils, seulement le routeur demande des configurations supplộmentaires afin d'ờtre capable de diffuser sa prộfixe d'adresse IPv6 Par contre, cette fonction est mise en place par dộfaut sur le routeur 2, le routeur de bordure BR1 et BR2 ( le mộcanisme d'auto-configuration sans ộtat est installộ sur le routeur ; les routeurs de bordure BR1 et BR2 utilisent le protocole RPL) Nous installons l'outil ô radvd ằ sur le routeur Pour rappel, radvd est un outil qui permet d'utiliser l'auto-configuration sans ộtats et nous pouvons configurer chaque interface rộseau via son fichier de configuration En thộorie, nous voulons avoir deux domaines d'internet diffộrentes pour les deux sous-rộseaux respectivement deux routeurs de bordure Dans ce scộnario expộrimental, nous n'avons pas une prộfixe d'adresse IPv6 partir du routeur Cependant, avec radvd, nous pouvons configurer dans le fichier de configuration de l'outil radvd afin que le routeur enverra une prộfixe d'adresse IPv6 fixộe l'interface du routeur de bordure BR1 et une autre prộfixe d'adresse IPv6 fixộe l'interface du routeur de bordure BR2 Fonction objective Minimum-hop Pour rappel, minimum-hop est un algorithme qui peut ờtre utilisộ dans la construction du graphe Dans cet algorithme, le parent d'un nud A est un autre nud B qui connecte directement avec le nud A et le nud B doit avoir le rang le plus petit Au sein de ce stage, la fonction objective minimum-hop est installộ pour le DODAG Nous pouvons dộcider la fonction objective du DODAG dans contiki en utilisant la valeur rpl_of0 Nous mettons le paramốtre RPL_OF a valeur rpl_of0 dans le fichier de configuration de contiki Temps envoyộ pộriodique des DIO Lintervalle de deux messages DIO consộcutifs envoyộ par un routeur de bordure est sous la formule suivante : m = a(12 + n) (ms) Oự : Paramốtre m est lintervalle entre deux messages DIO consộcutifs Paramốtre a est indiquộe par la constance RPL_DIO_INTERVAL_MIN dans le fichier de configuration de contiki Paramốtre n augmente une unitộ lors de chaque message DIO est diffusộ Ce 34 Chapitre Expộrimentation et analyse paramốtre se dộveloppe jusqu' quand n est ộgale la constance RPL_DIO_INTERVAL_DOUBLINGS dans le fichier de configuration de contiki, puis il devient Servir l'expộrience sur la gestion de panne du routeur de bordure [section 4.2.1], on met la constance RPL_DIO_INTERVAL_DOUBLINGS Pour cette raison, les intervalles des DIO consộcutifs sont : 4, 8,16, 4, 8, 16, 4, 8, 16, etc 4.3 Analyse partir des rộsultats expộrimentals obtenues, nous continuons analyser ces rộsultats pour ộvaluer ma solution proposộe [chapitre 3] 4.3.1 Phase de dộmarrage Figure 4.5 montre le temps d'ộmergement des messages dans le systốme qui utilise le modốle Syn-RPL (les protocoles Syn-RPL et RPL) par rapport au systốme qui n'utilise que le protocole RPL dans la phase de dộmarrage Par souci de concision, nous appelons ces deux systốmes respectivement le systốme Syn-RPL et le systốme RPL Figure 4.5 : Comparaison entre RPL et Syn-RPL dans la phase de dộmarrage 35 Chapitre Expộrimentation et analyse Environ secondes aprốs la mise en marche de routeur de bordure dans le systốme RPL, le premier message DIO va ờtre diffusộ au sous-rộseau par ce routeur de bordure Ces secondes d'attente sont en effet calculộes par la formule ô temps envoyộ pộriodique des DIO ằ [section 4.2.3] Plus de secondes aprốs, le nud destinộ recevra les paquets de donnộes envoyộes partir du nud de source dans le rộseau d'objets Ces secondes comprend une durộe de configuration du nud de source (aprốs avoir reỗu le message DIO) et une durộe de transmission du premier paquet de donnộes Pour le cas de systốme Syn-RPL, aprốs la mise en marche de routeur de bordure, il existe une durộe pour la communication entre le point de synchronisation et le routeur de bordure : le routeur de bordure envoie le message HPS au point de synchronisation et l'inverse, il reỗoit le message VBR Cette durộe est plus d'une seconde Aprốs ce fait, le systốme Syn-RPL fonction comme le systốme RPL (environ secondes pour le message DIO envoyộ et environ secondes pour les paquets de donnộes arrivộes au nud destinộ) sauf que les messages de synchronisation HPS et VBR sont ộchangộs frộquemment toutes les 10 secondes En comparant avec la phase de dộmarrage du systốme RPL, celle du systốme SynRPL a besoin d'une seconde de plus mon avis, une seconde est acceptable, l'utilisation de modốle Syn-RPL pour la phase de dộmarrage est donc assez efficace 4.3.2 Phase de rộparation Figure 4.6 montre le temps d'ộmergement des messages dans le systốme qui utilise le modốle Syn-RPL (les protocoles Syn-RPL et RPL) par rapport au systốme qui n'utilise que le protocole RPL dans la phase de rộparation Avant de cette phase, le systốme RPL possốde le DODAG avec un seul routeur de bordure D'autre part, le systốme Syn-RPL possốde le DODAG avec deux routeurs de bordure diffộrents qui construite respectivement deux sous-DODAG Aprốs que le bouton soit poussộ, le systốme RPL commence tout de suite de reconstruire le DODAG Le nouveau message DIO du DODAG est diffusộ au sousrộseau par le routeur de bordure secondes aprốs le signal du processus de rộparation Ces secondes sont calculộes en utilisant la formule ô temps envoyộ pộriodique des DIO ằ [section 4.3.1] Pendant ce processus, les paquets de transmission dans ce rộseau ne sont pas perdus, car la route pour les donnộes ne ferme pas encore Lors que 36 Chapitre Expộrimentation et analyse le nud de source et le nud destinộ reỗoivent des messages DIO, le graphes DODAG ne changent pas et ces nuds peuvent donc appliquer tout de suite l'ancienne route de transmission des paquets Pour le cas de systốme Syn-RPL, aprốs que le bouton soit poussộ par l'utilisateur, le routeur de bordure et le point de synchronisation s'ộchangent les messages RPS, VBR, VCK et PBR L'intervalle entre les messages venus du routeur de bordure (RPS et VCK) est une seconde Cette telle intervalle est indiquộe dans le pilote informatique du routeur de bordure Prộcisộment, chacune seconde aprốs avoir envoyộ le message RPS au point de synchronisation, le routeur de bordure vộrifie si le message VBR est dộj arrivộ, il enverra donc le message VCK au point de synchronisation Par contre, si le message VBR n'est pas encore arrivộ, le routeur de bordure continue attendre une autre seconde L'intervalle entre le message VCK et le dộmarrage de rộparation peut ộgalement ờtre expliquộ comme le cas de RPS et VCK Figure 4.6 : Comparaison entre RPL et Syn-RPL dans la phase de rộparation En comparant avec la phase de rộparation du systốme RPL, celle du systốme Syn-RPL a besoin d'au moins deux secondes de plus Lors qu'une connexion entre le point de synchronisation et un routeur de bordure dans le systốme Syn-RPL ne fonctionne pas bien, il peut causer beaucoup de dộlai une seconde En gros, mon avis, l'utilisation du systốme Syn-RPL pour la phase de rộparation est acceptable 37 Chapitre Expộrimentation et analyse 4.3.3 Phase de gestion de panne d'un routeur de bordure Figure 4.7 montre le temps d'ộmergement des messages dans le systốme qui utilise le modốle Syn-RPL (les protocoles Syn-RPL et RPL) dans la phase de gestion de panne d'un routeur de bordure Avant de cette phase, le systốme Syn-RPL possốde le DODAG avec deux routeurs de bordure diffộrents qui construite respectivement deux sous-DODAG Figure 4.7 : Gestion de panne du routeur de bordure Lors qu'un routeur de bordure (routeur de bordure ancien) est dộconnectộ, la courante de donnộes qui est partir de n'importe quel nud (nud de source) et destinộe un nud (nud destinộ) du sous-rộseau de ce routeur, est donc coupộe Aprốs une grande durộe d'attente environs 34 secondes, un autre routeur de bordure (nouveau routeur de bordure) envoie le message DIO au nud afin de lui demander de se joindre son sous-rộseau Ce nud rộponde le message DAO au routeur de bordure Tout de suite, le routeur de bordure et le point de synchronisation s'ộchangent les messages CHR et CCK Juste aprốs, le point de synchronisation crộe une nouvelle route pour le nud de source et le nud destinộ Toutes les actions depuis la rộception du message DIO jusqu' la rộception le premier paquet de donnộes aprốs la rộorientation de route du point de synchronisation ont lieu d'une petite durộe secondes Par contre, 38 Chapitre Expộrimentation et analyse l'intervalle depuis que le routeur de bordure ancien est en panne jusqu' la rộception du message DIO est grand et dộterminộ En effet, la valeur 34 secondes dans la figure est la valeur moyenne des plusieurs expộriences Pour l'explication de cette valeur, je rappelle un peu du mộcanisme ô temps envoyộ pộriodique des DIO ằ [section 4.2.3] Selon ma configuration, l'intervalle pộriodique de tous les deux messages DIO consộcutifs est secondes, secondes, 16 secondes et il retourne secondes, etc Retourner la panne du routeur de bordure ancien, les nuds qui sont au sein du sous-rộseau de ce routeur doivent attendre une durộe assez longue afin d'assurer la panne du routeur de bordure ancien plutụt que l'accident de transmission Pour cette raison, en programmation, j'ai dộcidộ une durộe d'attente la plus longue de DIO 25 secondes (8 + 16) En gros, lors que chaque n'importe nud dans un sousrộseau ne reỗoit aucun message DIO partir de son routeur de bordure durant 25 secondes, il peut considộrer que le routeur de bordure mentionnộ est en panne Aprốs cette pộriode d'attente, les nuds peuvent recevoir les messages DIO partir des autres routeurs de bordure afin de se joindre un de ces sous-rộseaux Dans cette expộrience avec des conditions favorables, l'intervalle depuis que le routeur de bordure ancien est en panne jusqu' la rộception du message DIO peut ờtre une valeur au milieu de 25 secondes 41 secondes Il est 25 secondes, ỗa veut dire que juste aprốs la durộe d'attente obligatoire, le nud reỗoit le message DIO d'un autre routeur de bordure et se jointe son sous-rộseau Il est 41 secondes, ỗa veut dire que aprốs la durộe d'attente obligatoire, le nud est au dộbut d'intervalle le plus grand entre deux DIO (16 secondes) Pour conclure, nous trouvons que mờme si la durộe de dộlai pour la rộorientation des routes dans le cas de panne d'un routeur de bordure est grande, il peut bien rộsoudre la problộmatique posộe 39 Chapitre Conclusion et perspectives Chapitre Conclusion et perspectives Nous avons conỗu le protocole Syn-RPL qui repose, en partie, sur RPL pour son usage dans un rộseau sans fils multi-saut Ce protocole permet de synchroniser multiple routeurs de bordure et donc maintenir un seul DODAG en utilisant une racine virtuelle dans un rộseau multi-domiciliộ Autant que je sache, notre solution protocolaire est actuellement la premiốre approche qui peut rộsoudre problốme de surcharge et la fois d'ờtre capable de restaurer automatiquement les communicants lors de la panne d'un routeur de bordure dans un rộseau d'objets En montant une plate-forme de test avec des ộquipements rộseaux et des nuds munis de capteurs, nous avons prouvộ que cette solution thộorique est capable de dộployer en situation rộelle En outre, partir des analyses des rộsultats depuis la campagne d'expộrimentation, nous trouvons que mờme si le taux rộussit du systốme qui utilise Syn-RPL est presque cent pour cent, le dộlai pour la phase de panne du routeur de bordure est trốs ộlevộ La question de choisir une valeur propriộtộ, la dộcision entre la fidộlitộ et la performance nous demande d'aller plus loin sur ce domaine 40 Chapitre Conclusion et perspectives L'avenir de ce protocole sera orientộ sur l'extension de notre ộtude aux expộriences dans un environnement mộdium ou grande ộchelle via le banc de test FIT-IoT 41 Chapitre Conclusion et perspectives Annexe A Installation de Contiki Contiki est une source de code ouvert et il marche directement sur les systốmes de Linux Pour mettre en place contiki sur une machine, il y a deux faỗons : Premiốre faỗon : tộlộcharger une version ô Instant Contiki ằ qui est situộ dans le site http://sourceforge.net/projects/contiki/files/Instant%20Contiki/ En effet, c'est une version du systốme de l'exploitation Ubuntu, qui comprend le rộpertoire de contiki dedans Cette faỗon d'installation est compatible avec une machine de Windows Deuxiốme faỗon : utiliser l'outil Git pour synchroniser la derniốre version du rộpertoire de contiki depuis le site https://github.com/contiki-os/contiki vers ton ordinateur Cette faỗon d'installation est compatible avec une machine de Linux Dans cette mộmoire, je ne fais qu'un guide pour l'installation de contiki en deuxiốme faỗon Prộcisộment, le rộpertoire contiki est installộ sur mon ordinateur (systốme de l'exploitation Debian, version Sid) via l'outil Git Il y a trois ộtapes : ẫtape : installer Git avec la commande $ apt-get install git-core ẫtape : aller vers la direction que vous voulez poser le rộpertoire de contiki $ cd ẫtape : tộlộcharger la derniốre version de contiki via Git $ git clone https://github.com/contiki-os/contiki 42 Chapitre Conclusion et perspectives Annexe B Installation et configuration de Foren6 Foren6 est une source de code ouvert On peut tộlộcharger facilement le rộpertoire de foren6 en utilisant l'outil Git qui est mentionnộ dans l'annexe A Cependant, foren6 travaille obligatoirement avec un capteur qui fait le rụle d'un renifleur Il faut donc installer le pilote informatique sur le renifleur Installation de foren6 comprend deux ộtapes : ẫtape : Tộlộcharger la source de code de foren6 via Git : $ git clone https://github.com/cetic/foren6.git ẫtape : Installer foren6 $ cd foren6 $ make $ make install Installation le pilote informatique sur le renifleur comprend deux ộtapes : ẫtape : Tộlộcharger le pilote informatique ô sniffer ằ lors qu'on ne trouve pas dans la source de contiki : $ cd contiki $ git checkout sniffer ẫtape : Mise jour ce pilote informatique sur le renifleur : $ make TARGET=sky sniffer.upload Aprốs avoir installộ foren6 sur l'ordinateur et le pilote informatique ô sniffer ằ sur le renifleur, on continue configurer les paramốtres de renifleur via foren6 Tout 43 Chapitre Conclusion et perspectives d'abord, on lance foren6 avec la commande : $ foren6 Puis, l'interface d'utilisation de foren6 est ouvert On clique sur le bouton ô Manage Sources ằ et une nouvelle fenờtre ô Manage Sniffers ằ est apparue juste aprốs Figure B.1 : Fenờtre ô Manage Sniffers ằ pour la configuration de renifleur dans foren6 Dans cette fenờtre, il y a trois paramốtres du renifleur qu'on peut modifier : Channel, Type et Baudrate On change le paramốtre Type ô snif ằ, ỗa veut dire qu'on utilise ce capteur associộ (renifleur) la mode de capture de donnộes Par contre, on ne modifie pas deux paramốtres Channel et Baudrate Domaine Target est pour la direction du fichier de pộriphộrique du renifleur Par exemple : /dev/ttyUSB0 44 Chapitre Conclusion et perspectives Rộfộrences [1] S Deering et R Hinden, Internet Protocol Version (IPv6) Specification, RFC2460, Dộcembre 1998 [2] I.F Akyildiz and W Su and Y Sankarasubramaniam and E Cayirci, Wireless sensor networks: a survey, Computer Networks, vol 38, pp 393422, Dộcembre 2001 [3] R Hinden et S Deering, IP Version Addressing Architecture, RFC 4291, February 2006 [4] N Kushalnagar, G Montenegro et C Schumacher, IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) : Overview, Assumptions, Problem Statement and Goals, RFC 4919, Aoỷt 2007 [5] G Montenegro, N Kushalnagar, J Hui et D Culler, Transmission of IPv6 Packets over IEEE 802.15.4 Networks, RFC 4944, Septembre 2007 [6] Gee Keng Ee, Chee Kyun Ng, Nor Kamariah Noordin et Borhanuddin Mohd Ali, A Review of 6LoWPAN Routing Protocols, Proceedings of the Asia Pacific Advanced Network 2010 vol 30, pp 71-78, 2010 45 Chapitre Conclusion et perspectives [7] Stephan Haller, The Things in the Internet of Things, Internet of Things Conference 2010 in Japan, Novembre 2010 [8] Tsvetko Tsvetkov, RPL: IPv6 Routing Protocol for Low-power and Lossy Networks, Seminar SN SS2011 : Network Architectures and Services, pp 6066, Juillet 2011 [9] T Winter, P Thubert, A Brandt, J Hui, R Kelsey, P Levis, K Pister, R Struik, J Vasseur et R Alexander, RPL : IPv6 Routing Protocol for Low-Power and Lossy Networks, RFC 6550, Mars 2012 [10] Isam Ishaq, David Carels, Girum K Teklemariam, Jeroen Hoebeke, Floris Van den Abeele, Eli De Poorter, Ingrid Moerman et Piet Demeester, IETF Standardization in the Field of the Internet of Things (IoT) : A Survey, Journal of Sensor and Actuator Networks, vol 2, pp 235287, 2013 [11] O Troan, D Miles, S Matsushima, T Okimoto et D Wing, IPv6 Multihoming without Network Address Translation, RFC 7157, Mars 2014 [12] David Carels, Niels Derdaele, Eli De Poorter, Wim Vandenberghe, Ingrid Moerman et Piet Demeester, Support of multiple sinks via a virtual root for the rpl routing protocol, EURASIP Journal on Wireless Communications and Networking, Juin 2014 [13] Julien Montavont, Cosmin Cobõrzan, and Thomas Noởl, Theoretical analysis of ipv6 stateless address autoconfiguration in low-power and lossy wireless networks, The 2015 IEEE RIVF, pp 198203, Janvier 2015 46 [...]... mémoriser toutes les routes du réseau Multi DODAGs DODAG avec une racine virtuelle Figure 2.7 : Deux approches de multi puits de collecte dans les réseaux d 'objets 15 Chapitre 3 Contribution pour la multi- domiciliation dans l'Internet des Objets Chapitre 3 Contribution pour la multi- domiciliation dans l'Internet des Objets Dans l'internet des objets, les objets physiques munis des capteurs et/ou actionneurs... Syn-RPL est utilisé dans le scénario « multi- domiciliation dans 20 Chapitre 3 Contribution pour la multi- domiciliation dans l'Internet des Objets l'internet des objets » Ce modèle est composé du protocole Syn-RPL pour les communications entre le point de synchronisation et les routeurs de bordure, ainsi que du protocole RPL dans dispositifs munis de capteurs ensemble dans le réseau d 'objets 3.4.1 Messages... dans cette publication, notre solution proposée va plus loin pour adapter la multi- domiciliation sur le réseau d 'objets 16 Chapitre 3 Contribution pour la multi- domiciliation dans l'Internet des Objets Dans la suite de ce chapitre, je proposerai le nouveau protocole qui s'appelle « SynRPL » En détail, j'expliquerai les fonctions de cette solution protocolaire via les phases de travail différentes dans. .. n'existe pas encore d'adaptation officielle de cette technique sur l'internet des objets 2.2.1 Multi- domiciliation Multi- domiciliation (« Multihoming » en anglais) est une stratégie dans les réseaux informatiques, qui améliore la fiabilité de connectivité d'internet en utilisant au moins de deux réseaux d'internet Un exemple de multi- domiciliation est d'utiliser deux Fournisseurs d'Accès à Internet (FAI,... nécessaires pour ce stage Dans la suite du chapitre, je donnerai une concept globale de l'internet des objets Ensuite, nous passerons respectivement les standards de la pile d'un modèle de réseau d 'objets (IEEE 802.15.4, IPv6, 6LowPAN, RPL) et la technique de multidomiciliation 5 Chapitre 2 Contexte 2.1 Internet des Objets Il existe plusieurs définitions différentes du terme « Internet des Objets » Cependant,... l'internet Internet des Objets peut être partagé aux réseaux d 'objets Dans la carde de ce stage, un réseau d 'objets est en effet un réseau de capteurs sans fils Les protocoles IPv6, 6LowPAN, IEEE 802.15.4 et RPL sont utilisés afin de construire un standard de pile de protocoles officielle pour ce réseau 2.1.1 Pile de protocoles dans l'Internet des Objets La concept de l'internet des objets comprend un... eux-même Par contre, dans la réparation globale, le routeur de bordure augmente la version du DODAG et diffuser les DIO avec cette nouvelle version du DODAG afin de reconstruire ce DODAG 2.2 Multi- domiciliation dans l'Internet des Objets Multi- domiciliation est une technique des réseaux informatiques Deux intérêts principaux de cette technique sont la partage de charge et la gestion de panne dans les réseaux... réseau d 'objets qui possède 17 Chapitre 3 Contribution pour la multi- domiciliation dans l'Internet des Objets un seul routeur de bordure n'a pas un mécanisme de traitement lors de la panne ce routeur de bordure Dans cette situation, les connexions entre les nœuds dans le sousréseau et les n'importe nœuds dehors sont déconnectées et ne sont pas capable de restaurer automatiquement Par contre, dans la... données entre les sous-réseaux d 'objets et tout autre nœud sont acheminés à l'aide des mécanismes de routage classique d'IPv6 Suivant le protocole RPL, un nœud dans un réseau de capteurs envoie les paquets de données à un autre nœud dehors via la racine du DODAG Cependant, la racine 18 Chapitre 3 Contribution pour la multi- domiciliation dans l'Internet des Objets virtuelle dans cette solution n'existe... phases de travail différentes dans le réseau multi- domicilié 3.1 Approche de la multi- domiciliation dans l'internet des objets Un réseau d 'objets qui comprend n nœuds et m routeurs de bordure (n > m > 1) En utilisant le protocole RPL, chaque routeur de bordure essaie d'envoyer des messages DIO pour construire son propre arbre Après le processus de construction des arbres, a nœuds se joignent à routeur