nRF91 repeatedly transitions to `+CEREG: 4` approximately every five minutes while roaming

[chcortes559123]

nRF91 repeatedly transitions to `+CEREG: 4` approximately every five minutes while roaming on Vodafone Germany

## setup

nrf9151 modem FW: mfw_nrf91x1_2.0.4

current SDK: NCS 3.2.4

## Description

We are using a **Verizon Global IoT SIM/eSIM profile** in Germany. The modem successfully attaches to **PLMN 26202**, Vodafone Germany, and reports roaming registration:

```text
+CEREG: 5,...
+CIND: "service",1
+CIND: "roam",1
%XOPNAME: ...,"26202"
```

When registered, the device can establish a TCP socket and successfully exchange data with our server.

However, we are observing a repeatable issue where the modem transitions from registered roaming service to:

```text
+CEREG: 4
+CIND: "service",0
+CIND: "roam",0
```

The important detail is that this transition appears to occur at a repeatable cadence of approximately **five to six minutes after successful registration**.

In multiple stationary tests, the timing was approximately:

```text
Successful +CEREG: 5 registration
↓ approximately 5 minutes 15 seconds to 5 minutes 45 seconds
+CEREG: 4
```

Examples from separate connection cycles include approximately:

```text
Registration: 00:03:53
CEREG 4: 00:09:51
```

and:

```text
Registration: 01:01:05
CEREG 4: 01:06:54
```

The similarity in timing makes us concerned that this may not be caused only by random RF degradation. We are investigating whether it could be related to:

* Periodic higher-priority PLMN searching
* HPLMN searching
* Roaming or network-selection policy
* A SIM/eSIM profile configuration
* A modem timer or network-selection procedure
* eDRX or another modem configuration interaction
* A modem firmware issue

We also observe separate cases while moving through poor coverage where `+CEREG: 4` appears to correspond to genuine RF loss. We therefore may have two related but distinct conditions:

1. Repeatable `+CEREG: 4` events occurring approximately every five to six minutes while stationary and previously registered.
2. `+CEREG: 4` events during genuine degradation or loss of radio coverage.

We would like help determining whether the periodic event is expected modem behavior and how the application should handle it.

## Network and SIM information

* SIM/profile: Verizon Global IoT
* Serving network during successful registration: PLMN `26202`
* Serving network name: Vodafone Germany
* Registration result: `+CEREG: 5`
* Roaming indication: `+CIND: "roam",1`
* RATs observed: LTE-M and NB-IoT
* Registration notifications: `AT+CEREG=5`
* Modem firmware: `mfw_nrf91x1_2.0.4`
* Socket type: TCP
* Socket connect timeout: 30 seconds
* Application socket timeout: 10 seconds
* PSM is disabled with `AT+CPSMS=0`
* eDRX is requested after registration

The eUICC reports three installed profiles, with the Verizon profile enabled:

```text
Profiles installed: 3
Profile 0: disabled
Profile 1: Verizon profile, enabled
Profile 2: disabled
```

The modem reports Vodafone Germany as a roaming network rather than a home or equivalent-home network.

## Repeatable cadence

The most concerning behavior is the repeatable delay between successful registration and `+CEREG: 4`.

A typical sequence is:

```text
+CEREG: 5
+CIND: "service",1
+CIND: "roam",1
%XOPNAME: ...,"26202"

[approximately five to six minutes pass]

+CEREG: 4
+CIND: "service",0
+CIND: "roam",0
```

In one detailed stationary capture, valid RF measurements were still present immediately before `+CEREG: 4`:

```text
%CESQ: 57,2,26,3
%XSNRSQ: 34,3,184,0
+CEINFO: 1,1,R,8,1,-85,9
+CEREG: 4
```

This does not appear to be an obvious total loss of RF coverage.

Our current application interprets `+CEREG: 4` as out of coverage and begins modem deactivation and backoff. We recognize that this may prevent us from observing whether the modem would recover automatically.

We plan to modify the application so that it does not immediately deactivate the modem after the first `+CEREG: 4`, allowing us to observe the modem behavior for at least 60 seconds.

## PSM and TAU timer observations

The registration notification includes:

```text
+CEREG: 5,...,"11100000","00100110"
```

Our interpretation is:

* T3324 Active Time is deactivated.
* T3412 extended periodic TAU is approximately six hours.

We therefore do not believe the approximately five-minute event is directly caused by the network-provided T3412 timer.

We also subscribe to `%XT3412` notifications. The observed T3412 values do not appear to expire at the same cadence as the `+CEREG: 4` event.

## eDRX configuration

After LTE-M registration, the application sends:

```text
AT+CEDRXS=2,4,"0101"
AT%XPTW=4,"1111"
AT+CEDRXS=2,5,"0101"
AT%XPTW=5,"1111"
```

The modem reports negotiated LTE-M eDRX parameters:

```text
+CEDRXP: 4,"0101","0101","0001"
+CEDRXP: 4,"0101","0101","1111"
```

We do not see an explicit eDRX error, but we plan to disable eDRX temporarily as an A/B test.

## Questions

1. Is a periodic transition to `+CEREG: 4` approximately every five to six minutes a known or expected behavior while registered on a roaming network?

2. Could this cadence be caused by a periodic higher-priority PLMN or HPLMN search?

3. Can SIM or eSIM profile parameters such as `EF_HPPLMN`, preferred PLMN lists, or roaming policy cause this search interval?

4. Is a roughly six-minute interval consistent with the SIM-controlled higher-priority PLMN search timer?

5. Does the nRF91 modem expose any notification that identifies when a higher-priority PLMN search begins or ends?

6. Would enabling HPLMN skip be appropriate for a global IoT or virtual-operator profile?

7. Is `%FEACONF` feature 1 supported and recommended with modem firmware `mfw_nrf91x1_2.0.4` for this use case?

8. Would manually selecting PLMN `26202` with `AT+COPS` be a valid diagnostic test to determine whether automatic PLMN selection is causing the periodic event?

9. When `+CEREG: 4` is received after the modem was previously registered, should the application immediately treat the modem as deregistered?

10. Is it appropriate to retain the previous state for a short grace period, such as 30–60 seconds, while waiting for `+CEREG: 2`, `+CEREG: 1`, or `+CEREG: 5`?

11. Should socket activity stop immediately on `+CEREG: 4`, even when `+CIND: "service",1` or valid RF measurements were present immediately beforehand?

12. Is there a recommended modem indication that confirms packet service is usable after registration returns?

13. Should the application wait for all of the following before opening a TCP socket?

```text
+CEREG: 1 or 5
+CIND: "service",1
+CGEV: ME PDN ACT
```

14. Are there additional modem notifications or traces that can identify whether the periodic event is caused by:

* Higher-priority PLMN searching
* Cell reselection
* Roaming behavior
* Network detach
* PDN reactivation
* SIM/eSIM profile activity
* eDRX
* Poor RF conditions
* A modem firmware issue

15. Would a modem trace include sufficient information to distinguish a SIM-driven PLMN search from a network-initiated detach?

## Expected behavior

After the modem reports:

```text
+CEREG: 5
+CIND: "service",1
+CIND: "roam",1
```

we expect the modem to remain registered unless:

* Radio coverage is actually lost
* The network explicitly detaches or rejects the device
* The SIM profile initiates a required network-selection procedure
* The application deactivates the modem

If a periodic PLMN search is expected, we would like to know:

* Whether `+CEREG: 4` is expected during the search
* Whether ongoing packet service should be interrupted
* Whether the application should wait for automatic recovery
* Whether the search can be disabled or modified
* Whether `%FEACONF` HPLMN skip is the correct configuration

## Actual behavior

During stationary testing:

* The modem registers while roaming on Vodafone Germany.
* TCP communication succeeds.
* Approximately five to six minutes later, the modem reports `+CEREG: 4`.
* Signal measurements immediately before the event may still be valid.
* The event repeats after later registration cycles.
* Our current firmware deactivates the modem immediately and enters backoff.

During mobile testing with poor RF conditions:

* Signal measurements may degrade or become unavailable.
* The modem reports `+CEREG: 4`.
* Service and roaming indications change to zero.
* The modem later returns to `+CEREG: 5`.
* In some cases it immediately returns to searching or receives an EMM cause.
* Socket operations initiated during unstable registration can take over 20 seconds and then fail with `ETIMEDOUT`.

## Modem-only log excerpt: periodic event with usable RF immediately beforehand

```text
[00:09:05.851,562] %CESQ: 57,2,26,3
[00:09:05.951,629] %XSNRSQ: 34,3,184,0
[00:09:06.051,727] +CEINFO: 1,1,R,8,1,-85,9
[00:09:06.151,824] +CEREG: 4
```

The RF measurements immediately before `+CEREG: 4` do not appear to represent complete loss of coverage.

Our application then currently performs:

```text
Out of network coverage
Entered backoff
Deactivating modem
```

We plan to remove this immediate deactivation during the next diagnostic test.

## Modem-only log excerpt: actual RF degradation and loss of service

```text
[02:02:14.288,055] %CESQ: 0,0,0,0
[02:02:14.388,214] +CSCON: 0,7,4

[02:02:16.852,447] %CESQ: 255,0,255,0
[02:02:16.952,545] %XSNRSQ: 127,0,32767,255
[02:02:17.052,642] +CEINFO: 1,1,I,0,0,255,127
[02:02:17.152,740] +CEREG: 4
[02:02:17.252,807] +CIND: "service",0
[02:02:17.352,874] +CIND: "roam",0
```

This second sequence appears consistent with actual loss of usable radio service.

we are looking for reasons as to why this is happening and would like to stop this because we enter backoff when we get CEREG:4 and this is not good from a customer perspective. 

Thank you, 

Christian

[Simon D-M]

Hi Christian,

Are you able to get some modem traces? If you are, can you please share a raw modem trace (.mtrace or .bin) with me?

We are able to see exactly what happens from the modem point of view, so instead of doing a wild guess I should be able to give you the reason why the modem is disconnecting from the network.

Best regards,

Simon

[chcortes559123]

getting modem traces isn't feasible as out UARTs are being used for other purposes and modem trace uses that but we can activate any URCs that can help and can answer any questions that help narrow down the possibilities if that would help

[chcortes559123]

we are using sysbuild so i added this in the options 

-Dcomm_coproc_mfg_SNIPPET=nrf91-modem-trace-rtt 

[Simon D-M]

Hi,

I think you got the speed wrong. I just tried, and it worked for me with the following command:

JLinkRTTLogger -Device NRF9151_XXCA -If SWD -Speed 50000 -RTTChannel 1 modem_trace.bin

And for the snippet, if your application is called "comm_coproc_mfg" (I think this is case-sensitive) I think it should work. To be sure, you can check the actual name by going into the "build" folder. There should be a folder with the exact name of your application inside.

Best regards,

Simon

[chcortes559123]

you were correct the speed was wrong, collecting now, will upload when done 

[chcortes559123]

modem_trace.bin

The periodic registration event occurred approximately five minutes after the modem initially registered.

The modem registered while roaming on operator 26202 at:

00:00:22.204
+CEREG: 5,"BBA9","013BCB03",7

The event of interest begins at approximately:

00:05:22.839
+CEREG: 4

The elapsed time from CEREG: 5 to CEREG: 4 is approximately 5 minutes and 0.6 seconds.

Please focus the modem-trace review on approximately:

00:05:15 through 00:06:00

Important events in that window:

00:05:22.739  +CEINFO: 1,1,R,1,1,-85,7
00:05:22.839  +CEREG: 4
00:05:22.939  +CIND: "service",0
00:05:23.046  +CIND: "roam",0
00:05:23.340  +CNEC_EMM: 9
00:05:23.440  +CEREG: 2,"57ED","029BF400",7,0,9
00:05:23.541  +CGEV: NW DETACH
00:05:24.170  +CNEC_EMM: 15
00:05:24.270  +CEREG: 2,"57ED","029BF400",7,0,15

The modem then searched several LTE-M and NB-IoT cells:

"57ED","029BF400",7
"CF11","029BF404",9
"E507","01497017",7
"BBA9","013BCB03",7

It eventually returned to the original LTE-M cell and registered again at:

00:05:53.791
+CEREG: 5,"BBA9","013BCB03",7

The complete interruption lasted approximately 31 seconds.

The five-minute behavior occurred only once or twice during this trace session and then stopped repeating, so this is the primary section of the trace that should be examined.

i just wanted to add this note because the 5minute behavior stopped happening after this and i am not sure if having the trace on has anything to do with this. 

[Simon D-M]

Hi Christian,

It looks like the issue is caused by the cell tower throwing an "EMM cause 9 (UE identity cannot be derived by the network)" after some time. After this the nRF9151 tries to reset its identity completely and reconnect to this network, but the cell tower denies it (EMM cause 15). So the nRF9151 tries to check if there are some other cells that he can connect to. After a bit of time it retries the same cell that denied him and manage to connect.

This is why you see that ~30sec delay before reconnecting.

I'm scared that there is nothing we can really do about it as this our modem is behaving according to the 3GGP specs... I think you should try to see with your network provider if they may have more information. They may be able to extract some logs from the cell tower directly.

Please keep me informed if you managed to get more information.

Best regards,

Simon