• State Verified Answer
  • Replies 2 replies
  • Subscribers 88 subscribers
  • Views 1191 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 263736
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Wake up from eDRX nRF9160

isurki

Dear Community,

I have been testing eDRX on nRF9160. For that, I have modified nRF Connect SDK "udp" sample. I have set eDRX cycle to 20.48s.  My program does the following:

The nRF9160 enters eDRX mode and sends to a Raspberry Pi with static IP an UDP package. The Raspberry reads the message and the IP of the nRF9160 . After sending the message it consumes around 70 uA, which seems nice. 

At some point, the Raspberry Pi sends an UDP package to the nRF9160. With some latency, nRF9160 wakes up automatically from eDRX mode and it is able to read the message sent from the Raspberry Pi.

I don't know even how this can work, but it seems to work. However, after some time of inactivity, the nRF9160 seems not to detect new UDP packages are incoming. I think that this method to make up from eDRX is not reliable. So how can I wake up my nRF9160 from eDRX in a reliable way? SMS could be a solution, but here in Spain Hologram does no offer a dedicated phone number to send SMS...

Any suggestion is welcomed!

Ander.

My UDP sample demonstration video.

  • +1

    Hi,

     

    I don't know even how this can work, but it seems to work.

     The operators typically has a small buffer for messages to devices in eDRX and/or PSM. During the next paging window, the network will inform the device that it has some data to download, and an RRC connection will be established so the data can be downloaded.

     

    However, after some time of inactivity, the nRF9160 seems not to detect new UDP packages are incoming.

     Based on how you are testing this, it looks like a NAT timeout to me.

    Cellular devices are often behind a carrier operated NAT layer. In other networks, we have seen this NAT layer time out after ~1min for UDP connections. After that, the device would get a new IP address/port, and therefore be unreachable by the old IP address.

    Is it enough that the device regularly sends messages to the cloud, and then the cloud can reply if necessary? or do you need to be able to initiate communication to the device from the cloud? 

    If the first scenario is enough, then that should work without any issues. But if you need the second scenario, you can either try to change to TCP, which typically has much longer NAT timeouts, or you must find an operator which supports SMSes or static IP addresses.

    You local Regional Sales Manager might be able to provide you more information about your local operators.

    If you do not know how to contact your RSM, you can send me a private address with your location, and I will provide you the contact information.

    Best regards,

    Didrik

  • 0 in reply to Didrik Rokhaug

    Hi 

    I have measured UDP working time, and as you told me seems to be 1 minute.

    TCP seems to work much better. It worked 10 minutes after the first attempt, but I don't know if it can be enough and I need to do more tests.

    I have found another way which is to use Hologram Tunneling. This option seems to be the most reliable one and it is easy to set up.

    All in all, I think I have a solution with Hologram Tunneling and I will test more TCP.

    Regards,

    Ander.

Related