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
