Mise en place d'un réseau IoT avec RIOT

1. Quelques généralités sur l'IoT

Le déploiement de la version 6 du protocole IP ouvre des perspectives quasi illimitées de communication à travers Internet entre tout système disposant d'une pile réseau compatible. En effet, par construction, cette version apporte un espace d'adressage beaucoup plus vaste que celui de son ancêtre pratiquement saturé IPv4, passant de 232 (un peu plus de 4 milliards) à 2128 adresses*. Cela doit permettre à terme d'adresser et donc de connecter, à peu près tout ce qui se trouve à la surface de la Terre. C'est donc en partie grâce à IPv6 qu'un si bel avenir, à l'horizon 2020, est promis à l'IoT.

Actuellement, des systèmes tels que [RIOT], [Contiki] ou [Zephyr] arrivent à faire communiquer par ondes radio des objets fonctionnant sur des configurations très contraintes, leur donnant ainsi une autonomie maximale sur batterie. On parle ici d'objets à base de microcontrôleurs ayant des caractéristiques largement inférieures à ceux équipant des cartes Raspberry Pi ou équivalents : quelques Ko de SRAM et de flash et un CPU fonctionnant à quelques dizaines de MHz. Donc plutôt des objets à base d'AVR, de MSP430 ou d'ARM Cortex-M0 jusqu'au Cortex-M4. Pour vous donner un ordre d'idée, ce type de systèmes peut rester en fonctionnement jusqu'à plusieurs années sans avoir besoin d'être rechargé et donc être installé dans des zones peu accessibles, voire hostiles [Low Power].

Pour réussir à faire tenir une pile réseau qui respecte les problématiques de l'IoT (peu de mémoire, autonomie maximale), plusieurs groupes de travail de l'IETF ont proposé de nouveaux protocoles et en ont adapté d'autres dans le modèle de couches IP (Figure 1).

Dans le cadre qui nous intéresse pour cet article, les objets connectés, qu'on appellera aussi « noeuds » par la suite, utilisent des interfaces de communication sans fil de type [802.15.4]. La consommation de ce protocole radio est très faible et on parle alors de réseau LowPAN pour LoW Power wireless Area Networks ou LLN pour Low-Power and Lossy Networks. En contrepartie, leur portée est courte : en fonction de la fréquence/modulation, jusqu'à la centaine de mètres pour la variante populaire dans la bande 2.4 GHz à 250 Kbps.

[6LowPAN] est une couche d'adaptation de la couche réseau IPv6 destinée à faire passer des trames IPv6 dont le MTU est au minimum de 1280 octets dans des trames 802.15.4 (127 octets). Cette couche d'adaptation permet donc de faire interopérer différents types de réseau en IPv6 (Ethernet, 802.15.4, Wifi, 4G... ). Le routage interne IPv6 entre les nœuds du réseau utilise le protocole à vecteur de distance [RPL], adapté à un réseau moins fiable (pertes de paquets, faible bande passante...). Sur un LLN, puisqu'on s'autorise de la perte de paquets, le transport des données s'effectue généralement par UDP, ce qui limite aussi la taille des entêtes.

Enfin, tout en haut de la pile, [CoAP] est un protocole de transport applicatif de type web (HTTP) proposant un modèle requête/réponse de type REST.

Tous ces protocoles sont disponibles dans RIOT et l'objectif de cet article est de vous montrer comment les utiliser pour faire de l'IoT.

2. Rappels préalables sur IPv6

Avant de rentrer dans les explications de configuration réseau sur les nœuds, il est essentiel d'avoir quelques notions sur IPv6. Ici, seuls les éléments nécessaires à la compréhension de la suite de l'article sont donnés, mais le lecteur désirant aller plus loin pourra se pencher sur lecture des RFC décrivant la norme en détail :  [RFC4291], [RFC2460], [RFC3306], [RFC3307], [RFC3849].

Contrairement à une adresse IPv4 qui est codée sur 32 bits (i.e 4 octets) et utilise une notation décimale (par exemple : 192.168.6.19), une adresse IPv6 est représentée par une série de 128 bits, soit 16 octets, et se représente avec une notation hexadécimale (Figure 2). Par exemple, une adresse IPv6 peut avoir pour représentation complète :

qui, suivant certaines règles (entre autres, une série de 0 contigus est remplacée une seule fois par ::, [RFC 5952]), peut s'abréger en :

Cette série de 128 bits est souvent divisée en 2 parties :

• les 64 bits de poids faible correspondent à l'adresse de l'hôte, ::19 dans l'exemple précédent. Généralement, ils sont construits à partir de l'adresse MAC de l'hôte pour garantir l'unicité d'une adresse IPv6 dans un sous-réseau (puisque l'adresse physique est elle-même unique, normalement) ;
• les 64 bits de poids fort correspondent eux à l'adresse réseau, 2001:db8:3c4d::ab:: dans l'exemple précédent. Ils contiennent en particulier le « préfixe » utilisé pour le routage de paquets IPv6 et utilisent, comme en IPv4, la notation CIDR : <préfixe>/<longueur en bit>.  Ce bloc de 64 bits se divise en une première partie contenant jusqu'à 48 bits et désignant le « préfixe de site », le reste des bits identifiant le sous-réseau. Un préfixe contient toujours 64 bits.

Certains préfixes sont réservés pour des usages bien précis :

• 2001:db8::/32 est utilisé pour la documentation (comme dans notre exemple). Il définit également une adresse unicast dite « globale », c'est-à-dire routable,
• fe80::/10 est utilisé pour les adresses unicast dites « lien-local ». Ce type d'adresse ne permet à 2 nœuds du réseau de communiquer que s'ils partagent un lien physique direct. C'est ce qui avait été utilisé dans le précédent article sur RIOT puisque les nœuds se voyaient directement via leur interface sans fil (802.15.4),
• ff00::/8 est utilisé pour les adresses multicast,
• fd00::/8 est destiné aux adresses « Unique Local Address ». Ces adresses correspondent aux adresses privées en IPv4 et ne sont pas routables.

Lorsqu'un nœud initialise une interface réseau et cherche à configurer son IP, il effectue une procédure dite de découverte de voisins définie par le Neighbor Discovery Protocol, NDP ([RFC4861]). Tout d'abord, il envoie un message ICMPv6 de type « Router Solicitation » et si un routeur est présent sur le même lien, celui-ci renvoie un message ICMPv6 de type « Router Advertisement » contenant le préfixe (ces derniers sont aussi envoyés périodiquement par le routeur). De cette manière, le nœud configure automatiquement son adresse IP globale avec le préfixe en utilisant le format illustré par la figure 2.

3. Communication directe entre 2 nœuds

Maintenant que le cadre et les éléments théoriques sont posés, il est temps de passer à la pratique. Le premier objectif consistera à faire communiquer 2 nœuds par radio 802.15.4 sur un lien local IPv6 à l'aide d'une des applications d'exemple disponibles dans le code source de RIOT, gnrc_networking. Cet exemple est utile pour plusieurs raisons :

• il utilise le shell de RIOT permettant d'avoir une console interactive sur un nœud,
• il charge les modules réseau et donne accès à des commandes supplémentaires liées à la configuration réseau et l'envoi de messages UDP entre nœuds,
• nous pouvons l'utiliser tel quel pour faire communiquer 2 nœuds.

Le principe est illustré par la figure 3.

Tout d'abord, il faut télécharger depuis GitHub le code source de la dernière version stable de RIOT (2016.04 au moment où ces lignes sont écrites) :

Toutes les manipulations qui suivent ont été effectuées sur des cartes Atmel SAMR21 Xplained Pro (Figure 4) et un PC sous Ubuntu 15.10 utilisé pour la compilation et pour flasher les firmwares sur les cartes. La version 16.04 d'Ubuntu devrait aussi fonctionner.

Sur le PC hôte, si ce n'est pas déjà fait, il faut également installer la chaîne de compilation pour l'architecture ARM du MCU de la SAMR21 :

Et ajouter l'utilisateur <user> aux groupes plugdev et dialout :

Sur le PC, pour simplifier les manipulations, notamment lors de la compilation des firmwares, on peut définir les variables d'environnement BOARD et RIOTBASE et les ajouter à ~/.bashrc :

L'environnement utilisateur doit alors être rechargé :

Si vous avez bien suivi les étapes précédentes, le code source de l'exemple gnrc_networking doit se trouver dans ~/RIOT/examples/gnrc_networking et vous pouvez brancher et récupérer l'identifiant des 2 cartes à l'aide de l'outil fourni par RIOT, ~/RIOT/dist/tools/usb-serial/list-ttys.sh. Ces informations permettent d'identifier chaque carte pendant les étapes de flashage (serial) et de se connecter à leur port série (tty).

Dans un premier terminal (qui sera nommé par la suite term1), on commence par flasher la carte identifiée par SERIAL=<SERIAL1> et se connecter sur PORT=/dev/ttyACM0:

L'opération est répétée dans un second terminal (term2), cette fois-ci sur la carte SERIAL=<SERIAL2> et PORT=/dev/ttyACM1 :

À ce stade, un terminal série est ouvert sur chacune des 2 cartes (via l'outil pyterm), ce qui permet d'interagir avec elles en utilisant les commandes du shell RIOT.  La commande help, renvoie la liste des commandes disponibles. La commande ifconfig affiche la configuration réseau de la carte sur term1 :

On voit que cette carte n'a qu'une interface réseau sans fil Iface 7 qui correspond à l'antenne 802.15.4. 3 adresses IP sont définies sur cette interface et en particulier 1 adresse « unicast » de type lien local : fe80::5841:2d52:e433:3f16/64.

Cette interface ne dispose pas d'adresse globale, car aucun routeur ne se trouve à proximité pour propager un préfixe. La carte term1 ne peut par conséquent pas communiquer avec d'autres hôtes à travers Internet. Par contre, puisque les 2 cartes sont proches et utilisent le même lien physique (canal 26 en 802.15.4), il est tout de même possible de les faire communiquer entre elles directement.

Pour cela, le shell dispose de la commande udp qui peut démarrer un serveur UDP ou envoyer des données par UDP. Sur term1, le serveur UDP est mis en écoute sur le port 8888 :

Et depuis term2, les données sont envoyées par UDP à term1 :

Normalement, les données reçues par le serveur UDP sont affichées sur term1 :

Remarquez le découpage (SNIP) du datagramme : SNIP 0 contient les données, SNIP 1 contient le header UDP, SNIP 2 contient le header IPv6 et SNIP 3 contient le header 802.15.4 MAC.

Le serveur UDP a bien reçu le message de 20 octets dont le contenu est affiché en hexadécimal (en rouge). Les deux cartes arrivent donc à s'échanger des messages UDP à travers leurs interfaces sans fil.

4. Configuration du routeur de bordure

Pour qu'un nœud du réseau puisse communiquer en IPv6 avec un hôte sur Internet, il lui faut une adresse unicast « globale ». Pour cela, il faut ajouter au réseau un routeur de bordure (i.e « Border Router » ou « BR ») qui sera chargé de propager le préfixe aux autres nœuds. On parle ici de routeur de bordure, car il se trouve à la frontière entre un réseau 802.15.4 et un réseau Ethernet. Pour cela, la carte branchée sur term1 est réutilisée pour être transformée en BR en la « flashant » avec le firmware de l'exemple ~/RIOT/examples/gnrc_border_router. Le terminal série sur term1 doit être fermé avec la commande /exit.

Le BR aura une interface reliée à l'ordinateur et une autre interface 802.15.4 pour propager le préfixe et communiquer avec les nœuds du réseau. Le schéma de principe est représenté figure 5 :

L'interface reliée à l'ordinateur n'est autre que la liaison série UART qui est multiplexée avec le flux des messages IP. C'est là une nouveauté de la version 2016.04 de RIOT, appelée Ethos pour Ethernet Over Serial. Le PC et le BR communiquent sur ce lien qui peut être vu comme un pont en utilisant leurs adresses lien local respectives. UHCP (Micro host configuration protocol) est utilisé pour configurer les interfaces du BR à travers Ethos. Attention, ces deux outils/protocoles ne sont pas standards.

L'exemple gnrc_border_router est d'abord flashé depuis term1 sur la carte 1 :

Ensuite, il faut compiler deux programmes nécessaires pour configurer le lien série et le BR :

• ethos sert à multiplexer à la fois les données réseau (paquet) et séries (shell) sur une seule UART ;
• uhcpd, un micro « DHCP » propre à Ethos (et RIOT) permet de configurer les adresses du BR.

Les codes sources de ces deux outils se trouvent respectivement dans ~/RIOT/dist/tools/uhcpd et ~/RIOT/dist/tools/ethos :

Enfin, pour mettre en œuvre toute la configuration depuis l'hôte Linux, RIOT utilise un script d'automatisation ~/RIOT/dist/tools/ethos/start_network.sh effectuant les opérations suivantes :

• la création d'une interface tap sur le PC, tap0, pour communiquer avec la carte par le lien série ;
• l'activation du forwarding et de l'autoconfiguration IPv6 dans le kernel de l'hôte Linux (vers tap0) ;
• l'ajout une adresse « ULA », fd00:dead:beef::1, sur l'interface loopback lo côté hôte Linux. Cette adresse sera utilisable par les nœuds du réseau LLN pour accéder au PC ;
• l'ajout d'une route pour le préfixe 2001:db8:3c4d:ab::/64 via l'interface tap0 ;
• le démarrage du démon uhcpd pour que le BR configure ses adresses et préfixes ;
• le lancement d'ethos.

Dans notre exemple, la carte est visible sur le terminal /dev/ttyACM0, la commande à lancer est donc :

En plus de faire passer le flux des données réseau, ethos donne accès au port série du routeur qui dispose aussi d'un shell. La configuration de ces interfaces peut donc être obtenue par la commande ifconfig :

Le préfixe 2001:db8:3c4d:ab s'est bien propagé à l'interface sans fil Iface 6. On remarque aussi l'adresse lien local utilisée pour l'interface filaire (« wired ») Iface 7. C'est sur ce lien que la carte communique avec l'interface tap0 du PC via Ethos.

Dans term2, le préfixe a bien été propagé par le BR vers la deuxième carte :

Son adresse IPv6 globale est 2001:db8:3c4d:ab:5846:1e6d:b1b9:16b6 et elle est donc en mesure de recevoir un message ICMPv6 envoyé depuis le PC avec ping6 :

Inversement, un message ICMPv6 peut être envoyé depuis le shell de la carte term2 vers l'ULA fd00:dead:beef::1 configurée par start_network.sh sur le PC :

5. Accès aux nœuds par CoAP

Le routeur de bordure est désormais fonctionnel et assure la connectivité IP entre les cartes et le PC. Il reste alors à s'intéresser au niveau applicatif pour accéder aux ressources des nœuds du réseau (capteurs, LED, bouton, etc.). Pour cela, RIOT permet d'utiliser le protocole [CoAP].

Les spécifications de CoAP ont été proposées par le groupe de travail CoRE (Constrained RESTful Environments) de l'IETF. Le protocole repose sur l'utilisation de requêtes de type REST pour accéder aux ressources des nœuds du réseau tout en restant compatible avec les contraintes des LLN. Le serveur CoAP (généralement en écoute sur le port 5683) s'exécute sur un nœud du réseau et répond, comme en REST, aux requêtes GET, POST, PUT et DELETE.

Le code source de RIOT contient l'exemple microcoap_server permettant d'exposer un nœud de notre réseau comme une ressource CoAP. Pour envoyer des requêtes CoAP, cet exemple se sert de [microcoap], une bibliothèque externe importée dans RIOT sous la forme d'un paquetage externe (voir dossier ~/RIOT/pkg). Lors de la première compilation du firmware, les sources de microcoap sont téléchargées avec Git, patchées pour être rendues compatibles avec l'architecture de RIOT puis compilées.

Cet exemple est donc flashé sur la deuxième carte (term2) :

Par défaut, l'exemple microcoap_server retourne seulement le type de la carte à une requête GET sur l'URL coap://[adresse]/riot/board. Ici l'adresse en question est celle de la carte term2, comme on l'a vu dans la précédente partie : 2001:db8:3c4d:ab:5846:1e6d:b1b9:16b6.

Depuis un nouveau terminal sur le PC, il suffit alors d'utiliser le client CoAP de [libcoap] pour interroger le nœud. Comme libcoap n'est pas disponible dans les dépôts officiels Ubuntu, il faut commencer par en récupérer les sources depuis GitHub puis les compiler :

La requête GET envoyée avec le programme examples/coap-client sur l'URL mentionnée plus haut retourne alors le type de la carte sur laquelle s'exécute le serveur CoAP :

Il est aussi très facile de modifier le code source de l'exemple pour étendre l'API exposée par le serveur CoAP du nœud. Cette API est définie et implémentée dans le fichier ~/RIOT/examples/microcoap_server/coap.c. À partir de la ligne 25, y sont d'abord initialisées des structures pour définir les chemins disponibles (coap_endpoint_path_t) puis la liste des endpoints vers les fonctions callback associées (coap_endpoint_t) :

Une requête GET (COAP_METHOD_GET) sur le chemin /.well-known/core renvoie la liste des chemins disponibles et définit la fonction handle_get_well_known_core comme endpoint (voir son implémentation ligne 41). D'après les spécifications CoAP, ce chemin doit être défini par défaut et retourner la liste des ressources disponibles sur le nœud. De même, est défini pour /riot/board le endpoint d'une requête GET vers la fonction handle_get_riot_board. Il est très simple d'adapter cet exemple pour récupérer par CoAP les valeurs d'un capteur branché sur la carte (voir l'article sur RIOT dans le précédent numéro). La fin du fichier contient les implémentations de ces fonctions callback (voir l'implémentation de handle_get_riot_board, ligne 89).

Microcoap supporte aussi les requêtes PUT (COAP_METHOD_PUT) : un endpoint peut donc être rajouté pour piloter la led qui se trouve sur la carte depuis le client CoAP.

Pour cela, comme il s'agit de piloter un périphérique GPIO de la carte, il faut inclure les définitions nécessaires dans coap.c :

Puis, définir le chemin /led dans notre API :

Ensuite, ajouter un endpoint vers une fonction handle_put_led dans le tableau endpoints déjà défini :

Définir et implémenter la fonction handle_put_led :

Enfin, la feature periph_gpio est requise dans le fichier Makefile :

Après flashage de la carte sur term2, la led de la carte est alors pilotable depuis le PC avec coap-client :

- LED allumée :

- LED éteinte :

À noter qu'il existe d'autres outils pour interagir avec un serveur CoAP :

• avec l'extension Firefox Copper : https://addons.mozilla.org/fr/firefox/addon/copper-270430 ;
• en Python : https://aiocoap.readthedocs.io/en/latest/ ;
• en JavaScript : le module nodejs coap, https://github.com/mcollina/node-coap.

Grâce à des bibliothèques de ce type, il est alors tout à fait envisageable de développer des applications web pour piloter et interroger des objets à travers Internet.

Vous voilà donc prêts pour développer avec RIOT des objets connectés utilisant les protocoles standards de l'IoT.

Conclusion

Cet article vous a présenté le principe et la mise en place avec RIOT d'un réseau basé sur la pile 802.15.4/6LowPAN/IPv6/CoAP pour le faire communiquer avec Internet. Cependant, il reste encore quelques étapes avant d'avoir un réseau d'objets connectés parfaitement fonctionnel et facile à déployer. Par exemple, avec les instructions données ici, le client doit connaître l'adresse IP des nœuds pour savoir à qui envoyer une requête CoAP. Le groupe de travail CoRE a fait une proposition dans ce sens avec [PubSub], mais cela nécessite un peu de travail supplémentaire pour la mettre en œuvre.

Nous n'avons également pas parlé des aspects liés à la sécurité lors des échanges de données entre nœuds et clients. En effet, tous les messages transitent « en clair » par radio... Pour limiter le risque d'écoute, le projet Eclipse développe une implémentation du protocole DTLS adaptée aux systèmes fortement contraints [TinyDTLS]. Un portage de cette bibliothèque est actuellement en cours [PR5395] et sera disponible dans la prochaine version de RIOT qui sortira en juillet (2016.07).

Enfin, pour échanger des informations avec un objet connecté, d'autres protocoles applicatifs existent et commencent à être considérés par la communauté en vue d'être intégrés prochainement dans RIOT. Citons par exemple [MQTT] utilisé depuis de nombreuses années et assez répandu et [IoTivity], un projet plus récent qui semble prometteur, et beaucoup d'autres architectures liant les objets IoT et le Cloud (comme Node-Red...).

Remerciements

Je tiens à remercier Cédric Adjih, chercheur chez Inria, ainsi que Francisco Acosta et José Alamos, ingénieurs chez Inria pour leurs conseils éclairés et pour le temps qu'ils ont pu me consacrer pour relire (et corriger) cet article.

Bibliographie

[RIOT] http://riot-os.org/

[Contiki] http://www.contiki-os.org/

[Zephyr] https://www.zephyrproject.org/

[Low power] http://www.silabs.com/Support%20Documents/TechnicalDocs/low-power-32-bit-microcontroller-dtm.pdf

[802.15.4] https://tools.ietf.org/html/rfc6282

[6LowPAN] https://tools.ietf.org/html/rfc6282

[RPL] https://tools.ietf.org/html/rfc6550

[CoAP] http://tools.ietf.org/html/rfc7252#section-8

[RFC4291] https://tools.ietf.org/html/rfc4291

[RFC2460] https://tools.ietf.org/html/rfc2460

[RFC3306] https://tools.ietf.org/html/rfc3306

[RFC3307] https://tools.ietf.org/html/rfc3307

[RFC3849] https://www.ietf.org/rfc/rfc3849.txt

[RFC 5952] https://tools.ietf.org/html/rfc5952

[RFC4861] https://tools.ietf.org/html/rfc4861

[PR5291] https://github.com/RIOT-OS/RIOT/pull/5291

[PR4562] https://github.com/RIOT-OS/RIOT/pull/4562

[microcoap] https://github.com/1248/microcoap

[libcoap] https://libcoap.net/doc/install.html

[PubSub] https://tools.ietf.org/html/draft-koster-core-coap-pubsub-01

[TinyDTLS] https://projects.eclipse.org/projects/iot.tinydtls

[PR5395] https://github.com/RIOT-OS/RIOT/pull/5395

[MQTT] http://mqtt.org/

[IoTivity] https://www.iotivity.org/