SOFTSIM: NULL(0x60) APDU response and timeout to 2s

[Pascal TROUVIN]

Hi,

I'm exploring the SOFTSIM feature on a nRD9160-DK.

*** Booting nRF Connect SDK v3.5.99-ncs1-1 ***

SDK version used: v2.6.1

Currently the softsim is waiting for the APDU answer up to 2s, and I would like to know if there is a way to tell the softsim to wait a bit more. In a standard SIM protocol, it is defined in document ETSI-TS-102221 (https://www.etsi.org/deliver/etsi_ts/102200_102299/102221/17.01.00_60/ts_102221v170100p.pdf)

"The NULL-byte requests no further data transfer and the
terminal shall only wait for a character conveying a procedure
byte. This behaviour provides additional work waiting time as
defined in this clause."

So Does the NordicSemi softsim implementation support that?

Result:

SOFTSIM enabled

[00:00:02.723,358] <inf> cloudsim: CS>ATR?
[00:00:02.723,480] <dbg> cloudsim: replyToModem: (44)3B9F14801FC78031E073FE21136749250C2900000112 -> RC(0)LEN(22)

ATR send to SOFTSIM

[00:00:02.723,754] <inf> cloudsim: CS>80f20000000168
[00:00:02.723,876] <dbg> cloudsim: replyToModem: (68)621e8202782183023f008a01058b032f060fc60c90012083010183018183010a9000 -> RC(0)LEN(34)

[00:00:02.730,133] <inf> cloudsim: CS>00a408040000022fe20168
[00:00:02.730,255] <dbg> cloudsim: replyToModem: (106)62318202412183022fe2a506c00100ca01008a0105ab1580010190008001029700800118a40683010a9501088002000a8801109000 -> RC(0)LEN(53)

[00:00:02.730,407] <inf> cloudsim: CS>00b000000a
[00:00:02.730,499] <dbg> cloudsim: replyToModem: (24)981370104200204203f49000 -> RC(0)LEN(12)

[00:00:02.731,933] <inf> cloudsim: CS>00a408040000022f000168
[00:00:02.732,086] <dbg> cloudsim: replyToModem: (110)62338205422100200183022f00a50ac00100cd02ff00ca01848a0105ab10800101900080011aa40683010a950108800200208801f09000 -> RC(0)LEN(55)

[00:00:02.732,238] <inf> cloudsim: CS>00b2010420

[00:00:02.732,330] <inf> cloudsim: semaphore ss_apdu received

[00:00:04.232,452] <dbg> cloudsim: replyToModem: (2)60 -> RC(0)LEN(1)

[00:00:04.232,513] <inf> cloudsim: send NULL

[00:00:04.241,058] <inf> cloudsim: CS>00b2010420
Network registration status: UICC fail
LTE cell changed: ID: -1, Tracking area: -1
[00:00:05.732,635] <dbg> cloudsim: replyToModem: (2)60 -> RC(0)LEN(1)

[00:00:05.732,696] <inf> cloudsim: send NULL

[00:00:05.741,394] <err> cloudsim: softsim_handler.NRF_MODEM_SOFTSIM_DEINIT

So the NULL(0x60) seems to supported but there is also a hard timer set to 2s.

Is there a way to ask the softsim to wait longer?

Regards

[dejans]

Hi,

Does the NordicSemi softsim implementation support that?

I need to discuss this with our developers. I will get back to you by the end of this week.

Best regards,
Dejan

[dejans]

Hi,

Is there any specific reason why you want or need to have waiting period extended to over 2 seconds?

Best regards,
Dejan

[Pascal TROUVIN]

Of course, we are using the softsim to run the SIM over the cloud and thus you might sometimes have response time for more than 2s.

Kind regards

[dejans]

Hi,

Thank you for this information. I will get back to you during next week.

Best regards,
Dejan

[dejans]

Hi,

Is there any suggested timeout time which you would find to be better than existing 2 seconds? How many seconds before timeout would you find satisfactory? 

Best regards,
Dejan

[Pascal TROUVIN]

Hi,

5s or 10s would be a good start.

But the real option to fix it definitively would be to extend the timeout by 1s for each call of NULL command(0x60).

On other implementation, I was able to make the modem wait for more than 10s.

Kind regards

[dejans]

Hi,

Pascal TROUVIN said:

5s or 10s would be a good start.

But the real option to fix it definitively would be to extend the timeout by 1s for each call of NULL command(0x60).

Thank you for this information.

We will look into this. I expect to get back to you during next week.

Best regards,
Dejan

[dejans]

Hi,

This is just a short status update. We are still looking into this.

Thank you for your patience.

Best regards,
Dejan

[dejans]

Hi,

Although we have made some progress, additional time is needed. We continue working on this.

I expect to get back to you by the end of next week with another status update.

Thank you for your patience.

Best regards,
Dejan

[dejans]

Hi,

We are still looking into this issue. I will get back to you by the end of next week with another status update.

Best regards,
Dejan