- A node (ABP join mode) sends unconfirmed data up
- For every single uplink packet the RAK 7258 sends a downlink packet containing a NewChannelReq MAC command.
- RAK 7258 with enabled built-in LoRa server, several RFM95W-based nodes sending unconfirmed uplink messages
We are currently evaluating the RAK 7258 for building private LoRaWAN networks.
Also for development purposes the the built-in LoRa server is very interesting but causes the problem mentioned above.
Ideally the node would do the required changes after a NewChannelReq and send a NewChannelAns. But in case that the node is not listening for downlink messages the NewChannelReq will be ignored. This results in another NewChannelReq after the next uplink message. Sending unconfirmed uplinks is not unusual for simple devices, resulting in capacity issues for the downlink.
Is there a possibility to avoid additional NewChannelReq downlink messages if previous messages were not acknowleded?
I know that Chirpstack for example uses a max. mac-command error counter for exactly that reason:
“When a mac-command is nACKed for more than the configured value, then the ChirpStack Network Server will stop sending this mac-command to the device. This setting prevents that the Network Server will keep sending mac-commands
on every downlink […].”
Thanks for your support,