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].

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 1 280 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[14]) est préconisée[15] 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[16]) 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 »
À cause des caractéristiques des LoWPANs, les applications nécessitant beaucoup de ressources ne sont pas forcément 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)[17].
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 1 280 octets et les envoie à son équivalent 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[18].

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[19] :

  • 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[20].

Pour pallier ce problème, un mécanisme de récupération des fragments a été proposé[21]. 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 RFC 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[22]. Pour pallier ce problème, un draft IETF LOWPAN_HC1g[23] 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[24].

Aujourd’hui la proposition du groupe 6LoWPAN est d’utiliser LOWPAN_IPHC[25]. 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[26] :

  • 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 est dans le meilleur des cas de 70 à 75 octets. En effet, si l'on rajoute les informations de fragmentation comme indiqué 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 de l'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[27]. 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é[28] d'associer les transmissions sur ces ports à Transport Layer Security (TLS) (RFC 5246[29]). 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[30]).

Cependant, seul UDP est spécifié[31]. D’autres propositions ont donc été faites pour compresser TCP[32] et ICMP[33]. Il est donc nécessaire de spécifier la compression de chaque nouvel en-tête[34]. Pour pallier ce problème, 6LoWPAN_GHC[35] 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[36].

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. À 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[37] :

  • 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[38] :

  • 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[39], DYMO-LOW [40], HI-LOW [41].

Aujourd'hui, seuls deux protocoles sont légitimes pour de larges déploiements :

  • LOADng (de l'anglais Lightweight On-demand Ad hoc distance-vector routing protocol – next generation), le successeur de LOAD, un protocole mesh-under, standardisé à l'ITU au sein de la recommandation ITU-T G.9903. Ce standard est notamment utilisé au sein du programme Linky de compteurs électriques communicants d'Enedis (déploiement en France de 35 millions de compteurs) et d’Enexis (déploiement aux Pays-Bas de 2,5 millions de compteurs).
  • RPL (de l'anglais Routing Protocol for Low power and Lossy Networks, « protocole de routage pour LLN »)[42], un protocole route-over, standardisé au sein du groupe de travail ROLL[43] de l’IETF chargé de 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[44] : Routing Requirements for Urban LLNs ;
  • RFC 5673[45] : Industrial Routing Requirements in LLNs ;
  • RFC 5826[46] : Home Automation Routing Requirements in LLNs ;
  • RFC 5867[47] : Building Automation Routing Requirements in LLNs.
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-Oriented Directed Acyclic Graph, « graphe acyclique orienté vers la destination »). 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[48].

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[49] :

  • 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[50].

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[51] 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[52].

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[52]. Une façon de limiter le multicast consiste, entre autres, à ne pas lancer de DAD (de l'anglais Duplicate Address Detection, « Détection d'Adresse en Doublon ») en cas d’utilisation d’EUI64[52].

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[53].

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[54] :

  • 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 »[55]. 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 »)[55], 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é »)[53], ces messages de type RA transportent des préfixes d’adresses, des informations de contexte, et l’adresse du LBR[53]. 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 »)[54] et le DAC (de l'anglais Duplicate Address Confirmation, « confirmation d'adresse double »)[54].

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

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[57]. L'analogie a été prise avec les définitions de couleurs : trois vecteurs distance vers les références Vert, Bleu et Rouge[58].

En , 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 »)[59].

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[60]. 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[61].

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[62].

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[63].

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[64]) pour 6LoWPAN. En compressant les en-têtes et les différents messages, il est possible de réutiliser MIPv6 pour 6LoWPAN[65].
  • Utiliser Proxy MIPv6 (RFC 5213[66]) pour pallier le problème de la signalisation qui ne peut pas être gérée par les nœuds[67].
  • Lightweight NEMO : une version légère de NEMO Basic Support Protocol (RFC 3963[68]) pour 6LoWPAN dont le but est de réduire la surcharge due à l’en-tête de mobilité en le compressant[69].
  • Inter-PAN : mécanisme de gestion de la mobilité au niveau de la couche adaptation de 6LoWPAN[70].
  • 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é[71].
  • 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[72].
  • 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 »)[73].

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[68]) dans 6LoWPAN[63].

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[74] a été faite en s’appuyant sur des travaux en cours à l'IETF[75]. 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[76] et en les émettant en broadcast ou multicast (Méthode BroadcastGetRequest)[77] 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[78]. 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[79]. Elles sont regroupées sous le terme LNMP (de l'anglais LoWPAN Network Managment Protocol, « protocole de gestion des réseaux LoWPAN »)[80].

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

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[81] du 802.15.4, elle s’appuie ensuite sur une proposition IETF de MIB pour trois domaines[82] (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 broadcasts 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

En ce qui concerne la gestion de la MIB IPv6 (RFC 4293), elle définit l’adaptation[83] 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[83].

Gestion de Réseau

En s’appuyant sur le b6LoWPAN (Berkeley6LoWPAN Implementation, appelé aujourd’hui BLIP)[84], un Agent 6LoWPAN-SNMP a été développé[85]. 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[86], 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[87] 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[88]. En 2008, il a été montré la faisabilité de SOAP dans les LoWPAN[89]. 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[90]) peut être bénéfique car XML est trop verbeux pour les LoWPAN[91],[92]. Cette même année, SENSEI[93] (projet de intergiciel M2M basé sous XML) souhaite mettre leur effort et leur travail au développement des applications sur 6LoWPAN[94].

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

  • 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[96]) 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 ressources des équipements[97] ;
  • 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[95].

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 , l'IETF a lancé un nouveau groupe de travail appelé CORE[98] (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[98] (de l'anglais Constrained Application Protocol, « protocole d'applications contraintes »).

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

  • 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[100]) 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éfinit quatre 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
1GET65201-Created
2POST66202-Deleted
3PUT68204-Changed
4DELETE69205-Content
131403-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[101]. 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[102]. La découverte des ressources, leurs attributs et leurs relations dans les LoWPAN utilisant CORE sont définies comme ceci[103] :

  • 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[104] 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[105].

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[106].

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[107] ou d'autres très simples[108] de mise en œuvre.
  • l’utilisation de Compress-IPFIX[109],[110], un dérivé du protocol IPFIX (RFC 5101[111]), 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[112] ;
  • les bonnes pratiques de correspondance HTTP-CoAP[113] ;
  • 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 bâtiment 1 : « coap://all.etage1.bat1/rt=temperature »). Ce système fait appel au mécanisme de diffusion Multicast MLD(RFC 3810[114]), 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[115]) est indispensable[116].
  • l'utilisation de CoAP pour les BAC (de l'anglais Building Automation and Control, « Automatisation et Contrôle des Bâtiments »)[117] ;
  • l'amélioration des langages WebServices pour CoAP[118],[119].
  • 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[120].

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 possibilités d'attaques sur les réseaux 6LoWPAN ont été mises en évidence, celles-ci sont classifiées en deux catégories[121] :

  • 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 malveillantes (problèmes 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[121].

  • Sur la couche MAC : l'algorithme AES doit ê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és IKEv2 (RFC 5996[122]) n'est pas utilisable. Une gestion de clé de chiffrement 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[123]) (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é »)[124].
  • 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 "Timestamp" 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 »)[125]
  • la compression de l'entête IPsec pour optimiser la charge utile[126].
  • la mise en place d'un intergiciel permettant l'analyse de risque de sécurité dans les 6LoWPAN[127].
  • l'optimisation du cryptage[128].

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[129] ou EnOcean[130]). Avec la norme IEEE 802.15.4 (utilisation radio des capteurs sans-fil) de nouveaux standards propriétaires sont apparus (par exemple, ZigBee[131], Wireless-HART[132], etc.).

Lors de premières réflexions sur la mise en réseau de capteurs sans fils, 6LoWPAN est né d’une idée simple : « pourquoi réinventer un protocole alors que 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[133]) publie une thématique sur l'Internet des objets qui fait aujourd'hui référence[134].
  • 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 de la « European Technology Platform Smart Grid[135] », indique que les « smart grids[note 5] » électriques intégrant des « smart objects »[note 6] » qui permettent de gérer et optimiser la consommation électrique sont stratégiques[136].
  • Les États-Unis lancent un programme pour soutenir le développement des smart grids[137] 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ée[138].
Mars
Une première implémentation de 6LoWPAN sur TinyOS sort sur l'implémentation de « Arch Rock Compagnie : Primer Pack/IP ».
Avril
Une première implémentation de 6LoWPAN sur TinyOS est disponible sur l'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 des équipements d’un LoWPAN via l'IPv6 et de remplacer les protocoles de communication propriétaires comme ZigBee[139],[140], qui a été développé après la fin du projet Smart Dust[141].
2008
  • Les premiers tests démontrent que les équipements d'un réseau 6LoWPAN utilisant la pile UIP (micro IP) (aussi notée ųIPv6) pouvaient satisfaire les exigences de la phase 1 d'IPv6 Ready[142]. 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)[143]. Cette même année, l'entreprise Arch Rock lance un produit commercial IPv6/6LoWPAN répondant aux exigences d'IPv6 Ready phase 2 (Gold)[144]. De plus, une expérimentation de quatre semaines dans un environnement réel montre que l'utilisation des réseaux 6LoWPAN est réaliste (taux de délivrance des messages de 99.98 % et taux moyen de latence par saut < 62 ms)[145].
  • Le Conseil de l'Intelligence Nationale des États-Unis (NIC[146]) indique que l'Internet des objets (Internet of Things ou IoT) est l'une des technologies de rupture qui va structurer les tendances jusqu'en 2025[147].
juillet
L'IETF lance le groupe de travail ROLL[43].
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 certaines implémentations de 6LoWPAN (Berkeley IP, Arch Rock, SICSlowpan, Sensinode et Hitachi) ayant des systèmes d'exploitation « open source » (TinyOS et Contiki) et propriétaires (Sensinode et Hitachi)[148].
  • Sortie du livre 6LoWPAN: The Wireless Embedded Internet de Zach Shelby et Carsten Bormann, l'un des deux livres de référence concernant le 6LoWPAN[5]
octobre
Pour développer les smart grids[137], le président Obama annonce un investissement de 3,4 Milliards de dollars[149].
2010
  • Une expérimentation de 12 mois dans différents environnements montre que l'implémentation des réseaux 6LoWPAN est viable (taux de délivrance des messages > 99.9 % et taux moyen de latence par saut < 125 ms)[150].
  • Sortie du livre Interconnecting Smart Objects with IP: The Next Internet de Jean-Philippe Vasseur et Adam Dunkels, l'un des deux livres de référence concernant le 6LoWPAN[6].
janvier
Une étude démontre des perspectives économiques importantes dans l'IoT[151].
mars
  • L'IETF lance le nouveau groupe de travail CORE[98].
  • 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 an aux États-Unis. De même, l'utilisation de IoT dans le transport pourrait diminuer le nombre d'accidents sur la route et de ce fait économiser environ 100 Milliards de dollars par an[152].
septembre
Cisco[153] rachète la société Arch Roch (l'un des leaders des applications BAC pour les WSN)[154], ce qui renforce l'alliance stratégique préalablement signée entre Cisco et Itron[155] (spécialiste compteurs smart grid)[156].
2011
janvier
  • Un nouveau groupe de travail IETF, LWIG[157] (de l'anglais Light-Weight Implementation Guidance, « conseils de mise en œuvre légère ») est créé dans le but d'optimiser la pile 6loWPAN (moins d'utilisation mémoire, de consommation énergie et de complexité) pour une meilleure performance des équipements 6LoWPAN. Actuellement, dans ce groupe de travail, nous trouvons :
  • un guide pour l'implémentation d'une API 6LoWPAN[158]
  • une étude sur les problèmes d'interconnexion des 6LoWPAN aux réseaux IPv4 ainsi que quelques solutions[159].

Les Solutions 6LoWPAN

Les usages possibles

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

Cas d'usage possible de 6LoWPAN
L'industrie (Industrial Monitoring)
Exemple, détection de pièces défectueuses sur une chaîne 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)
Exemples, permettre 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ées 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 structures d'édifices tels que des barrages, des ponts…
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 médecin de surveiller et suivre l'état de santé (taux de sucre (diabète), le pouls…) de ses patients directement sur un terminal (PC, Smartphone…).
les transports (Vehicle Telematics)
Exemple, pouvoir surveiller la trajectoire d'une voiture sur les routes, et en cas de détection d'une trajectoire dangereuse, 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 telles que la gestion de l'eau et l'utilisation de 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[161].

Ces utilisations sont "grand public", 6LoWPAN peut aussi être déployé pour des usages "privés" tels que des usages militaires[162]. 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[163].

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 Fabricant

WiSMote

MSP430x5 CC2520

16k

nc

256k

Arago Systems[173]

MICAz

Atmel ATmega128L

nc

4k

128k

Crossbow[174]

TELOSB

TI MSP430

10k

16k

48k

Crossbow[175]

JN5139

32-bits RISC processor

96k

192k

externe

Jennic[176]

RC2xxx

Single-cycle high performance 8051

8k

4k

32-256k

Radiocrafts[177]

WPC-IP

MSP430F5

16k

nc

256k

Watteco[178]

NanoStack

TI CC1110

4-8k

32-64k

32k

Sensinode[179]

Tmote Sky

TI MSP430

10k

nc

48k

Moteiv ⇒ Sentilla[180]

eSPOT

ARM 926ej-S

1M

nc

8M

Sun SPOT[181]

PN2420

Atmega128L / MSP430

4k

nc

128k

PicosNet[182]

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

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

RIOT

NanoStack 2.0

Windows CE

COAPy (Python)

Wireshark

FreeRTOS

Sensinode

Android

jCoAPy (Java)

Copper : Extension Firefox

TinyOS

ZigBee SE2

Symbian

opencoap (C)
Contiki

libcoap (C)

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

Plusieurs implémentations de 6LoWPAN ont soulevé des problèmes. Parmi ceux-ci, on peut noter :

  • des problèmes d'interférence sur la bande de fréquence 2,4 GHz (en) ont pour effet de créer une augmentation des pertes de paquets et des RTT[185],[186].
  • une augmentation des pertes de paquets et des RTT lorsque la taille de la charge utile est trop importante[187].
  • la mise au place d'un délai élevé d’attente des paquets (> 500 ms) nécessaire pour limiter la perte de paquets[185].
  • l'utilisation excessive de SNMPv3 provoque une utilisation de la ROM importante, il en est de même pour la mise en place de l'authentification SNMP qui augmente aussi la latence[188].

À l'origine 6LoWPAN était fait pour être utilisé dans les réseaux 802.15.4. À partir de l'année 2010, 6LoWPAN a commencé à être utilisé sur d'autres supports (par exemple les courants porteurs en ligne[189], RFID[190] et Bluetooth[191]) et donc à être au cœur de l'"Internet des objets". Tous les travaux de l'IETF, à l'état de "draft", sont opérationnels mais ceux-ci ne sont pas encore tous formellement standardisés. Ils sont (en 2010) en perpétuelle évolution pour optimiser l'utilisation de 6LoWPAN[192].

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

Bibliographie

Livres et Articles
  • (en) Geoff Mulligan, « The 6LoWPAN architecture », Proceedings of the 4th workshop on Embedded networked sensors,‎ , p. 78-82 (DOI http://doi.acm.org/10.1145/1278972.1278992, lire en ligne)
  • (en) IEEE Standard for Information technology-- Local and metropolitan area networks-- Specific requirements-- : Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (WPANs), IEEE Std 802.15.4-2006 (Revision of IEEE Std 802.15.4-2003), , 320 p. (lire en ligne) lien DOI
  • (en) Zach Shelby et Carsten Bormann, 6LoWPAN : The Wireless Embedded Internet, Chichester, John Wiley & Sons, , 244 p., 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, (ISBN 978-0-12-375165-2, LCCN 2010001206, présentation en ligne)
  • (en) IEEE Standard for Information Technology - Telecommunications and Information Exchange Between Systems : Local and Metropolitan Area Networks Specific Requirements : Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs), IEEE Std 802.15.4-2003, , 670 p. (lire en ligne) lien DOI
  • (en) Houda Labiod, Hossam Afifi et Costantino Santis, Wi-Fi, Bluetooth, Zigbee and WiMax, Dordrecht, Springer Netherlands, , 11e éd. (ISBN 978-1-4020-5396-2, lire en ligne)
  • (en) Shahin Farahani, ZigBee Wireless Networks and Transceivers, Amsterdam, Newnes, , poche (ISBN 978-0-7506-8393-7, LCCN 2009275319, lire en ligne)
  • (en) Brett Warneke, Matt Last, Brian Liebowitz et Kristofer Pister, « Smart Dust: Communicating with a Cubic-Millimeter Computer », Computer,‎ , p. 44-51 (DOI /10.1109/2.895117, lire en ligne)
  • (en) National Intelligence Council, The Internet of things : Appendix F, NIC, , p. 1-19 texte intégral
  • (en) International Telecommunication Union, Internet of Things summary, ITU, 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 », The Internet of the Future 15th Open European Summer School and IFIP TC6.6 Workshop, EUNICE 2009, vol. 5733,‎ , p. 168-177 (DOI 10.1007/978-3-642-03700-9_18, lire en ligne)
  • (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 », Proceedings of the 2009 International Conference on Wireless Communications and Mobile Computing: Connecting the World Wirelessly,‎ , p. 1208-1212 (DOI 10.1145/1582379.1582643, lire en ligne)
  • (en) Alessandro Ludovici, Anna Calveras et Jordi Casademont, « Forwarding Techniques for IP Fragmented Packets in a Real 6LoWPAN Network », Sensors,‎ , p. 992-1008 (DOI 10.3390/s110100992, lire en ligne)
  • (en) Nicolas Tsiftes, Joakim Eriksson et Adam Dunkels, « Low-Power Wireless IPv6 Routing with ContikiRPL », Proceedings of the 9th ACM/IEEE International Conference on Information Processing in Sensor Networks,‎ , p. 406-407 (DOI 10.1145/1791212.1791277, lire en ligne)
  • (en) Myung-Ki Shin et Hyoung-Jun Kim, « L3 mobility support in large-scale IP-based sensor networks (6LoWPAN) », Advanced Communication Technology, 2009. ICACT 2009. 11th International Conference on, vol. 02,‎ , p. 941-945 (lire en ligne)
  • (en) Jin Ho Kim, Choong Seon Hong et Taeshik Shon, « A Lightweight NEMO Protocol to Support 6LoWPAN », ETRI Journal, vol. 30,‎ , p. 787-792 (DOI 10.1109/ICCIT.2008.290, lire en ligne)
  • (en) Gargi Bag, Mukhtar Hamid, S.M. Saif Shams, Ki Hyung Kim et Seung-wha Yoo, « Inter-PAN Mobility Support for 6LoWPAN », Convergence and Hybrid Information Technology, 2008. ICCIT '08. Third International Conference on, vol. 1,‎ , p. 685-695 (DOI 10.1109/ICCIT.2008.290, lire en ligne)
  • (en) Zinon Zinonos et Vasos Vassiliou, « Inter-mobility support in controlled 6LoWPAN networks », GLOBECOM Workshops (GC Wkshps), 2010 IEEE,‎ , p. 1718-1723 (DOI 10.1109/GLOCOMW.2010.5700235, lire en ligne)
  • (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 », GLOBECOM 2010, 2010 IEEE Global Telecommunications Conference,‎ , p. 1-6 (DOI 10.1109/GLOCOM.2010.5683658, lire en ligne)
  • (en) Md. Motaharul Islam et Eui-Nam Huh, « ISensor Proxy Mobile IPv6 (SPMIPv6)—A Novel Scheme for Mobility Supported IP-WSNs », Sensors,‎ , p. 1865-1887 (DOI 10.3390/s110201865, lire en ligne)
  • (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 », Military Communications Conference, 2009. MILCOM 2009. IEEE,‎ , p. 1-7 (DOI 10.1109/MILCOM.2009.5379823, lire en ligne)
  • (en) Kevin Dominik Korte, Iyad Tumar et Jurgen Schonwalder, « Evaluation of IPv6 over low-power wireless personal area networks implementations », Local Computer Networks, 2009. LCN 2009. IEEE 34th Conference on,‎ , p. 881-888 (DOI 10.1109/LCN.2009.5355015, lire en ligne)
  • (en) Thomas Luckenbach, Peter Gober et Stefan Arbanowski, « TinyREST – a Protocol for Integrating Sensor Networks into the Internet », Proc. of REALWSN,‎ (lire en ligne)
  • (en) Nissanka B. Priyantha, Aman Kansal, Michel Goraczko et Feng Zhao, « Tiny web services: design and implementation of interoperable and evolvable sensor networks », SenSys '08 Proceedings of the 6th ACM conference on Embedded network sensor systems,‎ , p. 43-48 (lire en ligne)
  • (en) Dogan Yazar et Adam Dunkels, « Efficient Application Integration in IP-Based Sensor Networks », BuildSys '09 Proceedings of the First ACM Workshop on Embedded Sensing Systems for Energy-Efficiency in Buildings,‎ , p. 43-48 (ISBN 978-1-60558-824-7, DOI /10.1145/1810279.1810289, lire en ligne)
  • (en) Corinna Schmitt, Lothar Braun, Thomas Kothmayr et Georg Carle, « Collecting sensor data using compressed IPFIX », IPSN '10 Proceedings of the 9th ACM/IEEE International Conference on Information Processing in Sensor Networks,‎ , p. 390-391 (ISBN 978-1-60558-988-6, DOI http://doi.acm.org/10.1145/1791212.1791269, lire en ligne)
  • (en) Choi Haksoo, Nakyoung Kim et Hojung Cha, « 6LoWPAN-SNMP: Simple Network Management Protocol for 6LoWPAN », 11th IEEE International Conference on High Performance Computing and Communications,‎ , p. 305-313 (ISBN 978-076953738-2, DOI 10.1109/HPCC.2009.49, lire en ligne)
  • (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) », NOMS 2008 - IEEE/IFIP Network Operations and Management Symposium: Pervasive Management for Ubiquitous Networks and Services,‎ , p. 417-424 (ISBN 978-142442066-7, DOI 10.1109/NOMS.2008.4575163, lire en ligne)
  • (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 », SenSys '08 Proceedings of the 6th ACM conference on Embedded network sensor systems,‎ , p. 421-422 (ISBN 978-1-59593-990-6, DOI http://doi.acm.org/10.1145/1460412.1460483, lire en ligne)
  • (en) Chauvenet, Tourancheau et Genon-Catalot, « 802.15.4, a MAC layer solution for PLC », Computer Systems and Applications (AICCSA), 2010 IEEE/ACS International Conference,‎ , p. 1-8 (ISBN 978-1-4244-7716-6, DOI /10.1109/AICCSA.2010.5586997, lire en ligne)
  • (en) Ricardo Silva, Valderi R.Q. Leithardt, Jorge Sa Silva, Claudio Geyer, Joel Rodrigues et Fernando Boavida, « A comparison of approaches to node and service discovery in 6lowPAN wireless sensor networks », Q2SWinet '09 Proceedings of the 5th ACM symposium on QoS and security for wireless and mobile networks,‎ , p. 44-49 (ISBN 978-1-60558-619-9, DOI /10.1145/1641944.1641954, lire en ligne)
  • (en) Nils Glombitza, Dennis Pfisterer et Stefan Fischer, « Integrating wireless sensor networks into web service-based business processes », MidSens '09 Proceedings of the 4th International Workshop on Middleware Tools, Services and Run-Time Support for Sensor Networks,‎ , p. 25-30 (ISBN 978-1-60558-851-3, DOI /10.1145/1658192.1658197, lire en ligne)
  • (en) Usman Sarwar, Gopinath Sinniah Rao, Zeldi Suryady et Reza Khoshdelniat, « A Comparative Study on Available IPv6 Platforms for Wireless Sensor Network », waset.ac.nz,‎ , p. 889-892 (lire en ligne)
  • (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 », MidSens '10 Proceedings of the 5th International Workshop on Middleware Tools, Services and Run-Time Support for Sensor Networks,‎ , p. 8 -14 (ISBN 978-1-4503-0454-2, DOI /10.1145/1890784.1890787, lire en ligne)
  • (en) Lars Schor, Philipp Sommer et Roger Wattenhofer, « Towards a Zero-Configuration Wireless Sensor Network Architecture for Smart Buildings », BuildSys '09 Proceedings of the First ACM Workshop on Embedded Sensing Systems for Energy-Efficiency in Buildings,‎ , p. 31-36 (ISBN 978-1-60558-824-7, DOI /10.1145/1810279.1810287, lire en ligne)
  • (en) HyunGon Kim, « Protection Against Packet Fragmentation Attacks at 6LoWPAN Adaptation Layer », Convergence and Hybrid Information Technology, 2008. ICHIT '08. International Conference,‎ , p. 796-801 (ISBN 978-0-7695-3328-5, DOI /10.1109/ICHIT.2008.261, lire en ligne)
  • (en) Shahid Raza, Thiemo Voigt et Utz Roedig, « 6LoWPAN Extension for IPsec », Conference or Workshop Item (Paper),‎ , p. 1-3 (lire en ligne)
  • (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 », NEWCOM++ Dissemination Day,‎ (lire en ligne)
  • (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 », 1st International Workshop on the Security of the Internet of Thing,‎ (lire en ligne[archive du ])
  • (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 », PM2HW2N '09 Proceedings of the 4th ACM workshop on Performance monitoring and measurement of heterogeneous wireless and wired networks,‎ , p. 25-30 (ISBN 978-1-60558-621-2, DOI /10.1145/1641913.1641917, lire en ligne)
  • (en) Jurgen Schonwalder, Tina Tsou et Behcet Sarikaya, « Protocol Profiles for Constrained Devices », www.iab.org,‎ , p. 1-5 (lire en ligne)
  • (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 », Information Networking (ICOIN), 2011 International Conference,‎ , p. 171-176 (ISBN 978-1-61284-661-3, ISSN 1976-7684, DOI /10.1109/ICOIN.2011.5723173, lire en ligne)
  • (en) Chieh-Jan Mike Liang, Nissanka Bodhi Priyantha, Jie Liu et Andreas Terzis, « Surviving wi-fi interference in low power ZigBee networks », SenSys '10 Proceedings of the 8th ACM Conference on Embedded Networked Sensor Systems,‎ , p. 309-322 (ISBN 978-1-4503-0344-6, DOI /10.1145/1869983.1870014, lire en ligne)
  • (en) Hyojeong Shin, Elmurod Talipov et Hojung Cha, « IPv6 lightweight stateless address autoconfiguration for 6LoWPAN using color coordinators », Proceedings of the 2009 IEEE International Conference on Pervasive Computing and Communications,‎ , p. 1-9 (DOI 10.1109/PERCOM.2009.4912770, lire en ligne)
  • (en) Elmurod Talipov, Hyojeong Shin, Seungjae Han et Hojung Cha, « A lightweight stateful address autoconfiguration for 6LoWPAN », Wirel. Netw., vol. 17,‎ , p. 183-197 (ISSN 1022-0038, DOI 10.1007/s11276-010-0272-0, lire en ligne)
  • (en) Jonathan W. Hui et David E. Culler, « IPv6 in Low-Power Wireless Networks », Proceedings of the IEEE,‎ , p. 1865-1878 (DOI 10.1109/JPROC.2010.2065791, lire en ligne)
  • (en) « XIII of the Energy Independence and Security Act of 2007 », smartgrid.gov,‎ (lire en ligne)
  • (en) M Chebbo, « EU SmartGrids Framework "Electricity Networks of the future 2020 and beyond" », Power Engineering Society General Meeting, 2007. IEEE,‎ (DOI /10.1109/PES.2007.386294, lire en ligne)
  • (en) Carsten Bormann, JP Vasseur et Zack Shelby, « The Internet of Things », IETF Journal, Volume 6, Issue 2,‎ (lire en ligne[archive du ])
  • (en) Jonathan W. Hui et David E. Culler, « IP is Dead, Long Live IP for Wireless Sensor Networks », SenSys '08 Proceedings of the 6th ACM conference on Embedded network sensor systems,‎ (DOI /10.1145/1460412.1460415, lire en ligne)
  • (en) John Carey, « Obama's Smart-Grid Game Plan », businessweek,‎ (lire en ligne)
  • (en) Elgar Fleisch, « What is the Internet of Things? An Economic Perspective », www.autoidlabs.org,‎ (lire en ligne)
  • (en) Michael Chui, Markus Löffler et Roger Roberts, « The Internet of Things », McKinsey Quarterly,‎ (lire en ligne)
  • (en) Carsten Bormann, « Getting Started with IPv6 in Low-Power Wireless “Personal Area” Networks (6LoWPAN) », Tutorial on Interconnecting Smart Objects with the Internet Prague,‎ , p. 27 (lire en ligne)

RFC et travaux de l'IETF

Liens externes
  • Portail des réseaux informatiques
  • Portail de l’informatique
  • Portail des télécommunications
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.