How does automatic network selection work with +COPS?

[Chraebs]

Hi

I was wondering if there is any further reading about the Automatic network selection set as <mode> in the +COPS set command.

Especially, I'm looking for a solution to choose the best roaming network. With modem 1.2.0 I observed that the automatic network selection might select a network where roaming actually doesn't work, although there is a working one nearby (but with slightly lower signal strength). Most probably, the roaming on the chosen network does not work because the IMSI provider and the network operator do not have a partnership (I'm about to verify this).

The modem indicates a Network registration status (+CEREG) status <stat> 4 Unkown with a <reject_cause> 15.

+CEREG: 5,4,"FFFE","FFFFFFFF",7,0,15,"11100000","11100000"

The description of reject cause 15 is acc. to 3GPP TS 24.301 Annex A:

No suitable cells in tracking area - This EMM cause is sent to the UE if it requests service, or if the network initiates a detach request, in a tracking area where the UE, by subscription, is not allowed to operate, but when it should find another allowed tracking area or location area in the same PLMN or an equivalent PLMN”

What is the best way to switch to a different network in case of such an error? Can the modem do this automatically?

Thanks for your support!

[Øyvind]

Hello, 

The modem should be able to do so, if it can find a suitable cell, and the SIM has roaming permissions. 

What network are you on, and what SIM card are you using?

Kind regards,
Øyvind

[Chraebs]

Hi Øyvind

Thanks for your answer.

Actually, we discovered that our issue is related to using the nrf-sdk 1.4.0 lte link controller. As we use lte_lc_connect_async() and it fails with error 8 (ENOEXEC), it is not allowed to call lte_lc_connect_async() directly again, because it will immediately return with error 8 again (because it calls AT%XSYSTEMMODE which requires the modem to be set to flight mode (AT+FUN=4, e.g. via lte_lc_offline()) before using it.

But I prefer to have the modem on and keep trying. With nrf-sdk 1.5.0 that issue actually can be avoided by using Kconfig CONFIG_LTE_NETWORK_DEFAULT=y.

For reference, here the network registration status before lte_lc_connect_async() returns with error 8:

+CEREG: 2,"3904","00DFF303",7,0,0,"11100000","11100000"

+CEREG: 2,"3904","00DFF303",7,0,11,"11100000","11100000"

+CEREG: 2,"040A","00FE4611",7,0,11,"11100000","11100000"

+CEREG: 4,"040A","00FE4611",7,0,15,"11100000","11100000"

[Chraebs]

As there is currently no reference flow chart for the network connection establishment, here some useful hints I found in the meantime:

Most generic handling of network registration status notifications (CEREG <stat>) during attaching (+CFUN=1) and automatic network mode (+COPS=0):

• 0: not registered
  • Something bad happened (e.g. SIM read failure or similar). Intervention required! E.g. check hardware and restart.
• 1: registered, home network
  • Success
• 2 searching:
  • Wait
• 3 registration denied:
  • Most tricky case.. Depends on the EMM reject cause (see 3GPP TS 24.301 Annex A) and your preferred behavior.
  • Often it is ok to do nothing and wait.
• 4 unknown
  • Most often, it is ok to do nothing and wait
• 5 registered, roaming
  • Success (in case user is willing to use roaming network)
• 90: UICC failure
  • Something bad happened (e.g. SIM read failure or similar). Intervention required! E.g. check hardware and restart.

The U-Blox application notes contain an example network registration flow-chart (UBX-13001820-R13 chapter 4.2) which gives some additional hints for error handling. It might be not 1-by-1 applicable on nrf9160 though.

The LTE link controller (nRF Connect SDK v1.5.0) does not tell how to react on the error cases.