for NB-IoT there is a technical limitation of 1024 bytes (but this also includes the protocol information). According to our no harm to network guidelines you shouldn’t use more than 1 MB/device/month for NB-IoT.
@florian-duecker I’ve revolved the issue by using the off the shelf OpenVPN option T-Mobile offers: Summarized for others&future:
The IoT Easy Connect LTE-M connectivity assings a private IP-range (in my case 10.42.242.0/24) to the sim-cards.
The IoT Easy Connect Portal>Settings>OpenVPN describes how to setup an OpenVPN connection to T-Mobile.
Activating this tunnel on my server enabled me to ping the devices and to carry out various connectivity test.
@cees-meijer we plan to offer LTE-M in 2 flavors in the future:
replacement for GSM with communication over public APN without any middleware layer in between module and your servers - AVAILABLE NOW
alternative to NB-IoT with secure communication and access to data via webhook through IoT Creators platform (for this one we need a new component in our backend and still investigate the customer needs that helps us with proper planning) - FUTURE
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.
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.
Sorry for my long silence!
I just wanted to inform you that eDRX has eventually been enabled a few weeks ago and is available across our complete LTE-M network.
Please let me know if you have any questions when testing this feature.
@sergii-skorostetskyi we didn’t get to integrate the LTE-M traffic with our device management platform yet. We’re still working on displaying some SIM related data in the portal. We’ll hopefully launch this feature soon, please watch our release log page. Device management will come hopefully beginning of 2022.
Do you need sonething urgently? Please let me know what you are planning, because we usually plan our priorities according to user feedback.
(I’m sorry for the late response! Somehow this post wasn’t noticed in the “General discussion” section. My apologies.)
Yes, the SIM cards that we as IoT Creators send out are always activated when you get them delivered.
And our SIM can connect to the 4G network using our publick APN: m2m.public.nl
You can check our “roaming” page to read about operators and bands that you need for LTE-M at your location, please note that LTE-M is not necessarily available everywhere where you’ve got 4G coverage.
If all this seems to be fine on your end and you still can’t connect please tell us the details where you got stuck. (AT commands and module logs)
On the Sara N3 there is a special command NSOSTF (https://www.u-blox.com/sites/default/files/SARA-N2-Application-Development_AppNote_%28UBX-16017368%29.pdf) but could not find any other module that supports this type of command.
@Stefan-de-Lange ,@David-Micallef Quectel BC95-G also has the NSOSTF command, see AT commands manual. And I’m assuming that their other modules (some of which are NB + LTE-M) will have that command too.
after we integrated the connectivity from Magenta Austria in the last days with IoT Creators/SCS platform succesfully I tryed with my devkit Quectel BG96 not only NB-IoT but also LTE-M and GSM - unfortunately pure LTE is not supported by the devkit.
It worked immediatly 🙂
With following AT commands I could connect to our Telekom network in Germany and send UDP messages to our server:
# Set frequency band for Telekom Germany
# Set our APN
# Use 0 for GSM ...
# ... or 8 for LTE-M
# ... or 9 for NB-IoT
# Connect to our UDP server
# Send "hello world" as hex
I don’t see the URCs arriving at your screen. As described in my last message, please configure your URC port.
If it is configured correctly you should see something like this:
+QIND: SMS DONE
Notice that the +QCSCON: 1,1 and +CEREG: 5,“6F55”,“18CB40E”,8 pop up automatically.
Also right after turning on the radio with AT+CFUN=1 you can see
+QIND: SMS DONE
popping up automatically. I dont see that in your logs. Please configure your URC port and issue the commands as I’ve shown in the example here.
Together with The Things Industries we are combining LTE-M and LoRaWAN capabilities to provide an out-of-the-box connectivity solution allowing for easy to setup and secure device-to-cloud communication.
LTE-M features very good signal penetration, well-suited for standalone, managed gateways inside, for example, smart buildings. The solution will therefore start with a pre-configured LoRaWAN gateway from Mikrotik, connected over a LTE-M backhaul to LoRa devices and The Things Industry platform.
Use of LTE-M reduces costs compared to LTE because of more affordable hardware, and lower usage costs. Ease of use for the customer is guaranteed through no-touch provisioning of gateways, as they come pre-registered and only need powering up when installed. The gateway optionally supports LoRa 2.4GHz for global deployments.
To support IoT deployments in Germany and the Netherlands, an Early Access offer will be launched with LTE-M backhaul for solution providers and system integrators - learn more and get started 👈
@Stefan-de-Lange the PCBs for testing are open on Attribution-NonCommercial 4.0 International (CC BY-NC 4.0).
You have the freedom to copy it and re-measure it. But you will get the same result. Sometimes NB-IoT is better and sometimes LoRaWAN. You should also read before you judge something.
Awesome news ahead: LwM2M v1.2 specification is finally released! One of the headlining features of LwM2M v1.2 is LwM2M over MQTT! This is a good opportunity for LwM2M to get way more visibility, as MQTT (arguably the most popular IoT protocol) is currently missing any real data model.
LwM2M 1.2 feature highlights: 
State-of-the-art energy-efficient security—Leveraging (D)TLS 1.3 and Connection ID enhances security while reducing the challenges and energy losses of connecting devices over LPWAs like NB-IoT.
MQTT as a transport protocol—MQTT users can now add LwM2M device management functionality. Inversely, using MQTT as a transport mechanism for LwM2M simplifies connecting to the cloud in some scenarios.
Single-step device commissioning—Now, bootstrapping a device requires just a single bi-directional session instead of the previous five exchanges, saving time, energy, and other resources.
Optimized data reporting—LwM2M data-format optimizations shave bytes from each message, increasing energy-efficiency, device lifespan, and return-on-investment (ROI).
More details: 
New transports for LwM2M; this allows LwM2M messaging to be conveyed over MQTT and over HTTP.
Optimizations for the bootstrapping interface; this reduces the amount of data and the number of messages transmitted during the bootstrapping exchange.
Optimizations for the registration interface; this reduces the amount of data transmitted during registration exchanges.
Optimizations for the information reporting interface; observation attributes may now be included in an Observe operation.
Support for LwM2M gateway functionality; this allows non-LwM2M IoT devices as well as LwM2M devices behind a gateway to be connected to the LwM2M ecosystem and to manage those devices remotely.
New, highly optimized encoding format based on CBOR called LwM2M CBOR.
Enhanced functionality for firmware updates.
Definition of new notification attributes (edge, confirmable notification, and maximum historical queue). Edge allows notifications to be triggered on rising and falling edges. Confirmable notifications allow the control of reliable transmissions of notifications.
Maximum historical queue allows the control of time-series data usage. Clarifications of object versioning rules.
Updates to use the latest communication security protocols based on TLS and DTLS 1.3 (as well as the use of the Connection ID).
Flexibility to control the use of TLS and DTLS 1.3 through configuration information.
Untangling the relationship of security credentials and their server configuration.
As stated above, we will implement eDRX for LTE-M beginning of next year, but we cannot tell you exactly when right now (our current target is Q1 2021). As far as we know, most of the other European LTE-M operators haven’t yet enabled eDRX neither, but also plan to deploy it next year.
eDRX does not exist in 2G, only in LTE, and deployed primarily (if not exclusively) in its Low-Power Wide-Area categories (i.e. LTE-M and NB-IoT).
PSM is supported in all of DT’s LTE-M networks as well as in all of our roaming partner networks. Like eDRX, PSM has only been standardized in LTE networks and is not available for 2G.