Quelle Qualité de Service (QOS) pour Smilio Action en Sigfox et LoRaWAN ?

Jérôme Chambard
28/05/2019 17:43

En fonction de vos cas d'usage, il sera nécessaire d'adopter la stratégie la plus adaptée pour assurer la meilleure qualité de service possible.

Smilio Action offre des possibilités infinies pour régler cette qualité de service, et il est important d'avoir une vue d'ensemble pour choisir la meilleure configuration. Cette configuration pourra être appliquée à distance, via l'API Skiply, ou via un downlink direct chez l'opérateur. Les détails des paramètres indiqués ci-dessous sont disponibles dans la documentation intégrateur.

Si vous avez des exigences QoS particulières, nous pouvons implémenter des mécanismes additionnels sur demande (adaptation du firmware).

Au niveau radio

Sigfox

Avec Sigfox, le protocole impose de répéter 3 fois les trames. Il n'est pas possible de changer ce fonctionnement. On travaillera donc essentiellement au niveau applicatif (voir plus bas).

LoRaWAN

Nombre de répétitions et SF

 Le protocole LoRaWAN permet de moduler plusieurs paramètres, notamment le nombre de répétitions (nbrep) et le spreading factor (SF). Il existe 3 façons de gérer ces paramètres :

  1. Via l'ADR : c'est alors le network server qui va envoyer automatiquement au device sa configuration (si vous êtes chez un opérateur public type Objenious ou Orange, vous pouvez lui déléguer cette gestion), en fonction de paramètres de réception comme le SNR ou le RSSI.
  2. Manuellement par commande MAC : vous imposer les paramètres, par le réseau au device (uniquement pour les réseaux privés).
  3. Manuellement via la configuration du device (voir le manuel pour les détails)

Smilio Action est compatible avec toutes ces méthodes.

 Trames confirmées

Il est également possible de demander au device d'émettre une trame jusqu'à ce qu'il ait reçu la confirmation du réseau, et ce jusqu'à X fois. Cette configuration est la plus efficace, tant en terme énergétique qu'en terme de QoS.

Cependant, dans la majorité des cas d'usage, elle est inadaptée aux réseaux publics. En effet, les gateways des opérateurs doivent respecter un Duty Cycle de 10% de temps dans l'air. Elles ne peuvent donc pas envoyer un DL (downlink) par message, sous peine de rapidement saturer leur temps dans l'air. Pour des devices n'envoyant pas plus de quelques messages par jour (max. 4), celà reste une solution envisageable sur tout type de réseau.

Dans les 2 cas (Sigfox et LoRaWAN), le device envoie un numéro de séquence qui permet de savoir si des trames ont été manquées entre deux émissions reçues.

Au niveau applicatif

Running mode normal

 En mode normal, les devices Skiply envoient des états de registres, et non des comptages remis à zéro à chaque envoi. Ainsi, même si une trame est manquée lors d'un envoi, le calcul des incréments lors de l'envoi suivant permettra de ne pas perdre le nombre d'appuis effectués (le serveur calcule la différence entre 2 états des registres). Couplé à des envois périodiques, il est ainsi possible d'assurer une qualité de service correcte sans avoir recours à des trames confirmées.

Il est également possible de combiner des envois immédiats avec des envois périodiques systématiques ou sur changement d'état. Il est à noter que l'API n'enverra pas de doublon, elle gère nativement cette redondance.

Running mode code (confirmation du contenu précédent)

 Le running mode code permet également de gérer des appuis en envoi immédiat. Chaque trame contient les boutons pressés à l'instant t, mais aussi le contenu et la date du précédent appui, ce qui permet de reconstituer l'historique des données en cas de trame manquée.

 Confirmation visuelle

 Un mode spécial permet de notifier à l'utilisateur si sa trame a été reçue par le réseau ou pas, à l'aide de 3 leds en façade (reçu = vert fixe 3 secondes, rouge = non reçu). Cette solution implique les mêmes inconvénients que les trames confirmés, mais fonctionne à la fois sur Sigfox et LoRaWAN.

Moyenne des notes : 4 (1 Vote)

Vous pouvez commenter cet article