When a join takes place, new session keys are negotiated, which renders the encryption of the queued downlink invalid, so it is dropped. I had a bunch of discussions with Mr. Brocaar on this topic while at my last job, and there are a few options that he was considering implementing to work around and/or give the operator more control over what to do in this situation.
This problem has already been discussed a few times in the forum. Is there anything new in this?
We’re developing sensors that we’re currently testing with a chirpstack server, and we’ve run into the problem of the downlink queue flushing during a join.
If the sensor repeatedly does not receive acknowledgement, it assumes that there may have been something weong in network connection and performs a new join. This causes the chirpstack to clear the downlink queue which is undesirable. Is it possible to disable the queue clear functionality during a join?
Not yet, the queue is persisted by the NS, while the payloads are encrypted by the AS. leaving the items in the queue means that (since these are already encrypted) will give you garbage data. There are some workarounds possible, but I’m not planning to add this to v3.
The upcoming v4 merges the AS and NS components so that queue items can be encrypted on sending the downlink. That makes it really easy to implement a “flush device queue on join” flag
Thank you for answer. We have encountered the same behavior with a commercial operator which use some commercial network server, so we must handle this with counters and downlink commands in communication protocol/payload.
One solution I was thinking about was responding to a “join” event on the server and send unconfirmed downlink again. This worked for HTTP integration, but for GCP PubSub only “up” events are sent. I didn’t try another integrations.