How to know if queued downlinks are retrieved
-
Is their a callback mechanism to tell the northbound application that downlinks are consumed by device?
We have to split up a file into several ±7,5K payloads to send as downlinks. When we have more than 75K to send to the devices, what is the way to go about this?
- Should the device send a message so the NB application knows?
- Does the IMPACT platform notify the NB application?
-
@magnatron if you have 75KB to send to a device you should probably switch to LTE-M… :)
-
@Stefan-de-Lange why?
-
@magnatron Because 75KB is too much for NB-IoT. It’s better suited for LTE-M
-
@Stefan-de-Lange then how come FOTA does work over NB-IoT? Modem fwpkg > 1MB
-
In general Stefan is right… But we do have some customers who are doing this with NB-IoT…
Pls give me a day or two to gather the right information for you
-
@Stefan-de-Lange @afzal_m thanks.
But still: can we know if queued downlinks are retrieved? Does the platform know? -
@magnatron It can work ofcourse but in general NB-IoT was not designed to handle so much data
-
@Stefan-de-Lange we only plan on being able to update our software when really needed without needing to get the devices back in store. This should not happen on a daily basis, or even monthly.
We just want to make sure we can. -
As I understood it the network only buffers upto 10 packets for a device. So depending on how long your devices sleep and how fast the data is pushed to the device, you can easily overrun that buffer. If the underlying protocol does not have a retry mechanism (eg: udp) the data is lost.
The impact platform is not aware of this as this is handled by the telco network.The ideal solution would be to use something like lwm2m and let the device request the firmware in boot sequence and let the device download the firmware from our platform … unfortunately this is not yet supported.
@afzal_m probably has some examples/best practices of how this can currently be achieved
-
Our Service Capability Server (IMPACT) doesn’t have the information whether a downlink message arrived or not.
This feature will be available in our new CoAP adapter (to avoid confusion: this is the pure version of CoAP and not the Neul version that you are used to). We do not have it commecially available yet, but is already available for testing. (I believe testing is a good idea for the future batches of your use case anyway.)
In the meantime I also checked with other customers how they are dealing with getting such confirmations. When they do a firmware update, it also includes a new configuration.In this configuration, there is a piece of code that ensures that the device from now on sends a new version number with each uplink.
For example:
- A temperature sensor sends its temperature with version 1.0 every 4 hours in the same uplink.
- The sensor receives a firmware update
- From now on, the sensor always sends version 2.0 with each uplink, if not then the update was not succesfull
Hope this helps!
-
@Ederuiter @afzal_m
Thanks.
We were thinking in that direction (sending version)
Another reason why I asked is that since I started sending downlinks to a (devkit) device for testing purposes, the device now is extremely slow in sending messages. It takes minutes, sometimes hours to send a single message (uplink).
Could that be linked to not “collecting” the downlink messages?
