• State Verified Answer
  • Replies 11 replies
  • Subscribers 97 subscribers
  • Views 822 views
  • Users 0 members are here
Attachments (4) Download All
Nordic Case Info
  • Case ID: 362538
Options

nRF9160 wakeup from RRC idle on incoming traffic, but data is lost

Stephan Walter

We are using the nRF9160 with firmware 1.3.6 to establish a DTLS connection to a server, using the Zephyr TLS stack.

The following problem occurs quite frequently: After some idle time, the modem will enter RRC idle and signal this with +CSCON: 0. If the server now sends data, the modem will wake up from RRC idle, but we don't actually receive the packet.

Such a case is documented here and in the attached files.

Packet trace on the server (server has local IP 172.18.16.75): /cfs-file/__key/communityserver-discussions-components-files/4/0284.trace0_2D00_server.pcapng

Packet #30 is an uplink packet from the nRF91 to the server. The server then tries to send data to the client (packets #31-#34). The modem wakes up for each of them, but no data is received:

10:11:11,633	+CSCON: 0
10:11:16,796	+CSCON: 1
10:11:20,263	+CSCON: 0
10:11:22,236	+CSCON: 1
10:11:25,596	+CSCON: 0
10:11:27,996	+CSCON: 1
10:11:33,560	+CSCON: 0
10:11:36,956	+CSCON: 1

At 10:11:38, packet #35 is finally received by the client and a response is sent to the server. This indicates that the connection remained active in the software stack and also in any middleware (NAT etc.).

Modem trace: /cfs-file/__key/communityserver-discussions-components-files/4/1754.trace0.bin The modem trace starts with packet #30 at 10:11:08.

We are aware that being layered on top of UDP, DTLS packets are not guaranteed to be delivered. But the packet loss is so frequent and severe that we suspect some problem in the interaction between modem and LTE-M network.

Parents
  • 0

    The modem trace shows different IP addresses than the server trace.

    Are you using a VPN or something similar from the mobile provider to your server?

    And in order to see, if that affects the traffic, a more complete modem trace would be helpful to see, if those addresses are changing over time.

    >  This indicates that the connection remained active in the software stack and also in any middleware (NAT etc.).

    Agreed, but the modem trace may be an additional indicator (from handshake to the final message exchange).

    And maybe some more  details from the modem setup, e.g.

    is eDRX used?

    Is the UDP socket "connected" to the "server ip"?

       

Reply
  • 0

    The modem trace shows different IP addresses than the server trace.

    Are you using a VPN or something similar from the mobile provider to your server?

    And in order to see, if that affects the traffic, a more complete modem trace would be helpful to see, if those addresses are changing over time.

    >  This indicates that the connection remained active in the software stack and also in any middleware (NAT etc.).

    Agreed, but the modem trace may be an additional indicator (from handshake to the final message exchange).

    And maybe some more  details from the modem setup, e.g.

    is eDRX used?

    Is the UDP socket "connected" to the "server ip"?

       

Children
No Data
Related
Terms of service