nRF9160 stuck in CEREG reject cause 15

RE: nRF9160 stuck in CEREG reject cause 15

Martin Lesund — Tue, 24 Mar 2020 11:57:38 GMT

Hi mjd093,
If you have bandlocked to the correct bands you should be OK.
Have you concluded what is the sequence to reproduce this issue?

Starting from Power ON reset.

- First device gets service (sometimes or always?)

- Then, the device is stationary, Service just gets lost at some point where it is shown as +CEREG:4 and reject indication?

Do you have a nRF91DK or a Thingy:91 where you can reproduce this issue with modem trace enabled?
Then we could analyze in detail what is going on between the modem and the network.

RE: nRF9160 stuck in CEREG reject cause 15

Lukáš — Mon, 23 Mar 2020 22:28:39 GMT

[quote userid="75438" url="~/f/nordic-q-a/58293/nrf9160-stuck-in-cereg-reject-cause-15/238114"]I took this same device for a drive as well later in the day. Hours after this log was taken, the device showed visual signs of being unable to reach the network until I had travelled around 5-6 miles. Note, the entire area is within NB-IoT coverage and as mentioned previously, a device reset can yield a very fast network connection even if 5,4 was detected before the reboot.[/quote]

I think I have approached the same issue as you. Our device is non-stationary and we often receive reject cause 15. Then, the modem is not able to recover until restarted. We use manual COPS to our Vodafone network in the Czech Republic and also band lock for band 20. There are no other bands or NB-IoT providers in our country.

I have described more details in the ticket #243590, but due to some internal details, I had to put it private. While it happens, our CEREG looks following:

[00:30:15.176,330] [0m<dbg> at_cmd.socket_thread_fn: Message: +CEREG: 4,"AE38","0009A120",9,0,15,"11100000","00101000"
[00:30:15.210,815] [0m<dbg> at_cmd.socket_thread_fn: Message: +CEREG: 4,"FFFE","FFFFFFFF",9,0,15,"11100000","00101000"
[00:30:21.024,291] [0m<dbg> at_cmd.socket_thread_fn: Message: +CEREG: 5,"FFFE","FFFFFFFF",9,,,"11100000","00101000"

RE: nRF9160 stuck in CEREG reject cause 15

MJD093 — Mon, 23 Mar 2020 15:27:14 GMT

Hi Martin,

I am not traveling, I am in the same location when I see this issue. I do have bandlocking on band 20 as this is the only known band that Vodafone is operating on in the UK. I could add that command into my application but I would have to wait for the issue to appear again in order to get a read out of that command.

So, are you suggesting that bandlocking should not be done? I have seen this issue on the thingy:91 with magpios set to Band 20 frequencies so I would expect that it shouldn't be able to find anything thing else as it is detuned to other bands.

RE: nRF9160 stuck in CEREG reject cause 15

Martin Lesund — Mon, 23 Mar 2020 15:08:54 GMT

Hi mjd093,
Sorry for the delay.

I cannot confirm this without a modem trace, but I think this could be that you are actually traveling in some areas that actually have bad NB-IoT coverage, OR (most likely not) that you have enabled some bandlocks that prevents the modem from finding the bands of the subscribed network cells.

What you could do is to run at+cops=? (manual PLMN search) in that area to see what NB-IoT networks are available. (I guess the result is that there are only "visitor PLMNs" i.e. all except the subscribed network)

You could try to perform the same test with modem trace enabled so we could look at the logs to analyze further what is happening.

Note: The bandlock can potentially make things worse. Based on experiences testing in Finland we have found that in urban areas cells are mostly on band 3 whereas in rural areas band 20 is used more (fewer clients, lower frequency = bigger cells).

Now if you have locked for example only "band 3", the service on "carrier A" may be obtained very fast in the urban area, but it is completely lost when the device moves out of the city -> the modem may find a cell of "carrier B" in the rural area, determines that "this is really the only available cell, we will need to try this" -> attempt that leads to #15 reject "no suitable cells in tracking area".

Best regards,
Martin L.

RE: nRF9160 stuck in CEREG reject cause 15

MJD093 — Wed, 04 Mar 2020 16:33:22 GMT

Hi Martin Lesund

The issue has popped up again and I have some additional AT information.

Socket status: 15:11, No more processes
Sending AT command: AT+CEREG=1
Modem response: OK

Socket status: 5:11, No more processes
Sending AT command: AT+CEREG?
Modem response: +CEREG: 1,4
OK

Socket status: 18:11, No more processes
Failed to receive "+CEREG: 1,5" from modem
*Debug* Requesting Advanced CEREG
Radio Scheduler had error with task: 3:-3
Sending AT command: AT%XMONITOR
Modem response: %XMONITOR: 4
OK

Socket status: 19:11, No more processes
Sending AT command: AT%NBRGRSRP
Modem response: %NBRGRSRP: 14,6254,33,276,6254,31,209,6254,30,393,6254,25,207,63
OK

Socket status: 88:11, No more processes
Sending AT command: AT+CEREG=5
Modem response: OK

Socket status: 5:11, No more processes
Sending AT command: AT+CEREG?
Modem response: +CEREG: 5,4,"A45D","07CBF70B",9,0,15,"11100000","11100000"
OK

Socket status: 65:11, No more processes
Sending AT command: AT+CGDCONT?
Modem response: +CGDCONT: 0,"IP","ep.inetd.gdsp","",0,0
OK

Socket status: 46:11, No more processes
Sending AT command: AT+CGACT?
Modem response: +CGACT: 0,0
OK

Socket status: 18:11, No more processes
Sending AT command: AT+COPS=3,2
Modem response: OK

Socket status: 5:11, No more processes
Sending AT command: AT+COPS?
Modem response: +COPS: 0
OK

EDIT:
I took this same device for a drive as well later in the day. Hours after this log was taken, the device showed visual signs of being unable to reach the network until I had travelled around 5-6 miles. Note, the entire area is within NB-IoT coverage and as mentioned previously, a device reset can yield a very fast network connection even if 5,4 was detected before the reboot.

RE: nRF9160 stuck in CEREG reject cause 15

Martin Lesund — Thu, 27 Feb 2020 10:29:47 GMT

Awesome, keep me updated if the issue appears again.

RE: nRF9160 stuck in CEREG reject cause 15

MJD093 — Thu, 27 Feb 2020 10:03:20 GMT

Hi Martin Lesund

I am using mfw v1.1.0 as I have a few deployed devices that I can update the application but not the modem firmware one. I can't update my mfw until I get those devices back as to ensure any fixes I make are compatible.

I had been meaning to add bandlock to my application, so I added that shortly after making this question and haven't seen it go to 1,4 recently. It sometimes gets stuck for a while in 1,2 but that would explain why 1,4 is difficult to clear if the network is hard to acquire at times.

I have added a bit of debug code for the 1,4 return case, utilising CEREG lvl 5 and XMONITOR, I will add the neighbouring cell command as well to this.

I'm hesistant to use COPS to directly select a network as my devices could be connected to different networks (have been used in 3 different regions so far) as I don't know if that would be a one-command-fits-all on the Vodafone networks.

I will monitor this for a few days and respond here. If I don't see it anymore then the XBANDLOCK command has done the trick.

RE: nRF9160 stuck in CEREG reject cause 15

Martin Lesund — Wed, 26 Feb 2020 14:43:49 GMT

HI mjd093,

Which modem firmware version are you running?
It would be interesting to get the results from %NBRGRSRP command also the CESQ info from the eNB.

Could you try to set the AT+COPS command to select the network and xbandlock to restrict the modem to connect to the wanted network?