nRF9160 PSM request accept/reject issues while using AGPS.

RE: nRF9160 PSM request accept/reject issues while using AGPS.

Albrecht Markus Schellenberger — Fri, 05 Aug 2022 06:23:18 GMT

Hello again Chetan,

[quote user=""]

2. What exactly is the meaning of retransmission attempts from the server side might indicate weak signal quality and how to fix that risk ?

3. Is there any problem with MQTT/TCP ?

[/quote]

Regarding the above-mentioned questions, I now have gotten some feedback from the modem team. I will just copy it as it is, since it should provide you with all the information and details needed:

"I checked the modem log (the part that was pointed by Markus above). It is true that there seem to be RRC connection release in the middle of some upper layer protocol data transfer. At least it seems that way because after RRC connection release and cell selection, Service Request is triggered immediately for UL data.

I suspect there is some problem in network side, probably in eNodeB. There should not be RRC connection release if there is constant data transfer ongoing. The release should happen only after certain time of inactivity. It is possible that network gets confused by missing SAF bit (signalling active flag) sent by UE in TAU request. SAF is not sent because at that point there was no UL data to be sent (modem cannot know will there be more data or not unless Release Assistance Indicator feature is used by application). TAU was triggered by application by configuring PSM parameters and application seems to repeat it constantly. This is not useful because if network does not approve the requested parameters once, it does not help to wait a couple of seconds before trying again.

In summary, this seems to be network side problem, although I suspect it does not occur if application stops configuring PSM parameters constantly."

Cheers,

Markus

RE: nRF9160 PSM request accept/reject issues while using AGPS.

Chetan Kale — Wed, 03 Aug 2022 05:41:46 GMT

Hello Markus,

Thanks for the response. Once you get the insights from your internal team please share the same with me.

Cheers,

Chetan

RE: nRF9160 PSM request accept/reject issues while using AGPS.

Albrecht Markus Schellenberger — Tue, 02 Aug 2022 10:20:58 GMT

Hello Chetan,

A quick update from my side (and my apologies again for the delay):

[quote user=""]1. Can you please explain me the root cause of the issues that even if bit 6 to 8th are "111" in AT+CEREG response, why the nRF9160 DK is getting GPS fix ? [/quote]

As already mentioned in the previous case, there are several occasions in the log where network releases RRC connection and +CSCON becomes 0.

689    136.813634            AT    119    Rcvd AT Command: %XMONITOR: 5,"","","310260","A21B",7,12,"005CD918",139,5035,32,21,"","11100000","11100000","01001001"  OK 10.165.188.145    142.250.138.192    ILP    87    [Malformed Packet] 142.250.138.192    10.165.188.145    TCP    52    7276 → 61083 [ACK] Seq=1 Ack=36 Win=65535 Len=0 142.250.138.192    10.165.188.145    ILP    82    [UNKNOWN PER: too long integer(per_normally_small_nonnegative_whole_number)][Malformed Packet] 10.165.188.145    142.250.138.192    ILP    106    [UNKNOWN PER: too long integer(per_normally_small_nonnegative_whole_number)][Malformed Packet] 142.250.138.192    10.165.188.145    TCP    52    7276 → 61083 [ACK] Seq=31 Ack=90 Win=65535 Len=0 142.250.138.192    10.165.188.145    TCP    760    7276 → 61083 [ACK] Seq=31 Ack=90 Win=65535 Len=708 [TCP segment of a reassembled PDU] 10.165.188.145    142.250.138.192    TCP    52    61083 → 7276 [ACK] Seq=90 Ack=739 Win=6372 Len=0 142.250.138.192    10.165.188.145    TCP    760    7276 → 61083 [PSH, ACK] Seq=739 Ack=90 Win=65535 Len=708 [TCP segment of a reassembled PDU] 142.250.138.192    10.165.188.145    TCP    760    7276 → 61083 [ACK] Seq=1447 Ack=90 Win=65535 Len=708 [TCP segment of a reassembled PDU] 10.165.188.145    142.250.138.192    TCP    52    61083 → 7276 [ACK] Seq=90 Ack=2155 Win=5664 Len=0 142.250.138.192    10.165.188.145    TCP    760    7276 → 61083 [PSH, ACK] Seq=2155 Ack=90 Win=65535 Len=708 [TCP segment of a reassembled PDU] 142.250.138.192    10.165.188.145    ILP    294    [UNKNOWN PER: too long integer(per_normally_small_nonnegative_whole_number)][Malformed Packet] 10.165.188.145    142.250.138.192    TCP    52    61083 → 7276 [ACK] Seq=90 Ack=3105 Win=6130 Len=0 142.250.138.192    10.165.188.145    TCP    760    [TCP Spurious Retransmission] 7276 → 61083 [ACK] Seq=31 Ack=90 Win=65535 Len=708 10.165.188.145    142.250.138.192    TCP    52    [TCP Dup ACK 702#1] 61083 → 7276 [ACK] Seq=90 Ack=3105 Win=6130 Len=0 142.250.138.192    10.165.188.145    TCP    760    [TCP Spurious Retransmission] 7276 → 61083 [ACK] Seq=739 Ack=90 Win=65535 Len=708 10.165.188.145    142.250.138.192    TCP    52    [TCP Dup ACK 702#2] 61083 → 7276 [ACK] Seq=90 Ack=3105 Win=6130 Len=0 142.250.138.192    10.165.188.145    TCP    760    [TCP Spurious Retransmission] 7276 → 61083 [ACK] Seq=1447 Ack=90 Win=65535 Len=708 10.165.188.145    142.250.138.192    TCP    52    [TCP Dup ACK 702#3] 61083 → 7276 [ACK] Seq=90 Ack=3105 Win=6130 Len=0 142.250.138.192    10.165.188.145    TCP    760    [TCP Spurious Retransmission] 7276 → 61083 [PSH, ACK] Seq=2155 Ack=90 Win=65535 Len=708 10.165.188.145    142.250.138.192    TCP    52    [TCP Dup ACK 702#4] 61083 → 7276 [ACK] Seq=90 Ack=3105 Win=6130 Len=0 142.250.138.192    10.165.188.145    TCP    294    [TCP Spurious Retransmission] 7276 → 61083 [PSH, ACK] Seq=2863 Ack=90 Win=65535 Len=242 10.165.188.145    142.250.138.192    TCP    52    [TCP Dup ACK 702#5] 61083 → 7276 [ACK] Seq=90 Ack=3105 Win=6130 Len=0 142.250.138.192    10.165.188.145    ILP    82    [UNKNOWN PER: too long integer(per_normally_small_nonnegative_whole_number)][Malformed Packet] 10.165.188.145    142.250.138.192    TCP    52    61083 → 7276 [FIN, ACK] Seq=90 Ack=3135 Win=6100 Len=0 142.250.138.192    10.165.188.145    TCP    52    7276 → 61083 [ACK] Seq=3135 Ack=91 Win=65535 Len=0 142.250.138.192    10.165.188.145    TCP    52    7276 → 61083 [FIN, ACK] Seq=3135 Ack=91 Win=65535 Len=0 10.165.188.145    142.250.138.192    TCP    52    61083 → 7276 [ACK] Seq=91 Ack=3136 Win=6099 Len=0 LTE RRC DL_DCCH    26    RRCConnectionRelease [cause=other] AT    23    Rcvd AT Command: +CSCON: 0 LTE RRC DL_SCH    69    SystemInformationBlockType1 LTE RRC DL_SCH    79    SystemInformation [ SIB2 ] LTE RRC DL_SCH    47    SystemInformation [ SIB3 ] NAS-EPS    20    Service request LTE RRC UL_CCCH    30    RRCConnectionRequest LTE RRC DL_CCCH    65    RRCConnectionSetup LTE RRC UL_DCCH/NAS-EPS    33    RRCConnectionSetupComplete, Service request AT    23    Rcvd AT Command: +CSCON: 1

When this happens the GNSS socket becomes active and actually manages to calculate a fix during that time. This is possible even without having the LTE socket into PSM.

[quote user=""]

2. What exactly is the meaning of retransmission attempts from the server side might indicate weak signal quality and how to fix that risk ?

3. Is there any problem with MQTT/TCP ?

[/quote]

Why network releases RRC during on-going data exchange is something that I need some advice on from our modem team. I will come back to you as soon as I have an update to share.

Cheers,

Markus

RE: nRF9160 PSM request accept/reject issues while using AGPS.

Albrecht Markus Schellenberger — Thu, 28 Jul 2022 13:05:26 GMT

Hello Chetan,

Thanks for the traces! I will have a look at them and come back to you. Since we still are in the middle of the vacation period, delays are to be expected.

Regards,

Markus