Global Moderators

Hi Adriaan,

Yes, thats true. I also made the same observations. For such “advanced” testing purposes, I strongly recommend to use python using the socket library. The easiest way would be to start a new thread for each incoming device and a more advanced setup would be with one thread for incoming traffic and one thread for outgoing traffic using asyncio.

BR,
Kolja

Hi,

instead of creating and deleting complete subscriptions after you added or deleted devices you can add or remove the device to or from from the existing subscription.

In the following the Nokia IMPACT API samples

• to get the devices of an existing subscription,
• list itemto add a devices to an existing subscription,
• list itemto delete a devices from an existing subscription (important: if the last device of a subscription is delete the subscription it-self is deleted as well).

Get devices of an existing subscription

GET https://iot.netwerk.t-mobile.nl:443/m2m/subscriptions/f37b094d-307f-4d43-82c5-73f81104e22f/serialNumbers
HEADERS: {
 "Content-Type": "application/json", 
 "Accept": "application/json", 
 "Authorization": "Basic QVBJX0NPTsl8wMDssAswMDAbxNcTU4XzNlZmEzOkpySS9YOC45Y19CrrRmI0OEY="
} 
BODY: {
 "serialNumbers": [
 "IMEI:452749630137052", 
 "IMEI:351938100191440"
 ]
}

RETURN STATUS CODE: 200
RETURN BODY: {
  "serialNumbers": [
    "IMEI:454596441983713",
    "IMEI:351938100191440",
    "IMEI:866425033313638",
    "IMEI:452749630137052",
    "IMEI:352656100979544"
  ]
}

Add devices to an existing subscription

POST https://iot.netwerk.t-mobile.nl:443/m2m/subscriptions/f37b094d-307f-4d43-82c5-73f81104e22f/serialNumbers
HEADERS: {
  "Content-Type": "application/json", 
  "Accept": "application/json", 
  "Authorization": "Basic QVBJsX0NPTl8wMDsssswMDAbxNcTU4XzNlZmEzOkpySS9YOfgC45Y19CRmI0OEY="
}
BODY: {
  "serialNumbers": [
    "IMEI:452749630137052", 
    "IMEI:351938100191440"
  ]
}

RETURN STATUS CODE: 200
RETURN BODY: {
  "subscriptionId": "f37b094d-307f-4d43-82c5-73f81104e22f",
  "msg": "Success",
  "code": 1000
}

Delete devices from an existing subscription

DELETE https://iot.netwerk.t-mobile.nl:443/m2m/subscriptions/f37b094d-307f-4d43-82c5-73f81104e22f/serialNumbers
HEADERS: {
 "Content-Type": "application/json", 
 "Accept": "application/json", 
 "Authorization": "Basic QVBJsX0NPTl8wcMDssAwMDAbxNabcTU4XzNlZmEzOkpySS9YOC45Y19CRmI0OEY="
} 
BODY: {
 "serialNumbers": [
 "IMEI:452749630137052", 
 "IMEI:351938100191440"
 ]
}

RETURN STATUS CODE: 200
RETURN BODY: {
  "subscriptionId": "f37b094d-307f-4d43-82c5-73f81104e22f",
  "msg": "Success",
  "code": 1000
}

@magnatron It was never possible to store the application url if the application didn’t return 200.

In the old version the inital request contained an empty body to test if the URL is valid. This has actually changed. No an empty dictionary structure is put as payload.

Regads, Roland

Hi,

for your information:

IoT Creators platform (SCS) times out the message forwarding POST request to the application URL if the application doesn’t response within 5 seconds.

In case of timeout SCS tries to re-POST the message 5 times. Every minute one retry is performed.

While the systems trys to re-send the message no new messages are POSTed to the application. There are queued.

As roaming is more or less transparent for the device as well as backend-end server, this recommendation formulated here https://forum.iotcreators.com/topic/594/data-packet-size still applies.

@JakubT ,
May I ask you if you’re still encounting roaming connectivity issues?
If you do, please don’t hesitate to provide us more details about the exact problem you’re experiencing!
Best regards,
Ronan

Hi @Alessandro-Parmigiani ,
The RRC inactivity timer is set by the network and cannot be modified by the device. Its value is usually consistent within one network (there are exceptions, though!) but it is not necessarily identical across all network technologies (e.g. NB-IoT and LTE-M).
Note that for NB-IoT, the RRC inactivity timer may also have different values depending on the CE-Level in which the module is (CE0, 1 or 2).

In Germany, the timer is set to 10s for LTE-M and between 20s and 30s for NB-IoT depending on the area.
We are however reviewing those values at the moment and will most probably shorten the RRC inactivity timer for NB-IoT in the near future, especially for CE Level 0 and CE Level 1.
We will gladly inform you via this post whenever this change has been performed!

If your application however does not expect downlink data after sending an uplink message, we strongly recommend using the Release Assistance Indication on NB-IoT to bypass this RRC Inactivity period and immediatly switch to Idle mode (as mentioned by Stefan de Lange above).

RAI is supported across all DT NB-IoT networks, with some regional limitations within our Polish network.
This feature unfortunately isn’t yet available for LTE-M, but has been standardized by 3GPP. It is therefore likely to be implemented in the future both by module vendors and network providers.

Hope this can help!

Best regards,

Ronan

@JakubT,

This essentially depends on your SIM contract and associated tariff. If this tariff includes EU-Roaming for instance, then Roaming in all Roaming Partner networks should be possible, and not only in DT’s own affiliates’ network.
Best regards,
Ronan

@JakubT ,
Could you help us understand what you exactly mean with “SIM-based restrictions”? Which specific issues are you experiencing?
Are you also talking about a network technology specifically (e.g. NB-IoT or LTE-M)?
Best regards,
Ronan

Hi Peter,

I just contacted you via our support channel so I can do some additional tests to your connection.

Can you please send my your IMEIs as a response to the email which you just got.

Many thanks!

Regards, Roland