NB-IoT TCP Packet loss and retransmittions

RE: NB-IoT TCP Packet loss and retransmittions

Øyvind — Tue, 03 May 2022 12:10:16 GMT

Please see answer from our nRF91 team:

There are two things that are causing delays and re-transmissions

The network has not enabled enableStatusReportSN-Gap configuration in eNB. This means that UE can't report about missing RLC PDU once it has been noticed. Instead, the report of missing RLC PDU is sent after there is nothing to transmit and network polls the device. This brings the delay in attached picture the customer is asking for. RLC PDU from the first TCP segment is lost and UE must wait for re-transmission from network.

TCP re-transmissions. Due to missing TCP ACKs the server starts to re-transmit TCP packets. This makes things even worse in lower layers as re-transmission of RLC PDUs happen when there is nothing to be send. TCP re-transmission makes the send queue even longer and missing RLC PDUs are sent with increasing delay.

When it might be difficult to add support for enableStatusReportSN-Gap in network the only way would be trying to increase TCP re-transmission timeout in server side. This may shorten the RLC PDU re-transmission delay and make the overall transmission faster.

Kind regards,
Øyvind

RE: NB-IoT TCP Packet loss and retransmittions

Vipul Panchal — Thu, 28 Apr 2022 13:02:40 GMT

We have our test network which is configured for NB-IoT (NB1)
I agree, you may be seeing the logs showing problems registering to the network as these are complete logs and we may be in the middle of changing some configuration or setting up the test network.
That's why I am not concerned about the device not registering. What I am more concerned about is when it successfully registers to the network, it faces issues transferring data over TCP packets (The modem seems to not receive any packets for around 20 seconds, highlighted in the screenshot).

RE: NB-IoT TCP Packet loss and retransmittions

Øyvind — Thu, 28 Apr 2022 08:41:55 GMT

Can you provide more information on what network you are trying to connect to? What version of nRF Connect SDK are you working on?

From your PCAP I see that you are receiving the following: +CGDCONT: 0,"IP","test123","192.168.3.2",0,0 OK

The provided log output from LTE Link Monitor has the following output several times:

2022-04-13T05:18:31.917Z DEBUG modem << [25:52:00.274,871] [0m<inf> event_manager: APP_EVT_DATA_GET_ALL[0m
2022-04-13T05:18:31.970Z DEBUG modem << [25:52:00.281,524] [0m<inf> event_manager: APP_EVT_DATA_GET - Requested data types (MOD_DYN, BAT, ENV, NEIGHBOR_CELLS, GNSS)[0m
2022-04-13T05:18:31.971Z DEBUG modem << [25:52:00.299,285] [1;33m<wrn> gnss_module: Failed to set GNSS fix interval, error: -22[0m
2022-04-13T05:18:31.973Z DEBUG modem << [25:52:00.310,974] [0m<inf> event_manager: SENSOR_EVT_ENVIRONMENTAL_NOT_SUPPORTED[0m
2022-04-13T05:18:32.002Z DEBUG modem << [25:52:00.357,696] [1;31m<err> modem_info_params: Link data not obtained: 5 -22[0m
2022-04-13T05:18:32.016Z DEBUG modem << [25:52:00.370,574] [1;31m<err> modem_info_params: Link data not obtained: 8 -22[0m
2022-04-13T05:18:32.038Z DEBUG modem << [25:52:00.388,671] [1;31m<err> modem_info_params: Link data not obtained: 3 -22[0m
2022-04-13T05:18:32.074Z DEBUG modem << [25:52:00.429,748] [1;31m<err> modem_info_params: Network data not obtained: -66[0m
2022-04-13T05:18:32.087Z DEBUG modem << [25:52:00.437,774] [1;31m<err> modem_module: modem_info_params_get, error: -11[0m
2022-04-13T05:18:32.098Z DEBUG modem << [25:52:00.445,678] [0m<inf> event_manager: MODEM_EVT_MODEM_DYNAMIC_DATA_NOT_READY[0m
2022-04-13T05:18:32.145Z DEBUG modem << [25:52:00.501,251] [1;31m<err> modem_info_params: Link data not obtained: 5 -22[0m
2022-04-13T05:18:32.161Z DEBUG modem << [25:52:00.513,610] [1;31m<err> modem_info_params: Link data not obtained: 8 -22[0m
2022-04-13T05:18:32.177Z DEBUG modem << [25:52:00.531,677] [1;31m<err> modem_info_params: Link data not obtained: 3 -22[0m
2022-04-13T05:18:32.217Z DEBUG modem << [25:52:00.572,326] [1;31m<err> modem_info_params: Network data not obtained: -66[0m
2022-04-13T05:18:32.237Z DEBUG modem << [25:52:00.580,352] [1;31m<err> modem_module: modem_info_params_get, error: -11[0m
2022-04-13T05:18:32.242Z DEBUG modem << [25:52:00.588,226] [0m<inf> event_manager: MODEM_EVT_BATTERY_DATA_NOT_READY[0m

[quote user="Vipul Panchal"]The problem is not with registering to a network.[/quote]

Yes, this is the problem from what I can see.

RE: NB-IoT TCP Packet loss and retransmittions

Vipul Panchal — Fri, 22 Apr 2022 14:25:34 GMT

Hi,

Thanks for your response.

The device being tested is in UK and we are using a test NB-IoT network (using Nutaq).
The problem is not with registering to a network. The problem is with modem not accepting the TCP segments (which are transmitted by the server, seen in the network capture. however not getting received on the client-side, seen in the modem trace)
Have a look at the image in the attachments.zip, where it shows a duration of approximately 20 seconds when the modem doesn't log any TCP packets whereas the server is sending them at the same time.

RE: NB-IoT TCP Packet loss and retransmittions

Øyvind — Fri, 22 Apr 2022 12:25:49 GMT

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.

RE: NB-IoT TCP Packet loss and retransmittions

Øyvind — Fri, 22 Apr 2022 12:19:29 GMT

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 years¹

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