nrf9160 dev kit fails to register to LTE-M network with multi-IMSI SIM

[LNZ]

Hi,

I am debugging a case where an nRF9160 cannot register on LTE-M in New Zealand using a multi-IMSI SIM(korewireless). The modem establishes an RRC connection, then stops searching entirely without ever surfacing a reject cause at the AT level. I have captured a modem trace and would like help interpreting what happens at the NAS layer.

---

## Setup

- Board: nRF9160 DK
- SiP: `nRF9160 SICA B0A` (from `AT%HWVERSION`)
- Modem firmware: `mfw_nrf9160_1.3.5`
- Application: `modem_shell` (MoSh), nRF Connect SDK v3.4.0, TF-M v2.3.0
- System mode: `%XSYSTEMMODE: 1,0,0,0` (LTE-M only)
- SIM: KORE OmniSIM Reach (works on other LTE-M devices)
- Location: Auckland, New Zealand. Band 28 (`%XCBAND: 28`).
- Trace captured with Cellular Monitor v2.8.0, trace database 1.3.5

## Observed behaviour

`+CEREG` never reaches 1 or 5. The modem finds cells, cycles between them within the same TAC, makes a single attach attempt, and then stops completely. No retry occurs for at least 15 minutes afterwards.

URC reporting was enabled before every test:

```
AT+CMEE=1
AT+CEREG=5
AT+CNEC=24
AT+CSCON=1
AT%XSIM=1
AT%USATEV=1
AT%MDMEV=1
```

Representative sequence:

```
AT+CFUN=4
+CEREG: 0
%XSIM: 0
OK

AT+CFUN=1
OK
%XSIM: 1
%CESQ: 41,2,2,0
+CEREG: 2,"46D3","00092D79",7
+CSCON: 1
%CESQ: 48,2,12,1
+CEREG: 0
%MDMEV: SEARCH STATUS 2
%CESQ: 255,0,255,0
+CSCON: 0

(no further activity for 15 minutes)
```

Afterwards:

```
AT+CEREG?
+CEREG: 5,2,"46D3","00092D79",7
OK

AT+CEER
OK

%CONEVAL: 6
```

## What I have already ruled out

**Signal** — RSRP was approximately -93 dBm at the moment the RRC connection was established (`%CESQ: 48,2,12,1`), RSRQ around -13.5 dB. Signal is comfortably usable.

**PLMN availability** — a full scan shows both NZ operators as available, and neither is forbidden:

```
AT+COPS=?
+COPS: (1,"","","53001",7),(1,"","","53005",7)
OK
```

**SIM and applet** — `%XSIM: 1`, `+CPIN: READY`. The eUICC applet executes REFRESH successfully and the IMSI does change:
```

**SIM profile specific issue** — the behaviour is identical across two different home operators. IMSI A(MCC 204 / MNC 04) and IMSI B (MCC 234 / MNC 50) both produce exactly the same result: RRC established, no NAS response surfaced, modem gives up. These are different home networks with different HSS and different roaming paths, so a single-profile subscription issue seems unlikely.

**APN / PDN** — the failure is at EMM level. `AT+CGDCONT?` returns empty, no PDN activation is attempted, and no ESM cause is ever reported.

## Questions

1. From the attached trace, can you confirm whether an **Attach Request was actually transmitted**, and whether **any downlink NAS message** (Authentication Request, Identity Request, Attach Reject, etc.) was received before the RRC connection was released?

2. After an RRC connection has been successfully established, on what basis does the modem decide to move to `+CEREG: 0` with `SEARCH STATUS 2` and stop retrying entirely? I would expect periodic retry behaviour governed by T3402 rather than a permanent stop after a single attempt.

3. Why is no reject cause exposed through `AT+CEER` or the `+CEREG=5` URC, given that `AT+CEREG=5` and `AT+CNEC=24` were both enabled? If the modem has an internal reason for abandoning the PLMN, is there any AT interface that exposes it?

4. Is this pattern consistent with **Attach Request sent, no NAS response received** (i.e. T3410 expiry), or does the trace show an explicit reject that is not being surfaced to the application layer? These two cases point at very different root causes, and I cannot distinguish them from the AT interface alone.

5. Does the `Modem domain event: Reset loop` seen on an earlier run affect retry behaviour in subsequent sessions, and is a full power cycle required to clear it?

Thank you,trace-2026-09-17T02-51-19.653Z CSCON changed.mtracetrace-2026-09-17T03-17-02.011Z_auto.mtrace

[Samruddhi Jadhav]

Hi Loke,

I have discussed about the trace you shared with the team. Here is an update on it from them. The log has the following:

00:30:09.745358 L23_AT_STRING AT_STRING <= %MDMEV: RESET LOOP

The AT-manual says this:

RESET LOOP indicates that the modem restricts Attach attempts for the next 30 minutes. The timer
does not run when the modem has no power or while it stays in the reset loop. The modem counts all the
resets where the modem is not gracefully deinitialized with +CFUN=0.
If there are more than seven resets, reset loop restriction is activated.
The Radio Policy Manager (RPM) configuration in the UICC might affect the maximum number of allowed
resets by triggering the reset loop restriction earlier than expected.
For more information on reset loop, see Modem Reset Loop Restriction.

 

Please let us know if you have any further questions.

Best Regards,

Samruddhi

[LNZ]

Hi Samruddhi,

Thanks for the details.

My guess is, modem was trying to register 7 times and failed so it reset 7 times and triggered RESET LOOP. Does the trace show the reason for failed registrations? 

I have following questions:

- Other than RESET LOOP, is there any other restriction on attach attempts?

- If RESET LOOP was not triggered, what could be other reasons that a registration was unsuccessful? 

- Is there a way to force applet to switch IMSI?

- What else should I try to find the root cause?

Thank you.

[Samruddhi Jadhav]

Hi Loke,

I have some feedback here from the team. 

The Reset loop triggers for example, when the user/app resets modem/devkit with a reset button/pin reset or modem crashes 7 times within a short time. If the interval between reset is less than 60s then those resets are counted for reset loop detection.

If reset loop was not triggered we cannot say based on this trace whether there were other reasons for unsuccessful registrations. In this trace the reason was reset loop prevention. 

How UICC applet works is a business of UICC provider/applet author. Triggers they use are not in control of modem and we have no "standard" way to enforce it. We would still suggest checking other cards. Also please note that we need proper modem traces to make further progress. 

Please let us know if you have any further questions. 

Best Regards,

Samruddhi

[LNZ]

Hi Samruddhi,

Thanks for the update. I notice the modem entered RESET LOOP mode after I have switched 7 working sims and the last one simA didn't connect. Then I waited 20+ mins and still not attached then I started the trace and wait another 20+ mins. simA didn't attach, then I switched to simB it did attach fast, then switched back to simA, still cannot attach. The whole process was in the modem trace. 

I don't know why simA cannot attach even I have set cfun=0 then cfun=1 to re-enable the modem. Want to find out the reason simA caonnt attach. Could you look into this? Many thanks.

trace-2026-10-15T03-48-17.260Z_2sims.mtrace

Loke,

[Samruddhi Jadhav]

Hi Loke,

We have taken a look at it now. 

SIM-A has IMSI 234502125648032 and the attach requests are done using it. A's IMSI (234-50, a UK-range IMSI) is refused by Spark's core. Either there is no roaming agreement for 23450 on Spark, or the subscription isn't provisioned for it. This is a network or SIM-profile problem, not a modem fault. 

The latter attach attempt is seen in log (after SIM swap and a successful Attach and the following UE initiated Detach) with SIM-A is rejected because above reason with EMM Cause #8. After an Attach Reject with EMM cause #8, the UE can attempt to attach again with the same SIM and IMSI only in the cases below:

• UE switch-off and switch-on. This is a full power cycle. CFUN=0 then CFUN=1 is not a power cycle
• UICC removal and re-insertion, or a SIM re-initialization by the modem. In the trace, a SIM swap with CFUN=41 cleared the latch, and Attach with SIM-A was re-attempted at 02:20.
• T3245 expiry. This only applies if the UE is configured to use T3245 (via EF_NASCONFIG or the USIM configuration in TS 24.368 or TS 31.102).

Best Regards,

Samruddhi

[Achim Kraus]

LNZ said:

I notice the modem entered RESET LOOP mode after I have switched 7 working sims and the last one simA didn't connect.

If you want to overcome the RESET_LOOP, a first step maybe to understand, what you "really" do. So, what exactly do you do, when switching the SIM? Exchange SIM and press RESET? If you do that "fast", then the modem handles that as fault and enters the RESET_LOOP. Therefore just don't switch it that fast.

I made my first experience with multi IMSI a couple of years ago. There are quite am lot of pitfalls with this approach.

The SIM provider should also handover the require information, e.g. which IMSI are on the SIM, which of that IMIS has a subscription for your destination. Also including the supported ways to switch the IMSI. Some SIM comes with  explicit commands (e.g. +CRSM sequence) others with an automatic selection triggered by timeouts when searching for a network. For the timeout you will need to know the time. If it's a short time (less than 4 minutes) you may need to select the NB-IoT/LTE-M mode and don't use both, otherwise the time to search successful for a network may be too short. If it's a larger time, then you will need patience. If it's a automatic multi IMSI SIM, please ensure, that you don't disable it (e.g. no CFUN=0). Also note, that such automatic multi IMSI may also trigger an IMSI change, when there is an outage. Especially for moving devices, that drains your battery faster than you will ever have assumed.

(My experience with that multi IMSI: don't use it for IoT.)