1

As far as I understand, LoRaWAN is intentionally designed as a Non-IP Stack. Based on all requirements on LoRaWAN, I can understand the design decisions behind the standard.

But IMHO, there are many other use cases for LoRa (just the physical protocol) which, for example, do

  • not need to be able to communicate to many gateways at the same time or
  • don't have low energy consumption requirements.

For these use cases, it would be nice to have other MAC implementations, where one could either have

  • IP-based stack on top of LoRa or
  • a lightweight protocol between LoRa-based Sensor and ONE gateway, which handles message transport & security

Sigfox has a similar architecture to LoRaWAN where the device/sensor sends messages directly to a backend-network to which the application needs to connect. To me, this kind of architecture seems pretty odd, since I loose many advantages of the internet and I am tightly coupled to a backend-network provider (imagine using LTE, you would need to explicitly add your application to the mobile providers backend).

I would like to have a local network (would be okay if it is not IP based) but the devices are connected to a gateway and there I have all flexibility what to do with the sensor data. Using LoRaWAN, this could be achieved by running a network server on the gateway but this would be rather a workaround than a solution I am looking for.

The only reason that I can see now, which makes this network architecture really necessary are that a device can connect to multiple gateways and therefore use cases as, e.g., asset tracking can easily be realized.

Are there any LoRa based solutions where I do not have to deal with setting up network servers? If not, why is that the case?

Edit: For Linux, I found this project here: https://de.slideshare.net/chienhungpan/lets-have-an-ieee-802154-over-lora-linux-device-driver-for-iot And also the LoRa Mesh Project: https://github.com/meshtastic/Meshtastic-device

Christof Tinnes
  • 113
  • 8
  • 1
    For most of the frequency bands supported by LoRa (915MHz in the US, 868MHz in EU for example), there is heavy (legal) restriction on air time. The rules are different for each band, but in general the maximum time a device is allowed to be active is 1%, which means IP-style communication isn't very feasible. There are LoRa chips for 2.4GHz which allows 100% air time though. But if you're going to use 2.4GHz, why not use BLE or Wifi which are designed for IP communication? – Mikael Falkvidd Oct 30 '20 at 16:42
  • Thanks. That would be an argument against IP-based stack but still, just a WiFi Style, Zigbee, Z-Wave,... Style communication to a single Gateway would be interesting. – Christof Tinnes Oct 30 '20 at 21:00
  • When I don't have IP-based communication between sensor and gateway, I want to terminate the connection at the gateway and be able to do whatever I want there with my data. With LoRaWAN, it will be forwarded to the "network". There, I need to take my data out or further process it. I understand that LoRaWAN wants to be like a mobile network provider, but with a mobile connection, I can still use IP and therefore have all kind of freedom on the client side. – Christof Tinnes Oct 30 '20 at 21:12
  • You can run the LoRaWAN network server and application server on the gateway if you want to. – Mikael Falkvidd Oct 31 '20 at 07:35
  • Yes this workaround I mentioned already in the post, but it is kind of ugly and I am wondering, why I can not find any other initiatives that develop a MAC implementation based on LoRa without this "provider network architecture". – Christof Tinnes Nov 03 '20 at 20:51
  • Maybe https://www.reddit.com/r/IOT/comments/jmgyl0/lorawan_without_gateway/ can be useful – Mikael Falkvidd Nov 04 '20 at 08:05

2 Answers2

0

LoRaWAN is a Low Power Wide Area Network (LPWAN). This means that the technology allows us building a scaleable wireless IoT network where all devices (things) can be connected even if their transmission power is limited. A LoRaWAN network can easily scale at a size of a country and the low power communication makes it possible to operate the network in an ISM band where both transmission power and bandwidth are limited anyway. Low transmission power also ensures long battery life time for battery powered devices. Beyond supporting geo-localisation, gateway diversity (meaning that the same radio frame can be received by multiple gateways) significantly increases the resiliency of the network, improves the link budget and lowers the packet error rate. Traditional IP based based protocols would require much higher average data rate than what LoRa was designed for. Although you are not obliged to use LoRWAN's MAC layer with the LoRa modulation and you may develop your own proprietary protocols, if low transmission power, long range and long battery life is not important for your use case, it is probably better to use another technology.

Norbert Herbert
  • 229
  • 1
  • 4
0

The Reticulum Network Stack supports many different physical mediums, including raw LoRa. Mediums like LoRa can be used exclusively, or mixed with any number of other mediums to build as simple or as complex networks as you need, from two devices to billions.

Reticulum is purposefully designed to handle very low data rates and very high latency, while still supporting transport accross much faster network segments, and is very efficient in terms of per-packet and overall protocol overhead.

The source code for the reference implementation, and releases can be found here: https://github.com/markqvist/reticulum

Mark Qvist
  • 125
  • 3