nRF9160 large difference in connection duration

RE: nRF9160 large difference in connection duration

Achim Kraus — Thu, 16 Mar 2023 11:49:12 GMT

> We will swap to another provider

Just take care. If it's a "global SIM" 9xxxx and you use mfw 1.3.2 or newer, there is a pitfall with HPPLMN searchs (that depends also on the HPPLMN search interval on the SIM). With such a SIM you will be faced a couple of searches for a 9xxxx network, even if your just in a common country. In my case that caused 1800mC every 2h (2h is the search interval on my previous SIM cards).

Good luck. It's not easy to find SIM cards, which are really fits low power use-cases.

RE: nRF9160 large difference in connection duration

Willem21 — Thu, 16 Mar 2023 11:31:03 GMT

Hi Achim,

We will swap to another provider since the Telenor SIM always uses roaming
and there is no guarantee that PSM/cDRX/eDRX is available.
This case can be closed.

Thanks for the support.

With best regards,

Willem

RE: nRF9160 large difference in connection duration

Achim Kraus — Mon, 06 Mar 2023 15:46:04 GMT

> The Wireshark capture still shows TCP IP messages, so think it are the real messages?

Yep, then ask your network provider.

> I use LTE-M to use minimal power.

In my experience, LTE-M PSM without RAI is not better than NB-IoT PSM with RAI (100mC vs. 80mC with about 10s RRC activity timer).

> Is it correct that I can't use RAI with LTE-M?

AFAIK that depends on your provider and the modem support. I've seen someone wrote to use AS RAI for LTE-M (see nRF9160 - AT RAI ), but I never managed to used it successful for now.

RE: nRF9160 large difference in connection duration

Achim Kraus — Mon, 06 Mar 2023 13:55:06 GMT

You'll see in the pcapng the RRCConnectionRelease. It's always about 20s after the last traffic.

The unintended TCP traffic is then from 15-200s. If you can get rid of it, you have the most done.

If you then want to optimize the left 20s, the consider to use RAI, if that's possible for your use-case.

But the very first thing is to ask your provider.

RE: nRF9160 large difference in connection duration

Willem21 — Mon, 06 Mar 2023 13:16:57 GMT

Hi Simon,

I've no more logging than shown in "serial log.txt", .pcapng and .bin.
How can I enable the logging of "RRC connection"?

Thanks for you reply in advance.

Best regards,

Willem

RE: nRF9160 large difference in connection duration

Willem21 — Mon, 06 Mar 2023 13:06:29 GMT

"Autoselect Trace DB" was enabled, so the correct database should be selected
I repeated the trace with "Select Trace DB" "mfw_nrf9160_1.3.4_trace-db.json"
The Wireshark capture still shows TCP IP messages, so think it are the real messages?

devzone.nordicsemi.com/.../trace_2D00_2023_2D00_03_2D00_06T09_2D00_19_2D00_01.043Z.pcapng

I use LTE-M to use minimal power.
Is it correct that I can't use RAI with LTE-M?
Is there another solution for LTE-M?

I will also ask the provider.

RE: nRF9160 large difference in connection duration

Simonr — Mon, 06 Mar 2023 11:43:38 GMT

Hi Willem

Just to add to what Achim has already written. From the power profiler trace this seems to be the RRC connection timing out. Since the network provider is the deciding factor on how long the RRC inactivity timer should be, it seems to set different timeouts upon every connection, which seems strange to me, but I think it's entirely up to the network provider to set it, and that it doesn't have to be constant. Upon connection, is there any logging showing what the RRC connection is set to perhaps?

Best regards,

Simon

RE: nRF9160 large difference in connection duration

Achim Kraus — Mon, 06 Mar 2023 10:32:13 GMT

> Are all these incoming TCP IP-messages necessary?

Do you use the right database for the mfw 1.3.4 and the capture therefore shows the real messages?

The TCP stuff is sure not necessary. In my opinion it should not be forwarded from the provider to the modem at all. But from the "cellular network", this are messages, which keeps the modem in RRC connected and so it enters the sleep mode delayed.

That TCP stuff is not originated from the modem (at least, I see only incoming messages, which are then answered).

There are three ways to go:

- ask your provider, why such TCP sync messages are forwarded to your modem and which other choices are offered.

- Switch of the modem with CFUN=0 and on again with CFUN=1. Switching every 5 Minutes you need also to check with your provider, if this is allowed. Not that your device gets blocked by the provider for too many registrations.

- enable RAI for "no response" (4, just one outgoing message). But once you want the receive an answer back, "one response" (3) will be required and if you check the times in the capture, then this may fail because of the unintended TCP traffic.

My conclusion:

Ask you provider about the TCP message and the available network options.

RE: nRF9160 large difference in connection duration

Willem21 — Mon, 06 Mar 2023 10:12:41 GMT

Are all these incoming TCP IP-messages necessary?
In order to safe power:
Is it possible to shut down all communications just after the UDP message is send?
And reconnect when it's time to send the next UDP message?

RE: nRF9160 large difference in connection duration

Achim Kraus — Fri, 03 Mar 2023 18:53:32 GMT

The capture shows some outgoing UDP traffic from the device to 8.8.8.8, that's what the sample does.

And it shows a lot of additional incoming TCP IP-messages from several other peers, which are then answered from the device, why ever.

I'm not sure, if that capture was extracted with the right database version for mfw 1.3.4. If so, your providers gateway/breakout forward a lot of traffic, which keeps your device "connected".