NewChannelReq downlink messages for every unconfirmed uplink message

LPWAN Industrial Gateways / Concentrators RAK7258
1

Issue:

  • 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.

Setup:

  • RAK 7258 with enabled built-in LoRa server, several RFM95W-based nodes sending unconfirmed uplink messages

LoRa® Server:

  • Built-in

Details:
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,
Julian

2

The built in server is chirpstack, just an older version from before the LoRaServer->Chirpstack name change, so you may want to check older threads on the chirpstack forum.

If I recall, there may be something you can do by not configuring uplink channels in the chirpstack setup; there’s actually no reason a network server needs to know about uplink channels, other than to pass the information down to nodes. (The knowledge a server needs for its own purposes is uplink to downlink mapping and that comes from the regional parameters spec)

3

Thanks for your advice. Finally we “solved” the problem by using an external Chirpstack instance instead of the built-in one.