LPWAN Module Configuration and Timers Calculation

Do you target to design a long-life IoT application?

Have you used and configured different power modes on a cellular module?

In this chapter, created for our readers and available from our IoT resource center, Vanja Samuelsson, Founder & CEO at Qoitech, interviews Markus Pihl.

Markus is a Senior Application Engineer at Thales DIS.

He explains how to calculate and configure timers to achieve the best efficiency of your low power design.

Let's jump right in.

How to use the power saving modes in NB-IoT and CatM

Video Transcription

Qoitech: In our last video, we talked with David, who explained how to set up the LGA DevKit and the Otii from Qoitech and start a recording.

We also discussed the theory of eDRX (extended Discontinuous Reception), PSM (Power Saving Mode), and the timers that control these modes.

Let us now dig a little bit deeper into these timers.

• How to calculate them
• How to configure the module to get the lowest possible energy consumption.

Timers and related commands

Markus, can you explain which timers one needs to work with and what the commands are to control them?

Thales: The following set of timers can be changed to optimize energy consumption:

• For PSM, we have timers called active time (in green) and periodic TAU (Tracking Area Update)  (in black),
• For eDRX, the eDRX value is the paging cycle length PCL (purple) and paging time window – PTW (in red).

Defined in 3GPP Technical Specification TS 27.007, PSM timers will be controlled by the: AT+CPSMS command.

According to the same specification, the eDRX settings should be controlled by the: AT+CEDRXS command, but within this at-command setting, the Paging Time Window (PTW - red) is not defined.

Therefore, we at Thales created an own command supporting the setting of the PTW as well, which is called: AT^SEDRXS.

And finally, to get into the lowest energy consumption mode of Cinterion® IoT Modules, to reach the bottom, we need to enable the so-called suspend within its configuration settings by this command:

AT^SCFG="MEopMode/PowerMgmt/Suspend",1

This setting only needs to be done once.

Qoitech: So we have three commands:

• 1 for PSM
• 1 for eDRX timers
• 1 to enable the suspend mode.

PSM timers

Can you show us now how to calculate them and how to set the timers for the PSM?

Thales: For the PSM, we use the AT+CPSMS command to set the requested periodic TAU (T3412 – light & dark blue) cycle and the requested active time (T3324 – yellow/red).

So let us set for the RequestedPeriodicTAU 7min, which is 420 seconds – with that setting, the module will be configured to send a Tracking Area update message to the network every 7 minutes.

 
The value needs to be entered in an 8-bit binary format where the first 3 bits represent the base multiplier of a 5-bit binary number. 

This is as specified in the 3GPP and can be found in specification: TS 24.008

For 7 minutes we can use e.g. a multiplier of 1 Minute => 101 and a value of 7=> 00111 or a multiplier of 30 secs => 100 and the value binary 14 => 01110.

The RequestedActiveTime works accordingly, but with different base values where we end up, e.g., a 10 seconds active time with the values 000 as 2 seconds base multiplier and 00101 equals 5 - altogether, it is this command:

at+cpsms=1,,,10001110,00000101

We provide a PSM Calculation Tool that supports you in at-cmd creation.

Qoitech: It would be perfect if you can show us the reference. How does it look like if we are not in PSM, if we haven't done anything, we haven't sent any of these commands?

Thales: The reference is no PSM, no eDRX, no suspend.

I activate a recording and start the Cinterion NB-IoT Module ENS22 with GPO2, which is connected to the ‘On-pin’ of the DevKit.
 

AT^CPSMS? shows PSM is off.

The module will register to the network, and after the RRC connection release, it will be in idle mode.

The small peaks will show the modules RF receiver listening to pagings in the standard DRX cycle of around 2.5 seconds for Narrowband IoT.

If I do a measurement over some sample time like this, we will end up with an average of 15 to 16 milliamps with no PSM.

The next step is to enable the PSM.

I switched on PSM with the AT+CPSMS=1 command, and we clearly see the difference.

The active time is down to 10 seconds, and afterward, the module is in PSM and sleeping.

According to the mentioned spec, the module requests the PSM values within an Attach request or Tracking area update message, which is sent to the network.

But if the network accepts the values, it is up to the mobile network or MNO.

Qoitech: So the network or the MNO has the last word….?

Thales: Yes…the different networks will accept different values or even might overwrite the values with their fixed values.

This is important to understand.

Let’s check what we’ve got: I send AT+CEREG=5 to enable the display of our values in the registration status command and request the status by sending AT+CEREG? The command returns the values used from the network side and has to be used on the module side.

To make the reading easier [ironic], the representation of the values in the AT+CEREG command is the other way around as they are entered in the AT+CPSMS command.

In AT+CPSMS, we entered periodic tau and active time, in the AT+CEREG, we get the active time and periodic tau at the end of the output.

If we compare the values for the active time, we've got the same value we set 000 and the 101 for our binary five.

But for the periodic TA, this looks different.

We have set the 101 and a 111 at the end as value.

Still, we received the 100 and 01110, which indicates a 30-second multiplier and a ‘14’ binary value which is finally the same seven minutes we set with our one-minute base multiplier, but the representation is different. In the network, they use the 30 seconds base even if we request a one-minute base multiplier.

So here, only another multiplier was used from the network.

Qoitech: Ok. So with these values, the module will go to sleep after 10 seconds and wake up for the periodic TAU after 7 minutes regardless of the representations we got?

Thales: Yes…we can see the 7 minutes here, and the energy consumption is down to around 13mA.

If we finally enable the Cinterion Suspend Mode the module indicates to be ready to go to suspend with a URC: +CIEV: suspendReady,1.

We now toggle the RTS signal for 5 seconds, which I’ve set to GPO1 in the Otii application.

The module will go into the real suspend after the active time of 10 seconds with an average power consumption of around 3 micro Ampere.

Compared to our reference, this is amazing, coming from 16mA down to 13mA and now to 3 micro Ampere.

eDRX timers

Qoitech: That’s pretty cool. And how about the eDRX timers…how will that look like when we start playing with those?

Thales: The timer values for setting eDRX are a little bit easier.

There is a defined table in which binary number is representing which timer value for the different radio access technologies LTE CAT M and NB-IoT.

We need to enter these values via the AT+CEDRXS command or via the Thales command: AT^SEDRXS where we can set the paging time window (PTW).

Thales: Let me take our Cinterion EMS31 IoT Module in LTE Cat-M to show the effect of eDRX. In the beginning, I deactivate eDRX to show the normal status, where we see the spikes of the receiver part according to the DRX cycle.

I enable the registration status display with AT+CEREG=4, and here we see again the currently used PSM timer and Active Time, which is a one hour PAM and an Active Time of five minutes, which means that the spikes we see here will be there the whole active time - so for five minutes.

In opposite to NB-IoT, in Cat-M, the default DRX cycle is only 1.25 seconds.

So we see some more spikes here, and if we take, for example, a 20 seconds time frame, we will end up with an average power consumption of 3.3 milliamps. Now I will enable eDRX with the at-cmd AT^SEDRXS=2,4,0010,0011, and here:

+CEDRXP: 4,”0010”,”0010”,”0011” we see our eDRX value which we have chosen, which is 20 seconds with a paging time window (PTW) of 5 seconds.

The module needs to adapt a little bit to the new setting.

This will take a short moment, but then what do we expect?

We expect a paging time window of five seconds where we see our spikes, and in the whole 20 seconds eDRX frame, we should not see any spikes anymore.

Let's check if the module is adapting correctly:

Now the module adapted to the new settings, and we can see in our 20 seconds eDRX time frame the paging cycle length (PCL). We have a five-second paging time window (PTW), and if we compare the current consumption, it dropped to 2milliAmp only.

I like this display because here, you can clearly see the difference between a non-DRX and an eDRX setup.

As I said, this will be done the whole active time.

So in our setting, for five minutes, and afterward, the module will go to sleep.

Qoitech: Thank you, Markus. Thanks for walking us through the timers for the power-saving modes of cellular LPWA. That was good—a step-by-step hands-on.

Now it's your turn

Thank you all for watching, and if you find this content very useful, press like and stay tuned for more.

Thales has teamed up with Qoitech to help developers improve their power design and conserve energy throughout entire IoT applications. The Thales Cinterion LGA DevKit and Otii measurement package closely examines power use at every step and makes design recommendations to achieve the right balance of functionality, device size and battery lifetime. Learn more in the videos how to optimise your power management design and save on costs.