6LoWPAN

6LoWPAN

6LoWPAN est l'acronyme de IPv6 Low power Wireless Personal Area Networks[note 1] ou IPv6 LoW Power wireless Area Networks[note 2].

C'est également le nom d'un groupe de travail de l'IETF. Le groupe 6LoWPAN a défini les mécanismes d'encapsulation et de compression d'entêtes permettant aux paquets IPv6 d'être envoyés ou reçus via le protocole de communication IEEE 802.15.4. IPv4 et IPv6 sont efficaces pour la délivrance de données pour les réseaux locaux, les réseaux métropolitains et les réseaux étendus comme l'internet. Cependant, ils sont difficiles à mettre en œuvre dans les capteurs en réseaux et autres systèmes contraints en raison, notamment, de la taille importante des en-têtes [1]. 6LoWPAN devrait permettre à IPv6 d'intégrer ces matériels informatiques contraints et les réseaux qui les interconnectent.

La spécification de base développée par le groupe 6LoWPAN est connue sous la forme de deux principales RFC :

  1. Le principal document de cette problématique est la RFC 4919[2].
  2. La spécification en elle-même est l'objet de la RFC 4944[3].

Sommaire

Description de la technologie

Un LoWPAN est constitué d'un ensemble d’équipements ayant peu de ressources (CPU, mémoire, batterie) reliés au travers d’un réseau limité en débit (jusqu’à 250 kbit/s)[4]. Ces réseaux sont composés d’un grand nombre d’éléments[5],[6].

En 802.15.4, la taille maximale du PSDU (de l'anglais Physical layer Service Data Unit, « Unité de données service de la couche physique ») est de 127 octets[7]. Avec les 25 octets de la sous-couche MAC (sans sécurisation)[8], il en résulte 102 octets au niveau liaison. En ajoutant la sécurisation de la couche de liaison de données (AES-CCM-128)[9], il ne reste que 81 octets disponibles au niveau IP. Il faut également tenir compte de la surcharge due aux en-têtes d'IPv6 (40 octets)[10], des éventuels en-têtes d'extension, d'UDP (8 octets)[11] ou de TCP (20 octets)[10]. Finalement les données utiles sont peu élevées (33 octets sur UDP et 21 sur TCP, voir figure ci-dessous) et ne permettent pas de respecter les spécifications d'IPv6 qui imposent un MTU minimal de 1280 octets[12].

Problème d'intégration d'un paquet IPv6 sur une trame 802.15.4

Pour s'adapter au support 802.15.4, l'équipement doit fragmenter un paquet IPv6 en plusieurs trames 802.15.4, et l'équipement distant doit ré-assembler toutes les trames 802.15.4 reçues pour régénérer le paquet IPv6 d'origine. Ces tâches sont consommatrices de ressources (mémoire et CPU) et génèrent de la latence (bufferisation, temps de création/vérification des entêtes).

Les problèmes inhérents aux LoWPANs sont[13] :

La fragmentation et le ré-assemblage 
les contraintes de tailles de paquet imposées par IPv6 et par 802.15.4 posent un problème de fragmentation/réassemblage excessif.
La compression de l'entête IPv6 
avec l'entête IPv6 actuel (40 octets), la charge utile est réduite. La compression de l'entête IPv6 est donc une nécessité pour optimiser les transferts de données sur un réseau 6LoWPAN.
Le routage 
les réseaux LoWPAN sont constitués d'une multitude de nœuds. Ils sont organisés en topologie de type « mesh » (multi-hop) ou en étoile. Un protocole de routage permettant de supporter de tels réseaux doit être mis en place. Celui-ci doit en plus répondre aux contraintes des nœuds eux-mêmes (faibles CPU et mémoire) ainsi qu’à celles du 802.15.4 (faible débit et petits paquets). De par leur taille, les équipements 802.15.4 sont facilement transportables. La mobilité doit donc être prise en compte.
L'autoconfiguration d'IP 
L’autoconfiguration d'adresse IPv6 de type stateless (SLAAC, RFC 4862) est préconisée[14] car elle réduit la sollicitation sur les équipements. Celle-ci nécessite la génération d'un identifiant d’interface de type EUI-64 ou de type short à 16 bits sur les équipements.
La supervision et la gestion du réseau 
la supervision/gestion d’un réseau 6LoWPAN est un élément essentiel. SNMP (RFC 3410) est déjà utilisé largement dans les réseaux IP et possède l’avantage d’avoir une multitude d’outils existants. En raison des contraintes imposées par 802.15.4 et des caractéristiques des équipements, l'adéquation de SNMPv3 à 6LoWPAN reste à déterminer.
Les contraintes sur les applications « hautes » 
A cause des caractéristiques des LoWPANs, les applications nécessitant beaucoup de ressources ne sont pas forcement appropriées. Il peut donc être nécessaire d’adapter les applications aux contraintes des LoWPANs (ressources des équipements, débit et taille de paquets réduit sur 802.15.4)[15].
La sécurité 
afin de contrôler l’intégrité des données transmises sur un réseau 6LoWPAN, la sécurisation du transfert des données devrait être implémentée au niveau IP, en plus de celle offerte par IEEE 802.15.4 (via AES).

Fragmentation et ré-assemblage

La couche adaptation de 6LoWPAN se situe entre la couche réseau et la couche liaison du modèle OSI. Elle reçoit de la couche réseau des paquets IPv6 de 1280 octets et les envoie à son équivalant sur l’équipement distant dans des trames 802.15.4. Ces trames ne disposant que de 81 octets de libre (cf Description de la technologie), la couche adaptation doit fragmenter les paquets IPv6 avant de les envoyer et les ré-assembler à la réception[16].

Chaque fragment est précédé d’un en-tête de fragmentation de 4 ou 5 octets. Cet en-tête contient les informations suivantes[17] :

  • 5 bits pour dispatch : permet d’identifier qu’il s’agit d’un fragment. Le premier fragment aura la valeur « 11000 » et les suivants « 11100 » ;
  • 11 bits pour datagram_size : taille du paquet IP avant fragmentation ;
  • 16 bits pour datagram_tag : identifiant commun à tous les fragments d’un même paquet IP ;
  • 8 bits pour datagram_offset : position du fragment dans le paquet IP (uniquement présent dans les fragments suivant le premier).
En-têtes de fragmentation 6LoWPAN.

Si un seul fragment est perdu, le paquet IP ne peut pas être reconstitué. Le problème avec ce mécanisme de fragmentation est qu’il faudra alors émettre à nouveau tous les fragments[18].

Pour pallier ce problème, un mécanisme de récupération des fragments a été proposé[19]. Il introduit un nouvel en-tête de fragmentation et surtout un mécanisme d’acquittement des fragments. L’acquittement permet à l’expéditeur de ne retransmettre que les fragments non reçus (non acquittés).

Compression d'en-tête

La RCF 4944[3] définit le mécanisme de compression des en-têtes IPv6 pour LowPAN : LOWPAN_HC1. Elle intègre aussi la compression de l'en-tête UDP sur 4 octets, mais n'autorise pas la compression du Checksum. De plus, elle restreint la plage des ports UDP de 61616 à 61631 afin de compresser à 4 bits cette valeur.

Cette compression d'en-tête IPv6 ne peut s’appliquer que sur les adresses de liens locales[20]. Pour pallier ce problème, un draft IETF LOWPAN_HC1g[21] a été publié. LOWPAN_HC1g s'applique sur les adresses globales pour les communications multi-sauts IP. Ces deux mécanismes de compression (LOWPAN_HC1 et LOWPAN_HC1g) sont complémentaires. Il est donc nécessaire d'implémenter les deux[22].

Aujourd’hui la proposition du groupe 6LoWPAN est d’utiliser LOWPAN_IPHC[23]. Il permet de remplacer LOWPAN_HC1 et LOWPAN_HC1g. Les octets IPHC résultent de la compression de l'en-tête IPv6. Ils intègrent principalement les informations de qualité de service (DSCP et ECN), des prochains en-têtes, le nombre de sauts et les adresses source/destination compressées.

Avec LOWPAN_IPHC le taux de compression dépend du type de communication[24] :

  • Pour les communications sur un lien local l’en-tête IPv6 peut être réduit à 2 octets(1-octet Dispatch et 1-octet LOWPAN_IPHC).
  • Pour des communications nécessitant plusieurs sauts IP l’en-tête peut être compressé sur 7 octets (1-octet Dispatch, 1-octet LOWPAN_IPHC, 1-octet Hop Limit, 2-octet Source Address et 2-octet Destination Address).

L'exemple ci-dessous montre l'augmentation de la charge utile par rapport à la problématique d'origine (voir 1re figure). Cette charge utile de 70 à 75 octets est dans le meilleur des cas. En effet, si l'on rajoute les informations de fragmentation comme indiquée dans le paragraphe ci-dessus, celle-ci diminuera à 65-70 octets pour ce cas de figure.

Trame 802.15.4 sur IPv6 avec compression de l'entête IPv6 et entête de fragmentation.

L'octet Dispatch a la même fonction que l'EtherType, il permet de déterminer le type de paquet au-dessus du 802.15.4.

Table 1 : Quelques exemples de valeurs possible pour l'octet Dispatch.
Valeur signification

01000001

paquet IPv6 non compressé

01010000

Broadcast LoWPAN

11000xxx

premier fragment

11100xxx

fragment

11110CPP

UDP Header

LOWPAN_NHC est proposé pour la compression de la couche transport[25]. De plus, afin d'éviter une surcharge de l'utilisation des ports UDP et surtout afin de contrôler l'intégrité des messages, il est préconisé[26] d'associer les transmissions sur ces ports à Transport Layer Security (TLS) (RFC 5246[27]). La compression du checksum est maintenant possible mais uniquement autorisée lorsque la couche supérieure utilise du tunneling (par exemple : IPsec Encapsulating Security Payload tunnel mode (RFC 4303[28]).

Cependant, seul UDP est spécifié[29]. D’autres propositions ont donc été faites pour compresser TCP[30] et ICMP[31]. Il est donc nécessaire de spécifier la compression de chaque nouvel en-tête[32]. Pour pallier ce problème, 6LoWPAN_GHC[33] a vu le jour. Cette nouvelle proposition a pour objectif de comprimer n’importe quel type d’en-tête.

Routage

Schéma de routage 6LoWPAN.

Le schéma de routage de 6LoWPAN peut être réalisé selon deux modalités différentes : mesh-under et route-over[34].

Mesh-under consiste à implémenter un routage au niveau de la couche adaptation (qui prend place entre la couche liaison et la couche réseau du modèle OSI), alors que route-over réalise cette implémentation au niveau de la couche réseau (voir schéma de routage 6LoWPAN). Dans route-over, le paquet IPv6 est reconstitué sur chaque équipement intermédiaire afin de prendre la décision de routage. A contrario, dans mesh-under, la décision de routage se fait au niveau 6LoWPAN et donc seulement avec les fragments du paquet IPv6. Dans ce cas, le paquet IPv6 n’est reconstitué que sur l'équipement destinataire. Par conséquent[35] :

  • mesh-under permet d’avoir un délai de transmission plus court ;
  • route-over est plus efficace dans des conditions dégradées (perte de paquets).

Des versions améliorées de mesh-under et route-over ont été proposées[36] :

  • Controlled mesh under : En analysant le contenu de l’en-tête du premier fragment, un équipement peut savoir quels sont les prochains fragments attendus. Si le prochain fragment reçu ne correspond pas au fragment attendu, l’équipement demande sa réémission ;
  • Enhanced route over : Un circuit virtuel est créé en associant l’adresse IPv6 et le champ datagram_tag de l’en-tête du premier fragment. Le circuit virtuel est alors emprunté par tous les fragments ayant le même datagram_tag.

Dans un premier temps, plusieurs protocoles de routage ont été développés par la communauté 6LoWPAN, tel que LOAD[37], DYMO-LOW [38], HI-LOW [39]. Aujourd'hui le groupe de travail ROLL[40] de l’IETF a en charge la définition des mécanismes de routage pour les LLN (de l'anglais Low Power and Lossy Network, « réseaux à basse puissance et avec pertes »).

Les problématiques de routage pour de tels réseaux sont définies dans :

  • RFC 5548[41] : Routing Requirements for Urban LLNs ;
  • RFC 5673[42] : Industrial Routing Requirements in LLNs ;
  • RFC 5826[43] : Home Automation Routing Requirements in LLNs ;
  • RFC 5867[44] : Building Automation Routing Requirements in LLNs.

Pour répondre à ces problématiques, le groupe de travail ROLL propose RPL (de l'anglais Routing Protocol for Low power and Lossy Networks, « protocole de routage pour LLN ») [45].

Schéma DAG

RPL est un protocole de routage IPv6 à vecteur de distance qui construit un DAG (de l'anglais Directed Acyclic Graph, « graphe orienté acyclique »)(voir schéma DAG). Il est implémenté en route-over.

Le LBR (de l'anglais Low power and lossy network Border Router, « routeur de bordure du réseau, de faible puissance et avec perte ») désigne l'équipement en bordure de réseau. Le LBR, de rang 1, est à la source du graphe orienté acyclique qui est construit par le protocole RPL précédemment cité. Le LBR et tous les équipements de rang supérieur forment une DODAG (de l'anglais Destination Object Directed Acyclic Graph, « objet de destination graphe orienté acyclique »). Le LBR envoie un message d’information DIO (de l'anglais DODAG Information Object, « Objet d'information DODAG ») en multicast. Lorsqu’un équipement reçoit une nouvelle version de DIO, il calcule notamment son rang (par rapport à celui qu’il vient de recevoir) et propage son DIO. Vu d’un équipement, tous les équipements possédant un rang inférieur peuvent prétendre être parents. Les routes optimales (« parents ») au sein du DAG sont obtenues à partir de métriques et de contraintes[46].

Le LBR émet périodiquement des DIO pour mettre à jour le DAG. Lorsqu’un équipement rejoint le réseau ou perd le lien vers son « parent », il peut attendre le prochain DIO (de la minute à l’heure) ou demander l’envoi d’un DIO par un message de sollicitation DIS (de l'anglais DODAG Information Solicitation, « sollicitation d'information DODAG »). Les messages DIO sont émis avec l’algorithme Trickle. Cet algorithme définit principalement deux choses[47] :

  • un numéro de séquence qui permet de savoir si l’information reçue est une mise à jour ;
  • le délai entre chaque émission d’information (qui varie en fonction de paramètres).

En 2010, des tests d'implémentation de RPL sur un système d'exploitation Contiki ont démontré que cette solution était économe en mémoire, en énergie et que des réseaux de capteurs sans fil ainsi formés pouvaient fonctionner plusieurs années avec cette implémentation. Si la consommation mémoire est un critère clef, il faut noter que cette implémentation consommait 8 % de la mémoire vive disponible pour assurer la mise en œuvre de RPL dans un environnement composé de 10 voisins. La quantité de mémoire morte, pour le stockage du programme était, elle aussi, jugée non négligeable[48].

Autoconfiguration d'IP

La RFC 4861 indique le mécanisme ND (de l’anglais Neighbor Discovery, « découverte de voisin ») qui permet une auto-configuration d’une adresse IPv6 sur un équipement. Ce mécanisme induit une utilisation intensive de messages multicast, il n’est pas utilisable dans l’état dans les réseaux 6LoWPAN.

De ce constat, le groupe de travail IETF 6LoWPAN a publié un draft[49] sur l’optimisation du ND afin d’alléger le processus d’autoconfiguration, que le LoWPAN soit routé en mesh-under ou en route-over[50].

Du fait que les équipements 6LoWPAN sont le plus souvent « endormis », des efforts particuliers ont été faits sur la limitation des messages RS (de l’anglais Router Solicitation, « sollicitation de routeur ») envoyés en multicast. Cette optimisation est effectuée en utilisant les messages RS uniquement pour trouver des routeurs par défaut valides lors de l’initialisation de l’équipement, ou à partir du moment où un routeur par défaut est considéré comme injoignable[50]. Une façon de limiter le multicast consiste, entre autres, à ne pas lancer de DAD (de l'anglais Duplicate Address Discovery, « Découverte d'Adresse en Doublon ») en cas d’utilisation d’EUI64[50].

Le LBR (de l'anglais Low power and lossy network Border Router, « routeur de bordure du réseau, de faible puissance et avec perte ») est dépositaire de la gestion du préfixe de l’adresse IPv6[51].

Les routeurs par défaut gèrent une table NCE (de l’anglais Neighbor Cache Entry, « entrée de table du cache listant les voisins ») où sont listées toutes les adresses du réseau 6LoWPAN. Lors d’une sollicitation, si une adresse n’est pas dans le cache, elle est considérée comme valide et est enregistrée avec une valeur « durée de vie ». Les adresses enregistrées dans le NCE peuvent être de trois types[52] :

  • Garbage-collectible (poubellisable) : Définie selon les critères donnés dans la RFC 4861. Il y a entre autres les adresses en cours de DAD et non encore validées.
  • Registered (Enregistrée) : Valide, avec une durée de vie explicite.
  • Tentative : Entrée temporaire avec une courte durée de vie, et qui a vocation à passer Registered.

Un paramétrage par défaut, adapté aux périodes de « sommeil » des équipements d’un LoWPAN, permet de conserver leurs adresses valides entre deux « réveils »[53]. Cette méthode permet de ne pas pénaliser les équipements en consommation d’énergie et évite de relancer une autoconfiguration à chaque réveil.

Ces éléments sont implémentés dans le New ND (nouveau ND) : ce message contient une ARO (de l’anglais Address Registration Option, « option d’enregistrement d’adresse »)[53], l’ARO permet au LBR de maintenir correctement ses NCE car elle est émise régulièrement par l’équipement qui transmet la Durée de Vie de son adresse au LBR.

Dans le cas d’un réseau routé en route-over les LR (de l'anglais Low power and lossy network Router, « routeur du réseau, de faible puissance et avec perte ») et LBR échangent des ABRO (de l'anglais Authoritative Border Router Option, « option de routeur de bordure autorisé »)[51], ces messages de type RA transportent des préfixes d’adresses, des informations de contexte, et l’adresse du LBR[51]. De plus les échanges de DAD en multi-sauts entre LR et LBR se font sur deux nouveaux messages ICMPv6 le DAR (de l'anglais Duplicate Address Request, « requête d'adresse double »)[52] et le DAC (de l'anglais Duplicate Address Confirmation, « confirmation d'adresse double »)[52].

Comparaison des ND(Neighbor Discovery) sur IPv6 et sur 6LoWPAN[54].

Une expérimentation d'autoconfiguration stateless a été réalisée en 2009 en utilisant des adresses LoWPAN de longueur 16 bits : la construction de l'adresse au démarrage de l'équipement se faisait sur trois vecteurs de distance en bonds, vers trois équipements « coordinators » référents (Vert, Bleu et Rouge), et d'une valeur aléatoire[55]. L'analogie a été prise avec les définitions de couleurs : trois vecteurs distance vers les références Vert, Bleu et Rouge[56].

En janvier 2011, une proposition d'autoconfiguration stateful a abouti à l'élaboration du LISAA (de l'anglais Lightweight IPv6 Stateful Address Autoconfiguration « autoconfiguration d'adresse IPv6 allégée et dynamique »)[57].

Le LBR travaille en mode proxy et possède un groupe d'adresses 16 bits à distribuer dans le LoWPAN. Ce groupe est divisé en blocs, divisés eux-mêmes en sous-blocs. Ces subdivisions créent une distribution hiérarchique de blocs d'adresses qui suit la topologie des LR[58]. Une expérimentation du LISAA a montré une faible latence dans l'autoconfiguration et une faible surcharge de l'en-tête. Par contre il a été remarqué une réponse lente lors des déplacements d'équipements[59].

La mise en place de la technologie RFID, au sein des capteurs faisant partie d’un réseau 6LowPAN, permettrait de réduire la consommation électrique de ces capteurs, du fait de la simplification de la phase de découverte et d’enregistrement de ceux-ci au sein du réseau 6LowPAN[60].

Mobilité

Mobilité 6LoWPAN

Lorsqu’un équipement se déplace au sein d’un LoWPAN (mobilité intra LoWPAN) et qu’il ne perd pas la connectivité avec le CFD (de l'anglais Coordinator-Function Device, « équipement avec la fonction coordinateur »), il n’est pas nécessaire de gérer cette mobilité car le protocole de routage peut la supporter[61].

Par contre, lorsqu'un équipement se déplace d’un LoWPAN vers un autre (mobilité inter LoWPAN), il est nécessaire de gérer spécifiquement ce type de mobilité. Pour cela plusieurs scénarios sont proposés :

  • Adapter MIPv6 (RFC 3775[62]) pour 6LoWPAN. En compressant les en-têtes et les différents messages, il est possible de réutiliser MIPv6 pour 6LoWPAN[63].
  • Utiliser Proxy MIPv6 (RFC 5213[64]) pour palier au problème de la signalisation qui ne peut pas être gérée par les nœuds[65].
  • Lightweight NEMO : une version légère de NEMO Basic Support Protocol (RFC 3963[66]) pour 6LoWPAN dont le but est de réduire la surcharge due à l’en-tête de mobilité en le compressant[67].
  • Inter-PAN : mécanisme de gestion de la mobilité au niveau de la couche adaptation de 6LoWPAN[68].
  • Inter-Mobility : protocole qui introduit de nouvelles entités, les 6LoWPAN PA (de l'anglais Proxy Agent, « agent mandataire »). Ces PA ont en charge la gestion de la mobilité[69].
  • Inter-MARIO : protocole dont la gestion des handovers est basée sur des équipements partenaires qui détectent le déplacement de équipements mobiles et initient la configuration. Cela permet d’accélérer la procédure de handover[70].
  • SPMIPv6 : protocole basé sur PMIPv6 (Proxy MIPv6) qui a pour but de réduire la consommation d’énergie. Pour cela la mobilité est gérée par deux nouveaux équipements le SMAG (de l'anglais Sensor network-based Mobile Access Gateway, « passerelle d'accès mobile pour les réseaux de capteurs ») et le SLMA (de l'anglais Sensor network-based Localized Mobility Anchor, « Point d’ancrage de mobilité localisée sur les réseaux de capteurs »)[71].

Pour gérer les cas où tous les équipements d’un LoWPAN se déplacent (Network Mobility), il est nécessaire d’implémenter le protocole NEMO (RFC 3963[66]) dans 6LoWPAN[61].

Supervision et Gestion de Réseau

La supervision d'un réseau LoWPAN est assurée à partir d'un serveur applicatif (NMS) placé dans le domaine IPv6. Les requêtes SNMP (de l'anglais Simple Network Management Protocol, «Protocole Simple de Gestion de Réseau»), envoyées par le serveur de supervision vers les divers équipements, ne sont pas adaptées aux contraintes d'un LoWPAN : elles ont des tailles de paquets trop importantes et sont trop nombreuses.

6LoWPAN-SNMP

La proposition d’un 6LoWPAN-SNMP[72] a été faite en s’appuyant sur des travaux en cours à l'IETF[73]. Elle consiste en l’utilisation d’un proxy (d'un serveur mandataire) qui relaye les paquets IPv6 en provenance d'internet vers le réseau LoWPAN en comprimant les requêtes SNMP[74] et en les émettant en broadcast ou multicast (Méthode BroadcastGetRequest)[75] pour limiter l’occupation de la bande passante : une requête répétitive commune à plusieurs équipements d'un LoWPAN n'est émise qu'une seule fois par le proxy au lieu de se faire succéder plusieurs requêtes individuelles (unicast) qui finissent par engorger le LoWPAN.

Afin de limiter la charge sur les équipements, il est proposé d’utiliser un préfixe pour les OID (de l'anglais Object Identifier, «identifiant d'objet») au lieu de leur arborescence complète[76]. Par exemple, un octet permet de définir l'équivalent de 255 arbres d'OID correspondants à 255 MIB Entreprise[note 3].

Architecture de Supervision

Deux architectures permettant la gestion de réseau LoWPAN ont été définies, l'une opérationnelle et l'autre informationnelle[77]. Elles sont regroupées sous le terme LNMP (de l'anglais LoWPAN Network Managment Protocol, « protocole de gestion des réseaux LoWPAN »)[78].

L'architecture opérationnelle est définie sur trois niveaux[77] :

End Device  
Équipement FFD (de l'anglais Full Function Devices, « équipement ayant la totalité des fonctions ») ou RFD (de l'anglais Reduced Function Devices, « équipement ayant des fonctions réduites »), raccordé en capilaire derrière un coordinateur.
Coordinator 
Équipement capable de gérer des fonctions de routage 6LoWPAN.
Gateway 
Équipement coordinateur pour le PAN (PAN Coordinator), interface avec l’IPV6. Il analyse les requêtes SNMP en provenance de l’applicatif NMS (Network Management System). Il gère l’opportunité, ou non, d’envoyer la requête dans le LoWPAN. Par exemple, si la valeur demandée dans la requête SNMP est d’une valeur constante dans le LoWPAN, il renvoie le résultat directement au NMS, sans relayer le message vers l’équipement cible ; sinon, il transfère la requête vers l’équipement désigné, en la fragmentant au format 6LoWPAN si nécessaire.

L’architecture informationnelle s’appuie sur la PIB (PAN Information Base) déjà déterminée pour les niveaux PHY et MAC[79] du 802.15.4, elle s’appuie ensuite sur une proposition IETF de MIB pour trois domaines[80] (voir Arborescence de la MIB LNMP) :

  • Rôle des devices : End Device, Coordinator ou Gateway ;
  • Organisation et Topologie du LoWPAN : Qui est voisin de qui, y a-t-il des profondeurs supplémentaires du réseau, etc. ;
  • Spécifications des broadcast dans les attributs de management, gestion de l’envoi, ou du relayage des messages broadcast envoyés dans le LoWPAN.
Arborescence de la MIB LNMP
Arborescence de la MIB LNMP

En ce qui concerne la gestion de la MIB IPv6 (RFC 4293), elle définit l’adaptation[81] des tables « mandatory » au LoWPAN managé :

Ipv6IpForwarding 
constant et de valeur 2 (notForwarding), les équipements ne sont pas considérés comme routeurs.
Ipv6IpDefaultHopLimit 
peut être traité comme une constante en fonction de l’architecture du LoWPAN managé.
IpAddressPrefix 
géré au niveau du Gateway LNMP.

Pour les OID de la Table ipv6Interface, il est extrêmement rare, à l’heure actuelle, qu’un équipement possède plus d’une interface, ces OID deviennent sans objet et d'autres tables comme ipAddressTable et ipNetToPhysicalTable sont considérées comme optionnelles[81].

Gestion de Réseau

En s’appuyant sur le b6LoWPAN (Berkeley6LoWPAN Implementation, appelé aujourd’hui BLIP)[82], un Agent 6LoWPAN-SNMP a été développé[83]. Il est constitué de 4 composants :

message dispatcher 
Envoi et Réception des messages 6LoWPAN-SNMP, vérification de la version SNMP pour le message processor.
message processor 
Traitement du message en fonction de la version SNMP.
message responder 
Génération du paquet SNMP renvoyé au serveur NMS, gère une temporisation permettant de simuler les réponses successives d'équipements différents en cas de retour après une méthode Broadcast PeriodicGetRequest.
MIB component
Implémentation de la MIB dans l'équipement.

Il a été conçu pour limiter le nombre de messages, leur taille et donc la charge sur les équipements.

Pour toutes les expérimentations sur le management SNMP d’un LoWPAN, il s’est avéré que l’utilisation des Gateway/Proxy a permis de correctement interfacer les domaines IPv6 et LoWPAN[84],[85], la traduction du SNMP IPV6 en entrée ou sortie vers le 6LoWPAN permet de superviser le réseau en profondeur. Par contre, il faut laisser aux équipements un temps de réponse moyen de 100 à 150 ms[86] avant de les considérer en Time Out[note 4]. Ceci tient aux compressions, traductions et fragmentations réalisées pour adapter le SNMP au 6LoWPAN.

Contraintes sur les applications "hautes"

Dès 2005, l'utilisation des Webservices a été proposée comme application pour les réseaux LoWPAN[87]. En 2008, il a été montré la faisabilité de SOAP dans les LoWPAN[88]. D'autres applications IP peuvent fonctionner sur les 6LoWPAN tel que SNMP (voir paragraphe ci-dessus) ou RTP[5]. Puis en 2009, une évaluation des performances entre REST et SOAP sur les LoWPAN démontre l’efficacité de REST par rapport à SOAP et que l’utilisation du langage JSON (RFC 4627[89]) peut être bénéfique car XML est trop verbeux pour les LoWPAN[90],[91]. Cette même année, SENSEI[92] (projet de intergiciel M2M basé sous XML) souhaite mettre leur effort et leur travail au développement des applications sur 6LoWPAN[93].

En juillet 2009, l'IETF définit les problèmes des applications sur réseaux 6LoWPAN ci-dessous[94] :

  • les équipements des LoWPAN ont souvent quelques Ko de RAM et la taille du code est limitée entre 48Ko à 128Ko. Au niveau de l'applicatif, il y a 50-60 octets de payload pour le code. Leur génération et interprétation exigent trop de ressources pour les processeurs 8-bits et 16-bit (dominant dans les équipements des réseaux LoWPAN) ;
  • l'utilisation d'UDP dans les LoWPAN est fréquente car TCP est beaucoup plus complexe à mettre en œuvre du fait des limites de certains systèmes et les pertes de paquets sur les LoWPAN ;
  • l'utilisation UDP et la taille des paquets transportés sur les LoWPAN montrent que les protocoles bavards tels que HTTP ne sont pas souhaitables. Mais l'utilisation de certains concepts web tels que les URI (de l'anglais Uniform Resource Identifier, « identifiant uniforme de ressource »), les MIME (de l'anglais Multipurpose Internet Mail Extensions, « extensions de courrier internet polyvalentes »), les proxys, etc. sont souhaitables. Le condensé du protocole HTTP seul ou avec l'utilisation d'XML ainsi que les services SNMP peuvent être faisables sur de telle architecture ;
  • sur les équipements de bordure (edge router), le Performance Enhancing Proxy (en) (en français « serveur mandataire aux performances améliorées », aussi connu sous l'acronyme PEP) (RFC 3135[95]) pourrait potentiellement être implémenté pour améliorer la connexion entre Internet et les LoWPAN par la conversion protocolaire (par exemple HTTP/TCP côté Internet et CoAP côté LoWPAN). Associer un système de cache sur ces mêmes équipements permettrait de limiter les temps de réponse, de réduire le trafic sur les LoWPAN et donc d'optimiser les ressouces des équipements[96] ;
  • afin de simplifier la mise en service (fonctionnement plug-and-play et bootstrapping), un protocole de découverte de service tel que SLP (de l'anglais Service Location Protocol, « protocole de localisation de service »), optimisé pour les LoWPAN est susceptible d'être employé. Une découverte des services pour les appareils qui dorment la plupart des temps (Service Discovery) devra être implémentée[94].

De plus, les applications doivent pouvoir s'interfacer avec d'autres standards tels que : ZigBee, DPWS, M2M, XML, EXI, etc. et assurer la sécurité et la mobilité.

En mars 2010, l'IETF a lancé un nouveau groupe de travail appelé CORE[97] (de l'anglais Constrained RESTful Environments, « environnements contraint RESTful »). L'objectif de ce groupe de travail est d'étendre l'architecture du Web sur les LoWPAN. Ce groupe de travail a commencé à définir un protocole WebService pour les LoWPAN appelé COAP[97] (de l'anglais Constrained Application Protocol, « protocole d'applications contraintes »).

COAP est un protocole RESTful ayant les caractéristiques principales suivantes[98] :

  • architecture client/serveur ;
  • architecture REST ;
  • sur UDP ;
  • modèle de transaction asynchrone ;
  • support les URI et les MIME ;
  • entête simple et petite (moins de 10 octets) ;
  • mise en place de système de proxy et de « cache » ;
  • utilise DTLS (RFC 4347[99]) pour la sécurité.
CoAP dans une architecture REST
Couche CoAP dans la pile protocolaire

COAP définit 4 types de messages de transaction. Ceux-ci sont de transmis en mode peer-to-peer et chaque transaction est identifiée par un Transaction ID (TID) :

  • Confirmable (CON) : Lors de la réception d'un message CON, un message de retour de type ACK ou RST est renvoyé. Un message CON comporte toujours soit une demande ou la réponse et ne doit pas être vide ;
  • Non-Confirmable (NCN): ils servent pour les messages ne nécessitant pas un ACK/RST (par exemple, les messages qui sont répétées régulièrement pour des exigences applicatifs). Un message NCN porte toujours soit une demande ou réponse et ne doit pas être vide ;
  • Acknowledgement (ACK) : Le message ACK doit faire écho du message CON sans indiquer le succès ou l'échec de la requête et doivent porter une réponse ou être vide ;
  • Reset (RST) : Le message RST doit faire écho du message CON et il indique au destinataire que la requête n'a pas été compris et il doit être vide.

Il défini 4 types de messages de méthode. Elles sont similaires à HTTP. Chaque ressource est identifiée par son URI :

  • GET : Récupère les informations d'une ressource identifiée par l'URI ;
  • POST : Crée une nouvelle ressource selon la demande de l'URI ;
  • PUT : Met à jour de la ressource identifiée par l'URI ;
  • DELETE : Supprime la ressource identifiée par l'URI.

Les messages CoAP ont un en-tête fixe sur 4 octets suivi éventuellement d'options de type Type-length-value (en) (« Type-longueur-valeur » en français, connu sous l'acronyme TLV) :

En-tête des messages CoAP
  • Ver (2 bits) : indique le numéro de la version CoAP (actuellement à 1) ;
  • T (2 bits) : indique le type de message (CON =00, NCN=01, ACK=10 et RST=11) ;
  • OC (4 bits) : indique le nombre d'options après l'entête, si 0 c'est qu'il n'y pas d'options et donc après l'entête il y a la charge utile ;
  • Code (1 octet) : Indique si le message est une demande (valeur de 1 à 31), une réponse (valeur de 64 à 191) ou vide (0) ;
Exemple d'utilisation de l'octet Code.
cas d'une demande cas d'une réponse
Valeur Code méthode HTTP Valeur Code réponse état HTTP
1 GET 65 201-Created
2 POST 66 202-Deleted
3 PUT 68 204-Changed
4 DELETE 69 205-Content
131 403-Forbidden
  • Message Id ou TID (2 octets) : identifiant du message permettant de gérer la correspondance des messages CON et des réponses (ACK ou RST) ainsi que la détection des duplications.

L'URL CoAP est du type : « coap://serveur[:port]/ressources ».

Le format des liens web des ressources CORE est une extension des HTTP Link Header Format de la RFC 5988[100]. Chaque lien transporte une cible de la ressource LoWPAN que l'on veut atteindre (par exemple la température sur un capteur). Cette cible est une URI comme définie dans la RFC 3986[101]. La découverte des ressources, leurs attributs et leurs relations dans les LoWPAN utilisant CORE sont définies comme ceci[102] :

  • Les extensions des HTTP Link Header Format pour CORE :
    • l'attribut "rt" : associe une chaîne de caractère à une ressource spécifique (par exemple la température) ;
    • l'attribut "if" : associe une chaîne de caractère à une interface regroupant plusieurs ressources (par exemple l'environnement qui serait égale à temperature + humidité + …) ;
    • l'attribut "ct" : indique le type de média (exemple ct=41 correspond à XML, 47 à EXI, 50 à JSON, …) ;
    • l'attribut "sz" : indique la taille de la ressource en octet.
  • Une interface spécifique « /.well-known/core » comme spécifié dans la RFC 5785[103] permet la découverte des ressources dans les CORE.
  • La possibilité de faire des requêtes en filtrant sur les ressources désirées (par exemple pour permettre d'atteindre l'attribut "rt" ayant la valeur température : GET /.well-known/core?rt=temperature).

L'état d'une ressource sur un capteur (serveur COAP) peut changer au fil du temps (par exemple l'évolution de la température). Pour suivre cette évolution, l’IETF fournit une simple extension pour que COAP donne aux clients la possibilité d'observer de tels changements[104].

COAP étant basé sur le transport de datagramme des 6LoWPAN, cela limite la taille maximale des informations des ressources pouvant être transférées sans fragmentation. Afin de pouvoir envoyer des données de taille supérieur à la charge utile possible, un mécanisme de fragmentation des données appelé "block-wise" a été mis en place. Il s'appui sur le champ option de l'entête CoAP[105].

Par ailleurs d'autres axes d’améliorations de CoAP sont à l'étude :

  • pour les mécanismes de découvertes des serveurs COAP, différentes pistes sont en cours, certaines sophistiqués[106] ou d'autres très simples[107] de mise en œuvre.
  • l’utilisation de Compress-IPFIX[108],[109], un dérivé du protocol IPFIX (RFC 5101[110]), est possible pour minimiser le transfert de données applicatives dans les réseaux 6LoWPAN ;
  • la mise en place d'un système de contrôle de congestion[111] ;
  • les bonnes pratiques de correspondance HTTP-CoAP[112] ;
  • la mise au point d'un système de regroupement des communications CoAP (par exemple pour avoir la température de tous les capteurs de l'étage 1 du batiment 1 : « coap://all.etage1.bat1/rt=temperature »). Ce système fait appel au mécanisme de diffusion Multicast MLD(RFC 3810[113]), supporté par le protocole de routage RPL. La diffusion de l'arbre Multicast peut être interne à un LoWPAN ou bien au travers d'internet. Pour ce dernier cas, la mise en place d'un proxy (RFC 4605[114]) est indispensable[115].
  • l'utilisation de CoAP pour les BAC (de l'anglais Building Automation and Control, « Automatisation et Contrôle des Batiments »)[116] ;
  • l'amélioration des langages WebServices pour CoAP[117],[118].
  • la mise en place d'un service d'annuaire de ressources pour faciliter la découverte des services sur les équipements 6LoWPAN, DNS Service Discovery[119].

La sécurité

La sécurité sur les 6LoWPAN doit permettre de garantir la confidentialité des données ainsi que leur intégrité et la disponibilité du réseau. Différentes attaques sur les réseaux 6LoWPAN ont été mises en évidence, celles-ci sont classifiées en deux catégories [120]:

  • attaques de type externe:
    attaque externe passive : exemple, écoute dans l'intention de découvrir des informations sensibles. (problème confidentialité)
    attaque externe active : exemple, faire un déni de service en effectuant un brouillage du signal radio afin de paralyser le réseau (problème disponibilité)
  • attaques de type interne:
    exemple, infiltration dans un LoWPAN pour collecter ou diffuser des informations à des fins malveillante (problème d'intégrité, confidentialité et disponibilité)
Résumé de la sécurité sur 6LoWPAN

Afin de sécuriser au maximum les communications sur les 6LoWPAN, la sécurité doit être implémentée sur différentes couches de la pile protocolaire[120].

  • Sur la couche MAC : l'AES devrait être utilisé pour sécuriser la couche liaison.
  • Sur la couche réseau :
    l'utilisation d'IPsec est possible mais le chiffrement consomme beaucoup de ressources et la méthode d'échange des clé IKEv2 (RFC 5996[121])) n'est pas utilisable. Une gestion de clé de cryptage utilisant le minimum de charge utile ainsi qu'une limitation des messages échangés entre les nœuds est un pré-requis.
    Une extension du protocole SEND (RFC 3971[122]) (de l'anglais SEcure Neighbor Discovery protocol, « protocole sécurisé de découverte des voisins ») permettant de sécuriser le mécanisme de découverte des voisins a été mise en place pour les réseaux 6LoWPAN, appelé LSEND (de l'anglais Lightweight Secure Neighbor Discovery Protocol, « SEND allégé »)[123].
  • Sur la couche application : par exemple une solution est de mettre en place la sécurisation via SSL

Diverses propositions ont été faites pour optimiser la sécurité des 6LoWPAN, comme :

  • l'utilisation des options "Timestamps" et "Nonce" de l'entête IPv6 pour protéger les réseaux 6LoWPAN des IP fragmentation attacks (en) (en français « attaques par fragmentation de paquets IP »)[124]
  • la compression de l'entête IPsec pour optimiser la charge utile[125].
  • la mise en place d'un intergiciel permettant l'analyse de risque de sécurité dans les 6LoWPAN[126].
  • l'optimisation du cryptage[127].

Histoire du 6LoWPAN

Les évolutions technologiques des années 1990 (miniaturisation de l'électronique, déploiement de nouveaux des réseaux sans-fil et des systèmes embarqués) ont permis l'émergence de nouvelles applications pour les réseaux de capteurs et d'actuateurs. Avec l'avènement des technologies sans-fil, les premières solutions utilisées étaient totalement propriétaires (par exemple Z-WAVE[128] ou EnOcean[129]). Avec la norme IEEE 802.15.4 (utilisation radio des capteurs sans-fil) de nouveaux standards propriétaire sont apparus (par exemple, ZigBee[130], Wireless-HART[131], etc.).

Lors de premières réflexions sur la mise en réseau de capteurs sans fils, 6LoWPAN est née d’une idée simple : « pourquoi réinventer un protocole alors quand nous avons déjà IP ? »[1].

2001 
Geoff Mulligan propose l’utilisation d’IP sur 802.15.4 pour des équipements de type capteur. Bien qu’ayant reçu un écho défavorable de plusieurs groupes comme Zigbee, d’autres comme Internet 0 (en) du MIT's Center for Bits and Atoms (en) ou le groupe de travail ROHC (de l’anglais RObust Header Compression, « compression d'en-tête robuste ») de l’IETF ont été intéressés[1].
2005 
  • L'International Télécommunication Union (ITU[132]) publie une thématique sur l'"Internet of Things" qui fait aujourd'hui référence[133].
  • l'IETF crée le groupe 6LoWPAN pour travailler spécifiquement sur le sujet de la mise en place de l'IP dans les réseaux de capteurs sans fils.
2007 
  • Maher Chebbo, membre "European Technology Platform Smart Grid[134]", indique que les "SmartGrid[note 5]" électrique intégrant des SmartObject[note 6] qui permettent de gérer et optimiser la consommation électrique sont stratégique[135].
  • Les États-Unis lance un programme pour soutenir le développement des SmartGird[136] pour la modernisation du transport et du système de distribution de l'électricité afin de maintenir une infrastructure de l'électricité fiable et sécurisé[137].
Mars 
Une première implémentation de 6LoWPAN sur TinyOS sort sur Implémentation de « Arch Rock Compagnie : Primer Pack/IP »
Avril 
Une première implémentation de 6LoWPAN sur TinyOS sort sur Implémentation de « Sensinode Compagnie : NanoStack v0.9.4 »
Août 
Le groupe 6LoWPAN publie la RFC 4919[2] afin d'assurer l'interopérabilité de la couche réseau.
Septembre 
La RFC 4944[3] voit le jour, sur la base de la RFC4919. Celle-ci devant permettre la connectivité directe à Internet les équipements d’un LoWPAN via l'IPv6 et de remplacer les protocoles de communication propriétaires comme ZigBee[138],[139], qui a été développé après la fin du projet Smart Dust[140].
2008 
  • Les premiers tests démontrent que les équipements d'un réseau 6LoWPAN ayant la pile UIP (micro IP) (en) (aussi notée ųIPv6) pouvait satisfaire les exigences de la phase 1 d'IPv6 Ready[141]. L'implémentation de la pile ųIPv6 est très peu consommatrice de ressources (moins de 12Ko de ROM et moins de 2Ko de RAM)[142]. Cette même année, l'entreprise "Arch Rock" sortait un produit commercial IPv6/6LoWPAN répondant aux exigeances d'IPv6 Ready phase 2 (Gold)[143]. Et une expérimentation de 4 semaines dans un environnement réel (domotique) montre que l'utilisation des réseaux 6LoWPAN étaient faisable (taux de délivrance des messages de 99.98% et taux moyen de latence par saut < 62 ms)[144].
  • Le Conseil de l'Intelligence Nationale des Etats-Unis (NIC[145]) indique que l'Internet des objets (Internet of Things ou IoT) est une des technologies de rupture qui va structurer les tendances jusqu'en 2025[146].
Juillet 
l'IETF lance le groupe de travail ROLL[40]
septembre 
L’alliance IPSO (de l’anglais IP for Smart Objects, « IP pour les objets intelligents »), présidée par Geoff Mulligan, est créée pour promouvoir l’utilisation d’IP dans des objets intelligents. Les objets intelligents sont des objets de petites tailles de type interrupteur, détecteur plus communément appelés capteurs.
2009 
  • Des tests permettent de montrer l'interopérabilité de certains implémentations de 6LoWPAN (Berkeley IP, Arch Rock, SICSlowpan, Sensinode et Hitachi) ayant des systèmes d'exploitation "opensource" (TinyOS et Contiki) et propriétaires (Sensinode et Hitachi)[147].
  • sortie du livre "6LoWPAN: The Wireless Embedded Internet" de Zack Shelby & Carsten Bormann, l'un des deux livres de référence concernant le 6LoWPAN[5]
Octobre 
pour développer les SmartGrid[136], le président Obama annonce un investissement de 3,4 Milliards de dollars[148].
2010 
  • une expérimentation de 12 mois dans différents environnements a montré que l'implémentation des réseaux 6LoWPAN étaient viable (taux de délivrance des messages > 99.9% et taux moyen de latence par saut < 125 ms)[149].
  • sortie du livre "Interconnecting Smart Objects with IP: The Next Internet" de Jean-Pierre Vasseur & Adam Dunkels, l'un des deux livres de référence concernant le 6LoWPAN[6]
janvier 
une étude démontre des perspectives économiques dans l'IoT importante[150]
mars 
l'IETF lance le nouveau groupe de travail CORE[97]
Un rapport indique qu'une meilleure gestion de l'insuffisance cardiaque, par des systèmes de capteurs surveillant à distance le poids, la pression artérielle, la fréquence et le rythme cardiaque, pourrait réduire les coûts de santé (hospitalisation et traitement) d'un milliard de dollars par année aux États-Unis. De même, l'utilisation de IoT dans la transport pourrait diminuer le nombre d'accidents sur la route et de ce fait économiser environ 100 Milliards de dollars par an[151].
Septembre 
Cisco[152] rachete la société "Arch Roch" (un des "leader" des applications BAC pour les WSN)[153], ce qui renforce l'alliance stratégique préalablement signé entre Cisco. et Itron[154] (spécialiste compteurs SmartGrid)[155]
2011 
Janvier 
un nouveau groupe de travail IETF, LWIG[156] (de l'anglais Light-Weight Implementation Guidance, « conseils de mise en œuvre légère ») a été créé dans le but d'optimiser la pile 6loWPAN (moins d'utilisation mémoire, de consommation énergie et de complexité) pour une meilleur performance des équipements 6LoWPAN. Actuellement, dans ce groupe de travail, nous trouvons :
  • un guide pour l'implémentation d'une API 6LoWPAN[157]
  • une étude sur les problèmes d'interconnexion des 6LoWPAN au réseaux IPv4 ainsi que quelques solutions[158].

Les Solutions 6LoWPAN

Les usages possibles

Dans un premier temps, les usages possibles des réseaux 6LoWPAN ont été définis en juin 2007[159]. Actuellement, les 6LoWPAN sont prévus pour être déployés dans les domaines suivants[160] :

Cas d'usage possible de 6LoWPAN
L'industrie (Industrial Monitoring) 
Exemple, détection de pièces défectueuses sur une chaine de travail afin de prendre les mesures nécessaires (remplacement) ou mesurer l'air ambiant pour la prévention des risques dans les usines de chimie ou autres.
Les bâtiments, édifices, etc. (Structural Monitoring) 
Exemple, permet la gestion "intelligente" des bâtiments pour économiser la consommation d'énergie, en mesurant la température, vérifier si les lumières sont allumés dans des bureaux vides et le cas échéant faire des actions : baisse de la température, extinction de lumière, ... ou bien surveiller l'état des structure d'édifices tel que des barrages, des pont, ...
la maison (Connected Home) 
Exemple, permettre de mettre en place des solutions domotiques ou de surveillance médicale à distance.
la santé (Healthcare) 
Exemple, permettre à un docteur de surveiller et suivre l'état de santé (taux de diabète, le pouls, ...) de ses patients directement sur un terminal (PC, Smartphone, ...)
les transports (Vehicle Telematics) 
Exemple, pouvoir surveiller la trajectoire d'un voiture sur les routes, et en cas de détection d'une trajectoire dangereuse, de pouvoir remettre la voiture dans le droit chemin
L'agriculture (Agricultural Monitoring)
Exemple, mesurer en temps réel différents paramètres environnementaux dans les cultures (température, humidité, pression, pH,...) afin de prendre des décisions tel que la gestion de l'eau et de l'utilisation pesticides.

Pour chacun de ces usages, des fonctionnalités de base (mobilité, taille du réseau, niveau de sécurité, etc.) ainsi que des architectures réseau 6LoWPAN sont proposées[160].


Ces utilisations sont "grand public", 6LoWPAN peut aussi être déployé pour des usages "privés" tels que des usages militaires[161]. L’intégration des 6LoWPAN dans les entreprises utilisant des systèmes d'information basés sur une architecture orientée service (Service-Oriented Architectures) est aussi faisable[162].

Les solutions existantes

Actuellement, diverses solutions utilisant 6LoWPAN sont déployées, on peut citer :

Ainsi que du matériel compatible 6LoWPAN :

Contrôleur RAM EEPROM Flash Fabriquant

WiSMote

MSP430x5 CC2520

16k

nc

256k

Arago Systems[172]

MICAz

Atmel ATmega128L

nc

4k

128k

Crossbow[173]

TELOSB

TI MSP430

10k

16k

48k

Crossbow[174]

JN5139

32-bits RISC processor

96k

192k

externe

Jennic[175]

RC2xxx

Single-cycle high performance 8051

8k

4k

32-256k

Radiocrafts[176]

WPC-IP

MSP430

nc

nc

nc

Watteco[177]

NanoStack

TI CC1110

4-8k

32-64k

32k

Sensinode[178]

Tmote Sky

TI MSP430

10k

nc

48k

Moteiv => Sentilla[179]

eSPOT

ARM 926ej-S

1M

nc

8M

Sun SPOT[180]

PN2420

Atmega128L / MSP430

4k

nc

128k

PicosNet[181]

Des OS, des API ainsi que des outils 6LoWPAN sont également disponibles :

Table 12 : Disponibilité 6LoWPAN.
OS opensource OS propriétaire OS mobile API (langague) Outils

Contiki

NanoStack 2.0

Windows CE

COAPy (Python)

Wireshark

FreeRTOS

Sensinode

Android

jCoAPy (Java)

Copper : Extension Firefox

TinyOS

ZigBee SE2

Symbian

opencoap (C)

libcoap (C)

De plus, 6LoWPAN est pris en compte dans plusieurs projets de recherche :

Les différentes implémentation de 6LoWPAN ont soulevées des problèmes. Parmi ceux-ci, on peut noter :

  • les problèmes d'interférence sur la bande de fréquence 2,4GHz ont pour effet de créer une augmentation des pertes de paquets et des RTT [184],[185].
  • l'augmentation des pertes de paquets et des RTT lorsque la taille de la charge utile est trop importante[186].
  • la mise au place de délai d’attente des paquets (>500 ms) pour limiter la perte de paquets [184].
  • l'utilisation excessive de SNMPv3 provoque une utilisation de la ROM important ainsi que la mise en place de l'authentification SNMP créer de la latence[187].

A l'origine 6LoWPAN était fait pour être implémenté dans les réseaux 802.15.4. A partir de l'année 2010 6LoWPAN a tendance à être utilisé sur d'autres supports (par exemple Courant porteur en ligne[188], RFID[189] et Bluetooth[190]) et donc à être au cœur de l'"Internet de Objet". Tous les travaux de l'IETF, à l'état de "draft", sont opérationnels mais ceux-ci ne sont pas encore standardisés. Ils sont actuellement en perpétuel évolution pour optimiser l'utilisation de 6LoWPAN[191].

Notes et références

Notes

  1. ↑ En français, Les réseaux personnels sans fil à faible consommation.
  2. ↑ En français, Les réseaux sans fil à faible consommation.
  3. ↑ Définitions de compteurs ou de paramètres lus et/ou modifiés à travers le protocole SNMP, spécifiques d'un constructeur
  4. ↑ En français, Délai de Réponse Dépassé.
  5. ↑ En français, grille intelligente.
  6. ↑ En français, objet intelligent.

Références

  1. ↑ a, b et c G. Mulligan 2007, Introduction
  2. ↑ a et b RFC 4919, 2007, page 1
  3. ↑ a, b et c RFC 4944, 2007, page 1
  4. ↑ IEEE Std 802.15.4™-2006, page 13
  5. ↑ a, b et c Z. Shelby et Al. 2009, introduction
  6. ↑ a et b JP. Vasseur et Al. 2010, introduction
  7. ↑ IEEE Std 802.15.4™-2006, page 45
  8. ↑ IEEE Std 802.15.4™-2006, page 159
  9. ↑ IEEE Std 802.15.4™-2003, page 172
  10. ↑ a et b RFC 2460, page 4
  11. ↑ RFC 768, page 1
  12. ↑ RFC 2460, page 24
  13. ↑ RFC 4919, 2007 page 4-9
  14. ↑ RFC 4919, page 8
  15. ↑ RFC 4919, 2007, page 8
  16. ↑ RFC4944, page 5
  17. ↑ RFC4944, pages 11-12
  18. ↑ P. Thubert et Al. 2010, page 3
  19. ↑ P. Thubert et Al., 2010
  20. ↑ A. Ludovici et Al. 2009, page 4
  21. ↑ J. Hui et Al. 2007
  22. ↑ A. Ludovici et Al. 2009, page 5
  23. ↑ J. Hui et Al. 2011
  24. ↑ J. Hui et Al. 2011, page 6
  25. ↑ J. Hui et Al. 2011, page 14
  26. ↑ J. Hui et Al. 2011, page 17
  27. ↑ RFC5246, 2008
  28. ↑ RFC4303, 2005
  29. ↑ J. Hui et Al. 2011, page 16
  30. ↑ A. Ayadi et Al. 2010
  31. ↑ C. O'Flynn 2010
  32. ↑ C. Bormann 2011, page 3
  33. ↑ C. Bormann 2011
  34. ↑ E. Kim et Al. 2011
  35. ↑ A. Chowdhury et Al. 2009, page 5
  36. ↑ A. Ludovici et Al. 2011, pages 5-7
  37. ↑ K. Kim et Al. 2007(a)
  38. ↑ K. Kim et Al. 2007(b)
  39. ↑ K. Kim et Al. 2007(c)
  40. ↑ a et b Routing Over Low power and Lossy networks (Active WG)
  41. ↑ RFC5548, 2009
  42. ↑ RFC5673, 2009
  43. ↑ RFC5826, 2010
  44. ↑ RFC5867, 2010
  45. ↑ RPL, 2011
  46. ↑ JP. Vasseur et Al. 2011
  47. ↑ RFC6206, 2011
  48. ↑ N. Tsiftes et Al. 2010, page 2
  49. ↑ Z. Shelby et Al. 2010, p. 1
  50. ↑ a, b et c Z. Shelby et Al. 2010, page 11
  51. ↑ a, b et c Z. Shelby et Al. 2010, page 12
  52. ↑ a, b et c Z. Shelby et Al. 2010, page 14
  53. ↑ a et b Z. Shelby et Al. 2010, page 15
  54. ↑ C. Bormann 2011, p. 27
  55. ↑ H. Shin et Al. 2009, p. 4
  56. ↑ H. Shin et Al. 2009, p. 1
  57. ↑ E. Talipov et Al. 2011, p. 184
  58. ↑ E. Talipov et Al. 2011, p. 188
  59. ↑ E. Talipov et Al. 2011, p. 194-195
  60. ↑ Silva et Al. 2009, p. 49
  61. ↑ a et b M-K. Shin et Al. 2007, pages 6-7
  62. ↑ RFC 3775, 2004
  63. ↑ R. Silva et Al. 2009
  64. ↑ RFC 5213, 2008
  65. ↑ M-K. Shin et Al. 2009
  66. ↑ a et b RFC 3963, 2005
  67. ↑ J-H. Kimet Al. 2008
  68. ↑ G. Bag et Al. 2008
  69. ↑ Z. Zinonos et Al. 2010
  70. ↑ M. Ha et Al. 2010
  71. ↑ Md. Motaharul Islam et Al. 2011
  72. ↑ C. Haksoo et Al. 2009, p. 305
  73. ↑ M. Hamid et Al. 2010, p. 1-29
  74. ↑ C. Haksoo et Al. 2009, p. 306
  75. ↑ C. Haksoo et Al. 2009, p. 308
  76. ↑ C. Haksoo et Al. 2009, p. 307
  77. ↑ a et b M. Hamid et Al. 2008, p. 419
  78. ↑ M. Hamid et Al. 2008, p. 417
  79. ↑ IEEE802.15.4
  80. ↑ S. Daniel et Al. 2009, p. 8
  81. ↑ a et b M. Hamid et Al. 2008, p. 421
  82. ↑ b6LoWPAN - BLIP
  83. ↑ C. Haksoo et Al. 2009, p. 309
  84. ↑ C. Haksoo et Al. 2007, p. 310
  85. ↑ M. Hamid et Al. 2008, p. 422
  86. ↑ M. Hamid et Al. 2008, p. 423
  87. ↑ T. Luckenbach et Al. 2005
  88. ↑ N. B. Priyantha et Al. 2008
  89. ↑ RFC 4627, 2007, page 1.
  90. ↑ D. Yazar et Al. 2009
  91. ↑ L. Schor et Al., 2009
  92. ↑ a et b le site officiel du projet Sensei
  93. ↑ R. Gold et Al. 2009
  94. ↑ a et b C. Bormann et Al. 2009
  95. ↑ RFC 3135, 2001, page 1.
  96. ↑ D. Bimschas et Al., 2010, page 8
  97. ↑ a, b et c IETF, 2010, pages 1
  98. ↑ Z. Shelby et Al. 2011(a)
  99. ↑ RFC 4347, 2006
  100. ↑ RFC 5988, 2010, page 1.
  101. ↑ RFC 3986, 2005, page 1.
  102. ↑ Z. Shelby 2011
  103. ↑ RFC 5785, 2010, page 1.
  104. ↑ Z. Shelby et Al. 2011(b)
  105. ↑ Z. Shelby et Al. 2011(c)
  106. ↑ A. Brandt 2011
  107. ↑ C. Bormann 2011
  108. ↑ C. Schmitt et Al. 2010, page 390
  109. ↑ L. Braun et Al. 2011
  110. ↑ RFC 5101, 2008
  111. ↑ L. Eggert, 2011, page 1
  112. ↑ A. Castellani 2011
  113. ↑ RFC3810, 2004, page 1
  114. ↑ RFC4605, 2006, page 1
  115. ↑ A. Rahman, 2011
  116. ↑ P. Van der Stok et Al. 2011
  117. ↑ G. Moritz, 2010
  118. ↑ G. Moritz 2011
  119. ↑ S.Cheshire et Al., 2011
  120. ↑ a et b S. Park et Al. 2011
  121. ↑ RFC 5996, 2010, page 1
  122. ↑ RFC 3971, 2005, page 1
  123. ↑ B. Sarikaya et Al., 2011
  124. ↑ H. Kim 2008, page 796
  125. ↑ S. Raza et Al., 2011
  126. ↑ A.A El Kalam et Al., 2010
  127. ↑ J. Ayuso et Al. 2010
  128. ↑ le site officiel de Z-WAVE
  129. ↑ le site officiel de EnOcean
  130. ↑ a et b le site offciel de ZigBee
  131. ↑ le site officiel de Wireless-HART
  132. ↑ le site officiel de l'International Telecommunication Union
  133. ↑ ITU, 2005
  134. ↑ site officiel du projet Européen : SmartGrid
  135. ↑ M. Chebbo, 2007
  136. ↑ a et b site officiel du projet gouvernemental Américain : SmartGrid
  137. ↑ Gouvernement US, 2007
  138. ↑ H. Labiod et Al. 2003
  139. ↑ S. Farahani 2008
  140. ↑ B. Warneke et Al. 2001
  141. ↑ le site officiel d'IPv6 Ready
  142. ↑ M. Durvy et Al. 2008, page 421
  143. ↑ U. Sarwar et Al. 2010, page 889.
  144. ↑ Jonathan W Hui et Al., 2008
  145. ↑ le site officiel du National Intelligence Council
  146. ↑ NIC, 2008
  147. ↑ K.D. Korte et Al. 2009
  148. ↑ John Carey, 2009
  149. ↑ Jonathan W Hui et Al., 2010, page 1865-1878
  150. ↑ Elgar Fleisch, 2010
  151. ↑ M. Chui et Al., 2010
  152. ↑ site officiel de Cisco
  153. ↑ Cisco : Annonce rachat Arch Rock
  154. ↑ site officiel de Itron
  155. ↑ Cisco : Cisco : Annonce alliance Itron
  156. ↑ Light-Weight Implementation Guidance (Active WG)
  157. ↑ C. Williams 2011
  158. ↑ Z. Cao 2011
  159. ↑ E. Kim et Al. 2007
  160. ↑ a et b E. Kim et Al. 2011
  161. ↑ H. Song et Al. 2011
  162. ↑ R. Glombitza et Al. 2009, page 25
  163. ↑ le site officiel de Sensinode
  164. ↑ le site officiel d'Arch Rock
  165. ↑ le site offciel de Picosnet
  166. ↑ le site officiel d'Indrion
  167. ↑ Communiqué Sagemcom, Linky, Spécification de Linky et le site officiel Linky ERDF
  168. ↑ le site officiel de Watteco
  169. ↑ le site officiel de Parchube
  170. ↑ Sports-tracker
  171. ↑ Powermeter
  172. ↑ Datasheet WiSMote et le site officiel Arago Systems
  173. ↑ Datasheet MICAz et le site officiel Crossbow
  174. ↑ Datasheet TELOSB et le site officiel Crossbow
  175. ↑ JN5139 sur le site officiel Jennic
  176. ↑ 6LoWPAN modules sur le site officiel Radiocrafts
  177. ↑ WPC-IP sur le site officiel Watteco
  178. ↑ NanoStack™ 2.0 sur le site officiel Seinsinode
  179. ↑ Datasheet Tmote Sky et le site officiel Sentilla
  180. ↑ Datasheet Sun™ SPOT sur le site officiel SunSPOT
  181. ↑ PN2420 sur le site officiel PicosNet
  182. ↑ le site officiel du projet Hobnet
  183. ↑ le site officiel du projet Eureka
  184. ↑ a et b Z. Suryady et Al., 2011, page 171
  185. ↑ CJ M. Liang et Al. 2010, page 309
  186. ↑ B. Cody-Kenny et Al. 2009, page 25
  187. ↑ J. Schonwalder et Al. 2011, page 1
  188. ↑ C. Chauvenet et Al. 2010
  189. ↑ R. Silva et Al. 2009, page 44
  190. ↑ B. Patil et Al. 2011, page 1
  191. ↑ C. Bormann et Al., 2010

Bibliographie

Livres et Articles

  • (en) Geoff Mulligan, « The 6LoWPAN architecture », dans Proceedings of the 4th workshop on Embedded networked sensors, 2007, p. 78-82 [texte intégral, lien DOI] 
  • (en) IEEE Std 802.15.4-2006, 2006
  • (en) Zach Shelby et Carsten Bormann, 6LoWPAN: The Wireless Embedded Internet, Chichester, John Wiley & Sons, 2009, relié (ISBN 978-0-470-74799-5) (LCCN 2009026837) [présentation en ligne] 
  • (en) Jean-Philippe Vasseur et Adam Dunkels, Interconnecting Smart Objects with IP: The Next Internet, Burlington, Elsevier Science & Technology, 2010 (ISBN 978-0-12-375165-2) (LCCN 2010001206) [présentation en ligne] 
  • (en) IEEE Std 802.15.4-2003, 2003
  • (en) Houda Labiod, Hossam Afifi et Costantino Santis, Wi-Fi, Bluetooth, Zigbee and WiMax, Dordrecht, Springer Netherlands, 2003, 11e éd. (ISBN 978-1-4020-5396-2)  aperçu
  • (en) Shahin Farahani, ZigBee Wireless Networks and Transceivers, Amsterdam, Newnes, 2008, poche (ISBN 978-0-7506-8393-7) (LCCN 2009275319)  aperçu
  • (en) Brett Warneke, Matt Last, Brian Liebowitz et Kristofer Pister, « Smart Dust: Communicating with a Cubic-Millimeter Computer », dans Computer, 2001, p. 44-51 [texte intégral, lien DOI] 
  • (en) National Intelligence Council, The Internet of things : Appendix F, NIC, 2008, p. 1-19  texte intégral
  • (en) International Telecommunication Union, Internet of Things summary, ITU, 2005  texte intégral
  • (en) Alessandro Ludovici, Anna Calveras, Marisa Catalan, Carles Gómez et Josep Paradells, « Implementation and Evaluation of the Enhanced Header Compression (IPHC) for 6LoWPAN », dans The Internet of the Future 15th Open European Summer School and IFIP TC6.6 Workshop, EUNICE 2009, vol. 5733, 2001, p. 168-177 [texte intégral, lien DOI] 
  • (en) Aminul Haque Chowdhury, Muhammad Ikram, Hyon-Soo Cha, Hassen Redwan, S.M. Saif Shams, Ki-Hyung Kim et Seung-Wha Yoo, « Route-over vs mesh-under routing in 6LoWPAN », dans Proceedings of the 2009 International Conference on Wireless Communications and Mobile Computing: Connecting the World Wirelessly, 2009, p. 1208-1212 [texte intégral, lien DOI] 
  • (en) Alessandro Ludovici, Anna Calveras et Jordi Casademont, « Forwarding Techniques for IP Fragmented Packets in a Real 6LoWPAN Network », dans Sensors, 2011, p. 992-1008 [texte intégral, lien DOI] 
  • (en) Nicolas Tsiftes, Joakim Eriksson et Adam Dunkels, « Low-Power Wireless IPv6 Routing with ContikiRPL », dans Proceedings of the 9th ACM/IEEE International Conference on Information Processing in Sensor Networks, 2010, p. 406-407 [texte intégral, lien DOI] 
  • (en) Myung-Ki Shin et Hyoung-Jun Kim, « L3 mobility support in large-scale IP-based sensor networks (6LoWPAN) », dans Advanced Communication Technology, 2009. ICACT 2009. 11th International Conference on, vol. 02, 2009, p. 941-945 [texte intégral] 
  • (en) Jin Ho Kim, Choong Seon Hong et Taeshik Shon, « A Lightweight NEMO Protocol to Support 6LoWPAN », dans ETRI Journal, vol. 30, novembre 2009, p. 787-792 [texte intégral, lien DOI] 
  • (en) Gargi Bag, Mukhtar Hamid, S.M. Saif Shams, Ki Hyung Kim et Seung-wha Yoo, « Inter-PAN Mobility Support for 6LoWPAN », dans Convergence and Hybrid Information Technology, 2008. ICCIT '08. Third International Conference on, vol. 1, octobre 2008, p. 685-695 [texte intégral, lien DOI] 
  • (en) Zinon Zinonos et Vasos Vassiliou, « Inter-mobility support in controlled 6LoWPAN networks », dans GLOBECOM Workshops (GC Wkshps), 2010 IEEE, Dec. 2010, p. 1718-1723 [texte intégral, lien DOI] 
  • (en) Minkeun Ha, Daeyoung Kim, Seong Hoon Kim et Sungmin Hong, « Inter-MARIO: A Fast and Seamless Mobility Protocol to Support Inter-Pan Handover in 6LoWPAN », dans GLOBECOM 2010, 2010 IEEE Global Telecommunications Conference, décembre 2010, p. 1-6 [texte intégral, lien DOI] 
  • (en) Md. Motaharul Islam et Eui-Nam Huh, « ISensor Proxy Mobile IPv6 (SPMIPv6)—A Novel Scheme for Mobility Supported IP-WSNs », dans Sensors, 2011, p. 1865-1887 [texte intégral, lien DOI] 
  • (en) Heecheol Song, Sang Hyuk Lee, Soobin Lee et Hwang Soo Lee, « 6LoWPAN-based tactical wireless sensor network architecture for remote large-scale random deployment scenarios », dans Military Communications Conference, 2009. MILCOM 2009. IEEE, octobre 2009, p. 1-7 [texte intégral, lien DOI] 
  • (en) Kevin Dominik Korte, Iyad Tumar et Jurgen Schonwalder, « Evaluation of IPv6 over low-power wireless personal area networks implementations », dans Local Computer Networks, 2009. LCN 2009. IEEE 34th Conference on, octobre 2009, p. 881-888 [texte intégral, lien DOI] 
  • (en) Thomas Luckenbach, Peter Gober et Stefan Arbanowski, « TinyREST – a Protocol for Integrating Sensor Networks into the Internet », dans Proc. of REALWSN, 2005 [texte intégral] 
  • (en) Nissanka B. Priyantha, Aman Kansal, Michel Goraczko et Feng Zhao, « Tiny web services: design and implementation of interoperable and evolvable sensor networks », dans SenSys '08 Proceedings of the 6th ACM conference on Embedded network sensor systems, 2008, p. 43-48 [texte intégral] 
  • (en) Dogan Yazar et Adam Dunkels, « Efficient Application Integration in IP-Based Sensor Networks », dans BuildSys '09 Proceedings of the First ACM Workshop on Embedded Sensing Systems for Energy-Efficiency in Buildings, 2009, p. 43-48 (ISBN 978-1-60558-824-7) [texte intégral, lien DOI] 
  • (en) Corinna Schmitt, Lothar Braun, Thomas Kothmayr et Georg Carle, « Collecting sensor data using compressed IPFIX », dans IPSN '10 Proceedings of the 9th ACM/IEEE International Conference on Information Processing in Sensor Networks, 2010, p. 390-391 (ISBN 978-1-60558-988-6) [texte intégral, lien DOI] 
  • (en) Choi Haksoo, Nakyoung Kim et Hojung Cha, « 6LoWPAN-SNMP: Simple Network Management Protocol for 6LoWPAN », dans 11th IEEE International Conference on High Performance Computing and Communications, 2009, p. 305-313 (ISBN 978-076953738-2) [texte intégral, lien DOI] 
  • (en) Mukhtar Hamid, Kang-Myo Kim, Ahmad Chaudhry Shafique, Akbar Ali Hammad, Ki-Hyung Kim et Seung-Wha Yoo, « LNMP-Management Architecture for IPv6 based low-power Wireless Personal Area Networks (6LoWPAN) », dans NOMS 2008 - IEEE/IFIP Network Operations and Management Symposium: Pervasive Management for Ubiquitous Networks and Services, 2008, p. 417-424 (ISBN 978-142442066-7) [texte intégral, lien DOI] 
  • (en) Mathilde Durvy, Julien Abeillé, Patrick Wetterwald, Colin O'Flynn, Blake Leverett, Eric Gnoske, Michael Vidales, Geoff Mulligan, Nicolas Tsiftes, Niclas Finne et Adam Dunkels, « Making sensor networks IPv6 ready », dans SenSys '08 Proceedings of the 6th ACM conference on Embedded network sensor systems, 2008, p. 421-422 (ISBN 978-1-59593-990-6) [[{http://doi.acm.org/10.1145/1460412.1460483 texte intégral], lien DOI] 
  • (en) Chauvenet, Tourancheau et Genon-Catalot, « 802.15.4, a MAC layer solution for PLC », dans Computer Systems and Applications (AICCSA), 2010 IEEE/ACS International Conference, mai 2010, p. 1-8 (ISBN 978-1-4244-7716-6) [texte intégral, lien DOI] 
  • (en) Silva, Leithardt, Sa Silva, Geyer, Rodrigues et Boavida, « A comparison of approaches to node and service discovery in 6lowPAN wireless sensor networks », dans Q2SWinet '09 Proceedings of the 5th ACM symposium on QoS and security for wireless and mobile networks, 2009, p. 44-49 (ISBN 978-1-60558-619-9) [texte intégral, lien DOI] 
  • (en) Nils Glombitza, Dennis Pfisterer et Stefan Fischer, « Integrating wireless sensor networks into web service-based business processes », dans MidSens '09 Proceedings of the 4th International Workshop on Middleware Tools, Services and Run-Time Support for Sensor Networks, 2009, p. 25-30 (ISBN 978-1-60558-851-3) [texte intégral, lien DOI] 
  • (en) Usman Sarwar, Gopinath Sinniah Rao et Zeldi Suryady, « A Comparative Study on Available IPv6 Platforms for Wireless Sensor Network », dans waset.ac.nz, 2010, p. 889-892 [texte intégral] 
  • (en) Daniel Bimschas, Horst Hellbrück, Richard Mietz, Dennis Pfisterer, Kay Römer et Torsten Teubler, « Middleware for smart gateways connecting sensornets to the internet », dans MidSens '10 Proceedings of the 5th International Workshop on Middleware Tools, Services and Run-Time Support for Sensor Networks, 2010, p. 8 -14 (ISBN 978-1-4503-0454-2) [texte intégral, lien DOI] 
  • (en) Lars Schor, Philipp Sommer et Roger Wattenhofer, « Towards a Zero-Configuration Wireless Sensor Network Architecture for Smart Buildings », dans BuildSys '09 Proceedings of the First ACM Workshop on Embedded Sensing Systems for Energy-Efficiency in Buildings, 2009, p. 31-36 (ISBN 978-1-60558-824-7) [texte intégral, lien DOI] 
  • (en) HyunGon Kim, « Protection Against Packet Fragmentation Attacks at 6LoWPAN Adaptation Layer », dans Convergence and Hybrid Information Technology, 2008. ICHIT '08. International Conference, août 2008, p. 796-801 (ISBN 978-0-7695-3328-5) [texte intégral, lien DOI] 
  • (en) Shahid Raza, Thiemo Voigt et Utz Roedig, « 6LoWPAN Extension for IPsec », dans Conference or Workshop Item (Paper), mars 2011, p. 1-3 [texte intégral] 
  • (en) Anas Abou El Kalam, Andrea Atzeni, Stefan Lindskog, Daniele Mazzocchi, Claudio Pastrone, Khalid Salih, Maurizio A. Spirito et Olivier Terzo, « Toward a formal framework to evaluate wireless sensor network security », dans NEWCOM++ Dissemination Day, 2010 [texte intégral] 
  • (en) Jesus Ayuso, Leandro Marin, Antonio J. Jara et Antonio F. Gomez Skarmeta, « Optimization of Public Key Cryptography (RSA and ECC) for 16-bits Devices based on 6LoWPAN », dans 1st International Workshop on the Security of the Internet of Thing, 2010 [texte intégral] 
  • (en) Brendan Cody-Kenny, David Guerin, Desmond Ennis, Ricardo Simon Carbajo, Meriel Huggard et Ciaran Mc Goldrick, « Performance evaluation of the 6LoWPAN protocol on MICAz and TelosB motes », dans PM2HW2N '09 Proceedings of the 4th ACM workshop on Performance monitoring and measurement of heterogeneous wireless and wired networks, février 2009, p. 25-30 (ISBN 978-1-60558-621-2) [texte intégral, lien DOI] 
  • (en) Jurgen Schonwalder, Tina Tsou et Behcet Sarikaya, « Protocol Profiles for Constrained Devices », dans www.iab.org, février 2011, p. 1-5 [texte intégral] 
  • (en) Z. Suryady, M.H.M. Shaharil, K.A Bakar, R Khoshdelniat, G.R Sinniah et U. Sarwar, « Performance evaluation of 6LoWPAN-based precision agriculture », dans Information Networking (ICOIN), 2011 International Conference, mars 2011, p. 171-176 (ISBN 978-1-61284-661-3)(ISSN 1976-7684) [texte intégral, lien DOI] 
  • (en) Chieh-Jan Mike Liang, Nissanka Bodhi Priyantha, Jie Liu et Andreas Terzis, « Surviving wi-fi interference in low power ZigBee networks », dans SenSys '10 Proceedings of the 8th ACM Conference on Embedded Networked Sensor Systems, 2010, p. 309-322 (ISBN 978-1-4503-0344-6) [texte intégral, lien DOI] 
  • (en) Hyojeong Shin, Elmurod Talipov et Hojung Cha, « IPv6 lightweight stateless address autoconfiguration for 6LoWPAN using color coordinators », dans Proceedings of the 2009 IEEE International Conference on Pervasive Computing and Communications, 2009, p. 1-9 (ISBN temp-isbn) [texte intégral, lien DOI] 
  • (en) Elmurod Talipov, Hyojeong Shin, Seungjae Han et Hojung Cha, « A lightweight stateful address autoconfiguration for 6LoWPAN », dans Wirel. Netw., vol. 17, janvier 2011, p. 183-197 (ISSN 1022-0038) [texte intégral, lien DOI] 
  • (en) Jonathan W. Hui et David E. Culler, « IPv6 in Low-Power Wireless Networks », dans Proceedings of the IEEE, 2010, p. 1865-1878 [texte intégral, lien DOI] 
  • (en) « XIII of the Energy Independence and Security Act of 2007 », dans smartgrid.gov, 2007 [texte intégral] 
  • (en) M Chebbo, « EU SmartGrids Framework "Electricity Networks of the future 2020 and beyond" », dans Power Engineering Society General Meeting, 2007. IEEE, juillet 2007 [texte intégral, lien DOI] 
  • (en) Carsten Bormann, JP Vasseur et Zack Shelby, « The Internet of Things », dans IETF Journal, Volume 6, Issue 2, novembre 2010 [texte intégral] 
  • (en) Jonathan W. Hui et David E. Culler, « IP is Dead, Long Live IP for Wireless Sensor Networks », dans SenSys '08 Proceedings of the 6th ACM conference on Embedded network sensor systems, 2008 [texte intégral, lien DOI] 
  • (en) John Carey, « Obama's Smart-Grid Game Plan », dans businessweek, octobre 2009 [texte intégral] 
  • (en) Elgar Fleisch, « What is the Internet of Things? An Economic Perspective », dans www.autoidlabs.org, janvier 2010 [texte intégral] 
  • (en) Michael Chui, Markus Löffler et Roger Roberts, « The Internet of Things », dans McKinsey Quarterly, mars 2010 [texte intégral] 
  • (en) Carsten Bormann, « Getting Started with IPv6 in Low-Power Wireless “Personal Area” Networks (6LoWPAN) », dans Tutorial on Interconnecting Smart Objects with the Internet Prague, 26 mars 2011, p. 27 [texte intégral] 

RFC et travaux de l'IETF

Liens externes


Wikimedia Foundation. 2010.

Contenu soumis à la licence CC-BY-SA. Source : Article 6LoWPAN de Wikipédia en français (auteurs)

Игры ⚽ Поможем сделать НИР

Regardez d'autres dictionnaires:

  • 6LoWPAN — is an acronym of IPv6 over Low power Wireless Personal Area Networks . 6lowpan is the name of the working group in the internet area of IETF. 6lowpan is the coupling that is aimed at allowing IPv6 packets to be sent to and received from Personal… …   Wikipedia

  • 6loWPAN — стандарт взаимодействия по протоколу IPv6 поверх маломощных беспроводных персональных сетей стандарта IEEE 802.15.4. 6loWPAN Аббревиатура от IPv6 over Low power Wireless Personal Area Networks . 6lowpan это имя рабочей группы IETF в области… …   Википедия

  • 6LoWPAN — ist ein Kommunikationsprotokoll zur Funkdatenübertragung und eine Arbeitsgruppe der IETF, die für diesen Standard zuständig ist, der zunächst in RFC 4944 festgelegt wurde. Der Standard umfasst dabei auch Header Kompressionsverfahren, die es… …   Deutsch Wikipedia

  • IEEE 802.15 — is the 15th working group of the IEEE 802 which specializes in Wireless PAN (Personal Area Network) standards. It includes six task groups (numbered from 1 to 6):Task group 1 (WPAN/Bluetooth)IEEE 802.15.1 2002 has derived a Wireless Personal Area …   Wikipedia

  • Ad-hoc On-demand Distance Vector — AODV (pour Ad hoc On Demand Distance Vector) est un protocole de routage destiné aux réseaux mobiles (en mode ad hoc). Il est à la fois capable de routage Unicast et Multicast. Il est libre de boucle, auto démarrant et s accommode d un grand… …   Wikipédia en Français

  • Ben NanoNote — A Ben NanoNote held on the palm of a hand Manufacturer Qi hardware, Sharism At Work Ltd Operating system Custom edition of OpenWrt …   Wikipedia

  • Daintree Networks (company) — Daintree Networks Type Private Industry Wireless Building Control Founded 2003 Headquarters …   Wikipedia

  • ZigBee — module. The €1 coin, shown for size reference, is about 23 mm (0.9 inch) in diameter. ZigBee is a specification for a suite of high level communication protocols using small, low power digital radios based on an IEEE 802 standard for personal… …   Wikipedia

  • Wireless sensor network — WSN redirects here. For the metasyntax, see Wirth syntax notation. Typical multi hop wireless sensor network architecture A wireless sensor network (WSN) consists of spatially distributed autonomous sensors to monitor physical or environmental… …   Wikipedia

  • Qi hardware — Inc. Type Public Industry Computer hardware Computer software Consumer electronics Digital distribution …   Wikipedia

Share the article and excerpts

Direct link
… Do a right-click on the link above
and select “Copy Link”