La montre connectée est aujourd'hui très utilisée par les sportifs pour suivre par exemple leurs données cardiaques (nombre de pulsations, tension, etc) pendant un effort ou pour compter le nombre de pas effectués au cours d'une journée.

Comment ces données sont-elles échangées entre la montre et Internet? Quels protocoles sont utilisés? Quelles sont les contraintes à respecter?

Sur ce genre d'application de l'Internet des Objets, les informations acquises par les capteurs présents sur la montre sont directement envoyées par radio, en utilisant une connexion Bluetooth Low Energy (aussi appelée Bluetooth LE ou encore BLE), à un smartphone, le terminal mobile de l'utilisateur. Toutes ces informations sont ensuite consultables directement sur le terminal mobile via une application dédiée et/ou depuis un site sur le web via un ordinateur. Dans ce second cas, les données sont envoyées par le terminal vers une plateforme IoT en passant par sa connexion Internet : cette connexion à Internet s'effectue alors en utilisant un réseau d'opérateur (3G, 4G et bientôt 5G) ou un réseau local WiFi. Les protocoles utilisés pour communiquer ces données vers les plateformes IoT sont en général dépendant des applications : il n'existe pas vraiment de standard pour cette partie de la chaîne.

La montre connectée étant destinée à un public large, elle doit pouvoir être facilement utilisable avec les terminaux que les potentiels utilisateurs utilisent déjà et donc utiliser un protocole radio et des applications compatibles entre la montre et le terminal mobile. Depuis plusieurs années, tout smartphone dispose nativement de la technologie BLE pour communiquer avec d'autres terminaux ou objets. C'est donc ce moyen de communication qui est utilisé. Pour plus d'informations sur les spécifications du protocole BLE, voir https://www.bluetooth.com/

Pour simplifier, il faut retenir que le Bluetooth LE fonctionne dans la bande ISM des 2.4GHz. Puis au-dessus de ce support de communication physique, le protocole spécifie des profils d'accès pour garantir l'interopérabilité des différentes classes d'objets. L'ensemble de ces profils est défini dans le Generic Access Profile de la couche physique jusqu'au Generic Profile Attribute (ou GATT).

Source: https://www.bluetooth.com/specifications/bluetooth-core-specification, Vol 0, Section 6

Plus précisément, la spécification BLE décrit un ensemble de profils/services GATT destinés à assurer l'interopérabilité entre les objets (dans notre cas, la montre et le smartphone). Un profil GATT introduit la notion de client et de serveur et les actions possibles entre le client et le serveur : consultation (lecture), modification, notification. Pour recevoir/accéder à des données, un client (le smartphone) établit une connexion avec le serveur (la montre).

Pour information, tous les profils et services GATT décrits dans la spécification BLE sont listés sur cette page: https://www.bluetooth.com/specifications/gatt/.

Par exemple, pour échanger des données liées à la fréquence cardiaque, le profil GATT correspondant est HRP (Heart Rate Profile).

Enfin, les données exposées par le serveur sont appelées attributes. Un attribute est soit un service (listé au même endroit que les profils GATT) soit une caractéristique. Chaque caractéristique contient la description, la valeur (unique) et des descripteurs pour qualifier la valeur.

Dans notre exemple, la fréquence cardiaque sera exposée avec la caractéristique Heart Rate Measurement (code 0x2A37).

La liste des caractéristiques est décrite sur cette page : https://www.bluetooth.com/specifications/gatt/characteristics/

Grâce à ce fonctionnement, toute application fonctionnant sur le smartphone et destinée à afficher la fréquence cardiaque d'un capteur BLE sera en mesure de traiter les données obtenues depuis la montre connectée via BLE, car celle-ci implémente le profil compatible GATT HRP contenant une caractéristique de type Heart Rate Measurement.

Autres ressources de documentation pour BLE : https://blog.groupe-sii.com/le-ble-bluetooth-low-energy/

La montre possédant généralement un écran et une interface ergonomique pour son utilisation primaire (à savoir donner l'heure), il n'est pas vraiment possible d'obtenir une consommation aussi basse que pour d'autres classes d'objets plus autonomes mais on peut raisonnablement penser qu'une autonomie d'au moins 24h jusqu'à plusieurs jours est courante. Dans tous les cas, l'utilisateur de la montre la manipule suffisamment régulièrement pour pouvoir la recharger au besoin.

Pouvoir contrôler le taux d'humidité du sol dans un jardin ou, à plus grande échelle, sur une exploitation agricole est un cas d'utilisation classique des objets connectés. Dans ce cas d'usage, les données remontées par les capteurs vont pouvoir être utilisées pour simplement remonter une alerte en cas de sécheresse et/ou actionner des systèmes d'arrosage automatique. Les données étant disponibles en temps réel, ce genre de système peut ainsi être utilisé pour optimiser l'arrosage de certaines cultures (par goutte à goutte) et donc réaliser des économies à la fois au niveau financier, qu'au niveau de la ressource en eau qui peut parfois être très limitée selon les régions (exemple: sécheresse dans la vallée centrale en Californie).

Plusieurs questions se posent pour déployer ce genre de système : comment faire pour remonter ces données depuis des zones éloignées, c'est-à-dire sur de grandes distances ? Quels sont les protocoles utilisés ? Quels sont les contraintes que l'objet doit respecter pour ce genre de système ?

Pour ce genre d'application, la tendance actuelle est à l'utilisation de technologies cellulaires où l'objet communique avec une ou plusieurs passerelles elles-même connectées à Internet. La communication entre l'objet et les passerelles s'effectue sur des bandes de fréquences permettant l'envoi de données sur une longue distance allant jusqu'à plusieurs kilomètres. Dans les réseaux cellulaires, on trouve 2 cas de figures:

Quand la bande de fréquence appartient à un opérateur : dans ce cas, l'émission de signal ne peut se faire qu'en respectant le protocole de communication pour lequel la bande est destinée et avec un accord commercial avec l'opérateur. C'est le même principe que celui de la téléphonie mobile. La bande des 900MHz, initialement allouée pour le GSM (la 2G) et aujourd'hui de moins en moins utilisée par la téléphonie, trouve dans l'Internet des Objets un nouveau domaine d'utilisation. Le protocole NB-IoT (Narrow Band IoT) réutilise cette bande partagée entre plusieurs opérateurs pour permettre de transmettre des données IoT moyennant un abonnement.

Quand la bande de fréquence est ouverte : c'est le cas de la bande ISM qui peut être utilisée par n'importe qui, moyennant certaines restrictions définies par un organisme public de régulation. En Europe, cet organisme s'appelle l'ETSI (European Telecommunications Standards Institute). Pour l'Europe, les bandes ISM généralement utilisées pour les applications liées à l'agriculture connectée sont les bandes des 433MHz et des 868MHz. Pour pouvoir émettre sur ces bandes de fréquences, il faut respecter 2 contraintes définies par l'ETSI et qui varient selon les bandes (et sous-bandes) utilisées :

• la puissance d'émission ne doit pas dépasser un certain seuil,
• la durée d'émission par heure, aussi appelée duty cycle, doit rester inférieure à un seuil. Cette limite est exprimée en % d'une heure.

Deux principales technologies cellulaires utilisent ces bandes ISM pour transmettre les données IoT : SigFox et LoRaWAN.

Dans tous les cas, l'objet communique par radiofréquences avec une station de base (ou passerelle), sur une bande de fréquence donnée et en utilisant un protocole de communication lié à la technologie utilisée. Ensuite, la station de base relaie les données à un serveur de l'opérateur à qui elle appartient. La communication entre la station de base et le serveur utilise les protocoles de communication classiques de l'internet (réseaux IP). Enfin, ce serveur se charge d'envoyer les données à son destinataire via un protocole applicatif prédéfini. Ce protocole garantit en général une certaine confidentialité des données et un accès facile à ces données (par exemple comme pour le web via HTTP, mais il existe de nombreux autres protocoles que nous ne détaillerons pas ici, comme MQTT).

Au niveau applicatif, pour ce genre de réseau, il n'y a pas de spécification particulière pour le formatage des données et donc pas de compatibilité entre 2 applications différentes sauf si elles connaissent a priori le format des données générées par l'objet.

Un réseau LoRaWAN est un réseau cellulaire fonctionnant sur les bandes ISM 433MHz ou 868MHz en Europe. Toujours en Europe, sur ces bandes, le duty cycle est en général de 1% mais il peut être supérieur ou inférieur sur certaines sous-bandes et la puissance d'émission ne peut pas dépasser 14dBm pour le 868MHz ou 20dBm pour le 433MHz. La technologie radio (définissant la modulation et le codage de l'information) utilisée pour communiquer entre les objets/capteurs et les stations de base s'appelle LoRa (pour Long Range) et permet d'envoyer de petites données avec des débits très faibles allant de 292 bits par seconde à 50 kilobits par seconde. Le protocole LoRaWAN définit ensuite des spécifications au-dessus de la technologie LoRa pour connecter un objet à un réseau cellulaire et lui permettre d'envoyer et de recevoir des données.

• Les objets qui communiquent en LoRa avec des stations de base ou passerelles.
• Les passerelles qui sont connectées par le réseau classique Internet à un serveur de réseau. Ce serveur se trouve dans le cloud et est géré par l'opérateur du réseau LoRaWAN.
• Les applications sont enfin branchées au serveur de réseau et permettent aux utilisateurs d'accéder aux données, soit via le web, soit via d'autres protocoles applicatifs comme MQTT.

Dans un réseau LoRaWAN, on programme sur l'objet une liste d'identifiants et de clés pour lui permettre de s'authentifier auprès du serveur du réseau. Cet aspect est important pour permettre au serveur de réseau de déterminer si un objet appartient bien à une application gérée par l'opérateur du réseau. Toute donnée reçue par le serveur et n'appartenant pas à une application par l'opérateur sera simplement rejetée.

Quelques mots sur l'opérateur du réseau : il en existe un grand nombre donc on ne les listera pas tous ici. Par exemple en France, certains opérateurs comme Orange ou Objenious (Bouygues Télécom) sont des sous-entités de grands opérateurs de téléphonie mobile. Ils proposent donc une couverture quasi complète du territoire et une facturation soit au nombre d'objets, soit au nombre de messages. Pour débuter, il est parfois plus simple d'utiliser des opérateurs dont l'accès au réseau est ouvert, comme Loriot ou The Things Network. Pour ce type d'opérateur, la couverture est assurée par des bénévoles déployant leurs propres gateways. La continuité de service n'est donc pas assurée. Cela dit, l'accès au réseau est gratuit et beaucoup moins restrictif en terme de nombre de messages et d'objets.

Dans un réseau LoRaWAN, on rencontre 3 classes d'objets:

• Les objets de classe A sont les objets ayant la consommation d'énergie la plus faible. En effet, ils passent la plupart du temps dans un état endormi, avec une consommation d'énergie quasi nulle, et se réveillent périodiquement pour envoyer une donnée. Après l'envoi de la donnée (on parle d'uplink), ils ouvrent 2 fenêtres d'écoute pour recevoir du serveur de réseau d'éventuelles données (on parle dans ce cas de downlink). Cette classe d'objets a une latence très élevée du fait qu'ils ne peuvent recevoir une donnée qu'après un envoi. Leur avantage reste leur niveau de consommation et ils sont particulièrement adaptés aux systèmes de contrôle déployés dans des zones éloignées et vastes.

• Les objets de classe B ouvrent périodiquement des fenêtres d'écoute et sont donc joignables plus souvent par le serveur de réseau. Cependant, ils consomment plus d'énergie puisqu'ils se réveillent plus régulièrement.

• Les objets de classe C sont tout le temps réveillés et lorsqu'ils n'émettent pas de données, ils restent en écoute d'éventuels messages envoyés par le serveur de réseau. Leur avantage est qu'ils offrent une très faible latence : un message envoyé par le serveur sera reçu immédiatement par l'objet, par contre, ils consomment énormément d'énergie, ce qui empêche leur utilisation pour une application où les objets fonctionnent sur batterie.

On l'aura compris, pour une application d'agriculture connectée comme présentée ici, seul un objet de classe A pourra être utilisé : en effet, il est important de pouvoir déployer l'objet et d'être certain que son autonomie sera maximale.

De nos jours, certains microcontrôleurs consomment environ 1 micro ampère en mode de fonctionnement minimal. Alimentés avec de petites batterie de 2000mAh, cela leur garantit une autonomie de plusieurs dizaines d'années!

Les objets connectés peuvent aussi être utilisés pour améliorer le suivi et le contrôle d'une maison ou d'un bâtiment. L'objectif peut être d'optimiser leur consommation énergétique en mesurant précisément la température en plusieurs points du bâtiment pour mieux contrôler le chauffage (ou la climatisation), de prévoir l'usure et donc la maintenance de certains équipements (on parle ici de maintenance prédictive dans l'industrie 4.0) ou encore d'améliorer la qualité de l'air en activant le système de ventilation si besoin. Et cette liste est bien loin d'être exhaustive!

Cependant, dans un bâtiment existant, il est trop coûteux de devoir tirer de nouveaux câbles pour installer ces nouveaux capteurs. C'est pour cela qu'on privilégie les solutions utilisant des technologies de communication par radiofréquence de courte portée avec des capteurs fonctionnant sur batterie : ce genre de capteurs peut alors être déployé n'importe où dans le bâtiment, dans les couloirs, dans les bureaux, dans les salles techniques, etc.

Le réseau de capteurs remonte les mesures des différents capteurs vers le système de gestion technique du bâtiment ou une application dans le Cloud. De là sont commandées les parties fonctionnelles du bâtiment : chaufferie, ventilation, éclairage. Un système d'alerte peut aussi être déclenché si une maintenance est nécessaire.

Comment fonctionne un réseau de capteurs? Comment le connecter au système de gestion technique d'un bâtiment?

Le but d'un réseau de capteurs est de compenser:

• L'absence d'infrastructure (pas de réseau filaire);
• La courte portée radio en utilisant chaque capteur du réseau comme relais (on parle aussi de noeud ou de routeur).

De cette manière, il est alors possible de transporter une information sur une distance plus grande que la portée radio d'un seul capteur en effectuant plusieurs sauts. Ce genre de réseau est également appelé réseau mesh.

Il suffit ensuite de placer une passerelle (aussi appelée noeud puits) suffisamment proche du réseau pour router les données du réseau vers le réseau interne du bâtiment voire même directement vers Internet.

Les données, une fois sur le réseau interne du bâtiment/Internet, peuvent transiter jusqu'à des serveurs applicatifs, un utilisateur ou un système de gestion technique de bâtiment et ainsi servir à prendre une décision : par exemple, démarrer le système de ventilation si la qualité de l'air dépasse un certain seuil.

Pour ce type d'installation, l'utilisation de la bande ISM 2.4GHz offre les meilleurs débits et une portée maximum d'environ 100 mètres.

Il existe plusieurs solutions de réseau de capteurs de type mesh fonctionnant dans cette bande comme par exemple BLE mesh, WiFi ou le 802.15.4.

La norme 802.15.4 a d'ailleurs été développée spécifiquement pour ce cas d'utilisation et a été standardisé par l'IETF (Internet Enginnering Task Force) pour les réseaux de capteurs à basse consommation.

C'est pourquoi nous nous intéresserons ici à ce protocole : il est tout à fait adapté à une utilisation pour un bâtiment intelligent.

Pour plus de détails sur 802.15.4, voir https://fr.wikipedia.org/wiki/IEEE_802.15.4.

Comme nous le verrons plus en détail dans le module 4 de ce Mooc, les réseaux 802.15.4 fonctionnent sur le même principe que les réseaux IP avec un modèle en couches. Certaines de ces couches ont dû être adaptées pour pouvoir être utilisable avec des capteurs très contraints (contraints = très peu de mémoire, quelques dizaines de kilooctets).

Au-dessus de la couche radio 802.15.4, on aura :

• Une couche d'adressage pour attribuer une addresse IP (plus précisément IPv6) aux capteurs;
• Une couche de routage pour le multi-sauts;
• Une couche de transport;
• Une couche applicative.

Toutes ces couches s'appuient sur des protocoles adaptés aux réseaux de capteurs utilisant des objets très contraints, c'est-à-dire disposant de capacités de calcul très limitées (de l'ordre de quelques dizaines de MHz), de mémoires très faibles (quelques kilos octets) et consommant très peu d'énergie. L'avantage du modèle en couches est qu'il rend le réseau de capteurs interopérable avec les réseaux informatiques conventionnels : un capteur peut communiquer directement avec un serveur et vice-versa. En utilisant le même protocole applicatif, il est donc possible de faire remonter des données des capteurs jusqu'aux équipements qui gèrent le bâtiment.

Dans un réseau 802.15.4, les capteurs restent en mode endormi la plupart du temps, la latence de ce type de réseau est donc importante. Même si cela engendre des contraintes de routage fortes - la topologie du réseau devant se réadapter en fonction de l'état d'éveil des capteurs - l'autonomie globale des capteurs peut aller jusqu'à plusieurs années.