Cellular LPWAN technologies come with many benefits, especially when it comes to power consumption. As with any other connectivity technology, one must be aware of what can affect the device’s battery life from the ecosystem perspective, and understand the potential trade-offs. In this article, we look into network registration and coverage (or lack of) and their impact on NB-IoT or Cat-M devices’ energy consumption.
Firstly, keep in mind that the effects of the registration and coverage are highly dependent on two things – the use case and the network that the device is operating in.
You need to know your use case really well. For example, if it is a mobile use case, are there are any potential scenarios where the coverage is really low or roaming is needed? This can have a big impact on how active your device will be and how often it goes to sleep. The network conditions are most likely changing so it is good to understand the worst-case scenarios that you could encounter. Furthermore, based on your choice of a security level, protocol, and connection to the network, the power consumption can be very different.
Different network operators work with different network settings resulting in devices potentially not being able to maximize their power performance. In a few cases, they might not be able to use some of the low-power features at all.
Usually, LPWA modules offer a lot of frequency bands in order to register to different networks. Therefore, scanning all available networks can be quite time-consuming. Having a static/stationary IoT device gives the best-case scenario since the device always tries to use the same frequency band to register to the same cell on the same network. For a mobile IoT device, this can get quite complicated and energy-consuming.
Let’s use the NB-IoT module Cinterion EXS82 from Thales to showcase the impact on energy consumption.
In automatic mode, the device always tries to register to its Home PLMN (Public Land Mobile Network) first, which is written on the SIM card. As soon as Home PLMN and the scanned PLMN ID match, the scan will be stopped. However, many MNOs offer SIM cards that are acting in roaming condition – even if you use them in the same country you bought them in. In this roaming mode, the module has to scan all available frequency bands and networks and will then check against the list of equivalent PLMNs listed on the SIM card. Of course, this will delay the first attachment to the network. In this case, see Fig 1., it takes 1 minute and 23 seconds and draws approximately 60mA of current.
One way to get around this, especially for stationary IoT devices, is to manually set the network to which the device should register. Fig 2. showcases this and the 9 seconds to connect to the network for the first time, reducing the current consumption by more than 50%. Furthermore, if the device tries to reconnect to the known cell, for example after waking up from deep sleep, the reattach will be even faster, in this case, 4 s, see Fig 3.
In addition to manually selecting the network, there are further benefits if the number of frequency bands to be scanned can be kept at a minimum. Fig 4 shows the time to attach and the energy consumption for two different mobile networks (MNO) with different number of frequency bands.
A stationary IoT device will certainly benefit from this, but even some mobile IoT devices would too. Let’s assume we are tracking rental bikes in Amsterdam. In order to do that, the devices need to be turned on once a week to check whether the bikes are still in the city. One could either use a weekly PSM (Power Saving Mode) cycle or turn the module on and off manually once a week. Both variants require scanning the network as the last cell is most probably not the current one. However, since the device mobility is still limited, compared to, for example, a container tracker, the manual network selection and limitation of the band could still be applied and beneficial.
So, a band limitation and a manual network selection would speed up connection to the network and save energy. But what happens if one of the bicycles is out of coverage?
NB-IoT and Cat-M offer extended coverage where the device is performing transmit repetitions in bad coverage scenarios. Of course, each repetition consumes energy and depending on the protocol used it might happen that even more packets are requested, leading to additional repetitions. However, if all that fails, a lot of module providers offer a possibility for a 2G fallback – like in the case of Cinterion EXS82. For that to happen, one should create a state machine in the application. So, in the case that the device won’t receive a response from the network, it initiates a fallback to 2G. Later on, once in coverage again, it switches back to NB-IoT or cat-M and utilizes the power-saving modes there.
The fallback to 2G is more power costly, as shown in Fig 5 (statistics in the right upper corner of the Otii app screen) the attach procedure in 2G is consuming 2mWh compared to Nb-IoT, consuming 700uWh. Therefore, going back to NB-IoT or Cat-M as soon as possible is preferable.
To summarize, network registration and coverage in NB-IoT or Cat-M networks can have a major impact on power consumption. Knowing your application and use case well is the key to picking the path of lowest current consumption. Utilize the power-saving modes that the network allows. In addition, if your use case allows, manually pick the network and limit the number of bands that are scanned. If your device is out of coverage, the network can provide extended coverage features. However, keep in mind that it can come with a cost of more energy consumption or having to have a fallback technology or additional network costs.
For a more indepth information and further examples, check out the video with the expert on that topic Marcus Pihl from Thales on our youtube channel:
Power Analyzer, Log Sync & Power Supply in one Product. Otii Arc comes with the featured-packed standard Otii software (perpetual license).