LPWAN Network and Protocols - Selection and Optimization

How to optimize network registration?

Which protocol is the most power-efficient?

In this comprehensive video interview, you will learn together with Vanja Samuelsson, Founder, CEO at Qoitech, Markus Pihl, Senior Application Engineer at Thales DIS, what configuration can suit your application use case best.
 

LPWAN Network and Protocols - Selection and Optimization

Video Transcription

Qoitech:
We looked into the power-saving features of narrowband IoT (NB-IoT) and Cat.M technologies in previous videos.

How to set them and how they can be used to lower the power consumption of your Internet of things device.

Today we're looking into three additional things that can have a significant impact on your current consumption. Those are network registration, coverage, and the choice of protocols.

How important is it to consider the impact of network registration, coverage, and protocols on the overall power consumption?

Thales: This highly depends on the use case, which is valid for your device and the network used. Every network has different conditions and depending on your device activity; these are the main factors related to power consumption.

As in 2G, 3G, and 4G, the LPWA technologies can use different protocols and, of course, different security levels and depend on your connection to the network, the internet connection to the servers.

For example, you will have a different power consumption.

Qoitech: So let´s start with the Network registration!

We know that different operators have different settings, which means that a device may not maximize or, in some cases, not even use some of the low power features. How does network registration work, and what impact can it have on power consumption?

Thales: The network registration part could be quite complex, and this, of course, is quite important for your power consumption. There are so many frequency bands available that the scanning of all bands can take some time.

Assuming we have a static device that is not moving at all, like a smart meter for monitoring gas or water, this would be the best condition, because this device will always try to register to the same cell on the same network and this will go quite well.
But as soon as devices are moving and have to scan the available cells all the time, this will have a big impact on your power consumption.

I prepared an example of an initial network scan with a fresh SIM card where the device reads the SIM card's content and then tries to find its home PLMN (Public Land Mobile Network).

So after startup, it will scan all enabled networks. In this case, only two NB-IoT bands (frequencies) have been enabled: Band 8 and 20. The problem is that many MNOs (Mobile Network Operators) sell SIM cards, which act in roaming mode, which has a big advantage for the MNO.

You can use the SIM card all over Europe, for example. But the disadvantage is that the device is trying to find its home PLMN (according to 3GPP), which never will be found, and therefore, the scan is quite long, as we can see here, after our start.

The scan is one minute and 20 seconds, with an average power consumption of nearly 60 mA.
This will be done in the devices' automatic network selection mode described in the 3GPP standards.

One way to get around this is to select the network to which the device should register manually.  

Here, for example, I have the startup, and then I force the device to register to network ‘26202’, for example, and here we have our registration done, which finally is only nine seconds.

As you can imagine, of course, in nine seconds, you will not consume so much energy as in one minute and 20 seconds. But this is mainly because the device wasn’t registered to the same cell before.

If the device tries to reattach to a known cell, this is the third example. It will be even faster, as it could be seen here: in four seconds, the device will reattach to a known cell, a valid use case for all static devices.

Any smart meter, for example, will not move, and as soon as the smart meter has found its cell, and wakes up after a PSM period. It will just try to reattach to the last known cell first and the last known network.

This is quite fast then, and of course, the best solution we can have with an average of 25 milliamps only for four seconds. This is relatively fast and usable.

Here's an example of NB-IoT networks in Germany. We visualized a little bit the number of bands to scan and the scan time and the consumed energy during this time, and as we can see, it makes sense to reduce the number of bands to be scanned to save power.

But of course, everything depends on the use case. It is perfect for a static device to reduce the number of bands because it will not move - no new bands and using PSM and eDRX will be the ideal solution to save power.

But let's assume we've got a bicycle.

Tracking shared bikes in Amsterdam - this device will turn on once a week. Every week the bicycle will be in a different place, and therefore the scan has to be completely new, and if we scan 20 networks and 20 bands, this would exhaust our battery.  

Limiting the number of bands and maybe a manual provider selection would be the best for such a use case.

Qoitech: How about the bicycle - if, let's assume, that it's actually out of the city - out of the coverage?
Thales: NB-IoT and cat.M offer extended coverage, where the device is doing retransmits of the data to overcome these bad coverage scenarios.

But depending on the protocol behind retransmits may be confusing for the protocol or may cause additional retransmissions causing more energy consumption.

Finally, as in our EXS82 module, there would be the possibility, for example, to do a fallback to 2G where we still have the best coverage worldwide.

But to overcome this, a state machine in the device should handle this situation. Should check the network status or if the server-side could be reached and, if not, do a fall back to 2G and finally return to the power-saving technologies like NB-IoT or cat.M.

Qoitech: But not all modules have a fallback to 2G since they don’t necessarily have the radio for 2G – right?

Thales: This is an option, yes. As mentioned, our EXS82 module can do a fallback to 2G, but I will show you the difference exactly here in this Otii recording.

Here we see our power consumption for a 2G startup.

Registering to the cell, getting an IP address till a shutdown. This is overall power consumption of 1mWatt/hour.
If I now show you the NB-IoT part where I have done exactly the same: starting up registering until I’ve got an IP and doing the shutdown, I will end up with a 700 uWatt/hour only.

There's a big difference between these technologies, and finally, one should always go back to the low power technologies.

Qoitech: Let's go into the third part and the different protocols. It will be exciting to show us how the data can be transmitted and the differences in power consumption that we can see when using different protocols?
Thales: Basically, every module offers a different set of protocols.

Let’s have a quick overview of the different protocols we have to find the balance between reliability, speed, and security, and finally, power consumption.

For example, with a UDP protocol, we do not have the guarantee that the package will reach its destination. It’s not connection-oriented.

For example, TCP is a connection-oriented protocol, and the protocol itself will take care that every packet will reach the destination. If one packet is lost, for example, it has to be resent, and then, of course, there are higher-level protocols like MQTT or HTTP, which are on top of TCP. 

And finally, the topping is security, where you have to do handshakes and key exchanges and cryptographic operations on the device, which consume additional power.

I've prepared a scenario where I used a static ENS22 NB-IoT module, and I always send the same amount of data. 40 bytes of data (a string, a number, and a timestamp) - just to represent, for example, a smart meter use case.

This I've done with different protocols to see how big the impact from a power consumption point of view is.

I did some pre-recordings to shorten this a little bit. Let’s do one live recording…I wake up my module, and I've prepared a UDP socket on my server, and I'm listening on that server port to see my final data. I've got a tcpdump running as well.

I will just open the UDP socket, and as soon as the connection is open, I can send my 40 bytes of data, and then I’ll close my socket. Now the module is showing me that it's able to go into sleep again.

Here I can stop my recording because this is exactly the scenario I've done with the other protocols as well.

They need the same mechanisms as TCP and add additional overhead for their protocol part, so a lot of traffic and, therefore, higher power consumption.

As we can see here, I received one UDP packet on my server. I always measure the time from where the module is ready to go to sleep again to the beginning of opening the socket.
With every protocol, I measured this time frame. Sometimes, of course, I'm a little bit faster, sometimes I've been a little bit slower. The part at the beginning could be minimized a little bit, but anyway, we've got an overall power consumption of 480 uWatt/hour for sending a UDP packet with 40 bytes of data.

If I now go to TCP, for example, I've got exactly the same scenario.

As TCP has to send much more packets because there are synchronization and acknowledgments for each packet, and in NB-IoT, it could happen that the packets have to be resent, we've got a longer period of activity and higher power consumption which is around 850 uWatts/hour.

This was UDP and TCP.

If I now send the same amount of data with an HTTP post to a server - I'm just marking it - we can see here the HTTP part. It will be around 1 mWatt/hour.

Again higher than in TCP.
Let us check MQTT, which is a quite often used protocol for NB-IoT.

My MQTT connection will need 1 mWatt/hour as well. There's not such a big difference to the HTTP example.

If I now go into the security parts, I use TLS.  A TCP connection, which is secure. We see a much higher power consumption: 1.76mWh.

Of course, there is a need to do the crypto part, and there's a longer handshake as well.

It is possible to make UDP secure as well. This is called the DTLS. 

DTLS needs a high amount of power. It's about 1.8 mWatt/hour. The main reason here's the security part. The handshake and the key exchange mechanisms as well. [Comment: We rechecked this value, and the main reason was the default setting of the openssl DTLS server, which had a quite small MTU size.

After setting the MTU size to a reasonable value of 1400, the number of packets has been reduced, and the power consumption dropped by 20%].

I can make it a little bit simpler if I use a pre-shared key - so-called PSK.

With TCP and PSK I go down a little bit to 1.1 mWatt/hour.

The same is possible with DTLS - secure UDP.

This is around the same amount of power that I need to set up for this DTLS connection.

The difference is that a pre-shared key, the key which is used to the crypt, is known on both sides already. Therefore we do not need so much energy and much fewer packets to be sent to get the crypto part up and running.

Finally, I made a test with non-IP traffic, which is, as the name says, not using the IP protocol as a transport layer.

With non-IP, we just send our 40 bytes of data, and it is sent within the control channel of the mobile network. The power consumption is going down to 320 uWatt/hour. This is definitely, from a power consumption point of view, the best solution.

Qoitech: There is an obvious difference in power consumption between these protocols. Let's look at the summary, and you prepared a good table for us to check that.
Thales:  I made a summary in this small table where we can see the power consumptions I just mentioned, which I have measured.

But I really like the amount of IP packets, especially the number of bytes, which are finally sent to transport our 40 bytes of the data string.

As already mentioned for non-IP - only 40 bytes of data are transferred.

For UDP, this amount is already doubled. And, as you can see, if you use a TLS or DTLS connection, it's more than 50 [spoken wrongly: a thousand] times of the initial byte size is needed to transfer these 40 bytes of data.

Non-IP traffic is quite interesting. It consumes the fewest energy, even for bigger data packets.

But how is it done? How will you get the data finally? Because non-IP (NIDD, Non-IP Data Delivery) will not be transferred into the internet because internet protocol is missing.

This data is finally terminating in the network of the mobile operator. The mobile operator will offer their customers different ways to access this data.

Maybe they push the data to an internet server or offer a web-GUI where you can pull the data. But this push and pull don't affect your power consumption anymore because this is on the network side.

So, this is really the best solution from a power consumption point of view for the device.

But of course the MNO, they offer this as a service and you might have to pay something for this service to get a non-IP data connection.

Qoitech: As a final note - to summarize: network registration, coverage, and protocol choice can have major impacts on power consumption.

In all three cases, you need to really know your application and the use case really well, and you can pick an excellent path and get to the slowest current consumption.

But it can come with the cost of having a fallback or having to have a fallback technology or additional network costs, right?

Thales: Yes. It's indeed quite essential to understand every single part of the application and what constraints and opportunities each solution might have. So testing the product during development is the key.

Qoitech: Yes - the testing is the key. Thank you, Markus, and thank you all for watching.  If you like this content, please ‘like’ and subscribe to this channel.

Until next time - thank you very much!

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.