Low-power Optimization for Cellular Modules
Last updated
Last updated
The Cat-M1 and NB-IoT cellular technologies were designed with low-power IoT devices in mind. They provide a number of features which developers of very low-power connected products can use to keep devices' power draw to an absolute minimum. Examples of such devices include location trackers, low-cost sensor nets, utilities meters, and preventative maintenance monitors.
This guide describes two of these optimization features: Power Save Mode (PSM) and Extended Discontinuous Reception (eDRX). It will help you assess how they might benefit your IoT application, and how to utilize them.
IoT devices typically send or receive data intermittently. Between periods of data transmission and reception, a device can sleep to minimize power consumption and maximize battery charge. The energy cost of completely detaching from the network at sleep, then re-attaching upon wake is high, so LTE allows the device to maintain its network attachment during sleep. However, the host network will periodically page the device, which needs to wake and respond. The device will then sleep again until it receives the next page or has to wake to send data.
This wake-respond-sleep process consumes only a small amount of energy, but its cumulative energy consumption can become significant over the lifetime of a device. Power Save Mode addresses this by letting IoT devices agree to an extended sleep period with the network. During this time, the network doesn't page the device, which can then wake only when it needs to send data or when the sleep period expires.
PSM was introduced in 3GPP Release 12 and is available to all LTE device categories. However, not all modems support PSM, so you will need to check the module you have selected.
The device requests PSM via an attach, a tracking area update (TAU), or a routing area update (RAU). It provides the network with two preferred times, called T3324 and T3412, respectively. The difference between them — T3412 minus T3324 — is the requested PSM period. The key word is 'requested' — the network chooses the time values that will be used. It may accept the values requested by the device or set different ones. The network retains connection state information, and the sleeping device remains registered with the network. If the device awakes and sends data before the expiration of the PSM period, a reattachment procedure is not required.
Many networks set limits for PSM periods. T-Mobile US, for example, imposes a maximum duration of 12 hours. Other networks have their own preferred maximum PSM span. Please consult the network you are using. Networks apply their limits when the device submits its T3412 and T3324 values: T3412 will be reset to an appropriate value if T3412 minus T3324 is greater than the allowed maximum.
In an active PSM period, the modem's radio is fully shut down and the device cannot send data or be reached. During development, you should be aware that the device's AT channel may also be closed down.
Data intended for the sleeping device is buffered: 3GPP requirements mandate that data packets must be stored by the network. The standard recommends that the network operator sets aside storage for at least the last 100 bytes.
PSM has to be supported by your chosen cellular module. It can be enabled by sending the CPSMS AT command to the device. For example:
The first parameter enables (1) PSM. The next two parameters — requested RAU and requested GPRS ready time — are not provided in this example. The third and fourth parameters are, respectively, the requested TAU and the requested PSM active time. The first of these is set to 30 hours ("01000011"). The requested active time is 18 minutes ("01000011"), ie. three-tenths of an hour.
How are these binary strings determined? The requested periodic TAU value is encoded according to the GPRS Timer 3 specification (see section 10.5.7.4a of 3GPP TS 24.008). Bits 5 to 1 represent the binary coded timer value. Bits 6 to 8 define the timer value unit for the timer:
| Timer 3 Value | Timer Value isincrementedin multiples of... |
|---|---|
000xxxxx | 10 minutes |
001xxxxx | 1 hour |
010xxxxx | 10 hours |
011xxxxx | 2 seconds |
100xxxxx | 30 seconds |
101xxxxx | 1 minute |
110xxxxx | 320 hours* |
111xxxxx | Timer is deactivated |
*See the note in the 3GPP TS 24.008 specification, table 10.5.163a for additional information on this value.
So, from the example above, "01000011" decodes as 3 (00011) times 10 hours (010) equals 30 hours.
The requested active time is a single binary string byte value defined by GPRS Timer 2 specification (see section 10.5.7.4 of 3GPP TS 24.008). Bits 5 to 1 represent the binary coded timer value. Bits 6 to 8 define the timer unit for the timer:
| Timer Value | Timer Value isincrementedin multiples of... |
|---|---|
000xxxxx | 2 seconds |
001xxxxx | 1 minute |
010xxxxx | 1 decihour (6 minutes) |
111xxxxx | Timer is deactivated |
So, from the example above, "01000011" decodes as 3 (00011) times 6 minutes (010) equals 18 minutes.
No network configuration need be done by the user; enabling PSM on the device is sufficient.
To disable PSM, you issue:
Extended Discontinuous Reception allows application developers to specify a period during which a device will stay in a low-power sleep state before waking to see if it has data pending. The device can listen for pending data indications without having to establish a full network connection. This uses less power than a full network connection does, and the time required to check for pending data is much shorter (just 1ms) than the time it takes to establish a full network connection.
Depending on your application, it might be quite acceptable for a device to be unreachable for several seconds or longer. eDRX allows the device to indicate a longer time than usual during which it will not be listening to the network.
When eDRX is not enabled, the length of time that a device can sleep before waking is set by the network — it's typically 1.28 seconds or 2.56 seconds. eDRX shifts that choice to the application. If the application can tolerate a latency of 90s, it can request a sleep period, called an "eDRX cycle", of 81.92s.
Why not the full 90s? Only certain periods are allowed for eDRX — these are listed in the eDRX cycle times table later in this guide.
Whatever the length of the eDRX cycle, the device keeps its receiver circuitry switched off for the specified period of time. It will not listen to either the Paging or the Downlink Control Channels. At the end of the cycle, the device briefly listens to the Physical Control Channel.
Enabling eDRX does not adversely affect the module's ability to send data — it just turns off reception for the configured cycle. But it does allow the application to select a sleep time that suits its own data flow, reducing radio use and so power consumption.
The device requests a given eDRX cycle from the network; the network confirms the eDRX cycle and provides a suitably set Paging Time Window (PTW). If the cycle time specified doesn't match one of the mandated durations, the network will respond with the closest official value. So if the application requests, say, 90s, the network will insist upon a period of 81.92s.
Here the eDRX cycle times you can request. The available values are based on the radio technology you are using:
| String | Cat-M1 Requested Time | NB-IoT Requested Time |
|---|---|---|
| 5.12s | N/A |
| 10.24s | N/A |
| 20.48s | 20.48s |
| 40.96s | 40.96s |
| 61.44s | N/A |
| 81.92s | 81.92s |
| 102.40s | N/A |
| 122.88s | N/A |
| 143.36s | N/A |
| 163.84s | 163.84s |
| 327.68s | 327.68s |
| 655.36s | 655.36s |
| 1310.72s | 1310.72s |
| 2621.44s | 2621.44s |
| N/A | 5242.88s |
| N/A | 10485.76s |
The application begins the eDRX cycle request by issuing an AT command, AT+CEDRXS. For example:
Copy code block
This requests eDRX be enabled with unsolicited result code (URC) feedback (2), for Cat-M1 (4), and an eDRX cycle time of 163.84s ("1001").
The network will respond, via a URC if configured as above, by repeating the requested cycle interval along with the actual effective cycle interval and the network specified PTW time. Here's a URC for the above command:
You can also check the current value with AT+CEDRXS?:
The returned PTW values depend on the radio technology:
| String | Cat-M1 Time Value | NB-IoT Time Value |
|---|---|---|
| 1.28s | 2.56s |
| 2.56s | 5.12s |
| 3.84s | 7.68s |
| 5.12s | 10.24s |
| 6.40s | 12.80s |
| 7.68s | 15.36s |
| 8.96s | 17.92s |
| 10.24s | 20.48s |
| 11.52s | 23.04s |
| 12.80s | 25.60s |
| 14.08s | 28.16s |
| 15.36s | 30.72s |
| 16.64s | 33.28s |
| 17.92s | 35.84s |
| 19.20s | 38.40s |
| 20.48s | 40.96s |
Depending on the modem your product uses, the requested eDRX cycle may be stored in non-volatile memory and persisted between sessions. Modules typically support disabling eDRX with a subsequent AT command along with an option to restore the default value.
eDRX support varies between carriers. For example, T-Mobile supports all documented (see Table 10.5.5.32 of 3GPP TS 24.008) values for the narrowband eDRX cycle, NB-S1 mode, ranging from ~20s (20.48s) to ~3hrs (10485.76s).
To disable eDRX, issue:
While not providing the same levels of power reduction as PSM, eDRX can offer a good compromise between device reachability and power consumption. eDRX can be used alongside PSM to obtain additional power savings, or it can be used on its own.
PSM is more power efficient because PSM cycles are much longer than eDRX cycles. As a result, the device can enter into a deeper, lower power sleep state with PSM than it can with eDRX. For instance, PSM sleep power might be 1-5μA whereas eDRX sleep power is 10-30μA, according to module manufacturers.
The actual savings you experience will depend entirely on the module you are using in your devices. We recommend that you use current-reduction values that you have measured when you are determining battery life of your product.
That said, a device using PSM takes much longer to wake up and will then be active for a much longer period of time than a device using eDRX. The eDRX wake-up-and-listen period is 1ms. Under PSM, a device will wake and receive and transmit control messages for about 100-200ms — and that's before it even begins to receive application-specific data.
Just because a network supports Cat-M1 doesn't mean that all or any of these power saving features are necessarily available to you. Please check with the network(s) your devices will be using. You should also be aware that these features, if available on a given network, may not be available to devices when roaming on other networks.
Whether you choose eDRX or PSM, or use both together, will depend entirely on your use-case. We recommend thoroughly testing all three approaches — eDRX alone, PSM alone, and eDRX and PSM together — to determine which delivers the best power savings for your application.
