nRF9151 stuck in disconnected, unable to reconnect to LTE-M

[teba99]

Hi,

We are testing connection resilience on our nRF9151 product. Generally, LTE-M connectivity (Germany, on Telefonica and/or Telekom) works fine.

However, under certain circumstances the nRF9151 appears unable to reconnect to the network. The only way to get it reconnect is with a full reboot.

One situation is when the SIM is briefly inactive for whatever reason (for example, an outage on the carrier side or because the network assignments change and the SIM is reset). The nRF9151 will loose connectivity immediately (as expected) and will try to connect later, but fails forever with "<err> modem_info_params: Link data not obtained: 5 -5". Only a reboot resolves it, after which the nRF9151 will immediately reconnect (no change on the SIM/network side).

In the same situation, we've also seen the modem actually re-attach to the network (as seen from the signallng logs) but the nRF9151 network stack apparently fails to establish a PDN session repeatedly with "nrf_cloud_transport: Could not connect to nRF Cloud MQTT Broker mqtt.nrfcloud.com, port: 45858. err: -111". Here also after a reboot it immediately reconnects. 

I understand the FPLMN List may come into play here, but I've also tested this by adding a new LTE-M network to the SIM that the device has not seen since the reboot, so it should not be in the FPLMN. But the nRF9151 is still unable to connect even to that new network (until a reboot).

My interpretation is that once the nRF9151 has disconnected it gets into a state where some part of the stack (modem, network stack, link manager) is stuck and fails to reconnect even though it could (SIM is active and suitable networks are available). A reboot resolves that state.

Unfortunately, a reboot is not a good option for us because we would then loose the data queued in RAM.  

Note: We are using the nRF9151 with the latest modem FW and nRF SDK, the application is based on the multi service sample.

Is this a known issue? Can I provide more information to help you analyse it? Do you have recommendations to deal with this situation?

Thanks much!

[Menon]

Hello Terrence,

Sorry for getting back to you a bit late.

We reviewed the modem trace and noticed the following:

• An Onomondo MVNO SIM was used in the DTAG network.

• Attach and a few data transfers worked initially, but eventually the network detached the device.

• The Detach Request message included EMM cause 7: EPS services not allowed, which according to 3GPP means the device cannot attempt EPS connections again in that PLMN.

• Recovery is only possible via a restart or by issuing CFUN=0 followed by CFUN=1.

The Detach Request included:

• NAS EPS Mobility Management Message Type: Detach request (0x45)

• Detach Type: Re-attach not required (2)

• EMM Cause: EPS services not allowed (7)

So you need to ask Onomondo/DTAG why this is happening. Onomondo provides Wireshark logs from their core network, so the cause should be visible there as well. Once you figure out why the Onomondo SIM card is being rejected by DTAG, you won’t need any workarounds.

Kind Regards,

Abhijith

[teba99]

Hi Abhijith,

Thanks for the detailed investigation. That makes sense. As explained, one way we triggered this issue was to briefly deactivate, then re-activate the SIM. We're not sure why that means the device cannot attempt EPS connections again to that PLMN ... this seems to be a valid case, but if that's the standard then we'll go with it . ;-)

However, as described above, we also seem to see this problem if the device looses the connection due to poor signal/coverage. In that case, too, the device is never able to reconnect. However, that case is much harder to reproduce, so I can't provide a modem trace at this time.

Anyway, it's good to know that for "EMM cause 7" this is the expected behavior and not a bug in the nRF network stack. As described we work around it by toggling the network interface. 

We will continue to test the connectivity robustness and report back.

Thanks,
-- Terrence