nRF9161, RSP not working?

[JyriLehtinen]

We're evaluating RSP with 1oT, and we managed to successfully swap the carrier using RSP with our nRF9160DK, running our standard application.

The nRF9161-DK, running the same application (though with an additional IMU), however, fails to respond to the RSP operations. 1oT responded that "Right now we are not getting any notification back from the card to our eSIM environment (SR - secure routing instance), which usually means that the device doesn't have eSIM support in general."

I tried flashing the Serial LTE Modem application, and enabled USAT events with AT%USATEV=1, but I don't get any events at all, and %USATINFO returns 0,0.

PDP session was open during the test, I was able to ping with AT#XPING="5.189.130.26",45,5000,5,1000 just fine.

Is there additional configuration we need to to with 9161 (as opposed to the 9160), to enable BIP and/or RSP, or do you have other ideas where the problem might be?

[Øyvind]

Hello, 

What Modem FW are you running on the nRF9161-DK? What version of the nRF Connect SDK is Serial LTE Modem based on?

Are using SLM on the nRF9160DK as well? 

Kind regards,
Øyvind

[JyriLehtinen]

nRF Connect SDK: 2.6.1

nRF9161DK mfw: 2.0.1

nRF9160DK mfw: 1.3.6

I haven't tried the SLM on the 9160, as the RSP was successful with our own application (though there we some problems on the 1oT side at first)

[Øyvind]

Øyvind said:

What steps are you following when adding this feature?

It was more a question of how you configured the RSP i.e. are the setting you are using based on a guide or tutorial? Just looking for more clues to what could be causing this.

Still waiting for more answers internally

[JyriLehtinen]

No tutorials, I followed the operators instructions to have the connection open (AT+CGDCONT=1,"IP","terminal.apn" & AT+CGACT=1,1), then initiated the operator to download a new profile on the eUICC.

It worked on the nRF9160 while running our standard application, which also keeps a data connection open (tested on one DK and one custom PCB), so I didn't even try issuing the AT commands manually.

With nRF9161 both SLM and our standard app both behave the same, profile download step times out.

[Øyvind]

Thanks for clarifying. Our modem team could not see anything in the modem trace that would indicate an issue. Are you able to collect a successful modem trace from the nRF9160DK? This way our team can compare the tow.

[JyriLehtinen]

I can try to get the 9160DK trace this week.

To clarify, was there anything in the trace that would even suggest there was any RSP being attempted? I have a feeling the initial instruction never makes its way to the modem.

[Øyvind]

JyriLehtinen said:

I can try to get the 9160DK trace this week.

Yes, please do. 

JyriLehtinen said:

To clarify, was there anything in the trace that would even suggest there was any RSP being attempted? I have a feeling the initial instruction never makes its way to the modem.

I think I misunderstood our modem team. They inform me that there was no BIP or SMS activity seen in the modem trace. I think this is why they would like modem trace from a working device

[JyriLehtinen]

Øyvind said:

They inform me that there was no BIP or SMS activity seen in the modem trace.

Precisely, that's why I think the error might not be in the nRF9161. But I'm not really familiar with all the black magic that happens during RSP, that's why I'm reaching out to both parties.

[JyriLehtinen]

Here's the capture for a successful RSP on a nrf9160DK and Serial LTE Modem application. I did forget to manually open the PDP, but looking at the trace instructions for the modem were included in the initial SMS ( as the modem issued the proper AT commands on its own).

9160dk_rsp_success_trace.bin

On the nRF9161DK the SMS was never received, so that's probably the step where this fails. On whose end the issue is I don't know.

[Øyvind]

Thank you for providing this trace. I will forward to our guys to figure out where the issue is.

Kind regards,
Øyvind

[Øyvind]

Thanks for sharing logs from your devices. This confirms the possible reason for why your device does not receive the SMS. 

On the nRF9160 there is seemingly no PSM activated, and thus the device receives the SMS as expected. With the nRF9161 the PSM is activated and thus does not receive the SMS until it is in RRC connected.

In the "fail log" modem requests to use PSM and the configured T3324 is just 10 seconds - network accepts this request. This means that UE will enter PSM sleep 10 seconds after the RRC connection has been released after Attach procedure. So, PSM is entered a lot before the network sends the SMS to UE - at least according to the pass log, but there may be some kind of variation of course.

We think this means that the PSM is the reason for not receiving the SMS. Of course the SMS should be received the next time modem wakes up from PSM (assuming network has already sent the SMS). You could either disable the PSM or trigger UL data about 2 minutes after the registration, to see if the SMS is received at PSM wakeup.

Let me know how this works for you.

Kind regards,
Øyvind

[JyriLehtinen]

Ok, disabling PSM from our application made the RSP go through on the nRF9161DK, strange though that the SMS was not previously received when the RCC connection was opened for data transmission, but that's probably operator issue.

Regarding the PSM Kconfig, I didn't set any PSM options in the Kconfig files, and neither of the nRF916x builds has PSM -options set in the output .config.
Does the 9161 enable PSM by default, or does it use previous settings unless overridden, and nRF9160 has PSM disabled by default?