Suport technique et veille technologique
Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
- Avril 2021 -
Le RFC 8724 décrivait un mécanisme général
de compression pour les réseaux LPWAN (réseaux
contraints pour objets contraints). Ce nouveau RFC 9011
précise ce mécanisme pour le cas spécifique de
LoRaWAN.
Ces « réseaux
contraints pour objets contraints » sont décrits dans le
RFC 8376. Ils ont des concepts communs mais
aussi des différences, ce qui justifie la séparation de SCHC en un
cadre générique (celui du RFC 8724) et des
spécifications précises par réseau, comme ce que fait notre
RFC pour
LoRaWAN, la technique qui est
utilisée dans divers réseaux déployés. Donc, rappelez-vous, LoRaWAN = la technologie,
LoRa = un réseau déployé utilisant cette technologie (mais d'autres
réseaux concurrents peuvent utiliser LoRaWAN). LoRaWAN est
normalisé par l'alliance LoRa (cf. le
texte de la norme) et les auteurs du RFC sont actifs dans
cette alliance. Si vous voulez un exemple d'utilisation de LoRaWAN,
je recommande cet article
en français sur une Gateway LoRaWAN
réalisée sur un Raspberry Pi.
La section 3 du RFC fait un rappel de SCHC : si vous n'avez pas
le courage de lire le RFC 8724, apprenez que
SCHC a deux parties, une de compression des
en-têtes, et une de fragmentation, les liens
des réseaux contraints ayant souvent une faible MTU. La section 4,
elle, explique LoRaWAN (vous avez aussi le
RFC 8376, notamment sa section 2.1). La
terminologie de SCHC et celle de LoRaWAN ne coïncident pas
parfaitement donc il faut se souvenir que Gateway
dans LoRaWAN s'appelle plutôt RGW (Radio GateWay) dans SCHC, que le
Network Server de LoRaWAN est le NGW
(Network GateWay) de SCHC et que les utilisateurs
de LoRaWAN doivent se souvenir que leur Application
Server est nommé C/D (Compression/Décompression) ou F/R
(Fragmentation/Réassemblage) chez SCHC. Les objets connectés par
LoRaWAN sont très souvent contraints et LoRaWAN définit trois
classes d'objets, de la classe A, la plus contrainte, à la
C. Notamment, les objets de la classe A émettent sur le réseau mais
n'ont pas de moment d'écoute dédié, ceux de la classe B écoutent
parfois, et ceux de la classe C écoutent en permanence, ce qui
consomme pas mal d'énergie. Autant dire que les objets de classe C
sont en général alimentés en électricité en permanence.
La section 5 est le cœur du RFC, expliquant en détail comment on
met en correspondance les concepts abstraits de SCHC avec les
détails du protocole LoRaWAN. Ainsi, le RuleID de
SCHC est mis sur huit bits, dans le port (Fport)
LoRaWAN (norme LoRaWAN, version 1.04, section 4.3.2), juste avant la
charge utile. L'annexe A du RFC donne des exemples d'encodage des
paquets.
Merci à Laurent Toutain pour sa relecture.
