Écran de saisie d'un point de mesure dans l'application web utilisée pendant une étude de couverture

Réseau

Étude de couverture LoRaWAN : mesurer avant d'installer

La question revient à chaque premier rendez-vous : est-ce que le LoRaWAN passe chez moi. Une brochure y répond par une portée en kilomètres, ce qui ne veut rien dire dans un bâtiment industriel. Nous préférons y répondre par une mesure faite sur votre site, avant qu'une seule gateway ne soit fixée au mur. Voici comment se déroule une étude de couverture, ce qu'elle relève, et ce qu'elle permet de décider.

Pierre Deswysen
Pierre Deswysen 7 min de lecture

Le motif : ce qu’on ne veut pas découvrir après coup

Une installation LoRaWAN se termine mal quand la question de la couverture arrive en dernier. Le réseau est en place, les devices sont posés, et celui qui se trouve au fond du site remonte mal, ou ne remonte pas du tout. À ce stade, la correction n’est plus une correction, c’est un chantier.

Déplacer une gateway n’est pourtant pas grand-chose en soi. Il lui faut un point d’alimentation et une arrivée internet, et quand elle est alimentée par le câble réseau lui-même, l’alimentation disparaît du problème. Ce qui coûte, c’est ce qu’il y a autour. Tirer cette arrivée internet jusqu’au nouvel emplacement peut vouloir dire traverser un hall entier. L’antenne doit être refixée, parfois en hauteur, parfois à l’extérieur. Autant y réfléchir avant plutôt que de le refaire une seconde fois.

Il existe des cas où cette réflexion se règle en une minute. Un atelier de taille modeste, quelques équipements à mesurer, tous dans une portée que l’expérience rend prévisible : l’étude apporte peu. Notre règle est simple. Dès que le site s’étend sur plusieurs bâtiments, dès qu’il faut descendre en sous-sol ou traverser des masses métalliques, dès qu’un point de mesure se trouve à une distance dont personne ne peut affirmer qu’elle passe, on mesure. Le doute décide, pas la surface.

Avant de se déplacer

Une étude commence sur écran, pas sur le terrain. Ce que nous demandons tient en quelques éléments : la nature du site, un plan quand il en existe un, les points où des mesures sont envisagées, et des photos des installations concernées. Le formulaire de projet du site sert précisément à ça, et l’échange qui suit permet de cadrer le reste.

Ces éléments ne remplacent pas la mesure, ils la préparent. Ils disent où placer la gateway pour le test, combien de points relever, et lesquels sont douteux. Un bâtiment en bardage métallique avec un sous-sol technique n’appelle pas le même parcours qu’un hall unique en maçonnerie. Il arrive aussi que ces photos suffisent à déplacer une question : un point de mesure prévu contre une paroi de chambre froide se traite mieux en le repérant avant de partir qu’en le découvrant sur place.

C’est également à ce moment qu’on vérifie que la question posée est la bonne. L’étude de couverture répond à « est-ce que le LoRaWAN passe ici ». Elle ne répond pas à « est-ce que le LoRaWAN est la bonne technologie pour ce que je veux mesurer », qui se tranche avant, et que deux autres articles de cette série traitent pour elle-même, l’un sur les grandes familles de réseaux IoT, l’autre sur le choix entre WiFi et LoRaWAN pour un capteur industriel.

Ce que l’étude mesure, et ce qu’elle ne mesure pas

Le principe tient en une phrase. On envoie des messages LoRaWAN depuis un device de test, en se déplaçant sur le site, et on regarde ce qui arrive à l’autre bout.

Chaque message reçu par une gateway est publié vers notre infrastructure, déchiffré, puis enregistré. Il ne porte pas seulement sa charge utile : il porte aussi la qualité avec laquelle il a été capté, sous la forme du RSSI et du SNR. Le premier dit à quel point le signal est fort, le second à quel point il est propre. Un signal peut être faible et parfaitement lisible, fort et pourtant noyé. Ce que la structure d’un bâtiment fait subir à une liaison est décrit dans l’article sur le fonctionnement du LoRaWAN. Ces deux valeurs sont la matière première de l’étude, et leur lecture fine fait l’objet de l’article consacré au device.

Le contenu du message, lui, n’a aucune importance. Ce qui compte est qu’il soit parti, et ce qu’il vaut à l’arrivée.

Reste une limite qu’il faut énoncer, parce que c’est elle qui dicte toute la méthode. Le message enregistré dit par quelle gateway il a été reçu et dans quel état, il ne dit pas où se trouvait celui qui l’a émis. Le réseau ne géolocalise pas les devices. Une série de mesures sans annotation ne produit donc rien d’exploitable : on obtient une liste de qualités de réception sans savoir à quel endroit du site chacune correspond. C’est exactement le trou que l’application comble.

Ce qu’il faut avoir sous la main

Un device de test LoRaWAN, d’abord. Un émetteur qu’on déclenche à la main, qui envoie un message et rien de plus.

Une gateway ensuite, opérationnelle, raccordée à internet et enregistrée sur notre infrastructure. Sans elle, les messages partent et personne ne les entend. Cette gateway fait partie du Pack Activation : un client qui l’a commandé reçoit tout ce qu’il faut, il lui reste à la brancher. Quand c’est nous qui réalisons l’étude, nous arrivons avec la nôtre, raccordée soit au réseau Ethernet du site, soit à un modem 4G quand aucune prise réseau n’est disponible à l’endroit voulu. Le placement et le raccordement de cette gateway sont un sujet en soi, traités dans l’article qui lui est consacré.

Qualité de réception relevée aux emplacements d'un site, du plus proche de la gateway au plus éloigné
Schéma explicatif. Un point plus éloigné peut mieux passer qu'un point proche masqué par une masse métallique, et c'est là que se décide le nombre de gateways. Les valeurs sont illustratives, ce n'est pas l'extrait d'un rapport.

Le déroulé, point par point

Le premier point enregistré est l’emplacement de la gateway elle-même. Tout le reste se lit par rapport à lui.

Viennent ensuite les points de mesure. Une quinzaine par défaut, davantage sur un site étendu, moins sur un bâtiment unique. Le nombre suit la taille et la complexité, pas un gabarit.

Pour chaque point, la manœuvre est toujours la même. On nomme l’emplacement en clair, avec le mot que les gens du site emploient : atelier, quai, chaufferie, local compresseurs. On note la différence de hauteur par rapport à la gateway, en positif si on se trouve au-dessus d’elle, en négatif si on est en dessous, parce qu’un étage ou un sous-sol ne se voit pas sur un plan vu du dessus. On ajoute un commentaire quand quelque chose mérite d’être retenu : une cloison métallique, une porte de chambre froide, l’orientation de l’antenne. On valide le point, et on déclenche l’envoi depuis le device de test. Puis on se déplace au point suivant.

L’ordre compte : le point est validé d’abord, le message est envoyé ensuite. C’est ce qui permettra de rapprocher chacun de sa position.

En fin de parcours, l’application produit un export au format JSON. Dans le cas d’une étude menée par le client ou par un partenaire, c’est ce fichier qui nous revient.

L’application, et ce qu’elle sert à décider

Nous mettons une application web à disposition de nos clients pour cette étape. Elle s’ouvre dans le navigateur du téléphone, sans rien installer, ce qui évite de demander à un responsable technique d’aller chercher un logiciel sur son mobile professionnel pour une opération d’une matinée.

Ce qu’elle fait tient en peu de mots : elle attache un lieu, une hauteur, une remarque et un instant à chaque tir. Rien de plus, et c’est suffisant, parce que la qualité du signal, elle, est déjà enregistrée de l’autre côté.

Elle relève aussi la position, avec une réserve qu’il vaut mieux poser franchement. Ce relevé est fiable dehors, sur une cour, un parking, entre deux bâtiments. À l’intérieur d’un hall, sous une charpente métallique ou en sous-sol, il se dégrade et peut placer un point à côté de la réalité. Ce n’est pas gênant, parce que ce n’est pas lui qui fait foi. Ce qui fait foi est la dénomination saisie en clair : la machine du fond de l’atelier, le bureau, le quai de chargement. Ce sont les noms que le client emploie tous les jours et qu’il reconnaît sans avoir à interpréter une coordonnée.

Une fois le fichier reçu, nous rapprochons les deux moitiés. Un connecteur MCP relié à notre infrastructure récupère les messages LoRaWAN enregistrés pendant la période de l’étude, avec leur RSSI et leur SNR, et les croise avec les emplacements et les annotations relevés sur place. L’horodatage sert de clé.

Le résultat est un rapport qui permet de trancher, et c’est là son seul objectif. Il ne cherche pas à produire une carte de couverture au mètre près, ce qu’une quinzaine de points ne permet pas. Il donne, pour chaque emplacement relevé, ce que la liaison y vaut, et ce que ça implique. Sa forme la plus utile est souvent la plus simple : un tableau, une ligne par emplacement, sous le nom que le client lui donne. Sur un site étendu et à ciel ouvert, les points se reportent sur une vue de dessus. Dans un bâtiment, ils se reportent sur le plan quand il en existe un, et à défaut le tableau suffit, puisqu’il dit lequel des emplacements passe et à partir d’où ça décroche. Le signal tient jusqu’à l’extrémité du site : une gateway suffit, on sait où la poser définitivement. Le signal se dégrade franchement à mi-parcours : soit on la déplace vers un emplacement plus favorable, soit il en faut une seconde pour couvrir le reste. Cette décision-là se prend sur des mesures, avant que quoi que ce soit ne soit fixé au mur.

Qui la réalise

Deux configurations, selon le niveau d’accompagnement choisi.

Le client la mène lui-même, sur son site, avec le device de test et la gateway de son Pack Activation, pendant que nous suivons l’arrivée des messages depuis notre infrastructure et que nous restons joignables. Il connaît son bâtiment mieux que nous, il sait où sont les points de mesure prévus, et il voit en direct si un tir est bien remonté. C’est le mode le plus courant.

Ou nous nous déplaçons, seuls ou avec un partenaire installateur, avec notre propre matériel. C’est le choix des sites où personne n’a le temps de s’en occuper, et celui des configurations où l’on préfère avoir l’œil sur place.

Dans les deux cas, la mesure est la même et le rapport est le même. Ce qui change est qui tient le device.

Ce que ça évite

Une étude de couverture ne rend pas un réseau meilleur. Elle empêche seulement de construire sur une hypothèse. La différence entre les deux se voit rarement le jour de l’installation, elle se voit six mois plus tard, quand un device isolé se met à manquer des relevés et que personne ne sait dire si c’est le device, la gateway ou la distance.

C’est aussi la raison pour laquelle nous préférons répondre à la question « est-ce que ça passe chez vous » par un relevé fait sur votre site plutôt que par une portée annoncée dans une brochure. Une portée théorique est vraie en terrain dégagé, entre deux antennes qui se voient. Un site industriel n’est pas un terrain dégagé : il a des murs, des charpentes, des cuves, des machines qui tournent et des portes qui s’ouvrent.

Reste l’ordre des choses, sur lequel il vaut mieux être clair. L’étude de couverture n’est pas une prestation qu’on commande seule pour décider ensuite si on se lance. Le choix de la technologie se tranche avant elle, sur ce qu’il y a à mesurer et sur ce que le réseau doit transporter, et c’est le sujet des deux articles cités plus haut. L’étude vient après ce choix. Elle ne demande pas s’il faut un réseau LoRaWAN, elle dit combien de gateways il en faut et où les poser.

C’est pour cette raison que le device de test et la gateway font partie du Pack Activation, et non d’une prestation détachée. Nous ne vendons pas une étude, nous installons un réseau, et l’étude en est la première étape. Une matinée de marche dans le bâtiment avec un téléphone en main, avant qu’un seul support ne soit percé.

Si votre projet en est là, parlons-en.

Partager cet article

Partager sur LinkedIn