@MarcoPeli Thank you, this was the problem. 😉

By using eDRX the device is able to receive downlink messages without sending uplinks.

Let me know if this helps:

https://docs.iotcreators.com/reference/send-base64-edrx-downlink-message

@GrandPep I had a look to your configurations. I saw that you registered for your API account an application URL but I cannot see any subscriptions. I will verify it and come back to you…

Regards, Roland

Hello again toustousio,

the reason why devices have to send an uplink message first to receive downlink messages lies in the nature of low-power wide-area devices, which are designed to use as little energy as possible to maximize battery life. This is achieved by putting devices to sleep. Keeping an open channel that can constantly receive data would go against any power-saving measures. Therefore, a device has to initiate the communication and basically send a “heartbeat” message to show that it is awake and available to receive information. Just like LoRaWAN class A devices, which do not maintain a constant network connection to reduce power consumption.

Using NB-IoT and eDRX, it is possible to move the buffering function of messages into the network to send the messages directly to your devices, without sending an uplink message to our platform every time before receiving downlink messages.
This is possible via our API and works just like sending a downlink message as described here with a few changes that I have detailed below.

URL: https://api.scs.iot.telekom.com:443/m2m/endpoints/<SERIAL-NUMBER>/downlinkMsgBase64Drx/0/data

HEADER:
Content-Type: application/json
Accept: application/json
Authorization: Basic <based64(<API-USERNAME>:<API-PASSWORD>)>

BODY:
{
“resourceValue”:<YOUR base64 encoded VALUE>
}

KEEP IN MIND:

This function requires that <YOUR VALUE> is a base64 encoded. Before it is sent to the device <YOUR VALUE> is decoded, to be able to send binary data without double the data volume caused by the hex format. eDRX messages are sent to the mobile network and buffered/queued by the network provider while the device is sleeping. Because eDRX messages need to be sent to an IP address our server stores the last IP address from the last uplink message and if you haven’t send any uplink messages or if your device has renewed its IP address, the eDRX message cannot reach your device. Deutsche Telekom’s network is configured to store a max of 10 messages with 500 bytes per IMSI. This is also limited to a certain percentage of the specified number of devices (overall capacity). This behavior can deviate for roaming scenarios, since not all networks are configured the same way.

I hope this answers your question.
Do not hesitate to reach out, if you have any addtional questions or problems.

Hi,

the first version of documentation for SIMCom SIM7022 how to

attach the device to Telekom NB-IoT network of IoT Creators and get assigned an IP address. Send “Hello World” uplink message via UDP from device to IoT Creators UDP server. Send “Hello Device” downlink message via UDP from IoT Creators portal to device. Receive “Hello Device” downlink message on device via UDP from IoT Creators UDP server.

is available now in IoT Creators documentation library.

https://docs.iotcreators.com/docs/simcom-sim7022

Would be great if you check it and give me some feedback for improvements and corrections.

Regards, Roland

@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

Last comment …

This is valid only for non eDRX downlink messages. eDRX messages are sent directly into the network and will be buffered by the mobile network until the device is available.

Unfortunately I don’t know how long the downlink message is buffered by the mobile Telekom network 😞

Regards, Roland

@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?

Hello guys

@Yassine-Amraue : thank you for explaining that there is a GUI and an API user. I’ve been banging my head trying to send a downlink message via API and always getting an ‘unauthorized’ error. But after registering a callback URL for the API user as well I can now send downlink messages via API to my device. Thanks again.

@magnatron : I am using a SIM7020 based device and previously via API sent downlink messages are getting delivered to it as soon as the device sends an uplink message.

Thanks
Felix

Hey @afzal_m,

Thanks for explaining. This helps.

Please consider making this a protocol when sending out emails about service interruptions (planned or not).

And please let us know what will happen with the sent data: Will devices need to send it again or will it arrive at our application after the update was successful?

Once we know this, we can tell our customers what to expect and how to act on degraded functionality,

Currently the API supports the following for functions/URLs to send downlink messages to the device

downlinkMsg/0/data
Sends regular queued downlink messages to device when uplink is received.

downlinkMsgBase64/0/data
Sends queued binary data blob message to device when an uplink is received. The function expects base64 encoded payload from the applaction as input into this function. Before the message is sent to the device it is decoded back to binary and sent to the device.

downlinkMsgDrx/0/data
Same like downlinkMsg/0/data but without queuing.

downlinkMsgBase64Drx/0/data
Same like downlinkMsgBase64/0/data but without queuing.

@Eric-Barten said in Downlink API dataformat:

ary the device visualizes the received data for yo

Okay, that my bad.
Thanks for the answer

@David-Netten

Hi David,

you are right, that the UDP server of IoT Creators doesn’t send back an acknowledgment for a received messages.

BUT: The CoAP/Leul server of IoT Creators acknowledges a received messages with a “2.05 Content” acknowlegment.

Be aware that CoAP/Leul is the Huawei flavor of CoAP and it is supported by Huawei chipset such as HiSilicon which are used in moduls such ublox N211 or Quectel BC95.

For many customers it is not enough to have an acknowledgment between the device and the IoT middleware. The implement an asynchronous acknowledgment between the application and the device on the basis of a downlink message. If you would need the asynchnronous application acknowledgment it wouldn’t make a difference between CoAP/Leul and pure UDP.

Regards, Roland

​

@Yosiel

That is great. Just reach out when you need assistance again. 🙂

@afzal_m Yes, I tried it few minutes before you wrote here 🙂 and it works!

Thank you very much, we can continue in our small project…

Thanks. We’re checking again. Get back to you soon…

I found the problem, I use an arduino leonardo with a dragino nbiot shield. For incomming/outgoing messages i use SoftwareSerial.h, to change the tx/rx pins to pins 10/11.

I fixed the problem by using the normal rx/tx pins and it works. Hence the library seems to be my problem.

Hope this helps anyone.

There is no option to query the status of a downlink message. Buffering of downlink messages may occur on different places in our solution it is hard to give an clear response to such a request due to the asynchronous nature of the protocols.

Note: after sending an uplink message we will try to downlink all buffered messages.

@sopwafel You could, but be aware of using PSM and expected latency. Your device might be sleeping again before it had the chance to receive a downlink message. I don’t know if it’s possible to use in combination with the T-Mobile CDP but you might want to take a look at LWM2M and CoAP. These protocols have acknowledgements build in.

The term “latency” relates to one-way, downlink or uplink communication. It does not include the time needed to establish a connection between the server and the device. If the device is in power saving mode, it will only receive or send data after it wakes up. According to measurements on current test setups with pre-commercial radio modules, data transmissions typically exhibit a latency of less than a second. In scenarios involving deployments in poor coverage areas, latency may increase up to 7-10 seconds. That said, NB-IoT technology is continuously being enhanced, so current figures are expected to improve with successive releases of the specification.

NB-IoT supports bidirectional communication, but the more common direction is uplink transmission. Only half-duplex is supported, i.e. uplink and downlink don’t take part simultaneously.

UL peak rate up to 230 kbps DL peak rate up to 250 kbps

Please note that these are not the datarates meanwhile. Current datarates are maximum 20Kbps UL/DL due to single tone transmission.

Does it also work for @trick2011 now?