Hi Andreas,

in general the MTU size for NB-IoT is not handled differently on the network side than for plain LTE. Choosing 1500 Bytes, which is the maximum for ethernet-based links can be considered as a good upper bound.
However, there are some points to consider bevor configuring this value. NB-IoT is usually used via private APNs (Mobile IP VPN NB-IoT). This means that an VPN connection via IPSec is established between our PGW and the customers infrastructure. The IPSec connection adds additional overhead and constraints on the effectively usable MTU size, for servers and devices behind the tunnel interfaces.
For instance, IPSec connections terminating on an AWS Site-to-Site GW are restricted to a MTU size of 1438 Bytes for devices and servers.
This means, that if you want to maximize the MTU, you need to determine the optimal size for each setup individually.

Actually, this is not a very complicated process. Once, the IPSec connection is established this can be achieved using ICMP pings, which are available on every common platform. On Linux-based servers the command:

ping <TARGET IP> -M do -s <MTU size - 28 Bytes>

can be used. Where <TARGET IP> is the IP-adress of a terminal attached to the network, using the private APN. The MTU size to be probed needs to be reduced by 28 Bytes to account for IP and ICMP headers.
If the ping is answered the MTU size can be increased otherwise, it has to be reduced. Usually, the response will already tell you which hop on the path requires fragmentation.

Cheers,
Thorsten

Hi Lorenz,

from the log in one of your previous posts it is pretty obvious, that your module is loosing its connection periodically.

What is really weird, is the fact, the the connection losses sometimes happen at times at which the module should be in PSM (e.g. reconnect 3:48 am). That suggests that the module is not even entering PSM, although the appropriate timers have been assigned by the network. You could check this by activating the URC:

AT+NPSMR=1

which provides indication for entering/leaving PSM. If the module is indeed entering PSM, this is a clear indication, that the detachment is initiated by the module, as the network would not be able to detach a module gracefully during PSM.

It is hard to say what is going on here without a trace from either the module or the network, but this is definitely erroneous behavior. There is no mechanism in the network which is causing periodic detachments, except for missing TAUs, and they seem to be fine.
However, what can be ruled out is the scan for the HPLMN in roaming, as this would not interrupt PSM and the interval for this scan is larger than 1 hour in the DT NB-IoT network. Furthermore, it would not cause a connection loss, or at least not on a correctly working module.

Unfortunately, the log does not tell whether the signal quality has changed during the test. Initially a very good signal was observed, but for the following data events the signal quality is queried too early to provide meaningful values. Maybe you can adjust your script to query the signal quality right after the +CEREG: 5,… and +NSOSTR URCs, which should always yield meaningful values.

For further troubleshooting you can collect traces on the module and send them for inspection to Quectel via your distributor. To get a dedicated support ticket for an investigation on the network side you would have to contact 1nce.

Best regards,
Thorsten

Hi Andreas,

in general the MTU size for NB-IoT is not handled differently on the network side than for plain LTE. Choosing 1500 Bytes, which is the maximum for ethernet-based links can be considered as a good upper bound.
However, there are some points to consider bevor configuring this value. NB-IoT is usually used via private APNs (Mobile IP VPN NB-IoT). This means that an VPN connection via IPSec is established between our PGW and the customers infrastructure. The IPSec connection adds additional overhead and constraints on the effectively usable MTU size, for servers and devices behind the tunnel interfaces.
For instance, IPSec connections terminating on an AWS Site-to-Site GW are restricted to a MTU size of 1438 Bytes for devices and servers.
This means, that if you want to maximize the MTU, you need to determine the optimal size for each setup individually.

Actually, this is not a very complicated process. Once, the IPSec connection is established this can be achieved using ICMP pings, which are available on every common platform. On Linux-based servers the command:

ping <TARGET IP> -M do -s <MTU size - 28 Bytes>

can be used. Where <TARGET IP> is the IP-adress of a terminal attached to the network, using the private APN. The MTU size to be probed needs to be reduced by 28 Bytes to account for IP and ICMP headers.
If the ping is answered the MTU size can be increased otherwise, it has to be reduced. Usually, the response will already tell you which hop on the path requires fragmentation.

Cheers,
Thorsten

@inge-eriksen
Hi Inge,

all of our SIMs for M2M and IoT are G-SIMs, which means that technically they are always roaming. So a query for the registration state, for instance with AT+CEREG, should always yield: 5.
On our testcards, we have currently no HPLMN deployed. For this reason the modem searches for a suitable network and will consider any NB-IoT network on the supported bands.
To make sure that the modem will only connect to the DT network, you can either fall back to manual network selection (PLMN-Id=26201), or restrict the supported bands to band 8. This will exclude any operators in Germany for which we have not yet roaming agreements.

Best regards,
Thorsten

Hi Inge,

alright, I was just confused because of the statement “eSim from T-mobile”. Anyway, this means you have probably a card with the APN internet.nbiot.telekom.de is this correct?

With this a connection to any server in the internet should be possible, as long as you do the addressing via IP.

Best regards,
Thorsten

Hi Inge,

the information provided in this thread is somewhat confusing for me, so I have to ask some questions in return to assess the problem. You state, that you are using an embedded SIM from T-Mobile NL and that you have no access to the Telekom Deutschland network in Germany, is this correct?
Have you checked, if the card is enabled for roaming within other Natcos of DT? Not all cards are allowed to do so. Your sales contact at T-Mobile NL should be able to provide this information.
In general we offer cards for testing with access to any given public IP in the the Internet via TCP or UDP. In any case, the addressing needs to be done with the public IP of your server, as our NB-IoT network does not resolve DNS queries.
Could you also provide the API calls to the nrf9160 which you are using to attach to the network? In particular those for APN configuration, Attach and configuration of bands.

Best regards,
Thorsten