• State Verified Answer
  • Replies 5 replies
  • Subscribers 88 subscribers
  • Views 239 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 359101
Options

Multi-IMSI connectivity issues

0sleep

We are currently evaluating thingy91x connectivity in different locations, using some Simbase multi-IMSI sims and are running into an issue where, sometimes, the modem will disconnect from the current cell, and then never reattach (neither to its' previous operator nor any new towers it can see). Using a multiple devices at the same time, the issue seems to happen only when traveling around, between cell towers. From doing some research into possible causes, I think it may have something to do with PLMN selection / something with the SIM card being able to tell the modem wether to reattach or disconnect from a certain PLMN? How do I diagnose it, and of course, how do I best fix it?

My current solution is to have a 5 minute timeout of "cell searching", after which the application forces the modem into offline mode, and then back to searching, which I assume is far from optimal.

Some log extracts:

[00:54:16.775,451] <wrn> lte_lc: Registration rejected, EMM cause: 15, Cell ID: 128391022, Tracking area: 33825, LTE mode: 7

[00:54:16.775,451] <wrn> lte_lc: Registration rejected, EMM cause: 15, Cell ID: 128391022, Tracking area: 33825, LTE mode: 7


[01:06:03.705,535] <wrn> lte_lc: Registration rejected, EMM cause: 15, Cell ID: 128391022, Tracking area: 33825, LTE mode: 7
[01:06:51.872,619] <wrn> lte_lc: Registration rejected, EMM cause: 13, Cell ID: 6424331, Tracking area: 42026, LTE mode: 9
[01:11:17.294,738] <wrn> lte_lc: Registration rejected, EMM cause: 15, Cell ID: 129148270, Tracking area: 33825, LTE mode: 7

... Various registration rejected EMM causes, mostly 15 and 13, but also sometimes 9 and 11

Parents
  • 0

    Let me recommend, that you first ask your SIM provider, how the SIM switches between the IMSIs.

    Auto switching with timeout? Then it will be contra-productive to switch off the modem, because the SIM may stay at a IMSI, which has no subscription for the available networks.

    And short timeout (e.g. 3 mins) make it less possible to search for both NB-IoT and LTE-M networks, so also that value should be know.

    Explicitly switching by "AT+CRSM" or similar? Then your issue may be not really related to the SIM. There are a couple of network search optimization implemented in the modem, e.g. "sticky rejection codes", which may help in some cases and other cases you will need to restart the modem with CFUN=0 and CFUN=1. And if that doesn't work, reboot the device.  

        

Reply
  • 0

    Let me recommend, that you first ask your SIM provider, how the SIM switches between the IMSIs.

    Auto switching with timeout? Then it will be contra-productive to switch off the modem, because the SIM may stay at a IMSI, which has no subscription for the available networks.

    And short timeout (e.g. 3 mins) make it less possible to search for both NB-IoT and LTE-M networks, so also that value should be know.

    Explicitly switching by "AT+CRSM" or similar? Then your issue may be not really related to the SIM. There are a couple of network search optimization implemented in the modem, e.g. "sticky rejection codes", which may help in some cases and other cases you will need to restart the modem with CFUN=0 and CFUN=1. And if that doesn't work, reboot the device.  

        

Children
  • 0 in reply to Achim Kraus

    I have had a poke around, and noticed that all "non-working" devices had switched to NB-IOT, while the working devices are on LTE-M. After a quick search, this makes complete sense. NB-IOT supports UDP only, which is fundamentally incompatible with MQTT (which needs TCP), oops. Setting CONFIG_LTE_LC_SYSTEM_MODE_LTE_M_GPS=y instead of the default CONFIG_LTE_LC_SYSTEM_MODE_LTE_M_NBIOT_GPS=y used in the asset tracker template ensures LTE-M only.

    This leads me to another question: When I move far enough away from all cells, I get disconnected due to being out of range. The network module handles LTE_LC_EVNT_PDN_DEACTIVATED, LTE_LC_EVT_PDN_NETWORK_DETACH and LTE_LC_EVT_PDN_SUSPENDED events as a "network disconnect" event, but sometimes the device is out of cell range and does not receive these events.  In this case, checking CEREG shows NETWORK_REG_UNKNOWN (code 4).

    Is it the right thing to then also treat  LTE_LC_NW_REG_UNKNOWN as a NETWORK_DISCONNECTED event (and then call lte_lc_connect_async), or will lte_lc's PDN module eventually emit a PDN_NETWORK_DETACH event?

  • +1 in reply to 0sleep
    0sleep said:

    This leads me to another question: When I move far enough away from all cells, I get disconnected due to being out of range. The network module handles LTE_LC_EVNT_PDN_DEACTIVATED, LTE_LC_EVT_PDN_NETWORK_DETACH and LTE_LC_EVT_PDN_SUSPENDED events as a "network disconnect" event, but sometimes the device is out of cell range and does not receive these events.  In this case, checking CEREG shows NETWORK_REG_UNKNOWN (code 4).

    Is it the right thing to then also treat  LTE_LC_NW_REG_UNKNOWN as a NETWORK_DISCONNECTED event (and then call lte_lc_connect_async), or will lte_lc's PDN module eventually emit a PDN_NETWORK_DETACH event?

    If you have any further questions not directly related to your original inquiry, please open a separate ticket for that. Thanks.

Related
Terms of service