Loading AI tools
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 :
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].
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).
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.
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.
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é
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é.
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) :
- 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é)
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].
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 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] :
- 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 :
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].
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
