Just join device only. Why downlink queue data delete?

ChirpStack Application Server
1

KakaoTalk_20210115_175745325
screen shoot is work step

question

  1. Just join device only. Why downlink queue data delete?
  2. “Device data page” not join. But device is join ok message.
  3. This time, reject insert downlink queue.
  4. But device uplink. And then, downlink queue ok.

I need your help.
thank you.

2

Another question

  1. Does the downlink work at the same time when executing a join?
  2. Downlink data is lost when the join is executed.
  3. I was send uplink data but not receive downlink data.
3

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.

I do not believe any have yet been implemented.

1 Like
4

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?

5

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 :slight_smile:

6

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.