Decrease CSCON: 1 time

[ralphvn]

I am using nRF9160 to develop a mobile measuring device.

For this purpose I need LTE and GPS, I know it is shared so I had to implement PSM/eDRX to make it work together. This goes well to a maximum logging frequency of about 13 seconds because GNSS is blocked by LTE activity for about 11/12 seconds after I send a measurement.

For this reason I changed my application, when I got a fix I do a measurement and send this logging. Then I have to wait till there is a new fix, about 12/13 seconds and do this again. I found out this 12/13 seconds that GNSS is blocked by LTE is caused by CSCON: 1, after 12 seconds I see +CSCON: 0 and there is a fix and a new measurement logged. I log these measurements to AWS IoT core and sending the data and waiting for an ACK is about 1 second. The other 12 seconds it is just waiting for CSCON getting 0 again.

Is there a possibility to decrease this CSCON: 1 time so it gets +CSCON: 0 sooner so I can get a fix more often, preferable every 5 or at least 10 seconds?

[Achim Kraus]

I guess you use TCP. With that, there are potentially more radio-data messages in the air than application data messages passed in. That makes it hard to use RAI (Release Assistance Indication) and it would anyway require to be supported by the MNO. So, if you not willing to switch to UDP, I don't see, how the RRC active time (after the last message exchange) could be reduced. Some try to use RAI even with TCP, but I'm not aware, that this is used with success.

[ralphvn]

It is correct I am using TCP, and the explanation is clear. For now, I will just leave it and maybe later evaluate using UDP is an option if I really need this time to be reduced.