Before activating radio module Set APN with AT+QCGDEFCONT rather than **AT+CGDCONT
Set frequency band explicity with AT+QBAND
Configure first APN, fequency band and mobile operator ID before switching on automatic attachment
WUS and other 3GPP Release 15 features aren’t yet supported in the DT networks and to our knoweldge in most other Operator networks.
Our focus is right now on completing the roll-out of key features like eDRX, while in parallel planning the introduction of new Rel. 14 features like New Category NB2.
WUS and other important Rel. 15 features are of course already on our Roadmap, unfortunately we cannot give you a concrete date when those will be deployed in the our networks yet.
Can’t eDRX to a certain extent address your power saving requirements for the time being?
The 2 hours is probably related to the 3GPP TAU timer, if it expires the device is implicitly released from the network I believe. Which is bad if you have a device that wants to sleep for more than 2 hours. So usually you set this value to whatever is the greatest the network accepts. You can run AT+CEREG=5, AT+CEREG? and check the returned values. It will tell you the timers that are used.
is the feature ‘network time’ (3GPP 27.007 Ch. 8.15) for NB-IOT/Cat-M1 supported in the Deutsche Telekom mobile network?
The NRF9160 SIP returns an error, while requesting the time. Also after a long time of being connected.
Hi Sven, sorry that it took us so long.
But now we have a clear statement from our experts that the network time feature is NOT supported in our network in Germany.
I did “normal” TCP/IP MQTT on top of NB-IoT connection with the Quectel BC66. So TCP/IP is possible. But I didn’t try to post a normal HTTP request.
LWM2M is implemented on top of CoAP and UDP. By this it works perfectly on NB-IoT. It is also supported by Quectel BC66. We tested it successfully with Eclipse Leshan server and the Nokia Impact LWM2M server.
We do these tests in parallel to normal network maintenance and improvement measures and we can share some preliminary results in CE-0 conditions from measurements in our Labs.
• Up to 200 devices can attach successfully simultaneously within 10 minutes under the condition that they do not immediately send data after a successful attach.
• Average round trip time (RTT) increases with increasing number of parallel transmitting devices. A randomization of transmission attempts leads to reduction of RTT and potentially improvement of battery lifetime
• With regards to the initial attach, only a small number of devices should be activated simultaneously (max. 60 devices)
• With regards to the regular data transmission with good signal level the following was observed:
• Failure rates increase with more than 160 devices trying to send 100 byte of data within one second
• Introducing a randomization timer of at least 40 seconds solves this limitation
• Avoiding synchronized data transmission results in better share of coverage levels across all devices
• Implication - Customers should avoid synchronized attaches and data-transmission of their devices
Currently, data packet buffering works only in combination with PSM, in the nearest future it should also work with eDRX. So once you activated this feature on your module, packets will be buffered automatically.
I’m trying to connect an Arduino MKRNB1500 to MS Azure IoT Hub but I constantly get the error -2 (Connection refused) on both port 443 and 8883. If I try to run the exact same script with a different SIM and carrier everything works perfectly.
My company uses T-Mobile SIMs and with those SIMs I can’t establish a connection to the IoT Hub.
Is T-Mobile blocking any ports on the mobile network in the NL or is there another fix for this problem?
Thanks a lot!
You can’t access any server on the internet directly, this is why it’s not working. The CDP is always in between and acts as a proxy. You can register a URL as an endpoint and the CDP will forward any trafic it receives from your device to your registered endpoint
Unfortunately there is no interactive map for the coverage of NB-IoT in Poland.
However, T-Mobile Poland has published a press release in which they announced the nationwide coverage (coverage of 94%).
They also published a map where you can get an overview of the coverage in different regions:
thanks for your offer. But I think at the moment it is not necessary to conduct tests in your lab in Bonn. We have the oppotunity to do some tests with a network simulator in an other Honeywell department (in India). If I will have the need for testing in Bonn before June, I would gladly come back to your offer.
every module supplier implement their own Maximal Transfer Unit (MTU). They can reach up to 1.358 Bytes.
If the message is larger than the MTU, the message should be divided into smaller messages.
We only limit the amount of data per month and the number of daily messages per device.