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

[Achim Kraus]

nRF9160, mfw 1.3.5, NCS 2.4.0

If PERIODICSEARCHCONF is set, the modem sleeps between the searchs (or at least goes to idle, what also saves some energy).

But if a multi IMSI SIM card is used, which switches automatically between the IMSIs when the registration is not successful, this seems to break that sleep.

For sure, there are good arguments for both behavior, either stay sleeping or starting a new search. But I would appreciate it, if this would be configurable. There are SIM cards which switching the IMSI every 120s and with such SIM cards in a radio gap the energy consumption will be pretty high. For now I only able to limit that, when I switch off the modem.

[Michal]

Hello Achim,

Due to the summer vacation period we are currently understaffed, so delayed replies must be expected. I am sorry about any inconvenience this might cause.

Best regards,

Michal

[Achim Kraus]

Still in summer vacation period?

[Øyvind]

Hello Achim, 

No, this wee we are coming back to more normal operations. I have forwarded your suggestion to our developers. 

Kind regards,
Øyvind

[Achim Kraus]

Thanks!

That means, for now (up to mfw 1.3.5) multi IMSI cards, which are switching the profile rather fast (e.g. 120s), will cause either extra power consumption or need a special "application level implementation".

If Nordic considers to redesign the multi IMSI support in the future, there is also a second pain-point in multi IMSI cards, which switch fast: If both LTE-M and NB-IoT is enabled, that may fail, because in an area, where the "prio" isn't supported, the "fallback" will be tried for only a short time, interrupted by the next IMSI change, which the starts the search again with the prio technology.

[Achim Kraus]

Any progress/update?

[Øyvind]

No updates. Our modem team are still discussing the feature request.

[Achim Kraus]

Thanks.

It's not that important for me. I was just struggling to use the PERIODICSEARCHCONF with some multi IMSI cards. If it's not supported for now, that's OK.

[Øyvind]

Achim Kraus here is the answer from our team on the feature request:

Attempting to find service when IMSI changes is based on the 3GPP standards. It is always possible that the new IMSI enables access to a network that was not allowed for the previous IMSI and network selection must always select the highest priority network available on the area, hence network scan needs to be performed. But we can optimize behaviour on some scenarios and will consider that in the future.

This second pain-point mentioned is already handled so that if IMSI changes during these searches we will not restart searches from the beginning, but will use what ever was already searched. We cannot know what has happened in the described scenario without a log file, but it may be that we have switched to “prio” system based on those already found results to attempt registration to a network that was found before the IMSI was changed (again).

Kind regards,
Øyvind

[Achim Kraus]

From my initial post:

> For sure, there are good arguments for both behavior, either stay sleeping or starting a new search. But I would appreciate it, if this would be configurable.

Sometimes the main important point seems to be ignored.