Hi,
I have explored power saving modes for nRF91 like eDRX regular interval wakeup modes, etc.
I want to know more about like is there any other way to wake up nRF91. like any specific protocol PKT is there? which I can send to nRF91 module, over cellular network, and device wakeup. (ex. Cellular modem wake up signal).
Thanks
Hi Trackr,
You can refer to https://infocenter.nordicsemi.com/topic/nwp_044/WP/nwp_044/intro.html. It covered the techniques that cellular IoT devices can use including power saving features.
I am not sure which PKT protocol you mean here, but in theory, if the device needs to wait for a wake-up signal its radio rx will need to keep on, this is not power efficient for a cellular IoT device.
Best regards,
Charlie
Hi Trackr,
You can refer to https://infocenter.nordicsemi.com/topic/nwp_044/WP/nwp_044/intro.html. It covered the techniques that cellular IoT devices can use including power saving features.
I am not sure which PKT protocol you mean here, but in theory, if the device needs to wait for a wake-up signal its radio rx will need to keep on, this is not power efficient for a cellular IoT device.
Best regards,
Charlie
Hi Charlie, Thanks for getting back.
So, we are specifically looking for ways to wake up nRF91 from Cloud.
Assuming our device will be in sleep mode and our end consumer requests some data from nRF91 device (Mobile - Cloud - nRF91), we would need to wakeup the device from Cloud (may be send wake-up packet or some other mechanism???); fetch data and then go back to sleep mode.
What are the ways to achieve the same?
I think, there are two topic:
Radio topic:
- if the device is in sleep mode, rx (radio receiver) is off. To receive any "wake up signal" over radio, it's obvious required to turn on the receiver, but that comes already with a high consumption.
- eDRX therefore enables to determine, how frequently the receiver is switched on. e.g. if you select 40.96 the device will enable the receiver every 40.96 seconds. If you select 81.92 then the device will consume less energy and enables the receiver just every 81.92s
- in many ultra-low-power cases, when a device should run rather for months instead of days or weeks, the device will need to sleep even much longer, e.g. 1h or 2h. Then PSM is a good choice.
Overall, in my experience many networks supports PSM, but not all networks support eDRX.
Application topic:
- a server will only be able to send data successful to the device, if the device turns on the receiver and somehow a route exists to the device. Assuming IP is used, you need at first a valid and healthy ip-route. That depends then on the used protocol flavor, TCP or UDP. Just make your own experience.
- In too many cases, regardless of the radio-layer, the ip-route is invalid and therefore the server is not able to send any data to the device over ip. The most stable solution here is unfortunately, that the device initiates the communication (again) and so establishes again a valid ip-route. For TCP/TLS this usually comes with overhead, for UDP it depends on the supported features. With DTLS 1.2 Connection ID, the overhead is very small.
- you may also consider to use a non-IP route, e.g. SMS or others. Then you need to check the APIs of your providers, how to do that. But also remember, this still requires a enabled receiver.
In my experience, the approach with frequently message exchanges initiate by the client using CoAP/DTLS 1.2 CID/UDP is currently the one with a good reliability and energy consumption. use-case, which just need days or smaller numbers of weeks will also be able to something else.
Thanks Achim for the detailed response. Clarifies lot of things.
Short story, eDRX or PSM is the window that makes sure to have any outside communication with cloud to be established.
Moreover, I believe there won't be TCP level keep-alive that can be established continuously for health-checks. Is that correct?
I'm no TCP expert nor do I claim to have too much TCP expertise.
Every IP message, including those, which are used TCP internal, requires a data-radio-message and so an enabled transmitter or receiver. Therefore the "window" applies also for those application unaware IP messages.
When the receiver is off, no "keep-alive" works in my opinion. And without, you don't know, if TCP is alive. It may be alive without "knowing". But if that is "often enough" the case is something you may check. I would guess this would be fragile and changing too much.
Gotcha. Thanks Achim for your insights.
Appreciated.
