Avoiding signaling storms when updating the channel plan

I’m sitting on a Chirpstack 3.15.x server that will be upgraded to rel 4 in a few weeks time. Before I do that, I want to update the channel plan in the network. We have about 20 000 devices in operation right now. Have understood that if we update the channel plan in Chirpstack and reboot the server, it will try to update the channel plan in all devices by sending two downlink messages per device/sensor.

Has someone tried this? I don’t want to kill the network by swamping it with DL traffic and the buffers in the gateways won’t be able to handle the buffering. Does Chirpstack offer some way of scheduling the updates or does someone have best practice suggestions to share?

ChirpStack will only send the channel updates as Class-A downlink. Thus after changing the config, you first need a Class-A uplink before ChirpStack will respond with a mac-command to sync the channel config. Assuming that the uplinks are spread over time, the channel re-configuration will be spread over time too.

2 Likes

Yes, I’m aware that’s the procedure. I just have a lot of devices reporting every 15th min and commercial traffic in the network. Would have been preferable to be able to schedule this a bit.

DL traffic and the buffers in the gateways won’t be able to handle the buffering.

The NS will not schedule more packets than can be transmitted on a single channel for each gateway. Plenty or RAM for packets at the gateway.

In your case, class a packet every 15min.
If devices are not sync’d to tx at same time of day, they should be staggered. Two uplinks rxd at same time can be answered in rx1 for one device and rx2 for the other. The gateway will not hear packets while transmitting. I share for those who don’t know only.

2 Likes