Comment choisir un protocole de communication pour son projet IoT ?

Les objets connectés sont de plus en plus nombreux, et répondent à des besoins extrêmement variés : smart cities (gestion de flotte, de trafic, …), Industrie 4.0 (maintenance prédictive, usine intelligente, …), santé (e-Health, télémédecine, …). Tous ces domaines sont accompagnés de contraintes et d’exigences très hétérogènes, et il est nécessaire de les prendre en compte dès le début de la vie d’un projet afin de s’assurer de faire de bons choix, sur lesquels il ne sera pas nécessaire de revenir.

Nous allons aujourd’hui nous consacrer à la partie « connectée » des objets constituant l’IoT. En effet, afin de faire remonter des informations ou bien d’être mis à jour et configurés à distance, ces dispositifs ont besoin d’intégrer des technologies de communication, le plus souvent sans fil. De nombreux buzzwords sont apparus ces dernières années pour désigner celles-ci : 0G, 5G, Bluetooth 5, etc.

Nous vous proposons ici de jeter un œil sur les réalités derrières ces mots, pour vous permettre d’orienter vos choix, et ainsi mieux faire la différence entre réalités techniques et effets d’annonce.

Trois facteurs guident généralement le choix d’un protocole de communication : la portée, le coût et le volume des données à transmettre. Nous aborderons donc cette problématique sous ces trois aspects.

Une fois la question de la distance de communication réglée, il faut s’intéresser à la quantité de données que votre objet va transmettre et/ou recevoir. En effet, toutes les technologies listées ci-dessus ne permettent pas de faire circuler de grands volumes de données.

Le volume de données transmissibles par une technologie donnée est en général fortement corrélé à la consommation d’énergie de celle-ci : communiquer un nombre de messages important nécessite plus d’énergie qu’un faible nombre de message. Si ce facteur est important pour votre application, il faudra le prendre en compte lors du choix d’une technologie.

En plus de la quantité de données transmissible, il faut également prendre en considération la latence de communication de celles-ci. En effet, en fonction des protocoles, elle peut aller de quelques millisecondes à quelques dizaines de secondes. Si votre application doit assurer la délivrance de message urgents, il faudra privilégier les technologies disposant de latences faibles.

Comme illustré dans le tableau précédent, la portée des protocoles et leur faculté à transmettre un volume de données important ne sont pas corrélés. Dans les protocoles courte portée, le WiFi est à privilégier lorsqu’il est nécessaire de transmettre des messages de taille conséquente (plusieurs dizaines ou centaines de méga et au-delà). Pour des tailles de données plus modérées, le Bluetooth ou les technologies basées sur le standard IEEE 802.15.4 peuvent être utilisés. Enfin, les protocoles de type ZWave ou EnOcean sont strictement à utiliser dans les cas d’application pour lesquels ils ont été conçus : l’envoi de courts messages pour des objets domotiques.

Pour les protocoles longue portée, si le volume de données à transmettre quotidiennement dépasse les quelques centaines de kilooctets, le Sigfox et le LoRa sont à proscrire. En effet, ces deux protocoles sont fortement limités en termes de débit, et les cas d’applications visés sont l’échange de courts messages de façon ponctuelle (quelques fois par jour). Additionnellement, la latence de ces protocoles peut atteindre plusieurs dizaines de seconde, ce qui les rend particulièrement peu appropriés dans les scénarios ou ce paramètre est important. Ceux-ci permettent néanmoins d’atteindre des autonomies très importantes dans les situations ou les objets n’ont que de faibles besoins de communication. Ces protocoles présentent également un autre inconvénient : si les communications depuis l’objet vers le réseau sont limitées, celles en sens inverse (communément appelées downlink) le sont encore plus. En effet, le protocole Sigfox limite par exemple le nombre de message à 140 en émission et 4 en réception. Cette limitation représente un frein considérable à l’utilisation de ces technologies pour les cas d’application dynamiques, ou les objets ont besoin d’être fréquemment reconfigurés à distance ou de recevoir des informations de votre part.

Les protocoles cellulaires « nouvelle génération » dédiés à l’IoT comme le NB-IoT ou le LTE-M permettent des débits faibles à moyens, les valeurs annoncées de débit pour le premier étant de quelques dizaines de kilobits par secondes et de plusieurs centaines de kilobits par seconde pour le second. La latence du NB-IoT reste néanmoins élevée (jusqu’à une dizaine de secondes). Ces protocoles sont particulièrement intéressants pour les applications IoT. En effet, le NB-IoT peut être mis en concurrence avec les réseaux 2G qui sont progressivement en train d’être démantelés, et qui ne constituent donc pas une solution technique viable pour l’avenir. Le LTE-M peut quant à lui être vu comme une alternative moins chère que le LTE classique si les débits nécessaires restent modérés.

Comme abordé en fin de partie précédente, le prix est un facteur qui peut se révéler déterminant pour l’intégration d’une technologie dans un objet connecté. La notion de coût est relativement large, et il faut bien distinguer trois types de charges différentes :

Le coût de développement : ceux-ci sont les premiers à devoir être assumés. En effet, le choix d’une technologie a un impact direct sur le temps nécessaire au développement de l’objet. En général, plus une technologie est répandue, moins les coûts de développement associés sont élevés. En revanche, les technologies plus confidentielles nécessitent souvent plus d’expertise et les charges pour leur intégration sont plus élevées. Pour certaines technologies, il est nécessaire d’acheter certaines licences ou droits d’adhésion aux alliances les gérant.
En plus des coûts liés au développement de l’électronique de votre projet, il faut également prendre en compte ceux liés à l’exploitation des données de celui-ci. Cela peut par exemple prendre la forme d’une application smartphone à développer ou bien de backend de centralisation et traitement de données. En fonction des technologies choisies, ces coûts peuvent être plus ou moins élevés (le développement d’applications mobiles est relativement standard, alors que la création d’edge gateway pour les protocoles basés sur le 802.15.4 l’est beaucoup moins).

Le coût d’exploitation : il ne faut pas imaginer qu’une fois les objets chez les particuliers ou déployés dans les environnements visés, les coûts s’arrêtent. En effet, certaines technologies reposent sur des infrastructures existantes (p. ex., réseaux cellulaires), et l’exploitation de vos objets vont entrainer des charges d’exploitation récurrentes. Généralement, les technologies de courte portée coûtent moins cher à exploiter : par exemple, le Bluetooth n’a seulement besoin que d’une application mobile avec laquelle interagir, alors que le LoRa doit reposer sur une infrastructure soit déployée par vos soins, soit exploitée par un opérateur réseau.
De nombreux opérateurs proposent des solutions pour la connexion à des réseaux cellulaires (Matooma, 1NCE pour les réseaux cellulaires classiques pour un faible volume de données, Orange en France pour le LTE-M, SFR pour le NB-IoT, Objenious pour le LoRa, etc.).

Avant d’envisager l’utilisation d’une technologie pour votre produit, il est nécessaire d’avoir conscience de toutes les implications de ce choix, aussi bien en termes de capacités sur la portée et le volume de données transférables que les coûts que cela implique. De plus, il faut également pouvoir faire la différence entre effet d’annonce des consortiums impliqués dans le développement de certains standards et réalités techniques. Un premier exemple peut se trouver dans le Bluetooth 5 : de nombreux articles mettant en avant une amélioration de la portée et du débit omettent souvent le fait que ces améliorations sont mutuellement exclusives (les applications longue portée auront nécessairement des débits faibles). Un second pourrait être les autonomies annoncées sur les protocoles tels que LoRa et Sigfox (certains constructeurs annoncent des autonomies supérieures à 10 ans), sans qu’on sache la fréquence des messages envoyés et reçus ou bien les capacités des batteries associées à ces tests.

Piwio peut vous aider à choisir le bon protocole pour votre application, en prenant à la fois en compte votre cahier des charges techniques, mais également les contraintes de vos cas d’application. N’hésitez pas à nous contacter ou à consulter nos offres, nous seront ravis de vous aider à réaliser votre projet !