@stefan-de-lange hi,
Thanks for helping out. We found that information too, but unfortunately, that is not the behavior we see when our device deregisters itself from the network.

In that post, Roland mentions the out-queue for downlink messages are deleted when the device is deleted. @Roalnd-Baldin could it be that the same behavior occurs when we close the PDP connection and deregister from the network?

@roalnd-baldin Hi,

The process is correct, except for a small addition in step 3; the response is sent on average three minutes after the uplink message is received. So the device will already be disconnected from the network and turned off when the downlink message is sent to the broker. Our device has eDRX disabled, and we do not use the eDRX API. Therefore, we expect the message to be queued by the broker.

Upon the next cycle (after 1 hour), a new uplink message is sent, so we would expect to receive the downlink message in the queue. However, we do not receive anything most of the time.

During our tests, we noticed that if we do not deregister from the network but cut the power from the modem immediately, and 1 hour later restore the power and register at the network again. We do receive the message that was placed in the queue.
Could it be that deregistering from the network causes the queue to be cleared?

@stefan-de-lange Hi Stefan,

Thanks for your reply,

What protocol are you using?

We are using UDP over NB-IoT.

I would definitely not recommend to register every hour

I agree. However, the customer can configure how often the device sends data to our backend. The connection interval can be set between 1 and 24 hours. In the case of 8+ hours which most of our customers configure, it is for our device more power efficient to shut everything down than go to PSM. In my original post, I mentioned 1 hour, but the same problem occurs when configuring a connection interval of more than 1 hour.

about the message queue

I am aware that the messages are queued. Waiting at least 3 minutes to send a reply will mean the connection of the nb-IoT device is already closed. This is the intended behavior for our situation. Next time the device comes online, it should receive the message from the queue. The problem is, it doesn’t receive any of the messages most of the time.

My guess is that when the modem deregisters itself from the network, the downlink message queue is cleared. But again t-mobile has to confirm this…

Would be really nice if T-mobile could confirm this.

We saw that if we don’t deregister from the network but just pull the battery out and after an hour replugs it again, the device enters its init loop and registers at the network and does receive all messages. But this is of course not a solution.

Can you please try again without shutting down but staying in PSM mode?

For testing purposes, I can try to implement this. However, this is not our desired solution.

Hi,

We encounter some unclear behavior with the downlink messages.

Our device registers itself every hour at the network, after which it will send an uplink message. When the device sends the uplink message, our backend replies with a downlink message that is delayed by a maximum of 3 minutes.

After the uplink message has been successfully sent, the modem waits for 10 seconds for a downlink message. Afterward, it closes the connection and shutdown the modem (we use the Telit modem ME310G1-WW). Note that for energy reasons, our device does not go to PSM but actually shuts down.

According to this setup, we would expect every connection interval a downlink message from our backend that was a reply to the previously sent uplink message. However, we notice that roughly 90% of the time, no downlink message is received at all. If we do receive a downlink message, it is only one single message, so the other messages are still gone. We wait at least 3 seconds after each received downlink message for another downlink message.

If we set the interval of sending an uplink message to every 5 minutes, all seems to work fine and each time a downlink message is received.

What could be the cause of this behavior, and how could we solve this issue? Our application desires to receive the downlink message at least 90% of the time.