%PERIODICSEARCHCONF - relation to EMM reject cause

[Achim Kraus]

nRF9160, mfw 1.3.5, NCS 2.4.2

Using %PERIODICSEARCHCONF I currently faced two issues:

1. the device doesn't go to sleep

2. the device isn't able to register to the network without CFUN=0/CFUN=1.

I tried to do a research on this topics and I found two other tickets:

NRF9160 EMM reject #11 behavior (mfw 1.3.2)

Network search behavior

Both pointing to a relation of the EMM reject cause and the sleeping mode.

Is it possible, to get a list of the of those reject causes, which turns the device into sleeping mode between the searches?

I assume, that the modem consider this reject causes also when it it comes to retry the registration. Is there also a list of such reject causes, which prevents the modem from consider to retry a registration?

[Didrik Rokhaug]

Hi,

Using %PERIODICSEARCHCONF I currently faced two issues:

1. the device doesn't go to sleep

2. the device isn't able to register to the network without CFUN=0/CFUN=1.

To debug these issues, we need a modem trace.

Both pointing to a relation of the EMM reject cause and the sleeping mode.

No, not really.

When doing the initial search for a network, you would expect the modem to try to connect to all available networks. If the network rejects the device, the modem will stop searching for that network, or only search for it in other tracking areas, etc. depending on the reject cause.

Once the modem has searched through all the enabled bands, and tried to connect to all relevant networks, it will start periodic searches, assuming it wasn't able to connect to any of the networks.

Only then is the %PERIODICSEARCHCONF relevant.

Is it possible, to get a list of the of those reject causes, which turns the device into sleeping mode between the searches?

What use do you expect from this list?

I cannot really think of a situation where the application would need to know this. Between the %MDMEV and +CEREG notifications, the application should have enough information about the status of the network search. And stopping the search early, might mean that a device is never able to connect to a network, even if one is available, as explained by the modem team in  RE: Network search behavior

You can find a list of the possible reject causes, and an explanation of them in 3GPP TS 24.301 Annex A and B.

Best regards,

Didrik

[Achim Kraus]

> To debug these issues, we need a modem trace.

Unfortunately, this happens randomly in the wild.

> What use do you expect from this list?

If you go through the other tickets here in the forum you will find quite a lot of users, which are surprised by the power consumption even using this %PERIODICSEARCHCON. That lists of reject causes helps to understand, if this is as intended or that something went wrong.

> I cannot really think of a situation where the application would need to know this. 

It's for the developers. Usually such a feature is activated with the intention to save power compared to a solution, where the power is controlled by switching off and on. If you get the those EMM reject cause, you know, that you don't need to analyze this further, if the behavior and power consumption is as intended by Nordic. The benefit of using %PERIODICSEARCHCON and keep some internal states for the search may then be less than the saving of switching off/on.

We had the same situation with the HPPLMN search, Nordic may remember, that the modem with mfw 1.3.2-1.3.4 was searching also for global PLMNs (9xxxx). We still see users here in the forum with those mfw versions, which are asking about that. If it gets clear, such questions can be answered faster and the developers don't need to capture modem traces. Even better, Nordic doesn't need to ask for that modem trace nor spending time in analyzing that, because the intended behavior is clear.

> You can find a list of the possible reject causes, and an explanation of them in 3GPP TS 24.301 Annex A and B.

I know that list. What I don't know, is the behavior of the modem firmware according the network search.

From the other ticket:

> Stationary device does not typically face the same #15 many times from the same tracking area, because modem remembers if certain tracking area has sent reject cause #15 (and some other causes, too). 

In my experience the opposite is the case. That #15 is the most received reject code using SIM cards of several different providers. It's also the one you usually get, when the SIM is deactivated. Unfortunately, it seems to be also the case for some hiccups or temporary outages of the providers. That experience makes the usage of  %PERIODICSEARCHCON turning the power consumption into to opposite. The modems doesn't enter the sleep mode and when the hiccup or temporary outage is over, switching off/on is required to register the modem again.

[Didrik Rokhaug]

Hi,

I've discussed this with the modem team a bit, and while no reject cause will affect when the modem starts periodic searches, or how the periodic searches are done, but, they can affect the current consumption during the sleep periods.

This is because the spec mandates that if the device gets rejected by a network with reject cause #12, #13 or #15 (and does not find another network it can attach to), it must stay camped on that cell.

This means that the device will listen for broadcasts from the cell, which will increase the power consumption. The main purpose for this is so that the device can still make emergency calls ,though this use case isn't very relevant for an IoT device. We are currently investigating if there is something we can do to make this better.

In the meantime, there unfortunately isn't an easy way to detect this situation for the application. Turning off the modem when you get one of the above reject causes isn't a good idea because you might not find other networks in the area which you can connect to. A better approach would be to keep track of if you get one of those reject causes, but still wait for the %MDMEV: SEARCH STATUS 2 notification from the modem. If you do not get connected to a network shortly after you got that notification (the modem seems to be sending the %MDMEV notification before it sends the +CEREG notification indicating that you are connected to a network), you turn off for a while.

[Achim Kraus]

Thanks a lot for the explanation. I will try that.

> (the modem seems to be sending the %MDMEV notification before it sends the +CEREG notification indicating that you are connected to a network)

Yes, that's something I stumbled over some time ago. Maybe Nordic considers to add a SEARCH STATUS for "3 => SUCCESS, CREG will follow".

[Achim Kraus]

Just as remark:

I still think it is very important and useful to know, which rejection codes are sticky and block future tries to register.

In the past weeks, some MVNO and MNO change the things, and in that trouble, the devices had to be reboot frequently just on order to escape temporary rejections.

According the information from some modem (GSMA) experts, the "Forbidden PLMNs" on the SIM card is used for a App to adjust that behavior. With the "internal nRF9160 forbidden list" solution, this approach doesn't work. It's only possible to add a PLMN while adding that to the list on the SIM, but it's not possible for a App to remove a PLMN from that list, because the nRF9160 does put the PLMN there and uses a internal list for that.

I don't know, where Nordic tests the assumptions about mobile network. But that differs from my experience.