Linux Embedded

Le blog des technologies libres et embarquées

Protocoles de communication, frameworks et systèmes d’exploitation pour les objets connectés

L’Internet des Objets, ou Internet Of Things (IoT), est un domaine en pleine expansion, et ces domaines d’application sont de plus en plus variés : pilotage intelligent d’une maison, monitoring d’installations, smart cities, etc. De nouveaux dispositifs intelligents font leur apparition : des modules de petite taille, embarquant des capteurs, une source d’énergie et une interface de communication. Seulement, les moyens et protocoles de communication conventionnels ne peuvent convenir pour ces nouveaux dispositifs : ils donnent lieu à une consommation trop élevée , un besoin en ressources réseau/mémoire/énergie trop important ou encore une complexité qui rend la mise en place difficile. Ce besoin a donc fait émerger de nouveaux protocoles avec des caractéristiques adaptées aux besoins des objets connectés : faible consommation, portée importante, débit faible, facilité de mise en œuvre, etc.

Cet article a pour but de présenter quelques-uns des protocoles et solutions les plus utilisés aujourd’hui (ou en devenir), dans le domaine de l’IoT, ainsi que leurs conditions de mise en place.
Il ne se veut pas exhaustif : il liste les principaux protocoles et logiciels existants pour l’Internet des Objets, en se focalisant sur les solutions “ouvertes” ou sur l’accessibilité des hardwares compatibles (facilité de mise en place, prix, …).

Concepts utiles

Modèle OSI

Afin de pouvoir présenter les protocoles les plus répandus pour l’IoT à ce jour, nous allons nous appuyer sur la représentation OSI (Open Systems Interconnection).
Ce modèle va nous permettre de représenter le découpage des fonctionnalités des protocoles étudiés par la suite, et/ou des stacks complètes. Le modèle OSI est structuré comme suit :

Layer Dénomination Rôle PDU associé
7 Application Point d’accès au service réseau Donnée
6 Présentation Chiffrement, conversion de données entre machines Donnée
5 Session Communication inter-host, gestion de sessions entre application Donnée
4 Transport Connexion end-to-end, contrôle de flux, notion de port Segment / Datagramme
3 Réseau Détermination du parcours des données et adressage logique (IP), services tels que le routage Paquet
2 Liaison Adressage physique (MAC et LLC) Trame
1 Physique Transmission des signaux Bit

Les quatre premières couches sont généralement fournies par le système d’exploitation, alors que les trois dernières sont plutôt propres aux applications qui utilisent le moyen de communication mis en place. En général, les couches 5 à 7 sont confondues : on ne parlera donc que de la couche 7 pour le côté applicatif.

On peut considérer un exemple de description par le modèle OSI, en observant la communication mise en place par un navigateur Web sur un ordinateur, celui-ci étant relié à internet grâce à un hotspot Wi-Fi. On obtient alors le modèle suivant :

Layer Dénomination Protocole Description
7 Application HTTP HyperText Transfer Protocol
4 Transport TCP Transmission Control Protocol
3 Réseau IP Internet Protocol
2 Liaison 802.11 Adressage MAC
1 Physique 802.11 Ondes radio (Wi-Fi)

Acronymes

Cette section propose une définition de quelques acronymes utilisés par la suite :

  • CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) : il s’agit d’une technique d’accès au medium de communication, qui se déroule comme suit :
    • toutes les machines ont accès au medium en même temps,
    • si une machine veut émettre, elle vérifie que personne n’émet à ce moment. Si personne n’émet, elle peut commencer à émettre, sinon elle attend,
    • si une collision a lieu (deux machines ont commencé à émettre en même temps), les deux machines arrêtent d’émettre et attendent chacune une durée aléatoire avant de retenter l’émission.

L’attente aléatoire de la troisième étape “autorégule” le conflit : l’une des deux machines va se remettre à émettre sur le medium avant l’autre, et la seconde , au vu des premières règles, va attendre que la première ait fini.

Il existe également la technique du CSMA/CD (Carrier Sense Multiple Access with Collision Detection), utilisée par exemple pour les communications entre calculateurs embarqués d’une automobile. Là, pour éviter de devoir attendre avant qu’un nœud du réseau puisse émettre, chaque émetteur détecte s’il existe une collision (par relecture sur le medium de ce qui est réellement émis): s’il détecte qu’une collision existe et que le niveau électrique présent sur la ligne est plus prioritaire (on parle de bit dominant), alors il arrête d’émettre: le nœud ayant le message le plus prioritaire peut alors continuer à émettre.

  • FSK (Frequency Shift Keying) : c’est une méthode d’encodage de l’information dans un signal alternatif. On assigne le 0 binaire à une certaine fréquence et le 1 binaire à une autre fréquence. Le signal encodé est donc un signal alternatif dont la fréquence varie au cours du temps.
  • PSK : même principe que le FSK, mais c’est cette fois la phase du signal que l’on fait varier.
  • Etalement de spectre : technique d’encodage de l’information qui vise à étaler un signal sur une bande de fréquence plus large que la bande d’origine.
  • DSSS (Direct Sequence Spread Spectrum), FHSS (Frequence Hopping Spread Spectrum) : deux techniques d’étalement de spectre utilisées dans le Wi-Fi.
  • OFDM (Orthogonal Frequency-Division Multiplexing) : technique d’encodage utilisée dans le Wi-Fi.
  • WPAN : (Wireless Personnal Area Network) : réseaux de faible portée (quelques dizaines de mètres).
  • LWPAN (Low Power Wide Area Network) : réseaux adaptés aux objets connectés, longue portée.
  • LRWPAN (Low Rate Wide Area Network) : réseaux à faibles débits.

Les protocoles et réseaux présentés plus loin peuvent appartenir à plusieurs de ces catégories.

Communication avec protocoles bas-niveau propriétaires

Il est possible, dans le cadre de certaines applications précises, de s’affranchir de l’implémentation d’une stack protocolaire bien définie. On peut par exemple utiliser une liaison radio “brute” entre deux microcontrôleurs, dont les spécificités “bas niveau” sont prises en charge au sein du module : l’enjeu serait ici de remplacer une liaison série câblée par un équivalent sans fil, plus que de déployer un réseau IoT en bonne et due forme, à moins d’implémenter une stack protocolaire proposant des services de plus haut niveau (adressage, routage, etc).

On peut trouver plusieurs modules à bas coût qui permettent de déployer ce type de canal de communication :

Module Fréquence Débit Max Portée Max Distributeur Prix
RFM12 433/868/915MHz 256kbps Dizaine de mètres en intérieur Farnell 10€
RFM69 433/868/915MHz 300kbps Centaine de mètres RS 8€
NRF24L01 2.4GHz 250kbps Dizaine de mètres en intérieur Seeed Studio 2.90$
NRF905 433MHz/868/915MHz 50kbps Centaine de mètres en intérieur DX.com 5€

Les protocoles bas niveau standards (couches 1 et 2)

Dans un premier temps, nous allons voir les protocoles de bas niveaux, c’est-à-dire ceux qui sont près du processus physique de communication, et qui par conséquent définissent le hardware qu’il faudra choisir dans le cadre de la conception d’une solution à base d’objets communicants. Ceux-ci peuvent définir toute leur stack (c’est-à-dire définir une spécification proche de l’application finale) ou uniquement les couches basses (physique, liaison, parfois réseau).

Avant de commencer, il peut être intéressant de voir comment sont normalisés les protocoles les plus répandus.
On trouve principalement, au plus haut niveau, l’Institute of Electric and Electronics Engineers (IEEE), qui définit les normes IEEE, et l’Internet Engineering Task Force (IETF) qui publie les Request For Comments (RFC). Si l’IEEE définit des normes, l’IETF détaille plutôt les aspects techniques d’Internet, avec des recommandations du type MUST, MUST NOT, SHOULD, SHOULD NOT. On trouve aussi l’International Standards Organization qui définit les normes ISO.

alt-text

Parmi les normes IEEE 802, certaines sont très largement répandues et font d’ailleurs l’objet d’une partie plus bas dans ce document. On peut notamment évoquer la norme 802.11 qui définit le Wi-Fi, ou le 802.15 qui définit les Wireless Personnal Area Network ou WPAN, qui elle-même définit la norme 802.15.1 (le Bluetooth) ou la norme 802.15.4 qui définit les Low Rate Wide Personnal Area Network (LRWPAN). On trouve aussi la norme 802.3 qui définit la norme Ethernet, ou encore la norme 802.16 qui définit le WiMax (technologie sans fil haut débit).

802.11

Il s’agit d’un ensemble de normes développé par l’IEEE très largement répandu puisqu’elles définissent, entre autres, le Wi-Fi. Les normes 802.11 définissent les couches Physique et Liaison des protocoles qui s’appuient dessus.

alt-text

Au niveau physique, le 802.11 propose plusieurs techniques de modulations (DSSS, FHSS, OFDM, etc).

Le Wi-Fi permet plusieurs modes de fonctionnement :

  • Mode infrastructure : les dispositifs communiquent entre eux par le biais de concentrateurs (Points d’Accès),
  • Mode Ad Hoc : la communication entre dispositifs se fait sans intermédiaires (P2P – Peer To Peer),
  • Mode Pont : plusieurs points d’accès se connectent entre eux pour étendre un réseau. Exemple : un nœud devient la « racine » et les autres points d’accès se connectent à lui. Ils offrent ensuite l’extension du réseau sur leur interface Ethernet,
  • Mode Répéteur : un point d’Accès « répète » le signal, pour en augmenter la portée.

Parmi ces normes, on peut trouver, avec les débits correspondants :

  • 802.11b : 11 Mbps / 6 Mbps utile,
  • 802.11a ou 802.11g : 54 Mbps / 25 Mbps utile,
  • 802.11n : 600 Mbps théorique,
  • 802.11ac : 1.3 Gbps théorique,
  • Etc (il en existe presque une vingtaine, 802.11ac étant la dernière).

C’est un protocole privilégié pour le haut débit de données. De plus, sa portée peut atteindre plusieurs dizaines de mètres. Néanmoins, il nécessite une quantité importante d’énergie.

De par la maturité de cette norme, on peut trouver un très grand nombre de modules 802.11 sur le marché, parmi lesquels :

Référence Fabricant Distributeur Prix
MRF24WB0 Microchip Farnell 17.5€
ATWINC1500 Atmel Farnell 18.3€
CC3100 (avec EmuBOOST) TI Farnell 137.48€
SPWF01SA.11 ST Mouser 18€
Photon Particle Particle 19$

802.15.4

Ce protocole défini par l’IEEE, qui sert de base à de nombreux autres protocoles parmi ceux détaillés dans la suite de ce document (ex : 6LoWPAN, Zigbee), est utilisé dans le cadre des réseaux LRWPAN (Low Rate Wireless Personal Area Network). C’est un protocole ouvert : ses spécifications sont disponibles sur le net et son implémentation n’est pas sujette à des royalties. Il définit l’architecture des couches Physique et Liaison. Ses principales caractéristiques (qui définissent donc aussi celles des protocoles de plus haut niveau qui reposent sur le 802.15.4) sont les suivantes :

Caractéristique Valeur
Fréquence de porteuse 2,4 GHz / 915 MHz / 868 MHz
Débit max 250 kbps
Taille max paquet 127 octets
Portée moyenne Quelques dizaines de mètres

 

Le 802.15.4 est donc utilisé dans le domaine radio, et propose un débit relativement faible. Son intérêt réside dans la faible consommation dont il a besoin.

Les fréquences utilisées tournent autour de 2,4 GHz, mais aussi 868 MHz pour l’Europe et 915 MHz pour l’Amérique.

Au niveau de la couche Liaison, la norme 802.15.4 supporte la mise en place de réseaux de type étoile ou mesh. Les dispositifs reposant sur la norme 802.15.4 peuvent être séparés en deux types distincts :

  • Full Function Device (FDD)
  • Reduced Function Device (RFD)

La différence entre les deux types porte principalement sur le rôle que peut prendre le dispositif au sein du LRWPAN. Le FDD pourra assurer les rôles de coordinateur PAN (gère l’initialisation du réseau et contrôle l’adhésion de nouveaux dispositifs à celui-ci, gère l’interface avec d’autres réseaux), de routeur (relaie les messages) ou de simple dispositif communicant, alors que le RFD de ne pourra être que simple dispositif communicant.

Une fois les rôles définis, le réseau peut suivre deux modes de fonctionnement distincts :

  • mode non-beacon : le coordinateur « attend » les données. Il n’est jamais dormant. Utile pour les dispositifs apériodiques et/ou qui émettent peu. Économie de batterie pour les autres dispositifs MAIS pas de garantie de délai d’accès au canal. Cette version utilise le CSMA/CA,
  • mode beacon : toutes les stations sont synchronisées sur le coordinateur qui déclenche les émissions à intervalle régulier.

Plutôt que de proposer des produits qui soient spécifiques au 802.15.4, nous verrons plus tard quelques modules et kits d’évaluation spécifiques aux protocoles qui reposent sur le 802.15.4. On peut cependant retenir les cartes CC2538EMK de TI (lot de 2 cartes à 130€ sur Farnell).

LoRa – LoRaWAN

Il faut distinguer le protocole Lora, qui définit le fonctionnement de la couche de niveau 1 (Physique), du protocole LoRaWan, promu par la LoRa Alliance (couche 2, Liaison).

LoRa

Son nom signifie « Long Range ».

alt-text

Le LoRa est un protocole bas niveau qui intervient dans la couche 1 du modèle OSI. La société Semtech est propriétaire de ce protocole depuis le rachat de la société qui l’avait développé, Cycleo SAS. C’est un protocole LPWAN (Low Power Wide Area Network) qui est donc plutôt utilisé pour des communications longue distance (LOng RAnge). Il définit sa propre technique de modulation du signal, en se basant sur une technique d’étalement de spectre.

Les distances visées impliquent une diminution des fréquences utilisées, qui sont les suivantes :

Europe Amérique Asie
868 Mhz 915 Mhz 433MHz

C’est (entre autres) la portée du LoRa qui rend ce protocole intéressant dans le cadre des objets connectés : d’un ou deux kilomètres en ville, elle peut atteindre la vingtaine de kilomètres en terrain dégagé. Le débit du LoRa, quant à lui, peut aller jusqu’à 38,4 kbps, mais le débit final pour l’application visée va aussi dépendre des couches supérieures. Le payload d’un paquet LoRa est aussi limité : il ne peut dépasser 256 octets.

Pour utiliser le protocole LoRa, il est nécessaire de se procurer des modules LoRa conçus par la société Semtech, tels que les transceivers SX1272 ou SX1276. On peut aussi passer par des kits de développement :

Référence Fabricant Distributeur Prix
SX1276/1278 Dev kit Semtech Modtronix 149.95$
inAir9B Modtronix Modtronix 14.95$
SX1276MB1MAS Semtech Digikey 58$

LoRaWAN

Le protocole LoRaWAN, défini par la LoRa Alliance (qui compte des membres tels que Cisco, Bouygues, IBM, ST) définit la couche Liaison des communications qui transitent grâce au protocole LoRa (et quelques fonctionnalités de la couche réseau), et a pour but d’unifier le décodage des paquets LoRa grâce à un unique protocole.

alt-text

Les réseaux LoRaWAN peuvent fonctionner de deux manières :

  • en P2P (ou mesh) : chaque nœud contribue au réseau et les dispositifs communiquent entre eux, il n’y a donc pas besoin de passerelle.
  • en étoile : les dispositifs communiquent avec une passerelle centrale qui fait le lien vers le réseau Internet. Les informations qui transitent sont donc disponibles sur les réseaux classiques.

Les réseaux LoRaWAN peuvent offrir un débit allant jusqu’à 22 kbps. Il sont réputés robustes face aux interférences, de part la nature des technologies de la couche inférieure (LoRa).

Tous les modules compatibles LoRaWAN que l’on peut trouver dans le commerce (Linklabs, Microchip, ST, etc) reposent sur les puces de Semtech évoquées plus haut.

Référence Fabricant Distributeur Prix
Tous les modules LoRa
Waspmote LoRaWAN Basboard Libelium Cooking Hacks 163€
Waspmote Gateway Libelium Cooking Hacks 140€
LoRaONE Beta Sodaq Sodaq 100€
LoRaBee Embit Sodaq 45€
LoRa Mote Microchip Microchip Direct 64.43

Il existe deux moyens pour faire transiter ses données sur un réseau LoRaWAN :

  • passer par des infrastructures existantes : des fournisseurs tels que Orange, Bouygues ou Archos ont déployé des réseaux LoRaWAN en France et proposent un accès à ces réseaux contre un abonnement.
  • déployer son propre réseau : il faut alors investir dans des gateways LoRa pour permettre le passage de données entre le réseau LoRaWAN et les réseaux IP classiques.
    Deux exemples de matériel de ce genre sont la passerelle MultiConnect Conduit de MultiConnect et les passerelles de LinkLabs. On peut aussi confectionner soit même sa passerelle LoRa (pour un prix autour de 200€, variable selon les fonctionnalités), en prenant par exemple un Raspberry PI et une carte-concentrateur LoRa.
    Il suffit alors de développer/adapter le logiciel qui convient (plusieurs projets Github existent à ce sujet). Le site Loriot propose une liste de passerelles avec leur prise en charge logicielle.

Symphony Link

Symphony Link est l’alternative au LoRaWAN proposée par Link Labs. Ce réseau s’appuie sur la norme 802.15.4 ainsi que sur LoRa pour la couche physique. Puisque c’est une technologie basée sur le LoRa, elle bénéficie de sa portée importante, à savoir une dizaine de kilomètres (annoncé sur le site de Link Labs).

RFID

La technologie RFID (Radio Frequency IDentification) est un protocole de communication très courte portée (quelques centimètres à quelques mètres).

alt-text

Cette technologie est définie par l’ISO/IEC 18000. Elle repose sur la présence de deux types de dispositifs :

  • les marqueurs (ou radio-étiquette, ou tag) : ce sont des dispositifs de petite taille comprenant une puce électronique et une antenne,
  • les lecteurs : ils fournissent (sans contact) l’énergie aux marqueurs et initient les communications.

Les lecteurs peuvent opérer à plusieurs gammes de fréquence, selon la portée désirée et/ou les normes légales en vigueur (125 kHz, 134,2 kHz, 13,56 MHz, 915 MHz, 2,45 GHz, 5,8 GHz). Les techniques de modulation utilisées dépendent alors de la fréquence impliquée (FSK par exemple).

On peut par exemple se procurer un module lecteur RFID chez SeeedStudio pour 12.50$. Celui-ci opère à 125 kHz.

Une autre technologie similaire est le NFC (Near Field Communication). D’une portée de quelques centimètres, le NFC est aujourd’hui largement présent dans nos smartphones et sert principalement à l’échange de données, au paiement sans contact ou à l’accès à du contenu exclusif.

Bluetooth

Largement répandu et bien connu, c’est un protocole qui définit notamment son fonctionnement dans les couches Physique et Liaison. Il repose sur la spécification IEEE 802.15.1 qui définit les couches Physique et Liaison des communications WPAN/Bluetooth.

alt-text

Le protocole en est aujourd’hui à sa version 4.2. Ses principales caractéristiques sont les suivantes :

Caractéristique Valeur
Fréquence 2,4 GHz
Débit max 24 Mbps
Portée max Quelques mètres, centaine de mètres dans les meilleures conditions

Il est implémenté dans de nombreux appareils comme les téléphones, les enceintes, les kits mains-libres, les ordinateurs, etc. Il repose sur une gamme de profils, permettant aux périphériques environnants de rapidement connaître les services proposés par un dispositif Bluetooth.

Au niveau physique, le bluetooth emploie pour sa couche radio le FSK, mais aussi le PSK depuis la norme 2.0.

Il y a deux rôles possibles pour un dispositif Bluetooth :

  • Maître : le maître qui veut connaître les esclaves environnants passe en « Inquiry ». Tous les esclaves environnants répondent aux requêtes d’Inquiry en présentant leur identifiant et leurs services. Il initie ensuite la connexion avec l’esclave désiré pendant la phase de « paging ». Le maître est un client.
  • Esclave : les esclaves répondent aux normes Inquiry et acceptent des connexions. Ce sont des serveurs qui proposent des services.

A ces mécanismes viennent s’ajouter le « pairing » et le « bonding ». Le pairing est une procédure n’ayant lieu qu’une fois, et qui permet de lier (« bonding ») deux périphériques : ceux-ci se connecteront ensemble dès qu’ils se voient, et ce sans besoin d’une nouvelle authentification.

L’utilisation du Bluetooth dans le cadre de l’IoT n’a vraiment commencé qu’avec la version 4.0 (aussi appelé Bluetooth Smart) qui a introduit les bases du Bluetooth Low Energy (BLE). Cette nouvelle spécification apporte un débit réduit pour le protocole ainsi que des remaniements dans les couches de la stack Bluetooth, mais au profit d’une durée de vie grandement améliorée : les dispositifs BLE sont ainsi conçus pour tenir plusieurs années sur une pile bouton. Il faut cependant garder à l’esprit que toutes les générations de Bluetooth ne sont pas compatibles entre elles : un dispositif “Smart Bluetooth” sera uniquement compatible avec le Bluetooth LE, alors qu’un dispositif “Smart Ready” sera aussi compatible avec le Bluetooth classique.

Ces améliorations ont donné lieu à un regain d’intérêt pour le Bluetooth et de nombreux modules sont disponibles pour tester cette technologie dans sa nouvelle version :

Référence Fabricant Distributeur Prix
CC2540EMK-USB TI Digikey 50€
BLE Nano Kit Red Bear Lab Snootlab 38€ le kit, 20€ le module seul
CY8CKIT-042-BLE Cypress Farnell 42€
NRF51822 USB BLE Adafruit Digikey 24,95€
RFD22102 RFDuino Sparkfun 42,65€

L’intérêt pour cette technologie est tel que le 6LoWPAN (protocole vu plus bas) a été adapté pour pouvoir être utilisé par dessus du Bluetooth : cette stack, qui a fait l’objet d’un draft de l’IETF, est par exemple déployable avec le SDK nRF5 for IoT de Nordic, sur des chips tels que le NRF51822.

Les protocoles de couche 3

Maintenant que nous avons vu les principales options qui s’offrent aux développeurs de produits connectés pour les couches basses de leurs supports de communication, nous allons voir quelles sont les alternatives aux protocoles des couches Réseaux classiques (ces couches étant chargées de fournir des services d’adressage et de routage inter-réseaux).

IPv4 / IPv6

Déjà très largement répandu dans le domaine des communications inter-ordinateurs, l’Internet Protocol (ou IP) est aussi utilisé dans le cadre des réseaux d’objets connectés pour permettre l’adressage des dispositifs communicants et le routage des paquets. Le protocole IPv4 est décrit dans la RFC 791, et le protocole IPv6 dans la RFC 2460.

Pour rappel, les protocoles IP opèrent au niveau 3 du modèle OSI (couche Réseau). Celui-ci encapsule les données provenant de la couche Transport (exemple : segment TCP, datagramme UDP) et les transfert à la couche Liaison de données.

IPv4 est le protocole IP le plus largement déployé à ce jour. Celui-ci utilise un adressage des stations sur 32 bits, mais le nombre d’adresses disponibles étant devenu insuffisant, une transition vers le protocole IPv6 a été amorcée, celui-ci proposant un adressage sur 128 bits.

L’implémentation d’une stack IP complète peut être lourde pour les objets connectés qui, généralement, disposent de ressources limitées. On peut donc trouver diverses implémentations plus légères permettant aux dispositifs de tout de même communiquer sur les réseaux IP, parmi lesquels :

  • μIP (Cisco, Atmel et SICS ont proposé une implémentation compatible IPv6 appelé μIPv6)
  • nanoIP
  • lwIP

6LoWPAN

Son acronyme signifie « IPv6 over Low Power Wireless Personnal Area Network ». Son apparition fait notamment suite au besoin de fragmentation des paquets IPv6 sur les réseaux 802.15.4 : la norme IPv6 nécessite des paquets d’au moins 1280 octets, mais la norme 802.15.4 limite la taille des trames à 127 octets. Le protocole 6LoWPAN, en plus de gérer cette fragmentation, assure par exemple :

  • la compression de l’en-tête IPv6 : permet de laisser plus de place aux données utiles
  • le routage : le 6LoWPAN permet la mise en place d’un routage pour les dispositifs à faibles ressources, par le biais de protocoles développés par la communauté. Le routage peut-être :
    • mesh under (au niveau de la couche 6LoWPAN) : le paquet n’est reconstitué que chez le destinataire. Cette méthode est plus rapide, sauf en cas d’erreur, auquel cas il faut rejeter tous les fragments et recommencer. Le protocole LOADng (Lightweight On-Demand Ad Hoc distance-vector routing protocol) permet d’assurer un routage de type mesh under. Il est par exemple déployé dans les réseaux de compteurs intelligents ERDF,
    • route over (au niveau de la couche IP) : les paquets sont reconstitués dans tous les équipements intermédiaires. La vitesse est légèrement diminuée mais au profit d’une efficacité accrue dans les mécanismes de protection contre les erreurs. Le protocole RPL (Routing Protocol for Low power and Lossy Network – voir RFC6550) permet d’assurer un routage de type route over.
  • Autoconfiguration IP : le 6LoWPAN introduit quelques optimisations des algorithmes de découverte des dispositifs voisins, déjà présents dans la norme IPv6
  • etc

Le protocole 6LoWPAN est principalement défini par deux RFC de l’IETF :

  • la RFC 4919 qui expose les problématiques auxquelles répondent le 6LoWPAN,
  • la RFC 4944 qui donne la spécification du protocole.

Le protocole 6LoWPAN est largement répandu à ce jour et de nombreux kits de développement existent. Il suffit de se procurer une carte compatible 802.15.4 et de trouver la stack 6LoWPAN compatible. Voici quelques exemples de cartes :

Référence Fabricant Distributeur Prix
NXP FRDM-CR20 (/!\ not a standalone) NXP Mouser 80€
STEVAL-IDIOO2V3 / 3V3 ST Mouser 48,5€ / 24€
CC2650 Eval kit TI Farnell 100€
USB Dongle Transceiver Spirit 1 ST RS 60€
Redwire Econotag OSHW InMojo 55€
Nooliberry Noolitic Noolitic ?
Merkur Board ? Semaf Electronic 35€
ATAVRRZUSBSTICK-ND Atmel Digikey 43$

Zigbee

Zigbee est un protocole propriétaire gratuit reposant sur la norme 802.15.4. Sa spécification est libre d’accès pour une utilisation personnelle, mais la commercialisation de produits Zigbee est conditionnée par l’appartenance (payante) à la Zigbee Alliance.

alt-text

C’est un protocole de courte portée (WPAN ou Wireless Personnal Area Network) par radio, à faible consommation et avec une grande facilité de déploiement (peu de code à développer, coût faible), ainsi qu’un faible débit. Sa portée peut atteindre 70 mètres. Le protocole Zigbee fait abstraction des couches Réseau et Transport, laissant à l’utilisateur le soin de définir l’application. Sa spécification est maintenue par la Zigbee Alliance. Le but de Zigbee est de proposer un moyen de créer son réseau WPAN plus simple et moins cher qu’avec des technologies classiques telles que le Bluetooth ou le Wi-Fi.

Au niveau des couches Physique et Liaison, Zigbee respecte la norme 802.15.4 et possède donc ses caractéristiques (notamment sa portée de quelques dizaines de mètres).

Pour les couches Réseau et Transport, la Zigbee Alliance fixe ses propres standards.

Le Zigbee présente les caractéristiques principales suivantes :

Caractéristique Valeur
Fréquences 2,4GHz / 868 MHz / 915 MHz
Débit max 250 kbps
Payload max 128 octets
Nombre max de dispositifs dans le réseau 65000

Le Zigbee est souvent confondu avec 802.15.4 (ou du moins, un abus de langage est fait). Il faut garder à l’esprit que le Zigbee repose sur le 802.15.4, et propose par-dessus son propre protocole, qui se place au niveau de la couche Réseau. Celui-ci permet par ailleurs le déploiement de configurations de réseau variées :

  • le réseau en étoile, le plus communément utilisé, notamment grâce à sa simplicité,
  • le réseau en mesh, mettant en place un système de communication « P2P » entre les modules,
  • réseau hybride, une combinaison des deux réseaux précédents.

Il existe une autre version de Zigbee appelée Zigbee PRO : celle-ci assure de meilleures performances et ajoute de nouvelles fonctionnalités (nombre maximal de dispositifs connectés, multicast, nouvelles fonctionnalités de sécurité, etc). Le Zigbee « normal » est tout de même maintenu afin de permettre l’accès à une technologie à bas coût.

La Zigbee Alliance a récemment proposé une nouvelle spécification du Zigbee à travers la spécification RF4CE : celle-ci propose un réseau qui permet l’utilisation de dispositifs à faibles ressources. Cette spécification impose de mettre en œuvre des « modules cibles » (ce sont les coordinateurs de la norme 802.15.4, il forment le réseau de base) et des « modules contrôleurs » (ce sont les « dispositifs de base » de la norme 802.15.4, ils « rejoignent » le réseau). En plus de ces 2 nœuds, on peut ajouter le nœud « routeur » (aussi issu de la norme 802.15.4).

On notera aussi la mise en place depuis 2013 de la spécification Zigbee IP, qui permet de déployer le protocole IPv6 sur des noeuds Zigbee. Cette implémentation se base d’ailleurs sur 6LoWPAN.

Au niveau hardware, les modules compatibles les plus réputés sont les modules Xbee, commercialisés par la société Digi. D’ailleurs, ceux-ci ne sont pas uniquement compatibles Zigbee : ils supportent d’autres protocoles tels que le Wi-Fi, Digimesh, 802.15.4 seul, etc. La gamme XBee comporte les modules suivants :

  • XBee-Zigbee : compatible avec le standard Zigbee
  • XBee Gateway : comporte la stack IP nécessaire pour communiquer avec les réseaux classiques
  • XBee 802.15.4 : implémente seulement le standard 802.15.4, pour une communication Point à Point
  • Xbee 900 : utilise la bande des 900 MHz au lieu de celle des 2,4 GHz. Compatible avec Digimesh
  • Xbee XSC : module à débit réduit mais portée améliorée
  • Xbee 2B : série avec hardware amélioré
  • etc…

A ces modules s’ajoute une Gateway Xbee qui sert à faire le lien entre un réseau XBee et un réseau IP.

On peut de plus se procurer des breakout boards afin de rendre autonome les modules XBEE, comme ceux de chez Sparkfun (une vingtaines d’euros sur Sparkfun, avec au choix une alimentation par USB ou sur secteur et une communication série).

Ces modules proposent des interfaces relativement simples pour la mise en place d’une interface de communication (UART, SPI).

En plus des modules Xbee, qui sont des modules “ready to use”, il existe de nombreux SoCs compatibles avec le protocole Zigbee :

Fabricant Référence
Microchip MRF24J40
Texas Instruments CC2650
Silicon Labs EM358x
Marvell 88MZ100
Freescale MC1323
NXP JN-516x
Atmel ATZB-24-B0
Telink TLSR8636
GreenPeak Technologies GP691

Une alternative à Zigbee est DigiMesh. Celui-ci ne propose plus qu’un type de nœud, ce qui simplifie le réseau.

Il existe un projet de support du Zigbee dans Linux (http://linux-zigbee.sourceforge.net) mais celui-ci a été basculé sur 802.15.4 et 6LoWPAN, car il fut impossible d’intégrer Zigbee dans Linux à cause des droits sur le protocole. Il existe aussi une implémentation Open Source de la stack Zigbee appelée ZBoss.

Les protocoles applicatifs (de couche 7)

Finalement, nous arrivons aux protocoles applicatifs. Ce sont eux qui vont assurer le transfert de données spécifiques à l’application que l’on souhaite déployer.

CoAP

CoAP (Constrained Application Protocole) est un protocole standardisé (défini dans la RFC7252) qui permet aux équipements à faibles ressources de communiquer sur des réseaux classiques tels que Internet. Pour cela, il s’appuie sur une couche UDP et se charge de faire le lien vers des applications HTTP.

CoAP repose sur le modèle REST (modèle Client-Serveur), et se charge donc d’implémenter des requêtes telles que GET, PUT, POST ou DELETE. Il est donc facile de développer une application utilisant CoAP pour quelqu’un connaissant les bases du protocole HTTP.

CoAP dispose d’un grand nombre d’implémentations, libres ou non. Le protocole étant développé au niveau applicatif, il ne dépend pas d’un hardware particulier (même si la légèreté de sa surcouche permet de le déployer sur des plateformes à faibles ressources telles que des microcontroleurs). On trouve par exemple une implémentation en C du nom de libcoap, ou encore SMCP, tous deux disponibles sur Github.

MQTT

MQTT est un protocole de communication léger, basé sur un système publisher/subscriber. Il est conçu pour fonctionner au dessus d’une stack TCP/IP.

alt-text

Pour fonctionner, MQTT nécessite le déploiement d’un broker (serveur qui centralise les données) qui va gérer la distributioin des messages aux clients.

Il existe une variante de MQTT prévue pour les réseaux de capteurs appelés MQTT-SN (l’une de ses principales modification est l’utilisation d’UDP au lieu de TCP).

Le protocole est ouvert. En conséquence, de nombreuses implémentations existent et sont trouvables par exemple sur Github. En C, on trouve par exemple le broker Mosquitto.

XMPP

XMPP (Extensible Messaging and Presence Protocol) est un protocole ouvert de messagerie instantanée. Le protocole de messagerie instantanée Jabber est notamment basé dessus.

alt-text

Le procotole est défini par plusieurs RFC (RFC6120, 6121, 6122, 3922 et 3223) qui définissent, à la base, les infrastructures Jabber.

Aujourd’hui, le protocole XMPP n’est plus seulement utilisé pour de la messagerie instantanée. Une implémentation de XMPP a été développée pour l’IoT (XMPP-IoT). Plusieurs API existent dans divers langages (voir XMPP-IoT sur Github)

SNAP

Le Subnetwork Access Protocol (SNAP) est un protocole Open Source susceptible d’être déployé sur des microcontrôleurs à faibles ressources. Il a été développé par l’entité HTH pour pallier à un manque (il leur fallait un protocole compatible avec leur système domotique basé sur un vieux protocole, PLM-24).

Le Protocole SNAP a, par exemple, fait l’objet d’essais dans la communauté RepRap pour faire communiquer des imprimantes 3D.

SSI

Le Simple Sensor Interface Protocol (SSI) permet de faire naviguer de manière simple des données sur un réseau de capteurs par-dessus une liaison UART ou une stack nanoIP (nanoIP intègre une librairie SSI). Ce protocole a été développé par un groupe d’entreprises (parmi lesquelles figure Nokia) et est aujourd’hui maintenu par l’European Union Framework Programmes for Research and Technological Development.

CBOR

CBOR n’est pas un protocole à proprement parler mais un format de données. Son acronyme signifie Concise Binary Object Representation. On peut donc l’utiliser par dessus les protocoles vus précédemment comme par exemple avec CoAP. Le modèle CBOR est implémenté dans de nombreux langages. Il est par exemple implémenté en C dans l’OS RIOT, spécialisé dans les plateformes à faibles ressources pour l’IoT.

Les protocoles multi-couches

Cette partie regroupe les protocoles qui interviennent sur plusieurs couches du modèle OSI. Cet étalement s’explique notamment par les organismes à l’origine de ces protocoles : ce sont souvent des entreprises ou des groupes qui construisent leur propre stack et la proposent ensuite en la présentant comme un potentiel standard pour les objets connectés.

WirelessHART

WirelessHART, basé sur le travail de la société Dust Networks s’appuie sur le protocole HART : il s’agit d’un protocole filaire qui fait passer une information dans une boucle de courant (soit un support cablé). Ce protocole est notamment utilisé dans l’industrie. WirelessHART est l’implémentation sans fil de ce protocole. Il s’appuie sur la norme internationale IEC62591.

alt-text

Au niveau Physique et Liaison, on retrouve encore une fois le standard 802.15.4, le protocole étant dans la bande des 2,4 GHz. Le reste des couches est propre au protocole, qui définit ainsi un réseau en mesh.

Linear Technology propose des kits de développement avec des nœuds WirelessHart (DC9018A-C, 135€ sur Farnell). Il faut aussi se procurer la passerelle WirelessHART adéquate (par exemple la LTP5903CEN, 2300€ chez Farnell).

ISA100.11a

ISA100.11a est un autre protocole industriel pour capteurs/noeud sans fil, défini par l’International Society of Automation (ISA)

alt-text

Ce protocole repose sur ceux vus précédemment : au niveau Physique et Liaison, on retrouve encore une fois le 802.15.4. On trouve ensuite du 6LoWPAN avec UDP par dessus, puis des applications ISA.

MiWi

MiWi est un protocole de communication sans fil propriétaire développé par Microchip. Il ne fonctionne que sur les chips Microchip.

alt-text

Le protocole MiWi s’appuie sur la norme 802.15.4, il opère donc à 2,4 GHz, cependant certains modules compatibles MiWi proposent l’utilisation de la bande des 868 MHz en Europe et des 915 MHz en Amérique.

Le protocole MiWi est en fait composé de deux protocoles :

  • MiWi P2P : déploiement d’un réseau Point à Point, avec une stack légère,
  • MiWi Pro : pour mettre en place un réseau de type mesh, avec une grande capacité en nombre de dispositifs.

Microchip définit la stack employée pour MiWi et le fonctionnement des protocoles dans les Application Notes AN1066 et AN1204.

Plusieurs modules existent pour mettre en place le protocole MiWi (mais aussi tout protocole se basant sur le 802.15.4), avec notamment la gamme des transceivers MRF24J40 (MRF24J40MA, chip seul, à 6€ sur Farnell).

Thread

Thread est un protocole de communication gratuit M2M.

alt-text

Sa stack est composée de protocoles vus précédemment :

  • Au niveau Physique et Liaison, on retrouve la norme 802.15.4,
  • Au niveau Réseau, on retrouve de l’IPv6, précédé du 6LoWPAN pour interfacer avec les couches basses,
  • Au niveau transport, on trouve de l’UDP avec en plus du DTLS (Datagram Transport Layer Security),
  • Le niveau applicatif est propre à Thread.

Les sources du protocole Thread sont accessibles aux membres du groupe Thread qui peuvent alors, à l’aide de la spécification, développer des produits compatibles Thread.

La spécification du protocole est maintenue par un regroupement appelé la Thread Alliance, qui comporte des sociétés d’importance en son sein (ARM, Google, Samsung).

Les plateformes de developpement EM35X de Silicon Labs permettent de s’initier au protocole (27€ le module chez Mouser, par exemple).

Weightless

Weightless est un standard ouvert pour les réseaux LPWAN, géré par le regroupement Weightless SIG.

alt-text

Le nom choisi rappelle que le protocole ne rajoute que peu de données d’en-tête aux données à faire transiter. Cette norme est en fait constituée de trois standards, Weightless-N, Weightless-P et Weightless-W.

__ Weightless-N Weightless-P Weightless-W
Direction Monodirectionnel Bi-directionnel Bi-directionnel
Fonctionnalités Simples Complètes Etendues
Portée 5 km+ 2 km+ 5 km+
Durée de vie sur batterie 10 ans 3-8 ans 3-5 ans
Coût d’un module Très bas Bas Bas-moyen
Coût du réseau Très bas Moyen Moyen

http://www.weightless.org/about/which-weightless-standard
On voit globalement que le Weightless rejoint la catégorie des protocoles longue distance, au même titre que le LoRa.

L’utilisateur devra donc choisir le protocole approprié selon l’utilisation qu’il désire :

  • si le coût en matériel et en énergie est un critère important, il faudra opter pour Weightless-N. C’est un protocole similaire à Sigfox (il utilise la technologie UNB). Nwave est à l’origine de cette version de Weightless.
  • si au contraire la performance est plus importante, il faudra se tourner vers Weightless-P. Son développement est assuré par la société M²Communication.
  • si le besoin de fonctionnalités étendues, on peut choisir Weighless-W (attention cependant, celui-exploite les fréquences TV, regroupées dans le “white space spectrum”. Ce sont des fréquences autorisées pour le broadcast).

Le protocole Weightless, bien qu’ “ouvert”, n’est implémentable par les industriels que s’ils ont la licence officielle proposée par le Weightless SIG.

Nwave propose une carte d’évaluation de Weightless interfaçable en USB. De plus, la société Neul (contributrice de la norme Weightless, rachetée par Huawei en 2014) propose le transceiver Iceni ainsi qu’une plate-forme de développement.

Dash7

Dash7 est un protocole sans fil développé à l’origine à des fins militaires, qui dépend de la norme ISO/IEC 18000-7.

alt-text

La Dash7 Alliance essaye maintenant de le propulser sur le devant de la scène et de le promouvoir pour l’utilisation des objets connectés. C’est un protocole opérant à 433 MHz avec un débit de 27,77 Ko/s. Il propose une portée de 1 kilomètre.

Il est possible de développer de nouvelles applications utilisant Dash7 grâce aux kits de développement suivant :

  • le kit développeur de Nornir, disponible sur leur site pour 859€
  • le WizziKit proposé par WizziLab à 140€

Z-Wave

Z-Wave est un protocole propriétaire développé par Zen-Sys, qui a été rachetée par Sigma Designs. C’est un protocole très répandu dans l’univers de la domotique qui opère à 868 MHz en Europe.

alt-text

Pour intégrer Z-Wave dans un produit, il faut obligatoirement passer par un chip Z-Wave officiel. Les dispositifs Z-Wave proposent une portée moyenne d’une quarantaine de mètres.

Référence Fabricant Distributeur Prix
Contôleur USB Z-Wave Sigma Designs Digikey 25€

Il existe une implémentation Open Source de Z-Wave appelée OpenZWave. Celle-ci est écrite en C++ est s’interface avec les modules Z-Wave grâce à un dongle Z-Wave parmi ceux présents dans la liste suivante :

Fabricant / Modèle Type de connection
Tricklestar USB
ACT ZCS101 RS232
Z-troller RS232
Aeon ZStick USB
Aeon Z-Stick S2 USB
Aeon Z-Stick Gen5 USB
Seluxit ViaSens 100 USB
Z-Wave.Me Z-Stick USB
Z-Wave.Me RaZberry USB
Vision USB Stick USB
Sigma Designs UZB Stick USB

Nwave

nwave-logo

Nwave est une société qui propose sa propre solution de communication longue portée.

 

Elle distribue son propre hardware et celui-ci supporte un protocole propre à la société. Parmi les dispositifs distribués par Nwave, on trouve :

  • un module radio à intégrer dans son design,
  • un modem universel, compatible avec la plupart des capteurs et dispositifs Nwave,
  • une station de base,
  • un kit de développement.

EnOcean

EnOcean est une société qui propose des modules sans-fil prêts à déployer. Les couches basses du protocole de communication utilisé sont propriétaires.

EnOceanLogo_4c

Voici quelques caractéristiques des modules déployables :

Caractéristique Valeur
Fréquences 2.4 GHz / 868 MHz / 915MHz
Portée 30 m indoor, 300 m outdoor
Débit 125 kbps

La particularité des modules EnOcean réside dans leur très basse consommation. Ceux-ci sont même capables de récupérer leur énergie de l’environnement ambiant (« energy harvesting ») (exemple : mini panneau solaire).

Le fabricant propose plusieurs modules et capteurs directement sur son site, ainsi que des API pour pouvoir développer ses applications.

ANT

ANT est un protocole conçu et commercialisé par la société Dynastream Innovations Inc, filiale de Garmin. Il est conçu pour les réseaux de capteurs à destination de divers secteurs comme la domotique, la santé, le sport ou l’industrie. Disposant d’une portée moyenne d’une trentaine de mètres, il supporte plusieurs architectures de réseaux.

alt-text

ANT propose à la fois la spécification de son protocole et des suggestions de composants hardware pour son implémentation :

  • SoC : nRF52832 (Nordic), CC2571, CC2570 (TI), les stacks ANT sont proposées pour ces SoCs
  • modules : ANT N5 (dev kit à 142$ sur Digikey, 20$ le module seul), C7 (22$ sur Digikey)

La société propose également des kits de développement et des dongles.

Insteon

Insteon est une technologie pour la domotique qui permet de connecter des lumières, des thermostats, des capteurs de mouvement, etc.

alt-text

Cette technologie est propriétaire (elle appartient à la société Smartlabs) et implémente ses propres protocoles de communication. La société propose des composants “plug & play” ainsi qu’une API pour développer ses propres applications connectées.

Les réseaux pour objets connectés prêts à l’emploi

Certaines sociétés, plutôt que de proposer du matériel et des API pour déployer des objets connectés, ont choisi de se focaliser sur le déploiement de leur propre réseau et de proposer aux utilisateurs un accès à celui-ci contre un abonnement. Même si les utilisateurs doivent se procurer le hardware leur permettant d’interfacer leur application avec ledit réseau, son implémentation devient ensuite relativement aisée, grâce aux outils fournis par les « providers ».

Réseaux mobiles

Les réseaux mobiles peuvent aussi être utilisés pour connecter des applications et dispositifs. Intialement prévus pour la communication par voix, on peut aujourd’hui déployer des applications utilisant les réseaux mobiles pour les communications entre objets connectés. Ces réseaux sont proposés par les fournisseurs “classiques” tels que Orange, Bouygues, SFR, etc… et des fournisseurs plus spécialisés tels que Transatel, Matooma, etc… Il existe plusieurs générations technologiques de réseaux mobiles, offrant chacune ses caractéristiques particulières :

Génération Technologie principale Année de mise en place Débit Commentaire
1G Advanced Mobile Phone System (AMPS) 1978 Technologie analogique
2G Global System for Mobile Communication (GSM) 1991 9,6 kbps Technologie digitale. Possède une variante appelée Digital Communication System (DCS)
2.5G General Packet Radio Service (GPRS) 171 kbps
2.75G Enhanced Data Rates for Global Evolution (EDGE) 384 kbps
3G Universal Mobile Telecommunicatios System (UMTS) 2001 1,2 Mbps
3G+ High-Speed Downlink Packet Access (HSDPA) 2008 14,4 Mbps
4G Long Terme Evolution (LTE) 2008 150 Mbps
4G+ LTE Advanced 1 Gbps

Les débits donnés sont bien sûr des débits théoriques maximaux et sont donc impossible à atteindre.

On peut trouver plusieurs kits de développement pour déployer des applications utilisant les réseaux mobiles :

Kit Fabricant Technologie(s) supoortée(s) Distributeur Prix
MG2639 Cellular Shield Sparkfun GSM, GPRS (+ GPS) Sparkfun 70 $
GSM Shield Arduino GSM, GPRS Arduino 70 $
FONA Breakout Adafruit GSM, GPRS Adafruit 40 $
3G(UMTS) + GPS Shield Embedded Artists UMTS”(+GPS) Embedded Artists 90 €

Certains opérateurs comme Bouygues, Orange ou SFR font preuve d’un intérêt marqué pour l’IoT et visent à développer toute une gamme d’offre d’accès à leurs réseaux pour des applications M2M (donc des applications à faible débit de communication). L’achat d’une carte SIM et d’un module compatible reste à la charge de l’utilisateur. L’offre propose ensuite l’accès à des réseaux mobiles (2G, 3G, etc).

Sigfox

Le réseau Sigfox est maintenu par la société éponyme. Au niveau de la couche Physique, le protocole Sigfox utilise la technologie Ultra Narrow Band (UNB), dans la bande des 868 Mhz en Europe, et 915 Mhz en Amerique.

alt-text

Sigfox propose un réseau plutôt qu’un protocole : en effet, une fois un module compatible Sigfox acheté par un utilisateur, celui-ci doit souscrire à un abonnement pour pouvoir faire transiter ses données sur le réseau Sigfox. L’utilisation de Sigfox a donc ses avantages et inconvenients :

  • Pas besoin de déployer une infrastructure pour utiliser le réseau Sigfox,
  • Peu d’effort de déploiement logiciel : Sigfox permet une récupération facile des données,
  • Nécessité de payer un abonnement pour utiliser le réseau,
  • Les données doivent transiter par les serveurs de Sigfox.

Le réseau Sigfox possède d’autres caractéristiques importantes :

  • Lien de communication mono ou bidirectionnel : le mode mono directionnel est à privilégier dans les applications ultra basse consommation,
  • Robustesse : Sigfox affirme que son réseau est robuste, de par sa couverture (fonctionne même en « Deep indoor », c’est-à-dire sous le niveau du sol) ou ses mécanismes de prévention des pertes (réseau redondant),
  • Sécurité : seul l’usager concerné peut déchiffrer les messages de son application, puisque c’est lui qui définit le format des données qu’il envoie.

Sigfox est avant tout conçu pour les applications ne nécessitant que très peu d’envoi de data (quelques messages de quelques octets par jour seulement). Voici les caractéristiques maximales des applications qu’un usager peut déployer via le réseau Sigfox :

Caractéristique Valeur
Message/jour 140
Payload 12 octets
Débit 100 bps

L’utilisateur peut récupérer ses données de plusieurs manières :

  • Sur l’interface web Sigfox,
  • Grâce à l’API Sigfox,
  • Par un système de callbacks.

Dans tous les cas, il a ensuite accès à la date du message reçu, l’identitifant du dispositif émetteur, et le message.

Pour mettre en place une application utilisant Sigfox comme support de communication, l’utilisateur doit d’abord se procurer un module compatible Sigfox. La société Sigfox rend disponible le protocole Sigfox à tout fondeur/manufacturier électronique, on peut donc trouver une grande variété de modules. Quelques-uns des plus connus sont les suivants :

Kit Fabricant Fournisseur Prix
ATA8250-EK3-E Atmel Mouser 105 €
TD1208 Eval Kit Telecom Design Telemetrie Shop 150 €
Akeru Snootlab Snootlab 100 €

Qowisio

A l ‘instar de Sigfox, Qowisio propose aussi son propre réseau ainsi que ses infrastructures aux usagers. Son réseau repose aussi sur la technologie UNB, mais il propose aussi la technologie LoRa, rendant son réseau hybride.

alt-text

Qowisio propose un framework pour créer des applications web capables de récupérer les données attendues par l’utilisateur.

Qowisio ne propose pas seulement une solution d’accès mais un déploiement complet des solutions demandées par les clients.

The Things Network

The Things Network est une communauté qui cherche à déployer gratuitement un réseau LoRaWAN pour tout usager d’objets connectés.

alt-text

L’initiative a d’abord commencé à Amsterdam : grâce à une campagne de crowdsourcing couronnée de succès, la communauté The Things Network a pu réaliser la couverture en LoRaWAN complète de la ville en 4 semaines. Son but est de répéter cette manoeuvre dans les autres villes du monde pour permettre un accès gratuit à un réseau LoRaWAN. The Things Network propose à l’achat 3 passerelles, dont une à 200 € qui vient d’être financée sur Kickstarter. Chaque utilisateur peut ensuite enregistrer ses objets connectés sur le site web dédié afin de commencer à les mettre en réseau.

Conclusion

Nous avons, tout au long de cet article, passé en revue les principales normes et références et termes de protocoles de communication pour les objets connectés, en constatant leurs diversité et leur spécificités (protocoles propriétaires ou non, niveau d’occupation du modèle OSI, variété du hardware existant, etc…). Cette partie peut être résumée grâce à la figure suivante, qui resitue chaque protocole dans le modèle OSI :

alt-text

Suite à la lecture de cet article, on peut se trouver confronté au choix d’un ou plusieurs protocole(s) pour la mise en place d’une démonstration, d’un système personnel dans le cadre d’une application domotique ou encore pour une utilisation professionnelle. Ce choix peut se révéler ardu devant l’étendue des possibilités. Quelques questions préliminaires peuvent accompagner le concepteur dans ses choix :

  • Est-ce que je désire une solution rapide à mettre en place, plutôt “plug & play” ? On peut envisager dans ce cas des solutions commerciales telles que Z-Wave, Insteon, EnOcean, etc.
  • Est-ce qu’au contraire je veux comprendre le fondement et le fonctionnement de mon système ? Dans ce cas, on peut partir d’un niveau beaucoup plus bas et commander des modules spécialisés et développer ses propres applications (plateformes de développement citées tout au long de ce document)
  • Est-ce que je veux m’appuyer sur des standards ouverts (6LoWPAN, CoAP, MQTT) ? Ou est-ce que je peux me contenter de firmware fournis par les fabricants (Zigbee, avec par exemple la Z-stack qui ne propose pas tout son code source) ?
  • Est-ce que je veux que mes objets connectés communiquent dans un environnement local (802.15.4, Wi-Fi, Bluetooth) ? Ou alors a-t-on besoin d’un réseau étendu (LoRa, Sigfox, Qowisio) ?
  • Dans le cas d’une communication longue portée, est-ce que je veux profiter d’un service “ready-to use” (Sigfox), ou alors je désire déployer mon propre réseau (hardware LoRaWAN) ?

On peut donc, en fonction de ses besoins, définir un couplage précis parmi les solutions présentées. Avec autant de groupes et d’organismes veillant au développement des normes et spécifications pour les objets connectés, il ne fait pas de doutes que l’Internet Of Things va continuer à susciter l’intếrét des industriels et particuliers, et nous devrions continuer à assister à l’émergence de systèmes intelligents autonomes. S’il y a donc un domaine particulier mouvant actuellement, c’est bien celui-ci !!

Sources

http://www.rs-online.com/designspark/electronics/knowledge-item/eleven-internet-of-things-iot-protocols-you-need-to-know-about
http://events.linuxfoundation.org/sites/events/files/slides/ELC-US-2015.pdf
https://www.linux.com/learn/tutorials/560384-how-linux-talks-to-the-internet-of-things-a-look-at-ieee-802154
http://f6kgl-f5kff.fr/realisation/sdr.pdf
http://eu.mouser.com/applications/wireless_mesh_networking_protocols/
http://postscapes.com/internet-of-things-software-guide
http://postscapes.com/internet-of-things-protocols
https://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI
http://www.objetconnecte.net/developpement-objets-connectes-les-chiffres/
https://fr.wikipedia.org/wiki/IEEE_802
https://fr.wikipedia.org/wiki/Wi-Fi
https://fr.wikipedia.org/wiki/IEEE_802.15.4
https://en.wikipedia.org/wiki/Comparison_of_802.15.4_radio_modules
http://events.linuxfoundation.org/sites/events/files/slides/ELC-US-2015.pdf
http://www.link-labs.com/lora-faqs/
http://www.link-labs.com/what-is-lora/
https://www.lora-alliance.org/What-Is-LoRa/Technology
https://www.cooking-hacks.com/documentation/tutorials/extreme-range-lora-sx1272-module-shield-arduino-raspberry-pi-intel-galileo/
http://www.sigfox.com/static/media/Files/Documentation/SIGFOX_Whitepaper.pdf
http://makers.sigfox.com/#about
https://github.com/minimaxwell/docs/blob/master/bluetooth/meetup/bt_meetup.pdf
https://fr.wikipedia.org/wiki/Bluetooth
https://tools.ietf.org/html/draft-ietf-6lo-btle-17
https://fr.wikipedia.org/wiki/6LoWPAN
http://www.embedded.com/electronics-blogs/embedded-cloud-talkers/4236873/How-to-setup-a-6LoWPAN-network
https://fr.wikipedia.org/wiki/Radio-identification
https://fr.wikipedia.org/wiki/R%C3%A9seau_de_t%C3%A9l%C3%A9phonie_mobile
https://fr.wikipedia.org/wiki/Global_System_for_Mobile_Communications
https://fr.wikipedia.org/wiki/Advanced_Mobile_Phone_System
http://www.arcep.fr/?id=8807
http://archives-lepost.huffingtonpost.fr/article/2010/03/17/1991549_c-est-quoi-gsm-2g-2-5g-3g-edge-gprs.html
https://fr.wikipedia.org/wiki/4G
http://www.commentcamarche.net/contents/1123-telephonie-mobile-3g-et-4g-expliquees
https://en.wikipedia.org/wiki/List_of_mobile_phone_generations
http://electronicdesign.com/communications/what-s-difference-between-zigbee-and-z-wave
https://fr.wikipedia.org/wiki/Z-Wave
http://elinux.org/images/7/71/Wireless_Networking_with_IEEE_802.15.4_and_6LoWPAN.pdf
http://www.nwave.io/
https://en.wikipedia.org/wiki/Weightless_(wireless_communications>
http://www.link-labs.com/what-is-weightless/
http://www.yokogawa.com/us/technical-library/resources/media-yokogawa.com/us/technical-library/resources/media-publications/prepare-wireless-protocol-for-the-future/” rel=”nofollow”>publications/prepare-wireless-protocol-for-the-future/
http://www.threadgroup.org/Portals/0/documents/whitepapers/Thread%20Stack%20Fundamentals_v2_public.pdf
https://www.aruco.com/2014/07/thread-protocole/
http://www.silicon.fr/huawei-savance-les-objets-connectes-neul-96909.html
https://en.wikipedia.org/wiki/MiWi
http://www.microchip.com/pagehandler/en-us/technology/personalareanetworks/technology/home.html
http://blog.domogy.com/le-protocole-miwi-de-microchip/
http://www.bortzmeyer.org/7252.html
https://en.wikipedia.org/wiki/Constrained_Application_Protocol
http://coap.technology/
https://fr.wikipedia.org/wiki/Representational_State_Transfer
http://mosquitto.org/man/mqtt-7.html
http://mosquitto.org/
https://github.com/mqtt/mqtt.github.io/wiki
http://www.libelium.com/downloads/documentation/waspmote_datasheet.pdf
http://www.hth.com/filelibrary/pdffiles/snap.pdf
http://www.hth.com/filelibrary/plm-24/plm-24.pdf
http://openkontrol.org/llap/index.php/openkontrol/69-LLAP%20-%20Lightweight%20Local%20Automation%20Protocol
https://sourceforge.net/projects/ucip/?source=typ_redirect
https://sourceforge.net/projects/nanoip/
https://fr.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol
http://www.janding.fi/iiro/papers/SSI%20protocol%20specification_12.pdf
http://thethingsnetwork.org/
http://www.insteon.com/
https://en.wikipedia.org/wiki/ANT_(network)_
https://www.thisisant.com/
https://en.wikipedia.org/wiki/AllJoyn
https://allseenalliance.org/framework/

Un commentaire sur “ Protocoles de communication, frameworks et systèmes d’exploitation pour les objets connectés ”

  1. nouvel fabienne
    le 31 mai 2017 à 9 h 02 min

    Article et rétrospective très intéressants et utiles

    le schéma final donne une vue d’ensemble et permet de se retrouver ds ts ces standards et offres

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *