July 28, 2022
Connectivity, Asset Tracking, LPWA, IoT
But how does LTE-M and NB-IOT deliver these benefits? One way is with protocol innovations to the standard that enable edge devices to communicate with cellular networks in a variety of different ways. A perfect example of this is the eDRX (Extended Discontinuous Reception) feature, which enables IoT application developers to significantly extend the battery lifetime of edge devices by minimizing how much power they use.
So, what is eDRX? What differentiates it from the Power Saving Mode (PSM) feature? And in what types of IoT applications might a company want to use it?
Developed by mobile network standardization body 3GPP and introduced in 3GPP Rel.13, eDRX enables application developers to set, and later change how long an edge device stays in low-power sleep mode before it wakes up to listen for any network indications for pending data.
With eDRX, the device can listen for pending data indications without having to establish a full network connection. By just listening for a pending data indication, eDRX uses less power than if it made a full network connection, so this process helps preserve the device’s power. The time needed for this listening process is also much shorter than the time it takes to make a full network connection.
The maximum sleep time for eDRX devices range from up to 43 minutes for devices using LTE-M LPWA networks, to up to three hours for devices using NB-IoT LPWA networks. The minimum sleep time can be as short as 320 milliseconds (ms) for LTE-M and 10.24 seconds for NB-IoT.
In the past (i.e. with eDRX’s predecessor, DRX), the length of time that a device would sleep before waking up was dictated by the network (typically 1.28 seconds or 2.56 seconds). With eDRX the device, rather than the network, chooses the length of time it will sleep, a period referred to as the eDRX cycle. Since a device is not reachable when it is sleeping, the time to reach a device depends on how long the application developer sets the eDRX cycle.
This ability to set the length of the eDRX cycle provides IoT application developers with a lot more flexibility when it comes to balancing a device’s reachability versus its battery consumption. For example, if the application chooses an eDRX cycle of 82 seconds, when a cloud service sends the device a command (e.g. report your location), it could take up to 82 seconds for the device to get that command before it would report back its location. This delay is often referred to as “mobile terminated latency”.
How sensitive an application is to mobile terminated latency depends highly on the application. For example, a pet finding application could tolerate a couple minutes to get a location fix for a pet -- especially if this means the battery will last 1-year versus 1-week. With other applications, like a remote light, one might only want to wait a maximum of 5 seconds for the remote battery powered light to respond to an “ON” request -- which means the eDRX cycle needs to be set to 5 seconds.
The other good thing about eDRX is that it is not static -- the application can change it anytime it wants. For example, the application can set the original eDRX cycle for an hour (extending the life of the device’s battery) and then later, when the application needs to be more responsive, reduce the eDRX cycle to a couple of minutes (using more battery power, but allowing the device to be reached with a much shorter delay).
PSM is another common feature used to reduce the power used by LPWA devices. In general, PSM sleep times are much longer than eDRX. These longer sleep times allow the device to enter into a deeper, lower power sleep mode than eDRX (e.g. PSM sleep power is a few microamps whereas eDRX sleep power is 10-30 microamps). However, a PSM device takes much longer to wake up out of sleep mode and it is active for a much longer period of time, because it must connect to the network before receiving any application data. For eDRX, the device needs to wake up and listen for 1 ms whereas for PSM, the device will need to wake up and receive and transmit control messages for about 100-200 ms before it can receive a message from the cloud application – a 100X difference!
Some IoT applications do not need to be reachable at all (e.g. they only transmit data to the cloud) or they can tolerate long reachability delays (e.g. they only need to be reachable once per day). For these types of applications, PSM is a good choice, since its sleep mode uses less power and is designed to be used when a device only has to wake up infrequently.
For other applications where one needs to reach the device more often (e.g. once per hour) eDRX is a better choice. As mentioned previously, with eDRX, the device can wake up and check for a pending data indication a lot faster than a device using PSM can (1 ms vs 100 ms), while using less power while it does so. eDRX can also help lower an application’s data transmission costs, since unlike PSM, which requires the device to connect and poll the cloud to see if there is data for it, eDRX only connects to the network and communicates with the cloud application when the device receives the pending data indication from the network, indicating there is data from the cloud application for it.
Though data transmission costs can be a factor, the most pertinent question of which power saving feature to use usually comes down to the use case’s reachability needs. Although it depends on many factors, in most cases the tipping point for when to use eDRX vs PSM is if the application needs to be reachable in a time period of approximately six hours or less.
eDRX is well suited for IoT application use cases where you want to preserve a low-cost edge device’s battery power, and the device’s reachability does not have to be instantaneous, between 5 seconds to six hours.
One example of such a use case is a smart gas meter monitoring IoT application. With many smart gas meter applications, government regulations mandate that the company responsible for the meter be able to quickly shut off the gas supply in a building, for example, after being informed that there is a fire nearby. While the company does not need to shut off the gas immediately, it does need to do so within a mandated time period, for example, two minutes from receiving the indication from the fire department of the fire spreading to the location where the smart gas meter is located.
With eDRX, the company can set up the smart gas meter to request an eDRX cycle of 82 seconds. This eDRX cycle ensures the meter can respond to a shut-off request within the required 2 minutes. In this way, the life of the device’s battery can be extended, the cost of the device can be reduced (since it needs a smaller battery), and the data transmission costs for the application are minimized (since the device only connects and transmits data when it is told to by the network). All while complying with the government regulation and helping ensure the building’s occupants are safe if there is a fire nearby.
Another example of a popular IoT use case that eDRX is well suited for are what I would call “finding” IoT applications – for things like pets, bikes, laptops, expensive tools and similar assets. Unlike asset tracking applications, where frequent, close to real-time updates are required, for these applications the user will usually only want to know where the asset is when the asset has been misplaced or lost. Of course, when they do want to find the asset, they will often want this information quickly -- within 1 or 2 minutes is usually acceptable if this provides the device with an extra year of battery life. In a couple of minutes Fido can’t get into too much trouble – but give him an hour on his own, and he can get into a lot of trouble with the neighbor’s cat.
With eDRX, users can learn the current location of their pet, bike, laptop, tool, or other asset in a minute or two, using a small, low-cost, low-power device attached to the asset. In addition, since the device would only connect to the network when it was told to, data transmission costs for the application would be nearly zero.
As the two examples above illustrate, eDRX expands the IoT market by offering application developers the opportunity to deploy new kinds of IoT applications for use cases where they do not need to reach their edge device immediately, but also can’t wait six or more hours to do so. For these type of use cases, the Sierra Wireless HL7800 LPWA module provides best-in-class eDRX performance.
With an eDRX cycle of 82 seconds, the average current used by the HL7800 can be as low as 50 microamps (depending on mobility, temperature, coverage, and network configuration and of course application data transmissions). Assuming minimal application data transmissions, this means one alkaline AA battery could power the device for more than 2 years! Or if a rechargeable battery is preferred, a 2x1x1cm lithium Ion battery (small enough to fit around Fido’s neck) could power the device for more than 3 months!
In addition to the HL7800 LPWA Module, Sierra Wireless offers a variety of other embedded IoT modules for various eDRX use cases. All of these modules are available as Ready-to-Connect solutions, with an embedded SIM pre-connected to global mobile networks that simplifies edge device installation and deployment. For companies interested in an all-in-one edge-to-cloud solution for connecting to their industrial assets, Sierra Wireless also offers Octave, which integrates edge devices, network, and cloud APIs into a single solution.
Start with Sierra to learn more on how you can use eDRX, PSM and other innovative LPWA features for IoT applications that allow you to unlock value in today’s connected economy.
Get innovation delivered to your inbox. Sign up for our blog and stay on top of the very latest from Semtech (formerly Sierra Wireless).
