NbTrans and networks with frequent collisions

ChirpStack Network Server
1

UPDATE
There are two sources of packet loss- low SNR and collisions. The NbTrans calculation makes sense for low SNR nodes, but only escalates the problem in busy networks. I think this is the source of our problem. We will be deploying a network inside larger commercial buildings, and though we are working to reduce the LoRa transmissions to a minimum, there will be times where we have high packet rates.

For networks with a high probability of collisions, it would be very good to limit the ADR NbTrans setting.

Original
Periodically LoRaServer (3.0.2) is ramping the NbTrans count from 1 to 2 to 3 in two separate back-to-back uplinks. During this time, the RN2903 returns only mac_err for any transmission attempt. Then inexplicably LoRa ramps NbTrans back down to 2 then to 1, in about 1 second.

We have verified the packet loss is currently less than 5%.

  1. Most importantly, is there a way to limit NbTrans to 1.
  2. Why is this happening? (And what information do I need to supply? Capturing packets is difficult because the LoRa Server portal eventually stops responding after not too many packets)
2

Would it be possible to make the maximum NbTrans configurable? It would be very useful for networks running near saturation. Extra packets in an already busy network are very detrimental.

3

Hi @brocaar,
Do you have any updates about making maximum NbTrans configurable?

We would like to limit “NbTrans” value to maximum 1. Do you think modification of the “idealNbRep” variable in the code below would solve our issue?
https://github.com/brocaar/chirpstack-network-server/blob/master/internal/adr/adr.go#L92

Your feedback about this would be greatly appreciated.

Thank you.

4

Yes, that value defines the number to which the NbTrans will be set.