in some conditions, device does not try to change RAT type to maximize chance of connection

RE: in some conditions, device does not try to change RAT type to maximize chance of connection

Achim Kraus — Mon, 11 Dec 2023 08:03:29 GMT

Just in the case:

The simplest solution, if your SIM card is no Multi-IMSI card, is to ensure, that the modem has enough time to switch and find a proper network. In my experience it usually takes mostly about 1-2 minutes to find a network. In cases, where quite a lot of networks with the wrong network type are available, that may slow down and so 10 minutes and more gets also realistic.

Therefore the easiest approach would be to check that network search timeout and, if it's less than 10 minutes, try a larger one.

RE: in some conditions, device does not try to change RAT type to maximize chance of connection

Achim Kraus — Sun, 10 Dec 2023 16:41:15 GMT

> In that case, I don't expect it to change IMSI. Isn't it?

Yes, if it connects fast with the current IMSI, it doesn't switch that.

> But his seems now deprecated looking into the library files.

In my experience, the old mechanism is replaced by the CONFIG_LTE_MODE_PREFERENCE

CONFIG_LTE_MODE_PREFERENCE_AUTO
CONFIG_LTE_MODE_PREFERENCE_LTE_M
CONFIG_LTE_MODE_PREFERENCE_NBIOT
CONFIG_LTE_MODE_PREFERENCE_LTE_M_PLMN_PRIO
CONFIG_LTE_MODE_PREFERENCE_NBIOT_PLMN_PRIO

and works very similar.

> But why the radio should not switch from one another if the provider rejects it?

It is switching, but, e.g. for CONFIG_LTE_MODE_PREFERENCE_LTE_M, it first checks all available networks for LTE-M, before it switches to NB-IoT. And these check takes a while. Using CONFIG_LTE_MODE_PREFERENCE_LTE_M_PLMN_PRIO is changing that to first checks "all prioritized" and available networks for LTE-M, before it switches to NB-IoT. That's faster, but may be not fast enough.

And usually, this approach is connecting to a network, it just takes some time.

But using a mulit-IMSI is then changing that, because when the IMSI is changing, the search starts again and so the time to find a network with the "fallback RAT" may not be enough.

But again, this is just a guess based on my experience.

RE: in some conditions, device does not try to change RAT type to maximize chance of connection

barbiz — Sun, 10 Dec 2023 15:39:41 GMT

Thank you Achim for the deep explanation. I will work to determine if our SIM is multi-IMSI. Bot I don't think this will be able to find out, if the SIM is connecting at first instance. In that case, I don't expect it to change IMSI. Isn't it?

I will also ask to provider.

One thing I honestly don't understand is about the LTE-M/nb-iot switch.

On the documentation, it seems that once it was possible to lock radio on a single RAT and set another as FALLBACK (see https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/libraries/modem/lte_lc.html#connection-fallback-mode). But his seems now deprecated looking into the library files.

Still, you can enable both with preference. But why the radio should not switch from one another if the provider rejects it? Does the radio expect that, only because nb-iot is there, then provider will allow to register?

I think as well that Nordic should further elaborate on this point. Naeem can you help us?

Thanks

RE: in some conditions, device does not try to change RAT type to maximize chance of connection

Achim Kraus — Sat, 09 Dec 2023 16:22:03 GMT

> how are you extracting home PLMN list?

That's done using AT+CRSM commands.

> how can you know the provider from the CEREG notification, which is just telling TAC and CID?

That's something I asked a month ago, see nRF9160, mfw 1.3.5, CEREG with rejection, how could the PLMN be determined? Unfortunately, Nordic Modem doesn't provide this information to the users.

What you may try is to use "lte_lc_neighbor_cell_measurement". But you need to wait until the modem gets idle (+CSCON: 0). With that you get a list as:

[ 0]: plmn 26201, tac 67b9, cell 01CC2B03, earfnc 6400, pid 206, rsrp -89 dBm, rsrq -7 dB
[ 1]: plmn 26203, tac e936, cell 01656201, earfnc 6200, pid 151, rsrp -93 dBm, rsrq -9 dB
[*2]: plmn 26201, tac 67b9, cell 01CC2B00, earfnc 1300, pid 438, rsrp -101 dBm, rsrq -10 dB
[ 3]: plmn 26201, tac 67b9, cell 01CC2B06, earfnc 1444, pid 270, rsrp -102 dBm, rsrq -11 dB
[ 4]: plmn 26202, tac b982, cell 031D7801, earfnc 6300, pid 197, rsrp -104 dBm, rsrq -13 dB

Anyway, I guess the first thing to do is to find out, if your SIM card is one with multiple IMSIs. TruPhone is using such SIM cards, and Flo.Live as well. So either ask your provide or frequently read the IMSI with "AT+CIMI" and compare that with the previous one. That may also help to find the timeout of the SIM card to switch the IMSI.

There for sure also SIM card with only one IMSI.

The point, why I guess, that your SIM card is one with multiple IMSIs is, that usually the modem remembers the rejects and do not retry that TAC. (It's not completely clear, I tried to also ask that here in the forum, %PERIODICSEARCHCONF - relation to EMM reject cause , but unfortunately the answer there is some "cannot really think of a situation where the application would need to know this". )

It will get pretty interesting. if Nordic doesn't speed up in documenting the exact and detailed behavior of the modem. If the idea of "global-roaming" turns more and more out to be unrealistic (see ESM Error Code 50: type ipv4 only allowed (NRF91 Asset Tracker) ) Multi-IMSI SIM cards will play a more important role. But using them with the nRF9160 is quite complicated, even more complicated without that details documented ;-). So, I'm looking forward, if "global roaming" or "multi-imsi" will get more usage.

RE: in some conditions, device does not try to change RAT type to maximize chance of connection

barbiz — Sat, 09 Dec 2023 11:29:46 GMT

Thanks Achim for this information, this is very interesting.

I will check the settings of my SIM cards here.

By the way, a little OT I need to understand:

how are you extracting home PLMN list?
how can you know the provider from the CEREG notification, which is just telling TAC and CID?

Thanks much!!

Marco

RE: in some conditions, device does not try to change RAT type to maximize chance of connection

Achim Kraus — Fri, 08 Dec 2023 18:15:18 GMT

The point is, you need to now your SIM card and the configuration stored in it.

Some SIM cards came with a list of "Home Networks" and or "Priorized Networks".

e.g. one of my SIM card has

CRSM eq. home plmn: 23410,310041,50501,45400,20408,26201,26003,21403,20801
CRSM home plmn sel: 23410,310041,50501,45400,20408,26201,26003,21403,20801
CRSM operator plmn sel: 23455,42505,42503,310011,23203,20610,28401,21910,28010,23003,23801,24801,24491,20205,21630

but other SIM cards don't use that lists.

If you select now LTE_MODE_PREFERENCE_????_PLMN_PRIO then the modem first checks to find an network in that list. In my case, the 26201. And then it tries to use LTE-M or NB-IoT with that network.

+CEREG: 2,"67B9","01CC2B00",7
I 95.141 : iccid: 8944477100000445083F (new)
I 95.141 : imsi: 204047795921998
+CEREG: 2,"D325","01CC2B0C",9
+CEREG: 2,"D325","01CC2B0C",9,0,15
+CEREG: 2
+CEREG: 2,"D325","01CC2B0C",9
I 16.211 : iccid: 8944477100000445083F
I 16.212 : multi-imsi: 208090063613998 (204047795921998, 121 seconds)
+CEREG: 2,"D325","01CC2B0C",9,0,15
+CEREG: 2
I 45.322 : Modem connects for 30 s of 300 s(multi imsi)
I 75.324 : Modem connects for 60 s of 300 s(multi imsi)
I 05.327 : Modem connects for 90 s of 300 s(multi imsi)
I 35.329 : Modem connects for 120 s of 300 s(multi imsi)
+CEREG: 2,"D325","01CC2B0E",9
I 37.370 : iccid: 8944477100000445083F
I 37.370 : multi-imsi: 204047795921998 (208090063613998, 121 seconds)
+CEREG: 2,"D325","01CC2B0E",9,0,15
+CEREG: 2
I 65.260 : Modem connects for 150 s of 300 s(multi imsi)
I 95.262 : Modem connects for 180 s of 300 s(multi imsi)
I 25.265 : Modem connects for 210 s of 300 s(multi imsi)
I 55.268 : Modem connects for 240 s of 300 s(multi imsi)
+CEREG: 2,"D325","01CC2B0C",9
I 57.878 : iccid: 8944477100000445083F
I 57.879 : multi-imsi: 208090063613998 (204047795921998, 120 seconds)
+CEREG: 2,"D325","01CC2B0C",9,0,15
+CEREG: 2
I 85.270 : Modem connects for 270 s of 300 s(multi imsi)
+CEREG: 2,"D325","01CC2B0C",9
I 77.292 : iccid: 8944477100000445083F
I 77.292 : multi-imsi: 204047795921998 (208090063613998, 120 seconds)
+CEREG: 2,"D325","01CC2B0C",9,0,15
+CEREG: 2
I 06.470 : Modem connects for 30 s of 300 s(multi imsi)
I 36.401 : Modem connects for 60 s of 300 s(multi imsi)
I 66.403 : Modem connects for 90 s of 300 s(multi imsi)
I 96.406 : Modem connects for 120 s of 300 s(multi imsi)
+CEREG: 2,"D325","01CC2B0C",9
I 98.545 : iccid: 8944477100000445083F
I 98.546 : multi-imsi: 208090063613998 (204047795921998, 120 seconds)
+CEREG: 2,"D325","01CC2B0C",9,0,15
+CEREG: 2
I 26.408 : Modem connects for 150 s of 300 s(multi imsi)
I 56.339 : Modem connects for 180 s of 300 s(multi imsi)
I 86.342 : Modem connects for 210 s of 300 s(multi imsi)
I 16.344 : Modem connects for 240 s of 300 s(multi imsi)
+CEREG: 2,"D325","01CC2B0C",9
I 18.959 : iccid: 8944477100000445083F
I 18.959 : multi-imsi: 204047795921998 (208090063613998, 120 seconds)
+CEREG: 2,"D325","01CC2B0C",9,0,15
+CEREG: 2
I 46.347 : Modem connects for 270 s of 300 s(multi imsi)
+CEREG: 2,"67B9","01CC2B06",7
I 79.723 : iccid: 8944477100000445083F
I 79.723 : multi-imsi: 204047795921998 (208090063613998, 120 seconds)

But as you can see, it still tries to search for one RAT quite long, even if only cells of a provider from that list are tested and not all. In my case, the SIM card then changes the IMSI after a time without network registration. And that causes again to search for the wrong RAT. And finally, it tries with the other RAT and has success. So in my experience, even using ???_PLMN_PRIO stick more to RAT than a user would assume.

RE: in some conditions, device does not try to change RAT type to maximize chance of connection

barbiz — Fri, 08 Dec 2023 16:21:56 GMT

Hello Naeem,

thank you for the explanation.

However, it is not clear to me why LTE_MODE_PREFERENCE_NBIOT_PLMN_PRIO should help to solve the issue. Can you please better elaborate on this?

Thanks much,

Marco

RE: in some conditions, device does not try to change RAT type to maximize chance of connection

Naeem Maroof — Wed, 06 Dec 2023 19:28:55 GMT

Hello

Thank you for contacting DevZone at NordicSemi.

Are you using: LTE_LC_SYSTEM_MODE_PREFER_NBIOT?
Which actually prefers the NBIOT network whenever it is available, and as such it appears (in your case) the network is available but not accepting.

How you are handling connections to the network in your application?
Should that kind of situation not be handled in your application? Once your application knows (lets say N times) a connection is rejected then it should switch the network. We have LTE Link Control library that provides such functionality. You may check the network-registration status, and based on that handle to switch the network in you application.

Are you using LTE_MODE_PREFERENCE_NBIOT_PLMN_PRIO config? This should do the job as per your case. It will make NBIOT as a preference, but will switch to LTEM if NBIOT is not available. You can try this as well, but once again, the issue could be not the unavailability of the network.

You can also use the connection fallback mode, which will connect to the other network after defined timeout.

Maybe changing operator or talking to them regarding roaming might also help solve the issue.

With regards,

Naeem

RE: in some conditions, device does not try to change RAT type to maximize chance of connection

Achim Kraus — Wed, 06 Dec 2023 12:16:02 GMT

Do you use a multi-IMSI-SIM-card? With such SIM-cards I had also that experience. The SIM card observes the modem trying to register at mobile-networks. If that isn't successful for some time (in my experience it starts with SIM cards using 2 minutes, I have also some with 5 and 10 minutes), then the SIM-card changes the IMSI and the modem restarts the network search with that new IMSI.

nRF9160, mfw 1.3.5, PERIODICSEARCHCONF and automatically switching multi IMSI SIM cards

The strategy to overcome that, is to swap/switch the "LTE-M/NB-IoT" priority after sometime of trying to register without success.