Waking and Interacting with an IoT Device in eDRX Mode On Demand
Written by: Kenta Yasukawa
Published: August 23, 2019
For IoT developers deploying and managing remote systems, power management remains one of the most pressing practical challenges. Successful power management can mean the difference between a successful release and a failed experiment, especially for devices running on battery power.
Every approach requires trade-offs between longevity and responsiveness. The longer a device is powered on, and the more frequently it activates an antenna, the more battery it drains. To save power, devices need to stay in sleep mode as long as possible and wake up as rarely as possible.
There’s still no silver bullet, but there are some known best practices, including what we usually describe as “SMS wakeup.” For devices connected to cellular networks, an SMS message can be used to trigger wakeups and provide additional commands to instruct a device on what to do and where to connect after waking. This is supported in the Soracom API and is often implemented by customers as shown below.
Newer cellular standards, like LTE Cat M1, also offer valuable features designed to help extend the life of battery-powered devices. One particularly useful feature is extended discontinuous reception (eDRX), which gives devices extended paging window intervals of up to 40 minutes while remaining online.
Unfortunately, there’s not a lot of good material available to help developers understand how to work with this feature. It addresses a common and important challenge, but if you google “eDRX” you’ll mostly find lists of specifications rather than any real hands-on developer perspectives.
Fortunately, we just did an interesting experiment with our strategic partner Pebblebee that helps to underscore just how much eDRX has to offer for IoT. Like many good experiments, this one happened somewhat accidentally: Pebblebee’s CEO, Daniel Daoura, knocked on our office door and said “Hey, we’re using SMS to wake up an LTE Cat-M device in eDRX mode, but it’s not very reliable. It sometimes wakes up, but often takes much longer than expected. Can you guys do something?” We thought we could, and both teams thought the results would be worth sharing.
Any better way than SMS to wake up devices on-demand?
The inconsistent behavior that Daniel and his team were seeing was interesting. Normally, an SMS message would be delivered instantly but if the receiver is not online, the SMS needs to be queued and retried later. In a case where the device is in a power-saving mode like eDRX, messages might be queued but not delivered immediately when the device finally checks in.
Daniel wondered if there might be an alternate trigger other than SMS that could wake his devices. In theory, delivery of an IP packet could do the same trick since packets sent to a device in eDRX mode can be buffered in the network for a time and then delivered if the device’s paging window opens before they are discarded.
So this approach could work in theory, but neither of our teams knew if it would actually work for Pebblebee’s case. When we encounter this kind of uncertainty, we have an approach we typically take, that is, “Let’s just do it!”
…
We decided to set up an environment as follows: A private isolated network for the PebbleBee device and their AWS VPC that would allow an EC2 instance to send packets to the device.
Using SORACOM Canal and Gate, it’s easy to create this kind of isolated network where only your devices and EC2 instances in your AWS VPC can communicate with each other using private IP addresses.
Once the environment was established, the first thing we tried was to deliver a ‘ping’ command on the EC2 instance to send packets to the device that was in eDRX mode.
Nothing happened.
Right, of course it couldn’t be that simple. But… let’s wait for a few more seconds so we can at least be sure we’ve run through an entire paging window.
!!!!
We got multiple echo responses from the device!
This gave us the proof that echo requests sent from the EC2 instances were buffered in the cellular network and delivered to the device during the paging window. More importantly, the device woke up from eDRX mode as expected, and processed the echo requests on wakeup!
So far so good. But it was still not good enough for Pebblebee’s use case. Their team needed the device firmware to know that a message was received so that it could take action on it. Apparently, ICMP echo requests sent with the ‘ping’ command would not reach the firmware.
So we tried one more thing. Doug Guillot, Pebblebee’s Senior Firmware Engineer, ran a command on the device to listen on a port and we ran `nc` command to send to the port on the device a JSON object `{“led_red”:1}`.
Daniel started a timer, set it to the eDRX paging time window and we waited. We all looked into the serial console on Doug’s laptop.
After a few seconds…
!!!
We got ring notification from the modem to the firmware!! It means we can wake up a device in eDRX mode and send a message!!!
I was so glad we could all say the two words I already love to say or hear when we try something new, i.e. “IT WORKS”! We now know how to efficiently wake up and interact with a device in eDRX mode!
But you may ask one important question that often comes after “it works” — how about security? If a UDP packet can wake up a device, can a malicious person send random packets from the Internet to wake up devices? At the very least, this would cause unexpected battery draining.
Fortunately, the answer to that question is already addressed in the architecture we developed at the start of this test. We have setup a private network dedicated for Pebblebee devices and servers. The devices are isolated from the Internet and a malicious attacker cannot reach the devices from the Internet.
I hope I could convey the excitement that we and our friends at Pebblebee had through this blog post. Do you also have an idea for IoT project? Honestly, solving these kinds of new challenges is what we love most about working out on the edge in IoT. If you have an IoT project you’re working to test, launch, or scale, feel free to reach out to us. We are here to help you build a secure, robust IoT architecture and accelerate your business.
Kenta Yasukawa
CTO & Co-Founder,
SORACOM, INC.
