1. Introduction Générale
SIGFOX est une technologie propriétaire créée par la société française éponyme fondée en 2009. Le réseau SIGFOX fait partie des réseaux LPWAN (Low Power Wide Area Network) au même titre que le LORAWAN basé sur la modulation LoRa.
Le réseau utilise les bandes de fréquences libres ISM (Industrial, Scientific and Medical frequency band). Par exemple, en Europe, elles correspondent à la bande 863-870 MHz. Chaque bande pour chaque région du monde est soumise à une réglementation qui lui est propre selon plusieurs critères : taux d'occupation de la bande, puissance d'émission, canaux réservés, écoute avant émission, etc.
Les réseaux LPWAN ont pour objectif de démocratiser la connexion des objets dans les domaines de l'industrie, la smart city, la maintenance prédictive. Tout capteur pouvant apporter de la donnée doit pouvoir être connecté à moindre coût tant sur l'aspect financier que sur l'aspect énergétique.
SIGFOX annonçait vouloir connecter des objets pour 1$.
2. Approche théorique
2.1 Les bandes ISM
Les bandes ISM sont des bandes libres (non licenciées) utilisées notamment par certains réseaux LPWAN tels que SIGFOX et le LoRaWAN.
Pour pouvoir occuper ces bandes, il est nécessaire de se soumettre à certaines normes. Ces dernières sont garantes de la viabilité des réseaux sur ces bandes. En effet, sans normalisation, il deviendrait difficile de garantir un minimum de réussite quant à la transmission des données.
En ne respectant pas les normes, les usagers de la bande s'exposent à une augmentation du nombre de collisions des données empêchant la bonne réception de celle-ci par les coeurs de réseau.
Pour le cas de l'Europe, la norme en vigueur est définie par l'ETSI (European Telecommunications Standards Institute) via la norme EN 300-220 notamment.
Ci-dessous une mise en forme graphique de cette norme concernant le taux d'occupation possible de la bande. On constate que celle-ci est découpée en plusieurs sous-bandes avec des restrictions qui leur sont propres.
Il est donc possible d'utiliser les différentes sous-bandes plus ou moins longtemps et à des puissances plus ou moins fortes. Par abus de langage, on définit un taux d'occupation possible de 1% sur une heure glissante soit 36s.
De la même façon, la puissance maximum pouvant être émise par tout objet communicant sur cette bande doit être inférieure ou égale à 14dBm (25mW).
2.2 Paramètres de Modulation
Le réseau SIGFOX est basé sur 2 principes fondamentaux : la modulation D-BPSK (Differential Binary Phase Shift Keying) et l'UNB (Ultra Narrow Band).
2.2.1 Principes
D-BPSK
Pour encoder des 0 et 1, la modulation de phase est utilisée tout comme pour le BPSK. La particularité du D-BPSK vient du fait que pour encoder un 0, un changement de phase intervient alors que ce n'est pas le cas pour encoder un 1.
Ultra Narrow Band
SIGFOX utilise 192kHz de la bande ISM. Chaque message occupe 100Hz ou 600Hz selon les zones géographiques, correspondant à des débits de 100bps ou 600bps.
2.2.2 Raisons du choix
1 . La modulation D-BPSK a été choisie pour les raisons suivantes :
- Facile à mettre en oeuvre
- Les modules radio permettant cette modulation sont peu coûteux
- Les récepteurs sur cette modulation ont une haute sensibilité radio
2. L'Ultra Narrow Band permet quant à lui :
- Avoir une bonne immunité aux interférences
- Du fait du faible étalement, d'éviter les collisions de données. Ceci en fait un protocole assez fiable.
On voit dans l'image ci-dessus, qu'avec un étalement faible, la probabilité d'avoir des collisions de données devient elle aussi faible.
Grâce à ce choix combiné à des débits faibles, on peut obtenir :
Il est naturel de vouloir comparer cette technologie à la modulation LoRa. La voici en quelques chiffres :
On constate que les bandes utilisées, les puissances à respecter et le bilan de liaison sont les mêmes (dans les faits SIGFOX a tendance à avoir une portée un peu plus élevée).
Les différences les plus notables résident au niveau des largeurs de bandes et des facteurs d'étalement ce qui implique un débit plus faible sur du SIGFOX.
Tout ceci n'est qu'un compromis entre durée de transmission/économie d'énergie et fiabilité de la transmission. LoRa permet ainsi d'avoir un débit plus rapide mais qui peut aller à l'encontre de l'assurance que le récepteur reçoive bien la donnée.
2.3 Protocole SIGFOX
Les spécifications du protocole SIGFOX ont été rendues publiques le 13 février 2019.
En les mettant dans le domaine public, SIGFOX a pour but de démocratiser sa solution dans le monde des objets connectés LPWAN.
Les spécifications sont accessibles sur le build SIGFOX à l'adresse suivante :
https://build.sigfox.com/sigfox-device-radio-specifications
2.3.1 Identification
Dans chaque module SIGFOX, le couple ID et PAC est primordial pour l'identification et le référencement d'un objet.
Chaque module (ou produit) possède un identifiant (ID) unique. Celui-ci est lié au PAC (Porting Authorization Code). Le PAC prouve l'identité du possesseur du module. Ce couple ID/PAC est obligatoirement fourni lors du provisionnement d'un module sur le portail SIGFOX. Sans ces identifiants, il est impossible de communiquer en SIGFOX.
Ces identifiants sont soit donnés par le fournisseur du produit, ou obtenus par interrogation du module SIGFOX.
2.3.2 Description Trames
On trouve 2 types de trames SIGFOX :
- Les Uplinks qui sont les trames envoyées du module vers le portail SIGFOX
- Les Downlinks qui sont les trames envoyées du coeur de réseau vers le module
Les Uplinks sont limités à 12 octets de données utiles soit au maximum une taille de paquet de 24 octets avec les données protocolaires.
En se basant sur un débit de 100 bits par secondes, on a une durée de transmission de l'ordre de 2s.
SIGFOX permet à l'utilisateur, pour chaque transmission, d'envoyer des salves de 3 paquets identiques afin de pallier au risque de perte de données.
Les uplinks sont transmis sur des fréquences de manière pseudo-aléatoire.
Les Downlinks quant à eux sont limités à 8 octets de données utiles. Ils suivent les mêmes règles que les uplinks.
SIGFOX offre différentes options sur ses abonnements conditionnant le nombre d'uplink et downlinks par jour.
On peut atteindre 140 uplinks/jour et 4 downlink/jour.
Ceci permet de toujours respecter la norme concernant le taux d'occupation (cf chapitre 2.1)
2.3.3 Sécurité Over-The-Air
SIGFOX a mis en place des mécanismes afin de permettre de sécuriser la donnée :
- Compteur de message pour parer aux attaques de ré-émission de messages
- Mise en place d'encryption AES128 pour l'authentification
- Code détecteur d'erreur CRC-16
La sécurité passe aussi par les bonnes pratiques à suivre lors de l'intégration d'un module SIGFOX comme l'ajout d'au moins un "secure element" tel qu'un STSAFE-A100 contenant les clés d'identification, l'établissement de bases de données sécurisées pour le stockage des clés d'identification (ID/PAC), ...
3. Réseau SIGFOX
SIGFOX base sa connectivité sur un réseau coopératif et mondial.
Il est intéressant de voir comment s’architecture ce réseau et quelle est la couverture du réseau SIGFOX à travers le monde.
3.1 Architecture
Le principe du réseau SIGFOX est la réception coopérative. Le message envoyé par un module est donc reçu par plusieurs stations de base qui le transmettent au coeur de réseau. Celui-ci en fonction des paramètres de qualité de réception, temporels et fréquentiels détermine quelle station est la plus appropriée pour la voie descendante.
Cette approche permet aussi d'assurer une plus grande qualité de réception du message par le coeur de réseau.
Voici une vue d'ensemble du réseau tel qu'il est configuré :
On voit donc les différents modules qui émettent sur les stations de base qui ensuite transmettent l'information au coeur de réseau.
Le coeur de réseau est constitué de l'OSS (Système de Soutien Opérationnel) pour le traitement des messages et du BSS (Business Support System) qui gère les commandes et la facturation par supervision.
Les messages sont ensuite redirigés sur le portail SIGFOX ou sur des serveurs clients via des Callbacks et APIs.
Il est donc tout à fait possible de gérer son propre parc avec son propre backend et frontend.
Les callbacks couvrent les types suivants :
Ce ne sont que des notifications par HTTP. On ne peut obtenir que de la data au contraire des APIs qui permettent de faire de la gestion du parc.
Ci-dessous la liste des plateformes où il est possible de plugger des callbacks sans développement supplémentaire.
Concernant les APIs, un large éventail existe. Une documentation exhaustive est accessible sur le site de SIGFOX. (https://support.sigfox.com/docs/api-documentation)
3.2 Couverture
La couverture quant à elle se veut mondiale.
SIGFOX suit la réglementation de chaque zone géographique et a donc créé un découpage en 7 zones. Ce découpage évolue régulièrement au cours du temps car SIGFOX continue d'augmenter sa couverture.
Chaque zone ayant ses propres caractéristiques radio
On constate comme expliqué dans le chapitre 2.1 que chaque zone doit se soumettre à sa réglementation en terme de fréquence libre, de puissance d'émission max. A ceci doit s'ajouter des spécificités. Sur les zones RC1 et RC7, les modules doivent respecter le taux d'occupation de la bande des 1%.
Pour les zones RC2 et RC4, il est nécessaire de faire du "Frequency hopping", soit émettre le message 3 fois sur 3 différents canaux avec une restriction de 400ms par canal et pas de nouvelle émission avant 20s.
Enfin, les modules en zones RC3 et RC5 doivent faire du "Listen before Talk", à savoir écouter l'activité sur la bande avant de pouvoir émettre.
Tout cela est décrit dans la spécification protocolaire et implémenté dans les modules disponibles sur le marché.
En effet, chaque module doit être certifié avant d'être commercialisé.
Concernant la France, la couverture annoncée par SIGFOX est la suivante :
En bleu, les zones bien couvertes, en violet les zones en cours de couverture.
4. Mise en oeuvre
Cette partie décrit une mise en oeuvre simple d'une connexion SIGFOX sur le portail.
4.1 Matériel capteur
La mise en place est très simple, il suffit d'avoir juste un objet à connecter sur le portail SIGFOX.
Pour cela, la carte d'évaluation utilisée est la STEVAL-FKI868V2.
Cette carte est basée sur le module ST S2-LP, "SIGFOX capable".
La carte mère est une NUCLEO-L073RZ embarquant un STM32L053R8T6.
Pour cet exemple, on utilise une carte émettant sur la bande 868MHz en zone RC1.
4.2 Software embarqué capteur
Sur cette carte est embarqué le software proposé par ST à savoir le X-CUBE-SFXS2LP1. Ce software est disponible librement ici : https://www.st.com/en/embedded-software/x-cube-sfxs2lp1.html#get-software
La manière la plus simple de compiler cet exemple est de télécharger un IDE tel que System Workbench for STM32 (SW4STM32) by AC6 et de suivre le User Manual détaillé de ST sur cette partie.
https://my.st.com/resource/en/user_manual/dm00551510-getting-started-with-the-xcubesfxs2lp1-software-expansion-for-stm32cube-stmicroelectronics.pdf
Cet article ne détaillera pas la mise en place du soft puisque le but de cette démonstaration est de montrer une connexion au portail SIGFOX. De plus, un binaire pré-compilé est déjà disponible dans le dossier Binary/ de l'application cible.
Pour l'exemple, est utilisée l'application exemple Sigfox_Push_Button_Demo/, permettant de recevoir un message SIGFOX à chaque pression du bouton de la carte d'évaluation.
4.2 Gateway
Coté passerelle de réception, afin de ne pas acheter d'abonnement et surtout être capable de pouvoir tester toutes les zones, il est très utile de se procurer le SDR Dongle vendu par SIGFOX
Vu que le module à tester est déjà physiquement en zone RC1, une antenne 868MHz est connectée sur le connecteur SMA du SDR. Le capteur émettra donc dans les bandes autorisées dans sa zone géographique.
Attention, si des essais sont faits sur un capteur RC2 par exemple alors que le capteur est située dans une zone autre (RC1 en France par exemple), il convient de connecter le module et le SDR en conduit via un câble. Il est interdit d'émettre sur des bandes autres que les bandes libres de la zone où se trouve le capteur !
Cet outil a un autre avantage, il peut servir d'analyseur de spectre à moindre coût.
4.2.1 Installation
L'installation se fait simplement sur machine Linux ou Windows en installant le Network emulator software disponible ici dans le paragraphe SDR Dongle : https://support.sigfox.com/products
Une fois le software installé, il faut lancer l'application et faire la mise à jour si nécessaire
4.2.2 Configuration
Il convient ensuite de configurer la passerelle. Ceci se fait par l'onglet Configuration et dans le menu RADIO de cet onglet.
Dans notre cas, il suffit juste de sélectionner la zone RC1. Par cette action, les paramètres propres à la zone s'affichent.
Si une zone n'est pas encore disponible, il est possible de la configurer en passant par la sélection "Other"
4.2.3 Provisionnement Capteur
Il reste enfin à référencer le capteur pour que celui-ci soit bien visible par la passerelle.
Il suffit de rentrer le DeviceID du capteur utilisé dans le champ "Identifier". Le champ "Name" peut rester vide mais il est préférable de le remplir pour une meilleure identification.
La passerelle est maintenant prête, il ne reste plus qu'à démarrer le capteur et appuyer sur le bouton. Apparaîtront alors les messages dans le menu "MESSAGES" du SDR Dongle
On voit que les informations suivantes sont disponibles :
- Le Device ID du capteur
- Le timestamp auquel le message a été reçu par la gateway
- Le numéro de message (celui-ci s'incrémente au fur et à mesure)
- La data
- Un pictogramme indiquant la qualité du signal reçu
- Les callbacks si celles-ci ont été activées.
4.2.4 Downlinks
Un type de callback est intéressant à configurer en première approche, il s'agit des downlinks applicatifs.
Les downlinks sont très utiles pour avoir un accès au device via le coeur de réseau par exemple pour de la configuration des capteurs.
Les downlinks se font toujours à l'initiative du capteur en SIGFOX. C'est ce dernier lors de l'envoi qui demande au coeur de réseau de lui envoyer un downlink et ouvre donc sa fenêtre de réception en conséquence.
Pour les configurer sur le dongle, il suffit de se rendre dans l'onglet CONFIGURATION > CALLBACKS et de cliquer sur New
Pour un test rapide, il suffit enfin de mettre le downlink mode en "DIRECT" et de remplir le champ "Downlink Data in hexadecimal" avec la valeur voulue.
Toute cette méthodologie est aussi applicable sur le backend SIGFOX en ligne lors de l'achat d'abonnement.
5. MONARCH
SIGFOX complète régulièrement son offre avec des "features" supplémentaires.
Une d'entre elles semble particulièrement intéressante pour parer au problème de roaming. En effet les technologies basées sur le LPWAN sont souvent confrontées à cette limitation lorsque les objets se déplacent dans le monde.
Pour faire simple, le MONARCH permet au capteur, après écoute d'une trame émise par une balise, de se reconfigurer sur la bonne zone. Le capteur émettra donc avec les contraintes propres à la zone géographique dans laquelle il est.
Dans ce que SIGFOX appelle des points d'intérêts (ports, aéroports), une balise émet toutes les 5 minutes une trame de 400ms dans la configuration RC propre à la zone où elle se trouve.
Le module, ayant détecté par d'autres capteurs un profil atterrissage, de déplacement de container, ou autre, se met en écoute pour savoir dans quelle zone il se situe.
Une fois qu'il a capté la trame d'identification, il se reconfigure si nécessaire et se remet à émettre les datas sur la bonne zone RC.
6. CONCLUSION
SIGFOX a été un précurseur dans les réseaux LPWAN et continue de diversifier son offre afin de contourner des problématiques liées à ces réseaux.
Les performances radio et énergétiques en font une solution viable pour des solutions IoT à moindre coût.
Il n'en reste pas moins que les technologies LTE-CATM et NBIOT portées par les opérateurs téléphoniques risquent de changer l'approche des industriels quant au choix des solutions connectées.
Cela se jouera certainement sur une approche combinée entre les réseaux LoRa ou SIGFOX et les réseaux LTE pour fournir une solution la plus complète possible.
Sources :
https://www.etsi.org/deliver/etsi_en/300200_300299/30022001/02.04.01_40/en_30022001v020401o.pdf
https://www.semanticscholar.org/paper/Coverage-and-Capacity-Analysis-of-Sigfox%2C-LoRa%2C-and-Vejlgaard-Lauridsen/705951f4e219698a9f6e8af4e032ea0dfe7fbf9f
https://www.ismac-nc.net/wp/wp-content/uploads/2017/08/sigfoxtechnicaloverviewjuly2017-170802084218.pdf
https://www.sigfox.com/en/what-sigfox/technology
https://www.sigfox.com/en/news/sigfox-opens-radio-specifications-connected-objects
http://simpleiot.eu/2018/06/30/lora-vs-sigfox/
https://support.sigfox.com/docs/device-idpac-couple
https://build.sigfox.com/