Backup methods for LoRaWAN

(Goodfellas) #1

Hi everyone,

We have a project, which monitors traffic for first responder. LoRaWAN uses star topology. Although star topology has many advantages, we concern about backup plan when a gateway does not function properly.
We don’t want the data to be interrupted.
So, is there anyway the closest node from the gateway turn to gateway mode temporarily (for couple days). Then, we’ll have enough time time to fix the gateway?
Our team has looked into OpenThread protocol, but still want to use LoRaWAN for our project.

Untitled%20document Untitled%20document%20(1)

We would appreciate any ideas.

(Sandgroper) #2

This is not quite an accurate description of the technology. LoRaWAN is a broadcast technology. A node has no knowledge of the gateway it is talking to. Any gateway within range will receive a node’s packet and forward the traffic to the backend. The backend is responsible for removing duplicate packets.

The achieve higher availability, increase the number of gateways.

If your nodes only every transmit (do not receive) then, if you use ABP (Activation by Personalization), you have more flexibility. You can use LoRa repeaters. These repeat LoRa frames - they do not know the payload and do not care if the payload is a LoRa packet or a LoRaWAN packet. I have built an Air Quality monitoring system for First Responders combating Wildland Fires using this technology. Check out

(Goodfellas) #3

Thank you!
Your project is very interesting. It is a great reference for us. I wonder if we can predict wildfire by using those data from your sensor nodes.
Back to our problem, we just brainstorm couple methods:

  1. Add additional repeaters (thanks to Sandgroper).
  2. Add other wireless communication technologies.
  3. Switch to mesh.

(LoRaTracker) #4

Cant see how, most nodes are single channel and do not have the required Internet connectivity.

If you want more resiliance, is there a particular problem in just installing two gateways ?


The best answer is that you place 4 new gateways, so that your entire coverage is duplicated.
What has already been noticed is that node is almost always single channel. and that they also have no internet connection.
If it is the business area, expand the Wi-Fi or cable network on the locaite and place the 4 gateways extra. In this way you get coverage of at least 2 gateways at every location.
But of course you can also take the test by checking this in practice first how far a node actually comes to communicate with a gateway. Of course, you can easily see in the TTN console that a node enters through multiple gateways.


(Goodfellas) #6

Thank you,
So we have 2 scenarios here one is in urban or suburban area and the other is in rural area.

  • For the first area, we can expand WiFi network or use LTE with extra gateway.
  • For the second area, we can use repeater to forward LoRa packet to gateway.

Cost to expand WiFi and install extra gateway are our problems.
In mean time, we’ll look into the repeater method and keep updating our progress.

(Arjan) #7

In that rural area, do you have a proper power source for the repeaters? They’ll need to be listening at all times, 24/7.

Also, you might need to de-duplicate messages, if you’ve disabled the frame counter checks.

(Sandgroper) #8

Regarding costing, you may need to recheck your assumptions. The cost of gateways and LTE is valid concern for a research project requiring funding however when it comes to real Wildland Fire events, the costs of deploying First Responders and guaranteeing their safety, is so high, the relative difference in cost to deploy additional LTE and WiFi is not significant. In our system we also offer, as an option, satellite comms directly from the Sensor nodes. The cost of utilizing a satellite service during a Wildfire event is insignificant with the added advantage that you do not need to be concerned with, line-of-site obstructions along the transmission path or the lack of coverage for LTE backhaul.

It is different for Sensor Nodes intended to be deployed indefinitely, in this case satellite is unlikely to be commercially viable.

(Sandgroper) #9

With the appropriate hardware and software, it is possible to deploy light weight, efficient, solar powered repeaters.