Inconsistent LTE connection behavior and event sequence in poor signal areas (nRF9160)

[shahab_1]

Hi Nordic team,

I’m working with an nRF9160-based device and have observed inconsistent LTE behavior when the device operates in areas with poor or unstable signal strength.

In low-signal environments, the modem repeatedly attempts to connect to the network. The sequence of LTE events varies between connection cycles.

Sometimes LTE_LC_NW_REG_UNKNOWN and LTE_LC_NW_REG_NOT_REGISTERED both come when the device is in a bad connection area, and sometimes only the LTE_LC_NW_REG_UNKNOWN event comes. If I don’t call lte_lc_func_mode_set(LTE_LC_FUNC_MODE_DEACTIVATE_LTE), then the pattern shown in the attached screenshot is observed.

If I call this function lte_lc_func_mode_set(LTE_LC_FUNC_MODE_DEACTIVATE_LTE) on UNREGISTERED event, then it works well and I can turn LTE back on after some time. However, the issue is that at low voltages, around or below 3.4 V, this function sometimes blocks the thread and never returns.

Also, as seen in the power profiler pattern the lte is trying to connect but the events are not triggered most of the time. For example, during the first attempt I see the LTE_LC_NW_REG_UNKNOWN and LTE_LC_NW_REG_SEARCHING events, but for the next 15 minutes, as shown in the screenshot, I only see one LTE_LC_NW_REG_NOT_REGISTERED event.

If I start LTE in an area where it cannot get a connection, the RRC first goes to CONNECTED, then IDLE after about 8 seconds, then LTE_LC_NW_REG_SEARCHING after a few seconds and then both events (LTE_LC_NW_REG_UNKNOWN and LTE_LC_NW_REG_NOT_REGISTERED) appear.

This makes it difficult to implement consistent application-level logic for managing LTE state transitions and power optimization.

Questions:

1. What is the expected pattern or sequence of LTE events during:

* Normal attach/detach

* Network loss

* Reconnection attempts

2. Is there an official document or timing diagram describing the LTE event flow in the nRF9160 modem firmware under various signal conditions?

3. In poor signal conditions, what is the recommended way to detect and manage repeated network failures?

Device: nRF9160

Modem firmware version: 1.3.7

SDK / NCS version: 2.7.0

Zephyr OS: v3.6.99-ncs2

[Benjamin]

Hi Muhammad,

These are quite general questions. I recommend going through our Cellular IoT course if you haven’t already. Some LTE event handling is demonstrated in our sample applications, such as the UDP sample. Also note that the modem handles many tasks automatically, so you don’t need to manage everything through event callbacks. For example, the modem will perform periodic cell searches when coverage is lost.

If you can share some logs or modem traces, we can take a closer look at any specific issues.

Best regards,
Benjamin

[shahab_1]

Hi Benjamin,

I have gone through the Cellular IoT course and also looked into the UDP sample. These are just basic LTE handling, I am talking about the exception where LTE is either very weak or is not available for several hours. I mentioned this already that LTE is trying to reconnect as you said, it is doing it automatically, I did not saved the logs for it but the behaviour was as I mentioned

"Also, as seen in the power profiler pattern the lte is trying to connect but the events are not triggered most of the time. For example, during the first attempt I see the LTE_LC_NW_REG_UNKNOWN and LTE_LC_NW_REG_SEARCHING events, but for the next 15 minutes, as shown in the screenshot, I only see one LTE_LC_NW_REG_NOT_REGISTERED event."

The issue here is that I dont want the modem to try a connection every few seconds when I know that the device is not going to get the connection for several hours, so to handle this I need a consistant behaviour and events from the modem so I can decide to turn off the modem and do not waste power as it is an IoT device. In the screenshot you can see that there is a pattern of modem trying to get the connection every few seconds/minutes but I can't find any documentation about it. So, can you please mention how can I set a custom pattern to try a connection may be every hour or a documentation about the events being generated during a connection loss so I can implement the logic according to it as the events I mentioned above are inconsistant.

[Achim Kraus]

I guess, the names of the registration events are mixing more up. If you check the docu of the at commands, some may be clearer.

+CEREG notifications:

0 – Not registered. UE is not currently searching for an operator to register to.
1 – Registered, home network
2 – Not registered, but UE is currently trying to attach or searching an operator to
register to
3 – Registration denied
4 – Unknown (for example, out of E-UTRAN coverage)
5 – Registered, roaming
90 – Not registered due to UICC failure

e.g. LTE_LC_NW_REG_SEARCHING is used, when them modem "UE is currently trying to attach or searching an operator to register to". Together with "sticky rejection" the modem may report that only on the first search-runs, but maybe not in the follow up ones, when a network rejected the registration (see my old ticket ).

All in all, if you want to have a feedback about "each search run", I use the modem sleep events when the modem is not registered. You may need to enable them in your prj.conf

CONFIG_LTE_LC_MODEM_SLEEP_NOTIFICATIONS=y
CONFIG_LTE_LC_MODEM_SLEEP_NOTIFICATIONS_THRESHOLD_MS=30000

(all in all: the network search is one of the very frustrating functions of the nRF91. Years ago it was draining the battery searching for 9xxyy networks (HPPLMN), never ever finding one. Takes me months and tickets over tickets. I'm not sure, if the modem still stays idle without network because of the "rescue calls" as mentioned in the old ticket above. My main strategy: cfun=0 after 30 min and then activate it again, when you want to schedule a new network search for periods about 15 min. Inconsistent events and sticky rejection blocks any more advanced mechanism.)