nRF9160 Message Delivery Issue with Truphone eSIM (probably due to PSM)

[Skorostetskyi]

I am writing to seek assistance with a challenging issue I've encountered in a project involving the nRF9160 module and Truphone eSIM for a pet tracker application.

I have recently come across a behavior that appears to be related to Power Saving Mode (PSM) settings, specifically with Truphone SIM (I have eSIMs and a normal SIM card). After further investigation, I have identified that the root cause of the issue is likely due to my experimentation with PSM settings.

Here are some key points regarding the situation:

• Messages sent from the nRF9160 Development Kit (DK) to our MQTT server are delivered promptly and reliably.
• However, when attempting to send messages from the MQTT server to the DK, the process is sporadic, especially when the modem enters Idle mode (as indicated by +CSCON: 0 and RRC mode: Idle).
• It's important to note that this behavior is not observed when using an iBases SIM card with an identical hardware and firmware configuration.
• During my testing phase, I inadvertently altered the PSM settings for a specific Truphone eSIM, probably leading to the TAU value of 10800 and an Active time of -1.
• The firmware and settings are uniform for both the Truphone and iBasis SIM card configurations.
• PSM has been explicitly disabled using the lte_lc_psm_req(false) function in my firmware.
• The PSM parameter update for the Truphone SIM card that consistently exhibits the issue is: TAU:10800, Active time: -1.
• I have also checked another Truphone SIM card, which now shows the expected PSM parameter update of: TAU: 3240, Active time: -1.
• I have also checked another iBasis SIM card, which now shows the expected PSM parameter update of: TAU: 3240, Active time: -1.

PM is currently off (CONFIG_PM=n), 

int modem_init(void) {
    int err;

	//disable PSM
	lte_lc_psm_req(false);
	lte_lc_edrx_req(false);

	//lte init
	err = lte_lc_init();
	if (err) {
		printk("LTE modem INIT ERROR.\n");
		return -EINVAL;
	}
	lte_lc_register_handler(lte_handler);

	printk("- modem_init completed\n");

	return err;
}

 

If it is because of PSM settings then how can I revert it to the default/initial state?

I am seeking your expert advice and guidance to help me address this challenge. Specifically, I am interested in understanding how my experimentation with PSM settings could be affecting the behavior of the Truphone eSIM. Any insights, recommendations, or suggestions for troubleshooting would be greatly appreciated.

If there is any additional information, data logs, or specific tests that you would recommend to better diagnose the issue, please let me know, and I will be more than happy to provide them.

Modem trace: trace-2023-08-17T21-50-03.572Z.mtrace.zip

Thank you for your time and consideration.

Best regards,
Sergii Skorostetskyi

[Didrik Rokhaug]

Hi,

I am not sure if I understand what your problem actually is. Could you clarify?

What behaviour do you see, and what behaviour do you expect?

Can you share a log from the device?

As long as the active time is -1 (disabled, 1110000), you do not have PSM.

Best regards,

Didrik

[Skorostetskyi]

In short, I have nRF9160 DK and 3 sim cards (one from iBasis, 2 from Truphone).
iBasis and one Truephone work perfectly.
Using the second Truphone sim card makes nrf9160 unavailable to reliably receive messages from my MQTT server. " unavailable to reliably receive" means:
- can't get a message at all OR
- receive messages in 2-6 minutes after sending
And usually this behavior starts after it prints  `RRC mode: Idle` in logs.

The problem is that one of my sim cards does not work reliably (probably after PSM experiments).

I expect the DK to instantly receive messages from MQTT server using the second Truephone sim cart (as it currently does with one from iBasis and one from Truphone)

[Didrik Rokhaug]

Are you able to capture a modem trace from the device, so that I can see what state the modem is in when you try to reach the device?

[Skorostetskyi]

Is it a joke? I included modem trace twice.

[Skorostetskyi]

7230.trace-2023-08-17T21-50-03.572Z.mtrace.zip

[Didrik Rokhaug]

Hi, and sorry for the late reply.

I've looked over the trace, and I cannot really see anything wrong from the modem's point of view.

While in idle, the device is receiving pages from the network, so it seems to be in the correct state. However, most of the time, there are no pages for the device. When it does receive a page addressed at the device, it wakes up as it should.

To begin with in the trace, everything looks okay. The device is woken twice by an incoming message, which it responds to. Then, there are two ping requests from the device, which the broker replies to. At the same time as the second ping request, it also receives another message from the broker, but I don't know if that one was sent earlier or if the timing simply was this close.

After that follows a long period where the device sends 7 ping requests, but only get an TCP ACK back, no ping reply from the broker. Then, a few seconds after the last ping request, the device receives a paging from the network, indicating that it has incoming data. When it has re-established it's connection to the base station, it receives the 7 missing ping responses, along with 8 MQTT messages. After that, the connection seems to be back to normal.

To me, it seems like that the network or broker has buffered the downlink data to the device.

Have you tried to contact Truphone, and asked if they have any insight into what could be wrong?

What state does their core network think the device is in when it is "unresponsive"?

[Skorostetskyi]

Hey Didrik,

thank you for the such a detailed dive into the problem. 
Yes, I have contacted Truphone. Their response:

The MQTT typically uses the data network, such as Wi-Fi or mobile data, to transmit messages between devices, does not use the Network of Truphone.

Durant the timestamp provided by the customer we see the device attached and had usage. 

We do not see any major failure on the network.

However, Network Congestion or Signal Strength can provoke this issue. Unfortunately, we cannot control coverage availability.

I did not expect to get more from them

In this case I have a slightly different question: does NordicSemiconductor have partners (like iBasis that has a proven quality) who can provide eSims?

[Didrik Rokhaug]

Skorostetskyi said:

In this case I have a slightly different question: does NordicSemiconductor have partners (like iBasis that has a proven quality) who can provide eSims?

This is more a question for your Regional Sales Manager. If you do not know how to contact your RSM, you can send me a private message with your location and I will share the contact details.

You can also find some information on our webpage:

https://www.nordicsemi.com/Nordic-Partners/Solution-Partners

https://www.nordicsemi.com/Products/Low-power-cellular-IoT/Cellular-Connectivity-Partners?lang=en#infotabs

Skorostetskyi said:

does not use the Network of Truphone.

There are different possible architectures for LTE when it comes to roaming, and it is possible that the data doesn't go through Truphone's core network.

But, depending on where in the network the problem is, it might not help to change network provider, as if the problem is e.g. in the base station, and the device still connects to the same base station, it will probably experience the same issue.