Network search behavior

[allard.p]

Hello,

I've the following: NCS V2.2.0, Modem FW 1.3.3. I'm currently testing the system in bad network conditions. To test this i wrap the product in a lot of aluminum foil, in combination with an isolated USB port to connect to the debug and modem trace uart. I've set a data profile using %XDATAPRF=0, so I expect a search pattern of AT%PERIODICSEARCHCONF=0,0,0,1,"0,10,40,,5","1,300,600,1800,1800,3600"


But this is not the case:

[2023-01-31 21:13:52.243] <inf> cellular: Network registration status: LTE_LC_NW_REG_SEARCHING
[2023-01-31 21:14:12.910] <inf> cellular: LTE cell changed: Cell ID: 7677543, Tracking area: 1312
[2023-01-31 21:14:12.910] <inf> cellular: LTE mode update: NB-IOT
[2023-01-31 21:14:12.910] <inf> cellular: RRC mode: Connected
[2023-01-31 21:14:12.910] <inf> cellular: RRC mode: Idle
[2023-01-31 21:14:12.910] <inf> cellular: LTE cell changed: Cell ID: -1, Tracking area: -1
[2023-01-31 21:14:14.017] <inf> cellular: LTE mode update: none
[2023-01-31 21:14:14.017] <inf> cellular: Network registration status: LTE_LC_NW_REG_NOT_REGISTERED
[2023-01-31 21:17:22.279] <inf> cellular: Network registration status: LTE_LC_NW_REG_SEARCHING
[2023-01-31 21:17:54.175] <inf> cellular: LTE cell changed: Cell ID: 7677543, Tracking area: 1312
[2023-01-31 21:17:54.175] <inf> cellular: LTE mode update: NB-IOT
[2023-01-31 21:17:54.175] <inf> cellular: RRC mode: Connected
[2023-01-31 21:17:54.175] <inf> cellular: RRC mode: Idle
[2023-01-31 21:17:55.438] <inf> cellular: LTE cell changed: Cell ID: -1, Tracking area: -1
[2023-01-31 21:17:55.438] <inf> cellular: LTE mode update: none
[2023-01-31 21:17:55.438] <inf> cellular: Network registration status: LTE_LC_NW_REG_NOT_REGISTERED
[2023-01-31 21:20:33.403] <inf> cellular: Network registration status: LTE_LC_NW_REG_SEARCHING
[2023-01-31 21:21:01.386] <inf> cellular: LTE cell changed: Cell ID: 7677543, Tracking area: 1312
[2023-01-31 21:21:01.386] <inf> cellular: LTE mode update: NB-IOT
[2023-01-31 21:21:01.386] <inf> cellular: RRC mode: Connected
[2023-01-31 21:21:01.386] <inf> cellular: RRC mode: Idle
[2023-01-31 21:21:01.386] <inf> cellular: LTE cell changed: Cell ID: -1, Tracking area: -1

It keeps searching quite aggressive, this is draining the battery and is undesired. Our product sits outside and can be covered by snow for a long time, if the modem keeps searching this aggressive the battery will not survive the winter.

I've captured the wireshark log and can see that every search results in 'No suitable cells in tracking area'. I do use a roaming sim card. When i remove the foil the device connects without problems. Questions:

1. Why does the modem search so aggressive when receiving EMM cause 15?

2. Why is PERIODICSEARCHCONF completely ignored? I what conditions does the modem follow the set pattern?

3. Who sends this 'Cause: No Suitable Cells In tracking area (15)' message? Is it the network? How can I see which network? The roaming sim should have access to almost all networks in the area.

[Michal]

Some more details about the EMM cause #15 from one of our experts:

There are areas where more than one tracking area is available, for example borders of tracking areas. So, if one tracking area sends cause #15 the only reasonable option is to search for other tracking areas - especially in case of stationary device. The other option would be just to give up on searching, but then the device would be without connection. The reject cause #15 is not something that would typically change without changes in the subscription, so trying connection later again would not likely change the situation.

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). Modem will scan through all possible channels searching for some other tracking area. Modem stops the search when it finds one and modem will remember the channel at the next startup. So a suitable cell should be found faster at the next startup assuming modem found suitable cell in the first place.

2. So this only works in case of CEREG:4? And not in case of receiving a EMM cause of the network.

The periodic search configuration is taken into use when all channels have been scanned and a suitable cell has not been found. CEREG 4 could be reported in some other cases too, as description says "unknown".

For the use case of device covered by snow. Receiving cause #15 does not mean that modem is not able to find any network. It just means that one network in one tracking area has rejected the registration. The same network could have other tracking areas available, too. On startup (and PSM wakeup), modem sends %MDMEV: SEARCH STATUS 2 when it has completed the search and goes into periodic search state. Before that, it is not reasonable for stationary device to deactivate the modem, because the situation will not likely change. If deactivated earlier, at the next startup modem will just scan the same channels again and the same unfortunate channels won't be scanned ever. Therefore, in this case modem might not find a suitable cell even if there was one available. But, if it is expected that someone will clean the device out of snow soon, then it might be a good option to deactivate the modem at %MDMEV: SEARCH STATUS 1 which indicates that modem has completed a light search. Note that modem events need to be subscribed with %MDMEV=1. 

One option would be to limit the supported bands so that the search is faster and lighter. To be considered how future proof this would be in this use case because it is possible that network configuration changes and the same band is not anymore available but some new band is. Therefore, if band lock is used, some backup logic might be needed in application. The network configurations change rarely, but there is still a change of it.

Best regards,

Michal

[Achim Kraus]

 allard.p 

Though this is now some time ago, what is your experience in the meantime with power saving and the network search, maybe with PERIODICSEARCHCONF?

[allard.p]

I decided to ditch PERIODICSEARCHCONF and go with my own implementation.

My implementation works as follows:
- When the device is booted an automatic network search is done
- When a network is selected and a connection is made, the network is pinned using AT+COPS
- When network is lost, we will try to reconnect to the pinned network, using a backoff mechanism. Modem is disabled in between searches using CFUN. 
- When we cannot reconnect to the pinned network, we fall back to automatic selection mode
This is as suggested in this topic: HPPLMN search - Please consolidate advice. 

This method is not recommended by Nordic (we discussed this in a private ticket). We are seeing good results with this method, but I do not have numbers to back this claim.

This is all with modem firmware 1.3.3. I do think they have made some improvements in the recent versions, but I did not test this yet.

[Achim Kraus]

Thanks a lot for your reply.

I guess, my way will be very close to your's.

In my case, the most pain is the "stick rejection". Nordic maybe even full on GSM spec, but some SIM card providers seems to be "in development". I found, that some of my devices sticks "offline" after a hiccup or short temporary outage of that provider. In cases where I had access and could login via BLE and that shows, trigger an search with "%PERIODICSEARCHCONF=3" had no result within minutes. Also a retry didn't work. But CFUN=0/CFUN=1 brought the device back in seconds.

It's disappointing, the PERIODICSEARCHCONF looks so promising, but without the details and some additional features it's not for the wild.

[Achim Kraus]

Maybe one note about mfw 1.3.3 and pinned network using AT+COPS:

If that is done to prevent a HPPLMN search for global ISIMs (9xxxx), the good news is that with mfw 1.3.5 this is not longer the case ;-).

See mfw_nrf9160_1.3.5_release_notes.txt:

- Fix for higher priority PLMN search. Global PLMN IDs (start with digit 9) are no more
  automatically considered to be suitable for higher priority PLMN search and selection.