No downlink messages received after closing and reopening connection.
-
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.
-
@hans-liefting Hi Hans.
Our device registers itself every hour at the network, after which it will send an uplink message.
What protocol are you using? I would definitely not recommend to register every hour. Registering with the network is very costly energy consumption wise since many messages are exchanged. So unless your module has a very poor PSM mode the tradeoff is not worth it. Operators also generally don’t like it since it creates more load on the network.
When the device sends the uplink message, our backend replies with a downlink message that is delayed by a maximum of 3 minutes.
I am not entirely sure but I don’t think this will work since the downlink message has to be queued before you sent the uplink… but t-mobile will know the details on that.
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).
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…
Note that for energy reasons, our device does not go to PSM but actually shuts down.
Can you please try again without shutting down but staying in PSM mode?
-
@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.
-
@Hans-Liefting Hi,
I am not sure if I understood your process correctly …Process ?
- Device wakes up and connects to the network
- Device send uplink message
- Application receives the message and response with a downlink acknowledgment
- Device waits for 10 seconds
- Device closes the connection and shuts down.
- After one hour process is repeated at 1.
Problem ?
Downlink message isn’t received by the device reliable.If you send a non-eDRX downlink message our UDP broker queues the messages until it receives the next uplink message from the device. This means your application acknowledgement message requires an additional uplink messages to let UDP broker deliver the queued downlink message to your device.
In case you send an eDRX downlink message you can try to extend the 10 secs wait to e.g. 30 secs and see what happens. As you know eDRX messages are not queued by the UDP broker. eDRX messages are immediately pushed to your device by the UDP broker. In case you device sleeps the downlink messages are queued by the mobile network. If you are using eDRX downlinks it could be possible that 10 secs not enough for the network to deliver the message and 1 hour of buffering is to long. Maybe this is reason why it works if you wakeup every 5 minutes.
Regards, Roland
-
@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? -
There is some information here: https://forum.iotcreators.com/topic/733/how-long-will-a-downlink-message-stay-in-the-network-queue
-
@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?
-
@Hans-Liefting: Can you please send me the IMEI of your device to support@iotcreators.com? I will check the logs to understand when uplink and downlink messages are received and when downlink messages are sent by the udp server.
Regards, Roland
