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.

Will the current hardware support Rel. 14 via a firmware update?