NB-IoT TCP Packet loss and retransmittions

[Vipul Panchal]

Hardware: nrf9160DK
Modem FW: v1.3.1

We have been evaluating and configuring our proprietary application for NB-IoT, which is initially designed for LTE-M (CAT-M1). The Application is designed to exchange data with the cloud using MQTT over TLS and works fine with LTE-M.
However, when explicitly configured to connect to NB-IoT only network, we see a lot of TLS handshakes getting timed out (even after increasing the TLS timeout from 20 seconds for LTE-M to 90 seconds for NB-IoT).
Evaluating the Network capture files we observed many instances of TCP packet retries especially when a large data is exchanged over several TCP segments (the case where the server and clients exchange the certificates and keys during a TLS handshake).

To remove the dependency of our application and to just test the MQTT over TLS on the NB-IoT network, we switched to using the nrfConnect sample application "asset_tracker_v2".
The "asset_tracker_v2" application was configured to connect to NB-IoT only network and modem trace enabled.
After letting the application execute for a few hours, analysis was done using the application logs, modem trace and network capture.
We still see the same behaviour (TCP packet retransmissions) with the large data exchanges over several TCP segments.

Typical behaviour is observed, after receiving the first TCP segment of a large data packet, the modem seems to be not accepting any further segments for a period of approximately 20 seconds. (see the attached screenshot of the comparison between modem trace(left) and network capture (right))
Are we missing any configuration or can you give an explanation of the behaviour?

Also, attached is the Application Log, Modem Trace and Network capture for your further investigation.attachments.zip

[Øyvind]

Hello, 

my initial thought is the LTE-M vs NB-Iot bandwidth e.g.

Features	LTE-M	NB-IoT
Also known as	LTE CAT-M1, Enhanced Machine Type Communication (eMTC)	LTE Cat-NB1 (3GPP rel 13)	LTE Cat-NB2 (3GPP rel 14)
Bandwidth	1.4 MHz	200 kHz	200 kHz
Max throughput (DL/UL)	300/375 kbps	30/60 kbps	127/169 kbps
Latency	50-100ms	1.5-10s
Typical range	<11 km	<15 km	<15 km
Mobility/cell reselection	Yes	No	Limited
Roaming	Yes	Limited	Limited
Deployment density	Up to 50 000 per cell	Up to 50 000 per cell	Up to 50 000 per cell
Battery lifetime	Up to 12 years1

What is your location? Do you have equal access to both LTE-M and NB-IoT?

Will have a look at your attachments, in the meantime please read through our white paper nWP044 - Best practices for cellular IoT development. 

Kind regards,
Øyvind

[Øyvind]

A quick look at the log output you provided I find the following reject causes when connecting to NB-IoT

2022-04-13T08:35:41.826Z DEBUG modem << +CEREG: 2,"640F","0028C515",9,0,9
2022-04-13T08:35:42.732Z DEBUG modem << +CEREG: 2,"640F","0028C515",9,0,13

Cause #9 – UE identity cannot be derived by the network.

This EMM cause is sent to the UE when the network cannot derive the UE’s identity from the GUTI/S-TMSI/P-TMSI and RAI e.g. no matching identity/context in the network or failure to validate the UE’s identity due to integrity check failure of the received message.

Cause #13 – Roaming not allowed in this tracking area

This EMM cause is sent to an UE which requests service, or if the network initiates a detach request, in a tracking area of a PLMN which by subscription offers roaming to that UE but not in that tracking area.

Please verify SIM/status with your network provider.