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
