• State Verified Answer
  • Replies 4 replies
  • Subscribers 93 subscribers
  • Views 1134 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 293061
Options

nRF9160 PSM request accept/reject issues while using AGPS.

Chetan Kale

Hello Team,

This ticket is in continuation with Case ID: 292116. Based on last discussion I have taken more modem traces which are present in the attachment. Please ignore segmentation fault present in the traces as those are expected because of Firmware changes for the demo. 

Response from Markus: 

But the retransmission attempts from the server side might indicate weak signal quality, yes.

Question: 

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 ? 

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 ?

trace-2022-07-27T20-25-31.303Z.pcapngtrace-2022-07-27T20-25-31.303Z.bin

NCS version : 1.7.0

Modem Firmware version: 1.3.1

Device Revision : NRF9160_xxAA_REV2

Board Version : PCA10090

SIM used: iBasis

Thank you !

Regards,

Chetan

 

Parents
  • +1

    Hello again Chetan, 

    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 ?

    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

Reply
  • +1

    Hello again Chetan, 

    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 ?

    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

Children
No Data
Related
Terms of service