Implementing low-powered push notifications on nrf9160

[royalbee]

Hello,

We are interested in developing mechanism that will allow the server to send push notifications to our nRF9160 device.
We need to be able to respond to the notification quickly (preferably less than a minute), and obviously we need to save battery power as much as possible on our devices.

Can you suggest your preferred solution for that?

---

And some questions from the research we did so far:


Using eDRX to keep the modem in eDRX power saving mode until a notification arrives, seemed like a good option, but we are not sure about various things:

1. How many operators fully support eDRX and how reliable is it?
2. If one thread is waiting on eDRX and another thread tries to send data to server (on a different TCP socket), can they interrupt each other?
3. Is there a working reference project/sample program that implements communication with eDRX?
4. Will eDRX work with UDP sockets?
5. Will eDRX work AWS IoT library (using MQTT), out of the box?


Is there an option to keep the modem in some power save mode, and wake up on incoming SMS?
Or maybe stay on eDRX power saving, and the incoming SMS will trigger eDRX wakeup?


Can we we PSM power saving and wakeup on incoming notification somwhow?


In any case, any working reference code will be helpful.

Thanks in advance..

[emh203]

I have been successfully using the low power states.   Some tips:

1.)  There is a sample of eDRX and PSM.    Checkout the UDP sample.      That is what I started with.    I was able to get a 4uA sleep/idle

2.)   Getting to 4uA means you have to shut everything down.     UARTS, I2C, etc.    The CPU will go into its lowest power mode when all the threads are sleeping.  However,   this does not include peripherals.    I tried to use the Zephyr Power APIs but they seems to not work.    Specifically I2C.   I ended up just using my own baremetal code (skipping zephyr drivers)  and was able to get everything to a minimum.

3.)   If you are using the shell,  you need to make sure it is disabled.   I use Segger RTT for configuration over the zephyr shell and do this 2 minutes after boot:

    shell_uninit(shell_backend_rtt_get_ptr(),0);

4.)    I am not using eDRX as it seems PSM gets you to the absolute minimum.     It is carrier dependent.   And it depends on if you are roaming.   For example,  I use twilio sims which always "roam".     IN this case T-Mobile will not allow PSM but ATT will.   I have not tried Verizon.

5.)   TCP based protocols are effectively useless w/  PSM or eDRX.       Maintaining the TCP connection through PSM sleep states is a quagmire.  UDP is the path to the absolute lowest power.   That means MQTT base things won't work.

6.)    With PSM,    if you want to transmit, you simply do so.   The modem will power up and Tx.  It will stay alive for a prescribed about of time to receive messages.     The parameters are requested when you connect but I noticed that the carriers may ignore your timing parameters.    IN my case w/ ATT,    the modem will stay alive for about 10 seconds when I transmit and then go to sleep.

7.)   If you transmit a UDP packet to the modem while it is asleep,   the cell tower will queue message until you wake up.    This is not 100% though.   I noticed that sometimes it is lost.     We have a system that will queue up messages in our backend until it hears something.   Then we send during the 10 seconds window.

8.)   You may have a difficult time with quick reactions (not sure how quick you are expecting).   Keeping the modem alive even to Rx will really wipe out your battery.

9.)    Battery selection is critical.   We using a battery that includes a HLC to deal with the high Tx current.    

[royalbee]

Hi emh,

Thanks for your detailed reply. 
I wanted to wait for Nordic's response first, but that seems to take time, so I will ask you without waiting:


Using TCP/IP is not practical with PSM because of the ack, syn, fin and rst communications?
Will it also be a problem with eDRX? That's a big question because there are existing solutions based on TCP/IP, and developing a proper UDP based solution is quite an effort.

I am also not sure how PSM work exactly: Do you have a window like eDRX at which the modem checks with the network weather it has pending data waiting?
Without such a window I don't see how the modem can know about incoming data.
But with such a window, it means, that the modem will need to reconnect to the network (and to other resources) ? So if the interval of such a window is not large then it will consume a lot of battery power, and if the interval is very large, then incoming message will wait for a long time (and we want relatively quick response).

[emh203]

1.)    TCP based protocols can be difficult w/ PSM and EDRX because of the handshakes,etc.     If the protocol is well behaved then you could probably get away with it but I think it will always be more complicated (and use more power than something UDP based).        Even if you schedule transmissions from your server to the client,   the client must 'ack everything, wake up the modem, etc.    Also,  for things like MQTT, etc. you must be able to tune keep alive messages, etc.    With prepackaged cloud service you don't get a lot of control of details.     I am sure someone has gotten it to work but I found it was just easier to use UDP.

It all comes down to maintain socket state when sleeping.   Most protocols really aren't designed for it.

2.)   PSM seemed the simplest to me.    You can transmit whenever your want but the modem will stay alive for a bit (in my case about 8 seconds) to hear responses.     It does periodically check in with the tower for updates.  This parameter is configurable.    The default setting w/ the example is once an hour.     You can receive during this window as well.

From the perspective of your application code,  all you do is transmit when you want to.    You just have to know that you won't get incoming packets at any time.

Here is a current measure of the modem (3.6v in) waking up,  doing some UDP transmits and then going back to sleep.    Most of my Tx/Rx is at the beginning.   There is one blip at the end where I believe the modem is telling the tower it is going back to sleep.    You can see what average current is over that time period, etc.

   

In my case I send 3 UDP messages and each get an 'ack via our protocol.

Also note that w/ PSM and CAT-M,   you can be mobile.   We took a 2 hour drive to a test site and left the sensors on.   They were reporting every 10 minutes.     The modem will reconnect to the tower, etc.     I was able to map the drive.

I believe w/ PSM and a fixed location,   once the modem negotiates and goes to sleep, subsequent activity is faster as the tower maintains connection state.      If you can't get PSM the fall back is to completely power down the modem and get a new connection whenever you want to transmit.   This seemed about 4x worse in terms of battery life.  I don't have a hard measurement,  just what I noticed during experimentation.   

3.)    There at notifications you can get with XMODEMSLEEP.    You can get a notification of when tracking updates will occur (TAU timer) to also synchronize data transmission at that point in time.  I found it was just easier to Tx when I wanted.

eDRX might be better for you application as I thinking you can tune the timers to listen for messages more frequently.  However, I believe the PSM sleep currents will always be better.

The UDP sample under nrf/samples/nrf9160/udp  can be configured for either eDRX or PSM.

Also, see this:

 Getting started with current measurements on the nRF9160 

[emh203]

Also,  these links might be helpful:

https://www.twilio.com/docs/iot/supersim/low-power-optimization-for-cellular-modules

devzone.nordicsemi.com/.../online-power-profiler-for-lte