LoRaWAN™ è al momento la soluzione ideale per inter-connettere device e sistemi in contesti di grande ampiezza.
LoRaWAN™, la tecnologia di trasmissione a lungo raggio che abbiamo già introdotto in un precedente articolo, è al momento la soluzione ideale per inter-connetere device e sistemi in contesti di grande ampiezza: pensiamo ad ospedali, scuole e università, grandi industrie e magazzini di produzione e stoccaggio.
Per coprire le necessità di sensori in tali tipi di contesti sono sufficienti pochi gateway, rendendo così l'implementazione tecnico-operativa di queste reti molto efficiente in termini di costi.
Tipicamente, l'architettura network LoRaWAN sfrutta il sistema per cui i gateway vanno a raccogliere messaggi dai sensori e li re-inviano ad un server centralizzato.
Benché esistano diversi server LoRaWAN open-source sul mercato, ci è capitato di voler customizzare un'infrastruttura basata sugli specifici requisiti di progetto e non ce siamo pentiti.
La differenza principale tra un server open-source ed uno in qualche modo costruito "su misura" risiede nell'architettura del software e sullo scopo specifico del rilascio (intended deployment???).
[da sviluppare]
Altro vantaggio è dato dalla libertà di poter scegliere il linguaggio di sviluppo più congeniale al team IT:
[da sviluppare]
LoRaWAN network architecture typically uses the star-of-stars topology in which gateways are collecting messages from the end-devices (sensors) and forward them to a central network server. Despite there are open-source LoRaWAN servers already available I decided to build a new one. The main difference (and the first reason for building yet another open-source loraserver) is the software architecture and the intended deployment.
Other implementations consist of several servers, bridges and controllers, so I assume the intended deployment is a large distributed public network, operated by several collaborating entities. This architecture may become an overkill if you are a single entity operating a private network, either as an individual geek who wants to try a cool LoRa sensor, or as a commercial company who wants to collect data from the sensors deployed around their factory. My server aims at these private deployments and explicitly excludes the public distributed deployments. Everything runs in one “box”, including the LoRa applications, so it could be easier to deploy, maintain and secure. This is what we needed for our Process Sensor Project.
A second big difference is the programming language used. My server is written in Erlang (which I love), because it is very suitable for implementation of reliable near-realtime, message oriented protocols (just like LoRa). You may want to read Some Thoughts on Go and Erlang. Erlang even supports scalability (clustering), so my server could (one day) support large private networks, but the way it achieves that is fundamentally different to other implementations. I am not saying mine is better (or worse), it’s just very different and designed to meet different needs. My goal is to complement rather than to compete– to address different use-cases using a different architecture.
A third reason for building the server is personal– I just wanted to learn LoRaWAN by building yet another server (because it’s so easy to build servers in Erlang).
Categorie:
