À propos des groupes Multicast

Le multicast est une fonctionnalité cruciale pour la transmission en downlink ; il permet d'envoyer la même trame de downlink à de nombreux Capteurs en même temps. Ceci est particulièrement intéressant pour les capteurs de classe B et de classe C agissant comme actionneurs, où le serveur d'application peut contrôler de nombreux Capteurs en envoyant une seule trame de downlink (par exemple, allumer/éteindre des lampadaires ou des compteurs de gaz, etc.).

La fonction multicast optimise considérablement la capacité downlink et évite la surcharge des ressources de l'interface aérienne pour de nombreux cas d'utilisation de classes B/C. De plus, le multicast est une fonctionnalité obligatoire pour supporter la Mise à jour de Firmware Over the Air (également connue sous le nom de FUOTA).

Fonctionnement du multicast

Pour supporter le multicast, un capteur doit être configuré avec une DevAddr multicast, une NwkSKey multicast et une AppSKey multicast en plus de sa DevAddr unicast/clefs de session.

Alors que les DevAddr/session keys unicast sont distincts pour chaque capteur, les DevAddr/session keys multicast doivent être les mêmes pour tous les capteurs appartenant au même groupe multicast. Par conséquent, un groupe multicast se compose d'un capteur "virtuel" avec un DevAddr, NwkSKey et AppSKey.

Les capteurs doivent surveiller à la fois les adresses unicast et multicast.

Il existe deux manières de configurer les capteurs avec les DevAddr/session keys du groupe multicast :

1. Soit via une configuration personnalisée intégrée dans la pile du capteur qui est analogue à l'utilisation du mode ABP pour le multicast, même si le capteur utilise le mode OTA pour l'unicast.

2. Ou en utilisant une configuration par liaison radio via des messages de configuration de couche d'application, comme serait spécifié par la LoRa Alliance.

Du point de vue de ThingPark, le network server ne connaît pas la correspondance entre le capteur multicast « virtuel » et les capteurs « réels » qui y sont associés. La figure suivante illustre le flux de transmission downlink de bout en bout :

Pour supporter le multicast, les capteurs doivent utiliser soit le mode classe B soit le mode classe C. Les Capteurs natifs de classe A peuvent encore utiliser le multicast s'ils sont configurés au niveau applicatif pour passer en classe B ou C pendant la période de planification de la session multicast. Pour plus de détails, voir la Spécification de configuration du Multicast à distance LoRaWAN® v1.0.0.

Transmission de paquets en liaison descendante en mode multicast

Comme spécifié par LoRaWAN®, les trames multicast en downlink utilisent le mode « non confirmé » et n’incluent aucune commande MAC.

• Session multicast de classe B : pour le multicast de classe B, les capteurs écoutent l’adresse multicast sur des pingslots spécifiques qui ne sont pas nécessairement les mêmes que les slots de ping unicast. La périodicité du pingslot multicast est directement provisionnée dans le groupe multicast, ainsi que le débit de données et la fréquence de canal du pingslot multicast.

  Étant donné que le fonctionnement en classe B implique que les passerelles sont parfaitement synchronisées par GPS, une trame multicast en downlink peut être transmise de manière synchronisée sur toutes les passerelles sans aucun risque de collision, en tirant parti de l’effet d’interférence constructive qui est déjà le cas pour la transmission synchronisée des signaux beacon.

  note

  Si la passerelle ne peut pas transmettre la trame multicast sur le pingslot programmé, elle réessaie automatiquement la transmission sur les pingslots disponibles restants pendant les périodes de beacon en cours et suivante (comme en mode unicast) avant d’envoyer une indication d’échec au network server.

• Session multicast de classe C : pour le multicast de classe C, les capteurs doivent utiliser le même débit de données RX2 et la même fréquence pour les modes unicast et multicast. La fréquence et le débit de données multicast sont configurés dans le groupe multicast.

  Pour éviter les collisions radio entre les différentes passerelles participant à la même session multicast, le network server applique l’algorithme d’évitement de collision illustré par la figure suivante :

  

• Pour toutes les passerelles synchronisées par GPS (passerelles vertes dans la figure ci-dessus) : le network server planifie une transmission simultanée comme pour les capteurs de classe B ⇒ des transmissions parfaitement synchronisées (avec une précision de +/- 1 μs) réduisent le risque de collision.

• Pour les autres passerelles (non synchronisées par GPS), le network server utilise un algorithme de clustering pour regrouper dans le même cluster les passerelles suffisamment éloignées, tandis que les passerelles voisines sont placées dans des clusters différents. La distance minimale requise entre deux passerelles pour partager le même cluster est définie comme « Class C Collision Avoidance Distance » et est fixée par défaut à 7 km.

  Le network server planifie la transmission multicast de manière séquentielle pour chaque cluster : toutes les passerelles d’un même cluster transmettent leurs trames multicast en downlink en même temps (l’interférence est atténuée par la distance séparant ces passerelles), tandis que les transmissions multicast de clusters distincts ne se chevauchent pas dans le temps afin d’éviter les collisions. Ce cas est illustré par les passerelles orange dans la figure ci-dessus.

  note

  Si l’emplacement de la passerelle n’est pas provisionné dans ThingPark (passerelles bleues dans la figure ci-dessus), le network server considère chaque passerelle comme un cluster distinct.

Si la première transmission planifiée par le network server échoue pour certaines passerelles (éventuellement après que la passerelle a réessayé de manière autonome la transmission avant d’abandonner), le network server doit réessayer la transmission de la trame multicast jusqu’à ce que le nombre maximal de tentatives soit atteint (fixé par défaut à 3 tentatives).

La figure suivante illustre le schéma de retransmission utilisé par le network server pour les trames multicast :

Rapports récapitulatifs multicast

Le network server signale l’état de transmission de chaque trame multicast au serveur d’applications, sous forme de rapports récapitulatifs multicast. Pour en savoir plus, voir Référence d’API : LRC vers AS.

L’état de transmission des paquets multicast est également affiché dans le dashboard du groupe multicast, avec la légende de couleurs suivante :

Saisir	État du downlink	Type de rapport	Pourcentage de transmissions downlink réussies
	En cours	Partiel	≥ 80%
	En cours	Partiel	≥ 30 % et < 80 %
	En cours	Partiel	< 30 %
	Terminé	Finals?	100%
	Terminé	Finals?	≥ 80%
	Terminé	Finals?	≥ 30 % et < 80 %
	Terminé	Finals?	< 30% Remarque Un downlink partiellement envoyé (< 30%) est pris en compte si aucune passerelle n’était associée au groupe multicast au moment où le downlink multicast a été transmis.