NB-IOT JIO SIM Not connecting asset tracker Work Up to RRC Connected and stuck there.

[Hardik.Harpal]

Using NB- IOT JIO SIM in india, not connecting asset tracker Work Up to RRC Connected and stuck there. This is custom code very similar to asset tracker example. We are using custom board, same setup works fine on Ibasis SIM in USA.

[00:00:00.215,576] [0m<inf> asset_tracker: Connecting to LTE network.[0m
[00:00:00.215,942] [0m<inf> asset_tracker: This may take several minutes.[0m
[00:00:00.223,205] [0m<dbg> lte_lc.lte_lc_system_mode_set: Sending AT command to set system mode: AT%XSYSTEMMODE=0,1,1,0[0m
[00:00:00.259,643] [0m<inf> lte_lc: PDP Context: AT+CGDCONT=0,"IPV6","JioIPIoT"[0m
[00:00:00.267,608] [0m<dbg> lte_lc.lte_lc_system_mode_set: Sending AT command to set system mode: AT%XSYSTEMMODE=0,1,1,0[0m
[00:00:27.635,711] [0m<dbg> lte_lc.at_handler: +CEREG notification: +CEREG: 2,"C061","00282218",9
[0m
[00:00:27.636,444] [0m<inf> asset_tracker: LTE cell changed: Cell ID: 2630168, Tracking area: 49249[0m

trace-2021-07-13T00-06-58.563Z.pcapng

trace-2021-07-13T00-06-58.563Z.bin

[Heidi]

Hi! Håkon has gone on vacation so I have taken over this case.

The conclusion from the modem trace you provided is that the Attach procedure is prevented due to the modem reset loop restriction feature which was introduced in MFW 1.3.0. We have just released a white paper on the feature which should explain the functionality in detail: nWP042 - nRF9160 Modem Reset Loop Restriction

In short, the feature restricts Attach attempts to the network for 30 minutes in the case where the modem detects that the UE is in a reset loop. This can also happen if the modem is manually reset too many times.

The AT+CFUN = 0 command should be used for shutting down the modem gracefully in order to avoid this restriction. 

Please let me know if this solves the issue you are seeing. 

Best regards,

Heidi

[Hardik.Harpal]

Hi,

But I am seeing similar results in Modem firmware version 1.2.3 and earlier version on Dev kit I have 1.2.3 let me send you modem log from it. I will use MQTT simple example and configure it for nbiot.

Can AT_Client example running with link monitor can provide modem trace by default or do I have to change prj config changes to enable it?

Can you analyze this  new log withing next 22 hours? I have meeting with  JIO support team. If anything from their side I can provide our observation from Log they're asking for more detailed modem log as I explained in previous replies, I shared same modem trace (wireshark playable) with them. There are higher chances it is from network, but we need to figure it out as it is a month long now.

Regards,

Hardik Harpal

[Heidi]

Hi, we need the modem trace with MFW 1.3.0, because that's the version with the reset loop functionality.

Please take a new trace using MFW 1.3.0 and wait 30 minutes for the reset loop detection to go away. 

. 

[Hardik.Harpal]

Heidi

I will provide that log in next 30 minutes, but I have confusions.

1)  My problem is not reset loop but Network registration issue which is also happening in modem firmware 1.2.3. Is it not possible to find out the reason from that log what is LTE level error? I think it is possible. Our development is stuck due to this issue can we at least make it work on modem firmware 1.2.3 where there is no reset loop then meanwhile we can also work on modem fw v1.3.0 in parallel. Our objective is to find out why NBIOT registration failing in any modem fw version we can use.

Please can we not find anything related issue in this log because my doubt is after submitting new log from 1.3.0 without reset loop we will see similar issue in log as current log, and then it will take one extra day to start from there  

2) I have nrf9160 SIP marked B0, but it is showing Model: NRF9160_xxAA_REV2.in nrf programmer but as per modem firmware download section it is showing  \different B0 = Rev1 and as per guideline it is recommended to use rev1.3.0 on B1 = Rev 2 So can you clarify I am hesitating to use modem fw version 1.3.0 on our custom board I had one board with modem FW1.3.0 due to some hardware issue that board is not working. I need to upgrade modem fw in another board but is it safe.

 

[Hardik.Harpal]

Hi,

Please find attached log for MFW 1.3.0 for >30 min.

Captured two sessions.

trace-2021-08-17T13-12-42.288Z.pcapng

trace-2021-08-17T14-13-07.560Z.bin

trace-2021-08-17T14-13-07.560Z.pcapng

trace-2021-08-17T13-12-42.288Z.bin 

[Hardik.Harpal]

If required this log, it is wait for >30 min after AT+CFUN=0 and  before AT+CFUN=1trace-2021-08-17T14-59-19.467Z.bin

trace-2021-08-17T14-59-19.467Z.pcapng

[Heidi]

1. Yes, the problem isn't the reset loop but the logs aren't showing why the Attach isn't succeeding, because the Attach request is being blocked by the reset loop. So we needed a trace where the reset loop isn't blocking the Attach request to be able to see the reason for failure, which is most likely the same reason on MFW 1.2.3. 

2. I would assume the marking on the SIP is the correct version, but I will double check this. 

Your log revealed why the Attach doesn't succeed. The network does not allow to access with this SIM card (no matter which MFW version used), because there is no roaming agreement etc. If it should be possible to access the network with this card, you need to contact the carrier to resolve this.

[Hardik.Harpal]

Heidi said:

1. Yes, the problem isn't the reset loop but the logs aren't showing why the Attach isn't succeeding, because the Attach request is being blocked by the reset loop. So we needed a trace where the reset loop isn't blocking the Attach request to be able to see the reason for failure, which is most likely the same reason on MFW 1.2.3. 

I thought reset loop only present in MFW  1.3.0 and not in MFW  1.2.3, so I assumed there will be no reset loop blocking in MFW 1.2.3.

Heidi said:

Your log revealed why the Attach doesn't succeed. The network does not allow to access with this SIM card (no matter which MFW version used), because there is no roaming agreement etc. If it should be possible to access the network with this card, you need to contact the carrier to resolve this.

I already contacted them, earlier they are asking for more detailed log Like I said in earlier posts. Let me send them new log, but they are asking for LTE Physical, MAC, RRC, NAS signaling so don't know they can support.

So in the both new logs there is no reset loop observed. Right?

[Hardik.Harpal]

There is no roaming as they are the only cellular provider in India at the moment for NBIOT, and they have PAN India NBIoT working.

[Heidi]

Hi, 

Hardik.Harpal said:

I thought reset loop only present in MFW  1.3.0 and not in MFW  1.2.3, so I assumed there will be no reset loop blocking in MFW 1.2.3.

 Yes, the reset loop is only present in MFW 1.3.0. The reset loop isn't the problem, but it was preventing us from seeing the reason for the ATTACH request being rejected. 

RRC and NAS is visible in the PCAP file that you have attached earlier. And they show the reject PDU from the network. 

We don't understand why they want LTE physical or MAC. The reject is clear and visible, and the failure is in the NAS level, not below, meaning RRC PDUs should not be needed either.

​

[Hardik.Harpal]

Ok thanks 

Hardik.Harpal said:

2) I have nrf9160 SIP marked B0, but it is showing Model: NRF9160_xxAA_REV2.in nrf programmer but as per modem firmware download section it is showing  \different B0 = Rev1 and as per guideline it is recommended to use rev1.3.0 on B1 = Rev 2 So can you clarify I am hesitating to use modem fw version 1.3.0 on our custom board I had one board with modem FW1.3.0 due to some hardware issue that board is not working. I need to upgrade modem fw in another board but is it safe.

Can you check above, not that urgent, but we definitely need clarity on this? We just ordered few from digikey 2 months back, but it is same B0 marking but with Rev2 read n programmer. 

[Heidi]

The marking on the SiP is the correct labeling, so you have REV1.