Three reasons for creating an Open Source LoRaWan server

Three reasons for creating an Open Source LoRaWan server

Three reasons for creating an Open Source LoRaWan server

I believe that LoRaWAN™, the long-range, low-power wireless transmission technology, is a perfect solution for interconnecting devices in large buildings like schools, hospitals or manufacturing sites. Just a few LoRa gateways are required to cover sensors in the entire building, so the deployment is very cost efficient.

LoRaWAN network architecture

 

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).

The server is available under the MIT license at https://github.com/gotthardp/lorawan-server.

Petr Gothard
Petr Gothard
Research Specialist for IoT at Konica Minolta Labs Europe
X