Handling unresponsive devices which do not respond to MAC commands

ChirpStack Network Server
1

Hi all.

Does Chirpstack have any mechanism for detecting/mitigating against non-compliant/unresponsive devices which do not respond to some/all MAC commands, to preventing wastage of bandwidth?
Chirpstack will stop sending MAC commands, if the device NACK’ed them consecutively 3x (2x in v4?). But it appears to never give up, if the device does not respond.

In contemporary gateways that use the SX1301, they tend to be half-duplex. Thus downlinks may block the reception of all uplinks.
If Chirpstack encounters a device that does not respond to ADR, for instance, it seemed to result in downlinks in response to uplinks.

Other than the case of non-compliant devices, I think it can help against devices that are unable to receive downlinks (and thus do not respond), due to substandard site placement.

My usecase involves devices from customers. In some commercial LNS services, there may be a qualification exam for devices that are going to be deployed. However, this may not exist for my case. The only way I am aware of to identify such devices, is to manually go to the device’s profile to check the LoRaWAN Frame logger, and/or the channels and datarate heat maps. There seems to be no way to know about the use of these devices, or to mitigate against devices that trigger this negative reaction from Chirpstack.

In my proprietary LNS, I made the sending of MAC commands give up, if the device fails to respond more than 5 times or so. This can be a separate and greater number than the existing maximum error count feature.

Does Chirpstack have any feature like this?
If not, is it desirable to have something like this? Perhaps not only as a limit to the number of attempts, but also as an event?

I haven’t found any discussion about this, so I hope it will be a worthwhile discussion. I witnessed this behaviour in Chirpstack v3 and am still relatively new to v4. I major in Java and C, so while I could contribute such a feature, it may take time to produce a quality implementation.

Thank you for your time, in advance.

2

This is the radio world.
Anyone can send radio signals.

Nothing can be done if the nodes are not LoRaWAN compliant.

The bad behavior nodes can send packets every 100ms and try to jam all 8 frequencies with 5 SFs.
LoRaWAN has mechanism to mitigate the issue but not elimination.

The authority may catch the bad nodes btw.

3

I agree. But as the operator, there may be a need to prevent Chirpstack from compounding the problem. I refer to this issue of Chirpstack itself jamming up the network by responding to every uplink, in an attempt to control the unresponsive device.

Due to the half-duplex nature of some gateways, the LNS transmitting downlinks, could be a heavier cost than nodes transmitting uplinks.

So I believe there should be some mechanism to limit how many times it tries to command an unresponsive node. Regardless of whether it is a bad implementation or unable to receive downlinks due to its placement.

1 Like
4

Hi @brocaar . Sorry to bother you. I would like to know what you think and whether this feature is desired.

Owing to my workload and lack of experience with Rust, I would like to only try to contribute if it is a wanted feature.

Thank you in advance.