Ten years of power for NB IoT connectivity with a single battery

A full decade of performance on a single battery is a strong sales argument. It means that, once deployed, sensors can be left alone for years at a time. Particularly for applications set up in hard‑to‑access locations, such as underground, this can significantly cut the cost of maintenance of a fleet of devices. And it doesn’t end there. Multi‑year power autonomy comes on top of other benefits delivered by NB‑IoT, such as low device cost, long range, and high spectral efficiency.

It all sounds great, but actually developing a device that reliably delivers a full decade of connectivity on a single battery can be a challenge. In 3G networks, power consumption was deterministic: you could calculate it ahead of time based on a given usage scenario. Not so in NB‑IoT, where decisions by the mobile network operator (MNO) – often automated – can spell the difference between a full decade and just a few years of operation.

Ever since the world’s first pre‑standard NB‑IoT message was sent over a live network back in 2016, u-blox has been optimising NB‑IoT modules and gathering expertise to help fulfil the promise to customers of a full decade of connectivity.

Here are five things to keep in mind to meet the 10‑year benchmark:

1: Set your PSM parameters wisely
Like other LPWA technologies, NB‑IoT saves power by maximising the time that devices spend asleep. Power save mode (PSM) offers an efficient way to do this short of switching the modem off altogether. When in PSM, devices can wake up to communicate to the network. The network, however, cannot reach the device. 

PSM brings current consumption down to below three microampere. It uses release assistance to signal to the network that the module doesn’t expect a downlink response to its uplink message. That way it can be ‘released’ from the network immediately rather than waiting between 6 and 20 seconds for the connection to timeout due to inactivity. Additionally, PSM allows the device to keep its registration details when it goes to sleep, preventing it from having to go through the power‑hungry process of reattaching to the radio network for each new communication.

Power save mode is parameterised using two +CPSMS timers, T3324 and T3412, which the device requests to the mobile network operator upon initialisation. T3324 specifies the time a device is reachable by the network before entering PSM. The duration of each PSM interval is defined by the difference between the two.

Figure: NB‑IoT modem states after registration to the network.

2: You can’t enforce your PSM timers
Let’s say you’ve found the +CPSMS timer sweet spot that perfectly balances the power autonomy and the availability your application requires. So is it time to pop the cork and celebrate?

Not so fast. The mobile network operator accepts the +CPSMS timers it receives from a device as requests. It has no obligation to set them accordingly and can override them if they are out of range. So before you pop the cork, be sure to check the timers the network has assigned to your device using the appropriate AT Commands. Also, because your timers may change at any given time, it’s worth tracking them continuously to respond swiftly when timers are reset by the MNO.

3: eDRX will keep your device listening longer
As saw earlier, with the T3324 timer, you can request that your device listen to the network for a certain amount of time. Extended discontinuous reception, or eDRX, still to be rolled out by MNOs, will let your device extend that time while only slightly increasing your power needs. Basically it works by switching it in and out of a low power state in which current consumption drops to around three microampere.

When using eDRX, the mobile network operator’s IoT platform stores any messages that come in while the device is in the low power state and forwards them to the device when it awakens. It’s worth mentioning that eDRX can also be used without PSM, in particular for applications that need to receive messages at unknown times.

4: Coverage classes are beyond your control
One way NB‑IoT saves power is by whispering messages over the airwaves rather than shouting them. To ensure that all messages within the range of an NB‑IoT base station are heard, NB‑IoT attributes to each message, or even to every chunk of each message, a coverage class based on the signal to noise ratio that it measures.

Messages that can easily be heard over the noise fall into coverage class 0 (CO0).Those that are less clear fall into coverage class 1 (CO1) and are emitted by the device with 10dB coverage enhancement. The most extreme scenarios fall into coverage class 2 (CO2), in which messages are sent with 20dB coverage enhancement.

Being classified as CO1 or CO2 may well get your device’s message to the base station, but this comes at a cost. Because they are emitted with more power and repeated multiple times, they draw significantly more current from the battery than those sent in CO0.

The trouble with coverage classes is that, although they are a major factor in determining autonomy, they are beyond your control. Mobile network operators are typically unable to provide transparent guidelines as to which coverage class your device’s messages sent will fall into. The only way to know for sure is to monitor your device’s power consumption once it is deployed in the field.

5: Ultimately, it’s a balancing act
Say you are designing smart water meters that use NB‑IoT to transfer data to the cloud, where municipal authorities or the water utility can monitor the state and the consumption of the water network in real time. In such a scenario, you probably don’t want to advertise your product as delivering a decade of connectivity on a single battery if it only does so in coverage classes 0 and 1. 

The reality is that there is an inevitable tradeoff between battery life and coverage. And as we’ve seen, many of the key factors influencing your device’s performance are not in your hands. Of course you can always scale up the battery, but that may put off a subset of your customers. Designing devices for the IoT is always a balancing act, and it’s the same for devices that communicate over NB‑IoT networks.

If you’re developing IoT solutions using the SARA‑R4/N4, SARA‑N3, or SARA‑N2 series of modules and need guidance on maximising their battery autonomy or optimising their performance, u-blox can provide you with tools that will help you build your designs on a solid foundation.

Guest blog written by Phil Ware, Senior Applications Engineer, Product Centre Cellular at u‑blox. 

Courtesy of u-blox.