Hi, I’ve read many posts about this topic but still it is unclear, at least for me.
I have had multiple situations like this one: I have 2 GW receiving the uplink from a specific node working in Class C. Let’s say GW1 has good RSSI and SNR but GW2 doesn’t. However from some downlinks NS uses GW2 (the worst one) and the node doesn’t receive the frames because poor signal coverage.
Questions:
Can I tune the way the NS select the GW for downlink?
I have read about gateway_prefer_min_margin and installation_margin, are those the same command? One override the other? Can I use those commands to modify the NS behavior for selecting the GW for downlink? Let’s say increasing installation_margin from 10 (default) to 15?
Increasing the installation_margin could drive to any other working node to disconnection? Or improved connection conditions are expected?
Tune, as in to directly influence? No. But you might be able to get it to ignore the poorer choices by adjusting the downlink gateway margin (not to be confused with “instillation margin”).
No. installation_margin is documented in the configuration section of chirpstack.io. gateway_prefer_min_margin is not documented properly in v4, so here I quote the explanation from v3. gateway_prefer_min_margin is what you want to adjust to fit the site.
# Installation margin (dB) used by the ADR engine.
#
# A higher number means that the network-server will keep more margin,
# resulting in a lower data-rate but decreasing the chance that the
# device gets disconnected because it is unable to reach one of the
# surrounded gateways.
# 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.
If you really mean installation_margin, it is used in ADR. ADR determines how many steps to take, with a formula like this. So a higher margin will make it less aggressive. LNS can only advance the ADR steps, while it is for the node to reverse it as required. It will start by increasing the datarate until the maximum, before starting to decrease transmission power. It is also the part that uses nbtrans to compensate for message losses, targeting a reception rate of 95%.
The downlink gateway selection logic involves computing a list of candidates, which have received a copy of the most-recent uplink at a SNR level of at least the margin. A random gateway amongst this set is selected.
If there are no candidates, then the gateway which received the most-recent uplink at the best SNR and RSSI will be used.
If the most-recent uplink was received in such a way that only unfavourable gateways performed better because of collision or the ideal gateway missing the uplink, nothing much can be done to improve the situarion until the next uplink.
In our LoRaWAN Network Server(a small private company I’m working for) we’ve implemented best signal Gateway(GW) algorithm.
When an UpLink is received and there are more than 1 GW for this device, the server waits XXX ms for possible UpLinks from the other GWs. After that compares their RSSI and choose the best one through which to send the DownLink.
If there are 2 or more GWs with equal RSSI, then the server compares the SNRs of the received UpLinks.
If this is not implemented in ChirpStack, I suppose you can make a request.
Chirpstack does have a downlink gateway selection algorithm that works like that, but doesn’t compare RSSI. OP’s question was about how the margin can be adjusted, as it’s presently also picking gateways that aren’t sufficiently good choices. I guess, just adjusting the downlink SNR margin will solve his problem.
However, I think we might need a smarter algorithm, as RSSI is possibly important when the gateways are close but there are obstructions. But I haven’t figured out how important RSSI really is, in downlink gateway selection. As I detailed here, it used to be part of Chirpstack’s earlier design, but this design was removed without any explanation.
Do you have any views on whether factoring in the RSSI is important?