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

[royalbee]

OK thanks,

a few more questions:

1) You say that the default PSM window is 1 hour, and that you can receive also during this window. But how can I receive during the window if the modem is disconnected from the cellular network? the modem can't know about incoming data in such case right?

If I understand correctly, PSM is best used when the modem side initiates the requests to the server (and from your description that is indeed your case), but we need server-initiated requests, so I'm not sure how that will work (?)

2) You said that we need to do nothing special when PSM is used, just use socket and send and receive data. But you also said that you shut down all resources during sleep mode (UART, I2C, etc), so how is that done? you don't listen to XMODEMSLEEP notifications and do the shutdown?

3) Why roaming is needed for PSM, and what is this "always roam" SIM? and can I use SIM that doesn't always roam with PSM?

[Håkon Alseth]

Hi,

 

Both eDRX and PSM are modes that allows the UE (user equipment, ie. nRF9160 in this case) to sleep for longer periods before having to listen.

 

If your eDRX (or PSM) interval is 60 minutes, and the application does not trigger a send() during this period, you'll have a response time of 60 minutes.

If you need to poll a server connection (or incoming SMS for that matter) more frequently, you should adjust the interval accordingly.

 

If you are a TX driven application, ie. that you send data to a server, you can use PSM with a very high interval.

Each time you trigger a send(), PSM will automatically be re-negotiated afterwards.

royalbee said:

2) You said that we need to do nothing special when PSM is used, just use socket and send and receive data. But you also said that you shut down all resources during sleep mode (UART, I2C, etc), so how is that done? you don't listen to XMODEMSLEEP notifications and do the shutdown?

Disable your peripherals that you use, then place the GPIOs for those in its idle state.

royalbee said:

3) Why roaming is needed for PSM, and what is this "always roam" SIM? and can I use SIM that doesn't always roam with PSM?

Roaming is when you're connected to a network that isn't your original subscribed LTE network.

virtual operators, such as hologram/ibasis and many others, will always be roaming. They're socalled MVNO's:

https://en.wikipedia.org/wiki/Mobile_virtual_network_operator

Roaming agreements must be in order, and in some cases; you can roam but not get eDRX/PSM for instance. This is something you should ask the virtual operator about specifically.

 

Kind regards,

Håkon

[emh203]

1.)     Yes,  when using PSM   the modem only can get incoming packets during the TAU update  or during the active time after a transmit.      

So, as an example,  in my application I send packets every 10minutes.     The Modem stays alive for roughly 8seconds when I transmit.   I have my backend Tx any messages during this period.   It is it knows it can send a message to the device as it just received something.

You server initiated request really has to work within these boundaries.         You could have the modem wake up more quickly, to send a heart beat but your battery life will be severely impacted.

2.)   I decided to skip the zephyr driver API.  It seemed that the power management interface didn't work well.   There were various bits still left enabled.    I ended up just writing my own bare metal drivers for I2C, SPI, GPIO.   I had to implement some interconnect between peripherals (GPIO IRQ, SPI DMA, etc) and the Zephyr driver model wasn't really useful.   The hardware is quite simple on the nRF an I found it was easier to have  fine grained control over everything.

To shut off peripherals I simply looked at the register documentation and found the appropriate bits.    I also created a custom Zephyr board where I left most things disabled in the device tree.

In my case, I am able to get around 4.5uA sleep current using PSM.  This includes the nRF9160,  the quiescent draw of some other parts on my board, leakage, etc.      

I use a few more uA when a thread wakes up to check things, etc.   

Most Zephyr examples use the Shell/UART.    The shell spins up its own thread which uses power.   I ended up using the shell over Segger RTT and wrote some code to turn it off after a few minutes.

It takes some work but you can get current on the application side pretty low.

3.)    I should have been more clear.   If you use a MVNO   (Twilio, Hologram, etc) that works with various carriers,   they will show up on the carrier's network as a roaming device.  In some cases, T-Mobile for example,  will not allow PSM states while roaming.  AT&T however will allow PSM states on a roaming device.

If you uses a carrier sim card  (say directly from T-Mobile, ATT, Verizon, etc),   it will not be roaming on the network.  However, you still need to test that the tower grants you the PSM/eDRX state.

Services like Twilio, etc. are popular as it is easy to prototype.   Some carriers are very difficult to work with until you spend mega-$$$$