Take this information with a grain of salt until we can get an expert on NB IoT technology to answer this question, but the CE level should be set by the modem based on the measured downlink received signal power and increased automatically when the random access preamble retransmission limit set for the current CE level by the network has been reached.
How long it takes to reach this limit depends on the limit and the period between retries (waiting for the network’s random access response).

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.

Hello Mario,
sorry for the late reply, I am definitely not more knowledgable, but I hope that fm’s hints have helped you to find a way to change your DNS servers via the +UPSD command.
If not, I have checked the documentation for your module and the Syntax looks as follows:

AT+UPSD=<profile_id>,<param_
tag>,<param_val>

The values should be:
<profile_id>: 1
<param_tag>: 4 for primary DNS; 5 for secondary DNS
<param_val>: “xxx.yyy.zzz.www” [your desired DNS’s IP]

While looking for the information, I also noticed a topic where another modem did not receive DNS servers from the provider due to a firmware issue, so maybe an update will alleviate the problem as well.

I will also check whether DNS info should normally be provided at that APN for LTE-M SIMs or not.

let us know how it went
olli

Hello @Mikael-Guenais,
NB-IoT roaming is available in France via SFR. You can also always find up-to-date information on our roaming partners in our documentation library here.

I will contact you about the SIM card directly from our support email.

Best regards
Oliver

@Kevin-van-Bakel-0 you can absolutely still experiment with the T-Mobile NB-IoT network with those SIM cards, but they are part of a different service and are not usable in conjunction with IoT Creators. We have our own SIM cards with a specific profile that allows us to authenticate the SIMs and manage connections. IoT Easy Connect Start is pure connectivity and does not offer access to IoT Creators’ data-as-a-service, so you can still connect to the internet with the card via the APN “iot.t-mobile.nl” (specification), but if you want to try out IoT Creators’ platform, then you will have to get a SIM from us.

If you are still interested in using IoT Creators and not a public APN for pure connectivity, just get in touch with us and we’ll get you a SIM for your Starter plan. We offer the Starter plan with one SIM for free when you register, so you can test everything and if you have already created an account with it, but skipped the SIM ordering, because you thought that your IoT Easy Connect Start SIM would work for it, then we can easily manually send a SIM to your preferred address for use with IoT Creators. I just need a short ping from your end what you would like to do and you address.

Hello Kevin,

I think the solution is the SIM card that you have (IoT Easy Connect Start), which is not a SIM card enabled for our “cdp.iot.t-mobile.nl” APN. Therefore, you would not be able to connect to our platform with this SIM card, but will have to get a SIM card through iotcreators.com.
It looks like you haven’t ordered a SIM card with your Starter plan, correct?
In that case, I can send you one, just submit your preferred shipping address to support@iotcreators.com.

We have a partnership for NB-IoT with A1 Slovenija in Sovenia, so this was not intentional and will be fixed.
My previous suggestion unfortunately does not work properly, so contacting us directly is the best way to order in this case.
Sorry for the confusion.

Hello @Mikael-Guenais,
NB-IoT roaming is available in France via SFR. You can also always find up-to-date information on our roaming partners in our documentation library here.

I will contact you about the SIM card directly from our support email.

Best regards
Oliver

Take this information with a grain of salt until we can get an expert on NB IoT technology to answer this question, but the CE level should be set by the modem based on the measured downlink received signal power and increased automatically when the random access preamble retransmission limit set for the current CE level by the network has been reached.
How long it takes to reach this limit depends on the limit and the period between retries (waiting for the network’s random access response).

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.

@toustousio said in Why class A behavior ?:

I was wondering why does the iotcreators platforms treats devices as the equivalent of LoRaWAN class A devices (meaning the downlinks can only be received after an uplink) ? Is there a technical reason to why we can’t receive a downlink without having sent an uplink just before ?

Let me check this out for you toustousio with our technical experts. I’ll get back to you a this week, if one of them won’t directly answer here already.

For anybody experiencing a similar issue:
The problem with the module in question (SARA-R510M8S HW rev. 00B) has been acknowledged by u-blox and they will have it resolved in their next hardware revision 01B.
Unfortunately, there will be no fix beyond Mario’s workaround from u-blox for hw revision 00B.
Thx to Mario for the thorough analysis and help in getting this issue resolved.

Hej Gerrit,

I’m sorry to hear that you are having problems with additional devices. Unfortunately, we won’t be able to troubleshoot easyconnect SIMs from T-Mobile as they are not connected to IoT Creators.
T-Mobile should have a support number, which you can call for help or you could reach out to 1nce, since the service is based on their platform.
If you are using SIM cards from IoT Creators, then the APN advice from fm would be your best bet and you can also contact us again with the SIM card details to troubleshoot them on our end, if that hasn’t solved your issues.

@mario
Just as a heads up, I am tracking this topic internally, but I have to rely on feedback from our network people, in order to make any educated statements.
This is taking a little longer than I’d like it to, but thanks again for writing up your troubleshooting in such detail, this definitely helps.

If you’re open for a conversation, I’d love to hear from you about how the whole support journey looked for you and learn about positive and negative aspects that you encountered, so we can do better in the future. You can email me to set up a call, if you’re interested and available.