subscribing in Assert tracker v2

[Mustafa]

Hello,

I'm trying to send messages from the cloud (AWS-IoT ) to the device, so I modified the device so that it subscribes to a new topic and when I send messages from could, it seems that the device doesn't listen frequently to the cloud. sometimes it receives a message, sometimes not. and when I sent multi messages very fast, the device receive all messages after a random delay. 

I tried to check the code if there is any configuration I can use to force the device to listen to Cloud always. but without luck. This behavior is in Active and Passive mode as well. 

My question is: How can the device receive messages instantly from the cloud without delay. 

Thanks in advance.

[Albrecht Markus Schellenberger]

Hello Mustafa,

My apologies for the delayed reply. Markus Tacker is on vacation currently. I will forward the trace to our modem team for further analysis and keep you posted.

Regards,

Markus

[Albrecht Markus Schellenberger]

Hello again,

I already got some feedback from our modem team :-)

Analysis from log:

Application has configured PSM. Sleep period 1 hour, active time 2 seconds
00:00:00.206512 L23_AT_STRING AT_STRING => +CPSMS=1,,,"00100001","00000001"

UE sends TLS data that is acked by server. This is last data transmission.

40 sec after data transmission RRC connection is released and after 2 seconds active time the modem falls to PSM and is not listening to network.

00:00:49.655944 ERRC_PDU_TYPE_DL_DCCH_3 ERRC PDU: RRCConnectionRelease
00:00:52.933563 EMM_STATE_CHANGE : EMM_REG_NORMAL_SERVICE => EMM_REG_NO_CELL_AVAILABLE

After 20 minutes from last user data, the application tries to send more data, but TCP connection is already closed by the server.

So, PSM prevents the client from receiving DL data. Our recommendation is that you should start with disabling PSM completely. Afterwards, you could adjust the active time to the servers response time.

Regards,

Markus

[Mustafa]

Thank you Markus for your answer, Actually I'm still wondering about the reason to close the TCP connection with server-side. It supposes to keep the connection alive because CONFIG_MQTT_KEEPALIVE = 1200. even I tried to reduce this time but it always closes the connection after 320 seconds ( any value above 320sec causes CLOUD_TIMEOUT event).

[Albrecht Markus Schellenberger]

Mustafa said:

Actually I'm still wondering about the reason to close the TCP connection with server-side. It supposes to keep the connection alive because CONFIG_MQTT_KEEPALIVE = 1200. even I tried to reduce this time but it always closes the connection after 320 seconds ( any value above 320sec causes CLOUD_TIMEOUT event).

Thanks a lot for your feedback, Mustafa! That is a good and interesting observation. I wonder if maybe the NAT rules time-out, making the server not recognise the client anymore? I have to check this with our experts. I’ll be on vacation next week, but I asked my colleague Didrik Rokhaug to watch this ticket.

Regards,

Markus

[Didrik Rokhaug]

Hi,

Could you try to disable PSM, to see if that changes things?

Best regards,

Didrik