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 :
- Le principal document de cette problématique est la RFC 4919[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].
![](http://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Trame802.jpg/880px-Trame802.jpg)
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).
![](http://upload.wikimedia.org/wikipedia/commons/b/ba/Frag_header.jpg)
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.
![](http://upload.wikimedia.org/wikipedia/commons/thumb/c/cf/TrameHCFrag.jpg/880px-TrameHCFrag.jpg)
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.
Valeur | signification |
---|---|
| paquet IPv6 non compressé |
| Broadcast LoWPAN |
| premier fragment |
| fragment |
| 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
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.
![](http://upload.wikimedia.org/wikipedia/commons/thumb/b/bb/6LowPAN_DAG.jpg/330px-6LowPAN_DAG.jpg)
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].
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é
![](http://upload.wikimedia.org/wikipedia/commons/thumb/9/9e/6LoWPAN_Mobility.jpg/440px-6LoWPAN_Mobility.jpg)
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 relaie 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 correspondant à 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.
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é.
![](http://upload.wikimedia.org/wikipedia/commons/thumb/c/ca/ArchiCoAP3.jpg/550px-ArchiCoAP3.jpg)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/e/e4/ISOwithCoAP.jpg/180px-ISOwithCoAP.jpg)
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) :
![](http://upload.wikimedia.org/wikipedia/commons/thumb/a/af/CoaP-MSG-Header.jpg/440px-CoaP-MSG-Header.jpg)
- 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) ;
cas d'une demande | cas d'une réponse | ||
---|---|---|---|
Valeur Code | méthode HTTP | Valeur Code | réponse état HTTP |
1 | GET | 65 | 201-Created |
2 | POST | 66 | 202-Deleted |
3 | PUT | 68 | 204-Changed |
4 | DELETE | 69 | 205-Content |
131 | 403-Forbidden |
- Message Id ou TID (2 octets) : identifiant du message permettant de gérer la correspondance des messages CON et des réponses (ACK ou RST) ainsi que la détection des duplications.
L'URL CoAP est du type : « coap://serveur[:port]/ressources
».
Le format des liens web des ressources CORE est une extension des HTTP Link Header Format de la RFC 5988[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é)
![](http://upload.wikimedia.org/wikipedia/commons/c/c6/6lowpan-secu.jpg)
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 ou EnOcean). Avec la norme IEEE 802.15.4 (utilisation radio des capteurs sans-fil) de nouveaux standards propriétaires sont apparus (par exemple, ZigBee[129], WirelessHART (en), 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'Union internationale des télécommunications publie une thématique sur l'Internet des objets qui fait aujourd'hui référence[130].
- 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[131] », 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[132].
- Les États-Unis lancent un programme pour soutenir le développement des smart grids[133] 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[134].
- 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[135],[136], qui a été développé après la fin du projet Smart Dust[137].
- 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[138]. 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)[139]. 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)[140]. 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)[141].
- Le Conseil de l'Intelligence Nationale des États-Unis (National Intelligence Council, NIC) 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[142].
- 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)[143].
- 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[133], le président Obama annonce un investissement de 3,4 Milliards de dollars[144].
- 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)[145].
- 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[146].
- 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[147].
- septembre
- Cisco rachète la société Arch Rock (l'un des leaders des applications BAC pour les WSN), ce qui renforce l'alliance stratégique préalablement signée entre Cisco et Itron (spécialiste des compteurs smart grid)[148],[149].
- 2011
- janvier
- Un nouveau groupe de travail IETF, LWIG[150] (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[151]
- Une étude sur les problèmes d'interconnexion des 6LoWPAN aux réseaux IPv4 ainsi que quelques solutions[152].
Les Solutions 6LoWPAN
Les usages possibles
Dans un premier temps, les usages possibles des réseaux 6LoWPAN ont été définis en [153]. Les réseaux 6LoWPAN sont prévus pour être déployés dans les domaines suivants[154] :
![](http://upload.wikimedia.org/wikipedia/commons/thumb/5/50/6LoWPAN-usage.jpg/550px-6LoWPAN-usage.jpg)
- 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[154].
Ces utilisations sont "grand public", 6LoWPAN peut aussi être déployé pour des usages "privés" tels que des usages militaires[155]. 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[156].
Les solutions existantes
Actuellement, diverses solutions utilisant 6LoWPAN sont déployées, on peut citer :
- Sensinode[157], Arch Rock[158], ZigBee SE2[129], Indrion[159], Linky d'ERDF[160], WattECO[161], etc.
Ainsi que du matériel compatible 6LoWPAN :
Contrôleur | RAM | EEPROM | Flash | Fabricant | |
---|---|---|---|---|---|
WiSMote | MSP430x5 CC2520 | 16k | nc | 256k | Arago Systems[162] |
MICAz | Atmel ATmega128L | nc | 4k | 128k | Crossbow[163] |
TELOSB | TI MSP430 | 10k | 16k | 48k | Crossbow[164] |
JN5139 | 32-bits RISC processor | 96k | 192k | externe | Jennic[165] |
RC2xxx | Single-cycle high performance 8051 | 8k | 4k | 32-256k | Radiocrafts[166] |
WPC-IP | MSP430F5 | 16k | nc | 256k | Watteco[167] |
NanoStack | TI CC1110 | 4-8k | 32-64k | 32k | Sensinode[168] |
Tmote Sky | TI MSP430 | 10k | nc | 48k | Moteiv ⇒ Sentilla[169] |
eSPOT | ARM 926ej-S | 1M | nc | 8M | Sun SPOT[170] |
PN2420 | Atmega128L / MSP430 | 4k | nc | 128k | PicosNet[171] |
Des OS, des API ainsi que des outils 6LoWPAN sont également disponibles :
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) |
| ||
Zephyr RTOS[172] |
De plus, 6LoWPAN est pris en compte dans plusieurs projets de recherche :
- HOBNET[173], SENSEI[93], EUREKA[174], etc.
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[175],[176].
- une augmentation des pertes de paquets et des RTT lorsque la taille de la charge utile est trop importante[177].
- la mise au place d'un délai élevé d’attente des paquets (> 500 ms) nécessaire pour limiter la perte de paquets[175].
- 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[178].
À 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[179], RFID[180] et Bluetooth[181]) 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[182].
Notes et références
Notes
- ↑ En français, Les réseaux personnels sans fil à faible consommation.
- ↑ En français, Les réseaux sans fil à faible consommation.
- ↑ Définitions de compteurs ou de paramètres lus et/ou modifiés à travers le protocole SNMP, spécifiques d'un constructeur
- ↑ En français, Délai de Réponse Dépassé.
- ↑ En français, grille intelligente.
- ↑ En français, objet intelligent.
Références
- ↑ a b et c G. Mulligan 2007, Introduction.
- ↑ a et b RFC 4919, 2007, page 1
- ↑ a b et c RFC 4944, 2007, page 1
- ↑ IEEE Std 802.15.4-2006, page 13
- ↑ a b et c Z. Shelby et Al. 2009, introduction
- ↑ a et b JP. Vasseur et Al. 2010, introduction
- ↑ IEEE Std 802.15.4-2006, page 45
- ↑ IEEE Std 802.15.4-2006, page 159
- ↑ IEEE Std 802.15.4-2003, page 172
- ↑ a et b RFC 2460, page 4
- ↑ RFC 768, page 1
- ↑ RFC 2460, page 24
- ↑ RFC 4919, 2007 page 4-9
- ↑ (en) Request for comments no 4862
- ↑ RFC 4919, page 8
- ↑ (en) Request for comments no 3410
- ↑ RFC 4919, 2007, page 8
- ↑ RFC4944, page 5
- ↑ RFC4944, pages 11-12
- ↑ P. Thubert et Al. 2010, page 3
- ↑ P. Thubert et Al., 2010
- ↑ A. Ludovici et Al. 2009, page 4
- ↑ J. Hui et Al. 2007
- ↑ A. Ludovici et Al. 2009, page 5
- ↑ J. Hui et Al. 2011
- ↑ J. Hui et Al. 2011, page 6
- ↑ J. Hui et Al. 2011, page 14
- ↑ J. Hui et Al. 2011, page 17
- ↑ RFC5246, 2008
- ↑ RFC4303, 2005
- ↑ J. Hui et Al. 2011, page 16
- ↑ A. Ayadi et Al. 2010
- ↑ C. O'Flynn 2010
- ↑ C. Bormann 2011, page 3
- ↑ C. Bormann 2011
- ↑ E. Kim et Al. 2011
- ↑ A. Chowdhury et Al. 2009, page 5
- ↑ A. Ludovici et Al. 2011, pages 5-7
- ↑ K. Kim et Al. 2007 (a)
- ↑ K. Kim et Al. 2007(b)
- ↑ K. Kim et Al. 2007(c)
- ↑ RPL, 2011
- ↑ a et b Routing Over Low power and Lossy networks (Active WG)
- ↑ RFC5548, 2009
- ↑ RFC5673, 2009
- ↑ RFC5826, 2010
- ↑ RFC5867, 2010
- ↑ JP. Vasseur et Al. 2011
- ↑ RFC6206, 2011
- ↑ N. Tsiftes et Al. 2010, page 2
- ↑ Z. Shelby et Al. 2010, p. 1
- ↑ a b et c Z. Shelby et Al. 2010, page 11
- ↑ a b et c Z. Shelby et Al. 2010, page 12
- ↑ a b et c Z. Shelby et Al. 2010, page 14
- ↑ a et b Z. Shelby et Al. 2010, page 15
- ↑ C. Bormann 2011, p. 27
- ↑ H. Shin et Al. 2009, p. 4
- ↑ H. Shin et Al. 2009, p. 1
- ↑ E. Talipov et Al. 2011, p. 184
- ↑ E. Talipov et Al. 2011, p. 188
- ↑ E. Talipov et Al. 2011, p. 194-195
- ↑ Silva et Al. 2009, p. 49
- ↑ a et b M-K. Shin et Al. 2007, pages 6-7
- ↑ RFC 3775, 2004
- ↑ R. Silva et Al. 2009
- ↑ RFC 5213, 2008
- ↑ M-K. Shin et Al. 2009
- ↑ a et b RFC 3963, 2005
- ↑ J-H. Kimet Al. 2008
- ↑ G. Bag et Al. 2008
- ↑ Z. Zinonos et Al. 2010
- ↑ M. Ha et Al. 2010
- ↑ Md. Motaharul Islam et Al. 2011
- ↑ C. Haksoo et Al. 2009, p. 305
- ↑ M. Hamid et Al. 2010, p. 1-29
- ↑ C. Haksoo et Al. 2009, p. 306
- ↑ C. Haksoo et Al. 2009, p. 308
- ↑ C. Haksoo et Al. 2009, p. 307
- ↑ a et b M. Hamid et Al. 2008, p. 419
- ↑ M. Hamid et Al. 2008, p. 417
- ↑ IEEE802.15.4
- ↑ S. Daniel et Al. 2009, p. 8
- ↑ a et b M. Hamid et Al. 2008, p. 421
- ↑ b6LoWPAN - BLIP
- ↑ C. Haksoo et Al. 2009, p. 309
- ↑ M. Hamid et Al. 2008, p. 422
- ↑ M. Hamid et Al. 2008, p. 423
- ↑ T. Luckenbach et Al. 2005
- ↑ N. B. Priyantha et Al. 2008
- ↑ RFC 4627, 2007, page 1.
- ↑ D. Yazar et Al. 2009
- ↑ L. Schor et Al., 2009
- ↑ a et b (en) « 6LoWPAN: The wireless embedded Internet - Part 2: 6LoWPAN history, market perspective & applications », EE Times, (lire en ligne, consulté le )
- ↑ R. Gold et Al. 2009
- ↑ a et b C. Bormann et Al. 2009
- ↑ RFC 3135, 2001, page 1.
- ↑ D. Bimschas et Al., 2010, page 8
- ↑ a b et c IETF, 2010, pages 1
- ↑ Z. Shelby et Al. 2011(a)
- ↑ RFC 4347, 2006
- ↑ RFC 5988, 2010, page 1.
- ↑ RFC 3986, 2005, page 1.
- ↑ Z. Shelby 2011
- ↑ RFC 5785, 2010, page 1.
- ↑ Z. Shelby et Al. 2011(b)
- ↑ Z. Shelby et Al. 2011(c)
- ↑ A. Brandt 2011
- ↑ C. Bormann 2011
- ↑ C. Schmitt et Al. 2010, page 390
- ↑ L. Braun et Al. 2011
- ↑ RFC 5101, 2008
- ↑ L. Eggert, 2011, page 1
- ↑ A. Castellani 2011
- ↑ RFC3810, 2004, page 1
- ↑ RFC4605, 2006, page 1
- ↑ A. Rahman, 2011
- ↑ P. Van der Stok et Al. 2011
- ↑ G. Moritz, 2010
- ↑ G. Moritz 2011
- ↑ S.Cheshire et Al., 2011
- ↑ a et b S. Park et Al. 2011
- ↑ RFC 5996, 2010, page 1
- ↑ RFC 3971, 2005, page 1
- ↑ B. Sarikaya et Al., 2011
- ↑ H. Kim 2008, page 796
- ↑ S. Raza et Al., 2011
- ↑ A.A El Kalam et Al., 2010
- ↑ J. Ayuso et Al. 2010
- ↑ a et b (en-US) « Wireless network sensoring: Different strokes for different folks », sur Plant Engineering, (consulté le ).
- ↑ ITU, 2005
- ↑ site officiel du projet Européen : smart grid
- ↑ M. Chebbo, 2007
- ↑ a et b site officiel du projet gouvernemental Américain : smart grid
- ↑ Gouvernement US, 2007
- ↑ H. Labiod et Al. 2003
- ↑ S. Farahani 2008
- ↑ B. Warneke et Al. 2001
- ↑ (en) Mathilde Durvy, Julien Abeillé, Patrick Wetterwald et al., « Making sensor networks IPv6 ready », dans Proceedings of the 6th ACM conference on Embedded network sensor systems, (lire en ligne), p. 421-422.
- ↑ M. Durvy et Al. 2008, page 421
- ↑ U. Sarwar et Al. 2010, page 889.
- ↑ Jonathan W Hui et Al., 2008
- ↑ NIC, 2008
- ↑ K.D. Korte et Al. 2009
- ↑ John Carey, 2009
- ↑ Jonathan W Hui et Al., 2010, page 1865-1878
- ↑ Elgar Fleisch, 2010
- ↑ M. Chui et Al., 2010
- ↑ « Cisco: acquisition d'Arch Rock. », sur ABC Bourse (consulté le ).
- ↑ (en-US) « Cisco To Acquire Smart Grid Monitoring Tech Company Arch Rock », sur TechCrunch, (consulté le ).
- ↑ Light-Weight Implementation Guidance (Active WG)
- ↑ C. Williams 2011
- ↑ Z. Cao 2011
- ↑ E. Kim et Al. 2007
- ↑ a et b E. Kim et Al. 2011
- ↑ H. Song et Al. 2011
- ↑ R. Glombitza et Al. 2009, page 25
- ↑ (en) Zach Shelby et Carsten Bormann, 6LoWPAN: The Wireless Embedded Internet, Wiley (lire en ligne), « Seninode NanoStack », p. 154.
- ↑ (en) « Arch Rock Turns Wireless Sensors into Internet Devices », sur GovTech, (consulté le ).
- ↑ le site officiel d'Indrion
- ↑ Communiqué Sagemcom, Linky, Spécification de Linky.
- ↑ le site officiel de Watteco
- ↑ « Datasheet WiSMote »(Archive.org • Wikiwix • Archive.is • Google • Que faire ?) et le site officiel d'Arago Systems
- ↑ Datasheet MICAz et le site officiel Crossbow xbow.com.
- ↑ Datasheet TELOSB et le site officiel Crossbow xbow.com.
- ↑ (en) « JN5139 Wireless Microcontroller (IEEE802.15.4 and ZigBee) » [archive du ], sur jennic.com.
- ↑ (en-US) « 6LoWPAN », sur Radiocrafts (consulté le ).
- ↑ WPC-IP sur le site officiel Watteco
- ↑ (en) NanoStack 2.0 sur le site officiel de Sensinode.
- ↑ « Datasheet Tmote Sky »(Archive.org • Wikiwix • Archive.is • Google • Que faire ?) et le site officiel de Sentilla.
- ↑ (en) Ioakeim K. Samaras, George D. Hassapis et John V. Gialelis, « A Modified DPWS Protocol Stack for 6LoWPAN-Based Wireless Sensor Networks », IEEE Transactions on Industrial Informatics, vol. 9, no 1, , p. 209-217 (lire en ligne).
- ↑ « PN2420 »(Archive.org • Wikiwix • Archive.is • Google • Que faire ?) sur le site officiel de PicosNet.
- ↑ (en) « IEEE 802.15.4 - Zephyr Project Documentation »,
- ↑ (en) Chris Conway et Matthew Barnes, « Wireless sensor network data description and encoding in heterogeneous building systems », 2011 International Conference on Distributed Computing in Sensor Systems and Workshops (DCOSS), (lire en ligne).
- ↑ (en) « DoS detection system of 6LoWPAN sensing network » (consulté le ).
- ↑ a et b Z. Suryady et Al., 2011, page 171
- ↑ CJ M. Liang et Al. 2010, page 309
- ↑ B. Cody-Kenny et Al. 2009, page 25
- ↑ J. Schonwalder et Al. 2011, page 1
- ↑ C. Chauvenet et Al. 2010
- ↑ R. Silva et Al. 2009, page 44
- ↑ B. Patil et Al. 2011, page 1
- ↑ 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 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 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 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
- (en) « RFC 3135 : Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations »,
- (en) « RFC 3775 : Mobility Support in IPv6 »,
- (en) « RFC 3986 : Uniform Resource Identifier (URI): Generic Syntax »,
- (en) « RFC 3963 : Network Mobility (NEMO) Basic Support Protocol »,
- (en) « RFC 4303 : TIP Encapsulating Security Payload (ESP) »,
- (en) « RFC 4347 : Datagram Transport Layer Security »,
- (en) « RFC 4627 : The application/json Media Type for JavaScript Object Notation (JSON) »,
- (en) « RFC 4919 : IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals »,
- (en) « RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks »,
- (en) « RFC 5101 : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information »,
- (en) « RFC 5213 : Proxy Mobile IPv6 »,
- (en) « RFC 5246 : The Transport Layer Security (TLS) Protocol Version 1.2 »,
- (en) « RFC 5548 : Routing Requirements for Urban Low-Power and Lossy Networks »,
- (en) « RFC 5673 : Industrial Routing Requirements in Low-Power and Lossy Networks »,
- (en) « RFC 5785 : Defining Well-Known Uniform Resource Identifiers (URIs) »,
- (en) « RFC 5826 : Home Automation Routing Requirements in Low-Power and Lossy Networks »,
- (en) « RFC 5867 : Building Automation Routing Requirements in Low-Power and Lossy Networks »,
- (en) « RFC 5988 : Web Linking »,
- (en) « RFC 6206 : The Trickle Algorithm »,
- (en) « RFC 5996 : Internet Key Exchange Protocol Version 2 (IKEv2)) »,
- (en) « RFC 3971 : SEcure Neighbor Discovery (SEND) »,
- (en) « RFC 3810 : Multicast Listener Discovery Version 2 (MLDv2) for IPv6 »,
- (en) « RFC 4605 : Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying") »,
- (en) « draft-daniel-6lowpan-load-adhoc-routing-03 : 6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD) »,
- (en) « draft-montenegro-6lowpan-dymo-low-routing-03 : Dynamic MANET On-demand for 6LoWPAN (DYMO-low) Routing »,
- (en) « draft-daniel-6lowpan-hilow-hierarchical-routing-01 : Hierarchical Routing over 6LoWPAN (HiLow) »,
- (en) « draft-thubert-6lowpan-simple-fragment-recovery-07 : LoWPAN fragment Forwarding and Recovery »,
- (en) « draft-hui-6lowpan-hc1g-00 : Stateless IPv6 Header Compression for Globally Routable Packets in 6LoWPAN Subnetworks »,
- (en) « draft-ietf-6lowpan-hc-15 : Compression Format for IPv6 Datagrams in Low Power and Lossy Networks (6LoWPAN) »,
- (en) « draft-aayadi-6lowpan-tcphc-01 : TCP header compression for 6LoWPAN »,
- (en) « draft-oflynn-6lowpan-icmphc-00 : ICMPv6/ND Compression for 6LoWPAN Networks »,
- (en) « draft-bormann-6lowpan-ghc-02 : 6LoWPAN Generic Compression of Headers and Header-like Payloads »,
- (en) « draft-ietf-6lowpan-routing-requirements-09 : Problem Statement and Requirements for 6LoWPAN Routing »,
- (en) « WorkGroup : Roll Status Pages »
- (en) « draft-ietf-roll-rpl-19 : RPL: IPv6 Routing Protocol for Low power and Lossy Networks »,
- (en) « draft-ietf-roll-routing-metrics-19 : Routing Metrics used for Path Calculation in Low Power and Lossy Networks »,
- (en) « draft-shin-6lowpan-mobility-01 : Mobility Support in 6LoWPAN »,
- (en) « draft-silva-6lowpan-mipv6-00 : An Adaptation Model for Mobile IPv6 support in lowPANs »,
- (en) « draft-ekim-6lowpan-scenarios-00 : Design and Application Spaces for 6LoWPANs »,
- (en) « draft-ietf-6lowpan-usecases-09 : Design and Application Spaces for 6LoWPANs »,
- (en) « Constrained RESTful Environments : Description of Working Group »,
- (en) Z. Shelby et Al.(a), « draft-ietf-core-coap-06 : Constrained Application Protocol (CoAP) »,
- (en) Z. Shelby, « draft-ietf-core-link-format-04 : CoRE Link Format »,
- (en) Z. Shelby et Al.(b), « draft-ietf-core-observe-02 : Observing Resources in CoAP »,
- (en) Z. Shelby et Al.(c), « draft-ietf-core-block-03 : Blockwise transfers in CoAP »,
- (en) « draft-brandt-coap-subnet-discovery-00 : Discovery of CoAP servers across subnets »,
- (en) « draft-bormann-core-simple-server-discovery-00 : CoRE Simple Server Discovery »,
- (en) « draft-braun-core-compressed-ipfix-02 : Compressed IPFIX for smart meters in constrained networks »,
- (en) « draft-bormann-6lowpan-6lowapp-problem-01 : 6LowApp: Problem Statement for 6LoWPAN and LLN Application Protocols »,
- (en) « draft-hamid-6lowpan-snmp-optimizations-03 : SNMP Optimizations for Constrained Devices »,
- (en) « draft-daniel-6lowpan-mib-01 : 6LoWPAN Management Information Base »,
- (en) « draft-patil-6lowpan-v6over-btle-01 : Transmission of IPv6 Packets over Bluetooth Low Energy »,
- (en) « draft-gold-6lowapp-sensei-00 : SENSEI 6lowapp Requirements »,
- (en) « draft-eggert-core-congestion-control-01 : Congestion Control for the Constrained Application Protocol (CoAP) »,
- (en) « draft-castellani-core-http-coap-mapping-01 : Best Practice to map HTTP to COAP and viceversa »,
- (en) « draft-rahman-core-groupcomm-04 : Group Communication for CoAP »,
- (en) « draft-vanderstok-core-bc-03 : CoAP Utilization for Building Control »,
- (en) « draft-moritz-6lowapp-dpws-enhancements-01 : DPWS for 6LoWPAN »,
- (en) « draft-moritz-core-soap-over-coap-00 : SOAP-over-CoAP Binding »,
- (en) « WorkGroup : LWIG Status Pages »
- (en) « draft-williams-lwig-api-considerations-00 : Light Weight API Implementation Guidance »,
- (en) « draft-cao-lwig-gateway-00 : Considerations for Lightweight IP Gateways »,
- (en) « draft-daniel-6lowpan-security-analysis-05 : IPv6 over Low Power WPAN Security Analysis »,
- (en) « draft-sarikaya-6lowpan-cgand-01 : Lightweight Secure Neighbor Discovery for Low-power and Lossy Networks »,
- (en) « draft-cheshire-dnsext-dns-sd-10.txt : DNS-Based Service Discovery »,
- (en) « draft-ietf-6lowpan-nd-15.txt : Neighbor Discovery Optimization for Low-power and Lossy Networks »,
Liens externes
- (en) « site officiel Watteco »
- (en) « site officiel ARMbed »
- (en) « site officiel Indrion »
- (en) « site officiel du groupe de travail 802.15.4 de l'IEEE »
- (en) « site officiel de Berkeley IP »
- (en) « Cisco : Annonce rachat Arch Rock »
- (en) « site officiel du projet gouvernemental Américain : SmartGrid »
- (en) « site officiel du projet Européen : SmartGrid »
- (en) « site officiel de Cisco »
v · m | |
---|---|
Systèmes | |
Protocoles |
|
Langages | |
Matériel | |
Logiciels | |
Applications |
|
Protocoles de routage |
|
Conférences et revues |
|
v · m | |||||||
---|---|---|---|---|---|---|---|
Liaison infrarouge | |||||||
Liaison radio |
| ||||||
Liaison optique | Li-Fi | ||||||
Liaison satellite | Internet par satellite | ||||||
Réseau mobile |
Portail des réseaux informatiques
Portail de l’informatique
Portail des télécommunications