6LoWPAN

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

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 1^re 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.

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.

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

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 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 »)[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é 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].

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.

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

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

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.

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 juillet 2009, 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 mars 2010, 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 (« 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) ;

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

Dans un premier temps, les usages possibles des réseaux 6LoWPAN ont été définis en juin 2007[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].

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

• Sensinode[164], Arch Rock[165], PicosNet[166], ZigBee SE2[131], Indrion[167], Linky d'ERDF[168], WattECO[169], PACHUBE[170], Sport-Tracker[171], Google Powermeter[172]…

Ainsi que du matériel compatible 6LoWPAN :

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

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

• HOBNET[183], SENSEI[93], EUREKA[184]…

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

• (en) Geoff Mulligan, « The 6LoWPAN architecture », Proceedings of the 4th workshop on Embedded networked sensors,‎ 2007, p. 78-82 (DOI 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), 7 septembre 2006, 320 p. (lire en ligne) lien DOI
• (en) Zach Shelby et Carsten Bormann, 6LoWPAN : The Wireless Embedded Internet, Chichester, John Wiley & Sons, 2009, 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, 2010 (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, 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, 2003, 11^e éd. (ISBN 978-1-4020-5396-2, lire en ligne)
• (en) Shahin Farahani, ZigBee Wireless Networks and Transceivers, Amsterdam, Newnes, 2008, 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,‎ 2001, p. 44-51 (DOI /10.1109/2.895117, lire en ligne)
• (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 », The Internet of the Future 15th Open European Summer School and IFIP TC6.6 Workshop, EUNICE 2009, vol. 5733,‎ 2001, 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,‎ 2009, 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,‎ 2011, 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,‎ 2010, 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,‎ 2009, 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,‎ novembre 2009, 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,‎ octobre 2008, 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,‎ décembre 2010, 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,‎ décembre 2010, 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,‎ 2011, 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,‎ octobre 2009, 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,‎ octobre 2009, 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,‎ 2005 (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,‎ 2008, 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,‎ 2009, 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,‎ 2010, p. 390-391 (ISBN 978-1-60558-988-6, DOI 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,‎ 2009, 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,‎ 2008, 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,‎ 2008, p. 421-422 (ISBN 978-1-59593-990-6, DOI 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,‎ mai 2010, 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,‎ 2009, 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,‎ 2009, 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,‎ 2010, 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,‎ 2010, 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,‎ 2009, 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,‎ août 2008, 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),‎ mars 2011, 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,‎ 2010 (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,‎ 2010 (lire en ligne [archive du 24 septembre 2011])
• (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,‎ février 2009, 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,‎ février 2011, 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,‎ mars 2011, 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,‎ 2010, 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,‎ 2009, 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,‎ janvier 2011, 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,‎ 2010, 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,‎ 2007 (lire en ligne)
• (en) M Chebbo, « EU SmartGrids Framework "Electricity Networks of the future 2020 and beyond" », Power Engineering Society General Meeting, 2007. IEEE,‎ juillet 2007 (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,‎ novembre 2010 (lire en ligne [archive du 5 juin 2011])
• (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,‎ 2008 (DOI /10.1145/1460412.1460415, lire en ligne)
• (en) John Carey, « Obama's Smart-Grid Game Plan », businessweek,‎ octobre 2009 (lire en ligne)
• (en) Elgar Fleisch, « What is the Internet of Things? An Economic Perspective », www.autoidlabs.org,‎ janvier 2010 (lire en ligne)
• (en) Michael Chui, Markus Löffler et Roger Roberts, « The Internet of Things », McKinsey Quarterly,‎ mars 2010 (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,‎ 26 mars 2011, p. 27 (lire en ligne)

• (en) « RFC 3135 : Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations », juin 2001
• (en) « RFC 3775 : Mobility Support in IPv6 », juin 2004
• (en) « RFC 3986 : Uniform Resource Identifier (URI): Generic Syntax », janvier 2005
• (en) « RFC 3963 : Network Mobility (NEMO) Basic Support Protocol », janvier 2005
• (en) « RFC 4303 : TIP Encapsulating Security Payload (ESP) », décembre 2005
• (en) « RFC 4347 : Datagram Transport Layer Security », avril 2006
• (en) « RFC 4627 : The application/json Media Type for JavaScript Object Notation (JSON) », septembre 2006
• (en) « RFC 4919 : IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals », août 2007
• (en) « RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks », septembre 2007
• (en) « RFC 5101 : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information », janvier 2008
• (en) « RFC 5213 : Proxy Mobile IPv6 », août 2008
• (en) « RFC 5246 : The Transport Layer Security (TLS) Protocol Version 1.2 », août 2008
• (en) « RFC 5548 : Routing Requirements for Urban Low-Power and Lossy Networks », mai 2009
• (en) « RFC 5673 : Industrial Routing Requirements in Low-Power and Lossy Networks », octobre 2009
• (en) « RFC 5785 : Defining Well-Known Uniform Resource Identifiers (URIs) », avril 2010
• (en) « RFC 5826 : Home Automation Routing Requirements in Low-Power and Lossy Networks », avril 2010
• (en) « RFC 5867 : Building Automation Routing Requirements in Low-Power and Lossy Networks », juin 2010
• (en) « RFC 5988 : Web Linking », juin 2010
• (en) « RFC 6206 : The Trickle Algorithm », septembre 2011
• (en) « RFC 5996 : Internet Key Exchange Protocol Version 2 (IKEv2)) », mars 2010
• (en) « RFC 3971 : SEcure Neighbor Discovery (SEND) », mars 2005
• (en) « RFC 3810 : Multicast Listener Discovery Version 2 (MLDv2) for IPv6 », juin 2004
• (en) « RFC 4605 : Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying") », août 2006
• (en) « draft-daniel-6lowpan-load-adhoc-routing-03 : 6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD) », juin 2007
• (en) « draft-montenegro-6lowpan-dymo-low-routing-03 : Dynamic MANET On-demand for 6LoWPAN (DYMO-low) Routing », juin 2007
• (en) « draft-daniel-6lowpan-hilow-hierarchical-routing-01 : Hierarchical Routing over 6LoWPAN (HiLow) », juin 2007
• (en) « draft-thubert-6lowpan-simple-fragment-recovery-07 : LoWPAN fragment Forwarding and Recovery », juin 2010
• (en) « draft-hui-6lowpan-hc1g-00 : Stateless IPv6 Header Compression for Globally Routable Packets in 6LoWPAN Subnetworks », juin 2007
• (en) « draft-ietf-6lowpan-hc-15 : Compression Format for IPv6 Datagrams in Low Power and Lossy Networks (6LoWPAN) », février 2011
• (en) « draft-aayadi-6lowpan-tcphc-01 : TCP header compression for 6LoWPAN », octobre 2010
• (en) « draft-oflynn-6lowpan-icmphc-00 : ICMPv6/ND Compression for 6LoWPAN Networks », juillet 2010
• (en) « draft-bormann-6lowpan-ghc-02 : 6LoWPAN Generic Compression of Headers and Header-like Payloads », mars 2011
• (en) « draft-ietf-6lowpan-routing-requirements-09 : Problem Statement and Requirements for 6LoWPAN Routing », février 2011
• (en) « WorkGroup : Roll Status Pages »
• (en) « draft-ietf-roll-rpl-19 : RPL: IPv6 Routing Protocol for Low power and Lossy Networks », mars 2011
• (en) « draft-ietf-roll-routing-metrics-19 : Routing Metrics used for Path Calculation in Low Power and Lossy Networks », mars 2011
• (en) « draft-shin-6lowpan-mobility-01 : Mobility Support in 6LoWPAN », novembre 2007
• (en) « draft-silva-6lowpan-mipv6-00 : An Adaptation Model for Mobile IPv6 support in lowPANs », mai 2009
• (en) « draft-ekim-6lowpan-scenarios-00 : Design and Application Spaces for 6LoWPANs », juin 2007
• (en) « draft-ietf-6lowpan-usecases-09 : Design and Application Spaces for 6LoWPANs », janvier 2011
• (en) « Constrained RESTful Environments : Description of Working Group », mars 2010
• (en) Z. Shelby et Al.(a), « draft-ietf-core-coap-06 : Constrained Application Protocol (CoAP) », mai 2011
• (en) Z. Shelby, « draft-ietf-core-link-format-04 : CoRE Link Format », mai 2011
• (en) Z. Shelby et Al.(b), « draft-ietf-core-observe-02 : Observing Resources in CoAP », mars 2011
• (en) Z. Shelby et Al.(c), « draft-ietf-core-block-03 : Blockwise transfers in CoAP », mai 2011
• (en) « draft-brandt-coap-subnet-discovery-00 : Discovery of CoAP servers across subnets », mars 2011
• (en) « draft-bormann-core-simple-server-discovery-00 : CoRE Simple Server Discovery », mars 2011
• (en) « draft-braun-core-compressed-ipfix-02 : Compressed IPFIX for smart meters in constrained networks », mars 2011
• (en) « draft-bormann-6lowpan-6lowapp-problem-01 : 6LowApp: Problem Statement for 6LoWPAN and LLN Application Protocols », 2009
• (en) « draft-hamid-6lowpan-snmp-optimizations-03 : SNMP Optimizations for Constrained Devices », octobre 2010
• (en) « draft-daniel-6lowpan-mib-01 : 6LoWPAN Management Information Base », octobre 2009
• (en) « draft-patil-6lowpan-v6over-btle-01 : Transmission of IPv6 Packets over Bluetooth Low Energy », mars 2011
• (en) « draft-gold-6lowapp-sensei-00 : SENSEI 6lowapp Requirements », octobre 2009
• (en) « draft-eggert-core-congestion-control-01 : Congestion Control for the Constrained Application Protocol (CoAP) », janvier 2011
• (en) « draft-castellani-core-http-coap-mapping-01 : Best Practice to map HTTP to COAP and viceversa », mars 2011
• (en) « draft-rahman-core-groupcomm-04 : Group Communication for CoAP », mars 2011
• (en) « draft-vanderstok-core-bc-03 : CoAP Utilization for Building Control », mars 2011
• (en) « draft-moritz-6lowapp-dpws-enhancements-01 : DPWS for 6LoWPAN », décembre 2010
• (en) « draft-moritz-core-soap-over-coap-00 : SOAP-over-CoAP Binding », janvier 2011
• (en) « WorkGroup : LWIG Status Pages »
• (en) « draft-williams-lwig-api-considerations-00 : Light Weight API Implementation Guidance », mars 2011
• (en) « draft-cao-lwig-gateway-00 : Considerations for Lightweight IP Gateways », mars 2011
• (en) « draft-daniel-6lowpan-security-analysis-05 : IPv6 over Low Power WPAN Security Analysis », mars 2011
• (en) « draft-sarikaya-6lowpan-cgand-01 : Lightweight Secure Neighbor Discovery for Low-power and Lossy Networks », mai 2011
• (en) « draft-cheshire-dnsext-dns-sd-10.txt : DNS-Based Service Discovery », février 2011
• (en) « draft-ietf-6lowpan-nd-15.txt : Neighbor Discovery Optimization for Low-power and Lossy Networks », décembre 2010