nRF9160 connectivity & configuration help

[JonathanF]

Hello,

We are working to improve our connectivity globally, and have some questions about how we might improve our firmware.

We are using the nRF9160 to connect via LTE-M (CAT-M1) using a SIM that allows us to roam across multiple networks. This SIM has a feature that allows it to rotate through several profiles in order to find a network that we can connect to.

The initialization of the nRF9160 modem (FW 1.2.0) is done via the following AT commands:

• AT%CESQ=1
• AT+CPSMS=1,,,"01100000","00000000"
• AT+CSCON=3
• AT+CNEC=24
• AT%XSYSTEMMODE=1,0,0,0
• AT+CGDCONT=0,"IP","[APN]"
• AT+CEREG=5
• AT+CFUN=1

Our questions are:

1. What should we do about +CEREG status = 4 (“Unknown”)?
   Whilst the modem is searching and attempting to connect to a network (+CEREG: 2), we occasionally see +CEREG status messages indicating “Unknown” status.
   Example message: +CEREG: 4,"FFFE","FFFFFFFF",7,0,15,"11100000","11100000"
   Our question is what to do in this case? Is this an error, meaning we should try again (maybe turn the modem off, then on again), or should we just let the modem continue to search? Our interpretation of this above message is that the network search has completed, but no available networks were found (reject_cause=15, indicates “No suitable cells in tracking area”). Will the modem continue to search? We’ve also seen reject_cause=11 (“PLMN not allowed”) and have similar questions.
2. Is it possible to do a factory reset for the modem?
   One thing that makes debugging difficult is that we aren’t sure what settings are stored/cached in the modem’s NVM. This makes it difficult to compare device behavior across multiple devices.
3. When should we transition into AT+CFUN=0 and when should we transition to AT+CFUN=4?
   Several of the AT commands state that settings are written to NVM when transitioning to CFUN=0. Is there guidance on when it’s best to transition to off vs. airplane mode? Our approach has been to transition to airplane mode when we wish to save power, but when an unpredictable reset happens (via a user event), we want to be able to reasonably quickly connect to the network again.
4. Why does it sometimes take about 60 seconds from CFUN=1 to the first status update message (example: %CESQ: 14,0,0,0 followed within 1 millisecond by +CEREG: 2,"0411","00EF090F",7,0,0,"11100000","11100000"). Is there something we can/should be doing to force the modem to begin searching immediately?

Any help would be appreciated!

Thank you,
Jonathan

[Heidi]

Hi!

So there are few scenarios where this 'not searching' can happen.

• SIM init fails.
• There is a fatal/permanent reject for LTE registration, e.g. #8 (EPS services and non-EPS services not allowed), or #3 (Illegal UE), etc.

The above cases can happen occasionally, e.g. if the card can move in the reader, or due to some network issue. But these occasions should be quite rare.

You're using a SIM card that has several profiles and is able to switch between those. What could be happening is that some of the location status events are not being forwarded from the modem to the SIM card and thus the SIM card is not able to perform a SIM refresh to change its profile and allow LTE registration. 

If you're able to take a modem trace when the case you described happens we would be able to see this.

Did you activate the unsolicited CEREG notifications before CFUN=1 was sent?

 

Side note, there are many improvements in multi-profile SIM card functionality and AT+CEREG notifications in MFW v1.3.0, so I strongly advise you to update to the newest MFW release. If at all possible, a modem trace from the old and the new modem FW would be very interesting to see.

Best regards,

Heidi

[JonathanF]

Hi Heidi,

Thank you for the reply. How would either of the scenarios that you outlined work when the device is coming out of airplane mode (CFUN=4)?

Here is the initialization sequence we're using:

AT+CPSMS=1,,,"01100000","00000000"
AT+CGDCONT=0,"IP","eseye1"
AT+CEREG=5
AT%CESQ=1
AT+CSCON=3
AT+CNEC=24
AT%XSIM=1
AT+CFUN=1

As you can see, we have the CEREG and CSCON messages enabled. Presumably we do not need to re-set these every time after coming out of Airplane mode.

I was able to reproduce the issue on the devkit earlier today, but not with a trace running. I will attempt to do this overnight tonight.

I understand that v1.3.0 is improved, and we do intend to move to that when possible. As it stands now, we do not currently have support for updating modem firmware OTA; that work is ongoing. We also need to make sure that all of the devices we've currently manufactured are supported by v1.3.0.

Thank you,
Jonathan

[Heidi]

Hi!

The scenarios described can happen when the device is coming out of airplane mode.

Furthermore, the modem team let me know that unless this issue is present on MFW 1.3.0 where there are fixes to multi-SIM operation, they will not work on this case.

[JonathanF]

Hi Heidi,

Thank you for the response. Given this response, we will prioritize adoption of 1.3.0. Can you give any guidance on using 1.3.0 for Revision 1 hardware (nRF9160 SICA B0A)? The release notes currently specify that 1.3.0 should only be used for development and testing; what sort of limitations are there with Revision 1 hardware?

Similarly, do you expect Verizon certification to happen for 1.3.0? And, if so, what is the timeline on that?

Thank you,
Jonathan

[Heidi]

Hi!

We recommend all customers transition to nRF9160 SiP Rev 2, as MFW 1.3.0 and nRF9160 SiP Rev 1 will not be a widely certified combination.

I can make this case private and we can discuss your specific use case (i.e number of chips, reason you can't transition to Rev2) if you would like. 

With regard to Verizon certification, contact your RSM, David Day ([email protected]), for information on this. 

Best regards,

Heidi

[Momchil_MRP01]

I think we just reached resolution to this issue stated by JonathanF by having our SIM provided changing the IMSI rules affecting profile rotation and connection registartion using specific IMSI to a tower.

The suggestion by Heii-Irene was in fact the issue 

You're using a SIM card that has several profiles and is able to switch between those. What could be happening is that some of the location status events are not being forwarded from the modem to the SIM card and thus the SIM card is not able to perform a SIM refresh to change its profile and allow LTE registration. 

The SIM provide had rules setup for specific IMSI that caused Service Rejection (from Cell tower provider) rather than Home Rejection (from the SIM card provider). Service Rejection was then not translated to SIM card rotation and at that physcal location the device was only in search and connect to tower state but never registered to the provider or changed IMSIs.

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

Cause #15 – 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.