This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Possible issues with eDRX on Verizon

Using the nRF9160 on the Verizon network we are having some issues with eDRX.  Specifically sending data to the device from our MQTT server.  

We have configured a eDRX interval of 40.96 seconds with a PTW of 1.28 seconds.  What I'm seeing is that the socket from the device to the server remains open and we can send data in that direction with no issue.  Server initiated messages are not reliably delivered, and when a server messages is not delivered it s breaks the server to device connection so any subsequent MQTT publishes from the device do reach the server, but the ACK does not reach the device.  If we close/open the socket then communications resume. 

We tried increasing the PTW to 5.12 seconds and that seems to improve things somewhat, but we are still seeing the same issue. 

Also I'm finding that if a server message is initiated during or right after a eDRX cycle, on the following eDRX cycle the nRF9160 does wake up for the ~9second RRC timeout (as seen on a current meter), but the message is not received and the socket from the server to the device is broken.  

We are working with Verizon on this issue as well, but they are indicating that this may be a nRF9160 issue.  

Any feedback on this use case/configuration?

  • I have some additional information about how the Verizon network handles server to UE data.  Verizon is telling us that the network does not buffer any TCP to the UE, but they do buffer that they need to send a page to the UE.  After the UE receives the page, it will establish a RRC connection, but it is up to the server to deliver a TCP packet in the RRC window.  

    The issue is that the TCP server does not know when the UE has been paged. 

    It is possible for the nRF9160 to tell out application that it has been paged?  If so we could then send a message tot he server requesting data.  This could be a work around for the problem.  

    Since we are trying to implement bidirectional MQTT data, the current implementation of eDRX by Verizon basically makes server initiated TCP data useless, unless we can figure out a way to work around this issue.  

    Thank you for the help. 

  • Hi Joshua,

    A suggestion for a workaround to this could be that every time the UE device (nrf91) is going to do any communication it can send an empty MQTT packet to the server on a specific topic then the server responds accordingly with the correct data so you do not lose any packets. 

    NOTE: With the mfw1.1.0 the introduction of the AT+CSCON command can be used to get notifications when RRC Connections are established.

Related