Article written by our CEO, Daniel Daoura. Check out the original post here.
Last week I wrote about how growing a startup is similar to hiking the backwoods. I mentioned how great partners make a big difference. Soracom has been with us throughout our development of our new cellular products. For readers that have a thirst for learning about new IoT cellular technologies and how they work (high level), this article may be of interest to you. Otherwise, beware this gets a bit technical but still a great read - I hope.
Please share your thoughts in the comments below.
A new cellular connectivity technology for mobile IoT devices has emerged in its early phase in 2018, promising very low power consumption and extended battery life, namely LTE-M (or in some cases referred to as CatM1). As modem, module and carrier providers continue to make improvements we are now able to use these advances to consumers’ benefit. One key differentiation of LTE-M is huge power savings allowing the IoT device to go into sleep mode while not in use. In contrast to your phone’s LTE, IoT devices with LTE-M connectivity benefit from inherently low power consumptions due to the nature of low data rates and tailored cellular connectivity. LTE-M also offers a lower power consumption mode for some applications similar to the ones Pebblebee offers. This is called extended discontinuous reception (or eDRX) mode. When in eDRX mode, the IoT device is allowed to have extended paging window intervals of up to 40 minutes while remaining “connected” to the network. Backpacking teaches you to go back to basics to reduce weight on your back as much as possible. Luxury comes at a high price of breaking your back when climbing thousands of feet in elevation gain and miles of trekking. Similarly, and in many cases, IoT devices don’t need to carry all that weight of overhead and processing our phones require. We go back to basics, and limit usage as much as possible, and only when needed, while maintaining a heartbeat with the network.
Before I get too much into the nitty gritty details, none of this would have been possible without the dedication, professionalism and amazing support from both our modem/hardware chip partner and Soracom. We have had our share of crickets with partners throughout our journey here, and there’s little worst than committing to a supplier that you find out has no follow through in helping with co-development after already agreeing to it. So we attribute a lot of this success to our strategic partnerships and of course, the Pebblebee team.
After months of testing with several carriers, we began to realize the limited amount of public information available to get eDRX working on an LTE-M modem. Modem, module and chip providers say one thing, and then carriers say something else. So we decided to co-develop a working solution with Soracom. After numerous failed attempts at “waking” up the IoT device on a paging window with either an SMS message or Soracom “Napter”, we landed on a working solution.
Soracom has a service called the “Virtual Private Gateway” (VPG) which is a private, isolated network that allows us to connect the Pebblebee IoT device and our AWS VPC so that an EC2 instance can send packets to the device. Kenta, Soracom’s co-founder and CTO says that “by using SORACOM Canal and Gate, you can easily create such an isolated network in which only your devices and EC2 instances in your AWS VPC can communicate with each other using private IP addresses”.
We were able to demonstrate a successful PING or “Wake” with the device from our AWS server running Ubuntu. TCP (Telnet) would cause a ring event on the IoT device to wake it up so that it can discover what actions it needs to perform. This method allows the IoT device to sleep for minutes at a time and until it needs to do something such as provide a LAT/LONG location or be able to ring the device remotely.
We were able to measure power consumption with a special power meter (OTII ARC with PC graphical interface) to demonstrate the energy use of the device vs. time. It was demonstrated that while using one of the carrier SIMs with eDRX enabled, the device almost never went into deep-sleep due to continued activity associated with the LwM2M and other service stacks that are known to become active when on that particular carrier network. It proved to be too much overhead for an IoT device rendering LTE-M and eDRX power saving features ineffective. We then compared energy use using a Soracom SIM. We were amazed at how much more efficient the same IoT device proved to be. We witnessed the periodic energy use associated with the eDRX wake cycle and deep sleep as expected and advertised by out modem provider. Energy usage looked very good at 7uWh per eDRX wake. Occasionally, and when in poor cellular coverage, energy would spike up a little, due to the device having to scan longer for stronger adjacent signals.
This isn’t the end of the development road – although we have resolved many issues, and I will share more insight as we get closer to releasing our products – there are still many challenges to overcome. Such as, what happens when the device is moving from one cell paging area to another and the device is in eDRX mode (sleeping)? We have to implement rules such as motion detection in effort to combat any battery power guzzling processes. Should we use TCP vs UDP. The latter is recommended, but comes with its limitations. TCP may be overkill for some applications, but in some cases required. Our findings are that we currently have two methods of delivering a “wake” event to the IoT device to start processing actions initiated from the Pebblebee cloud/App. They are methods A and B. The former being unreliable due to carrier limitations and unknown/unsynchronized timing events.
When a user needs access to their Pebblebee device, such as finding it, or triggering an event on the device, a Pebblebee server will send a HTTP request to the Soracom API to attempt to wake up the device. Soracom will promptly send the SMS message, but if the device is in sleep mode, it will not receive it. Soracom will then wait for the Ready-For-SM message from the carrier to then resend the SMS message to the device. This method will only require an IMSI to deliver an SMS and will eliminate the need for the VPG, but it has proven to be unreliable due to the nature of SMS and unreliable timing between the carrier and device being awake.
In this scenario, the Pebblebee server will send a HTTP request to the Soracom API to attempt to wake up the device through a Virtual Private Gateway (VPG) which in turn will retrieve the device’s IP and the VPG will return with either a TCP or UDP packet to device. A TCP connection will trigger a wake event on the device. The VPG can then send a command over UDP to the device for instructions on what to do next.
The beauty of using Soracom’s VPG is not only that it has been the only way we have been able to prove eDRX mode works, and that the Pebblebee device can now last for an entire year on a single charge with cellular. We are able to create a secure method of communication between the Pebblebee server and device so that no malicious activity occurs from a random source attempting to wake up the device to drain it’s battery. Without a VPG, any hacker can send a UDP packet to wake up the device if they have the device’s IMSI number – at a minimum causing its battery to drain. The VPG is inherently a private gateway/tunnel to the device and it is a secured connection dedicated to Pebblebee devices and server. This in of itself makes Soracom’s VPG solution a great benefit to IoT companies providing a secure environment for their product line, ultimately improving user experience.
For a more in-depth review on the subject and how to get LTE-M up and running please read Kenta's (Soracom CTO) article "Waking and Interacting with an IoT Device in eDRX Mode On Demand".
Here’s a pic of the team that helped in making this development possible. Many others have helped as well and as mentioned earlier, this could not have been possible without our strategic partnership with Soracom, our hardware partners, and the Pebblebee team. I hope this has been informative enough to help you with your IoT endeavors. If you have questions or would like to contact me please send me a message over LinkedIn.