From the configuration:
# Prefer gateways for downlink with given uplink (SNR) margin.
# When receiving an uplink (by multiple gateways), the Network Server will
# prefer the gateways that have at least the configured margin for the uplink
# SNR when sending a downlink. Margin:
# uplink SNR - required SNR for spreading factor
# * In case multiple gateways match, the Network Server will select a random
# gateway from the match.
# * In case non of the gateways have the desired margin or the uplink
# modulation was not LoRa, then the gateway with the best SNR (or RSSI
# in case of FSK) will be selected when sending a downlink.
This describes an ability to set a margin, but I think based on the last comment, if only ONE gateway receives the packet, it will switch the routing info for that device.
Consider the following diagram, where multiple gateways are present:
Now the following scenario:
- “Node” is on the edge of GW2 coverage
- GW1 receiver is busy for some reason (e.g. sending a downlink to some device)
- “Node” sends an uplink during this time, so GW2 is the only gateway to receive the message.
- LNS updates “Node” gateway routing info to “GW2”, since that was the only Gateway to receive the packet
- Routing is now sub-optimal (or potentially blocked)
- In case downlink packet link budget is less than uplink, downlinks to “node” via GW2 can always fail, until Node sends another uplink via GW1 and the LNS sets the optimal route back to GW1
So, is my assumption of (4) correct? If it is the only gateway that received an uplink, LNS changes the route even if the margin config setting is not met.
My first goal of this topic is just to determine if the above scenario could occur.
It depends on the device class. For Class-A, the downlink is always routed through one of the gateways which received the uplink. For Class-C, last set of receiving gateways is stored in the device-session, so your assumption in 4) is correct.
- In case multiple gateways match, the Network Server will select a random gateway from the match.
- In case none of the gateways have the desired margin or the uplink modulation was not LoRa, then the gateway with the best SNR (or RSSI in case of FSK) will be selected when sending a downlink
I’m under Class-A and most of my sensors are received by at least four gateways, with significant differences in RSSI (from -115 to -40) depending on where sensor is located with reference to GWs.
I configured multiple GWs to try to (later) optimize signal strength (and thus battery life), but it seems that LoRaWAN doesn’t work that way? That it, do I have any control over which one GW a sensor it assigned to? If yes, how can I exercise this control?
This idea comes down to something like ‘static routes’, as we would say in IP land. Its a good idea for LNS, and I would propose such an option in Chirpstack - however the default behavior is very hard to argue with — unless you are in a certain situation.
With multiple gateways that have “
very good coverage” to your deployment, the dynamic routing is actually a good thing for your site deployment. The issue is when the above situation occurs when the gateway that is supposed to serve your device (GW X) happens to be busy for a minute (most likely its sending a downlink?) - and the horrible range gateway (GW Y) happens to pick up that uplink packet… Now, that gateway (GW Y) 78 miles away that “somehow through the grace of God” received that 1 packet because GW X was busy — the LNS now updates the routing info for device A to say “oh yes, GW Y is now the downlink path”
Please note :: this is only applicable to Class-C devices (for the most part)
Since you said you are under Class-A – I am not sure what the issue is? Can you elaborate on your issue “I configured multiple GWs to try to (later) optimize signal strength (and thus battery life), but it seems that LoRaWAN doesn’t work that way?” I think I know what you are asking: “static routes”?
I have a setup of ~100 class C nodes and a gateway. Some of the nodes have very low signal and SNR so I installed a 2nd gateway better located (but I keep the original sub-optimal gateway).
If I stop the suboptimal gateway and I send downlinks from chirpstack to any device it keeps in the downlink queue but is not sent to the node.
What I have to keep in mind or know in this scenario?
Class-C devices need to periodically send an uplink to update the device to gateway association. Probably ChirpStack is not aware that your device is now under the coverage of the new gateway and it keeps sending data to the old gateway which now has been turned off.
If the node sends uplink to the optimal gateway, will a confirmed downlink be sent to the device via optimal gateway?
I believe it should work.