Energy consumption in wireless IoT - part 1

Energy consumption in wireless IoT - part 1

The second edition of IoT M2M Times focuses on the topic of energy consumption of wireless IoT devices. Energy consumption determines the lifetime and cost of an IoT device. In this issue, we stay with a current project and look at it with different technologies. We hope you enjoy this issue as well.

  1. Why was energy consumption chosen as the theme for the second issue?
  2. The selection process for radio technologies
  3. Energy consumption of different technologies

Why was energy consumption chosen as the theme for the second issue?

We just have a new project on the table. Five to ten sensors and actuators on battery distributed over a few rooms should send a message in case of an alarm. The preferred delay between detection of an alarm and activation of the actuator should be less than 30 seconds if possible. The requested frequency range is SubGHz to get a better wall penetration. In addition, the network must set itself up, check itself and send the message to the actuators in the case of an alarm, without routing via the gateway. In parallel, a message goes to the cloud. In addition, there is a stay-alive (heartbeat) message every day for all participants in all rooms. A blue worker without much knowledge of IT and radio should be able to put it into operation without planning. The whole thing should not cost much and should work from battery for 6 to 12 months.

The selection process for radio technologies

The first edition of the IoT M2M Times already shows that we are dealing with all radio technologies in the Sub-GHz for LPWAN and Mesh-Net. What matters to us is the solution for the customer. That is why we are open to any radio technology.

Sigfox

Sigfox is out of the question for several reasons. A node-to-node message is not supported by the Sigfox protocol. A local Sigfox is expensive and cannot run off battery power. Connecting the gateway to the power socket is not allowed. The Sigfox nodes also do not check each other to see if they are still part of the network. The delay from the Sigfox node to the base is up to 6 seconds. A message from the gateway back to the node is only possible 4 times a day with a delay > 30 seconds.?The energy consumption per node is much too high. More about this in the next chapter.

LoRaWAN

LoRaWAN also falls out for several reasons. A node-to-node message is not possible with the LoRaWAN protocol. Local LoRaWAN is supported because the LoRaWAN server can run on the gateway.?Connecting the gateway to the wall socket is not allowed. The LoRa nodes also do not check each other to see if they are still part of the network. The delay from the LoRa node to the base is up to 2 seconds. The energy consumption per node to a public LoRaWAN node is far too high. More on this in the next chapter.

NB-IoT and LTE-M from 3GPP

The technology falls out for several reasons. A node-to-node message is not supported by 3GPP protocols. A local network based on NB-IoT and LTE-M is impossible in EU and cannot be operated from the battery. The NB-IoT / LTE-M nodes also do not check each other to see if they are still part of the network. The energy consumption per node is far too high. More on this in the next chapter.

Summary: It is not possible to solve the task with the classic LPWAN technologies. We will now look at Mesh-Net. The diagram shows that most of them fall out for several reasons. For Sub-GHz, only 6LoWPAN and NeoMesh remain.

Es wurde kein Alt-Text für dieses Bild angegeben.

6LoWPAN

A node-to-node message is supported by 6LoWPAN. A local 6LoWPAN is inexpensive. Unfortunately, 6LoWPAN does not allow the gateway and router to run on battery power. The 6LoWPAN nodes do not check each other to see if they are still part of the network, but the gateway does that. The delay of the 6LoWPAN nodes to the gateway is very short. The energy consumption per node is low. Unfortunately, 6LoWPAN does not allow routers and gateway on battery. 6LoWAN can therefore not be used.

NeoMesh from NeoCortec

NeoMesh meets all requirements. A node-to-node message is supported by NeoMesh. A local NeoMesh is inexpensive. With NeoMesh, the gateway and the router can be run on battery power. The NeoMesh nodes check each other to see if they are still part of the network. The delay of the Neomesh nodes to the gateway depends on the time to synchronise and the number of hops. The energy consumption per node, router and gateway is very low. NeoMesh is the winner of the comparison.

In order for NeoMesh to transmit its data to the cloud, a nationwide network with the bidirectional transmission with indoor coverage is needed. Such a network does not exist on either Sigfox or LoRaWAN. Therefore, the only remaining networks are those based on 3GPP technology called NB-IoT, LTE-M and GPRS.

The solution is a gateway also a battery with edge computing from the combination of NB-IoT, LTE-M and GPRS with NeoMesh from NeoCortec.

Es wurde kein Alt-Text für dieses Bild angegeben.

Energy consumption of technologies

The graph was taken from the LPWAN energy consumption study. For the most part, NB-IoT is better. However, NB-IoT is not always better. Sometimes LoRaWAN is superior to NB-IoT. Even Sigfox is better than NB-IoT and LoRaWAN in an isolated category.

Es wurde kein Alt-Text für dieses Bild angegeben.

Picture source: LPWAN comparison https://www.akoriot.com/white-papers/

The graph below was created to show that NeoMesh can often beat LPWAN. This particular use case above or the use case in the case study shows that neither NB-IoT, LTE-M, LoRaWAN or Sigfox have the best technology. In two use cases, NeoMesh beats the well-known LPWAN technologies.

Es wurde kein Alt-Text für dieses Bild angegeben.

NB-IoT versus NeoMesh with 12 bytes and 24 times per day

Energy consumption for the NeoMesh / NB-IoT, LTE-M, GPRS gateway

Unfortunately, there are many charlatans out there at the moment marketing a particular technology as the philosopher's stone. The crowning glory is then those who calculate the energy consumption of the SIM card beautifully and explain to us that the internal SIM card in the module (iSIM) requires less energy. The statement is correct. Unfortunately, this is hardly measurable compared to the consumption of the entire device.

The prophets who then sell the energy consumption due to the saved external MCU are not much better. If the external MCU is not working, then one of the two in the module is working internally. There are still two. Whether the internal one really needs less is another matter.

Assumption:

  • NB-IoT or LTE-M with 3 uA in Power Safe mode (PSM).
  • External MCU with 3 uA in a standby mode
  • Other electronics with 3 uA

We round up to 10 uA and ignore self-discharge, the doubling of current consumption when the room temperature is increased to e.g. 50 degrees Celsius.

Energy consumption for 24 hours in mWs

10 uA x 3600 seconds x 24 x 3.3 volts = 2.85 mWs per day. And then when it comes to doubling the current, it is 5.7 mWs. Look at the study and see that the consumption for once transmitting is between 185 mWs to 5000 mWs. If the 154 dB link budget is increased to 164 dB, the 5000 mWs become 50000 mWs, and the targeted 6 months become 0.6 months. 10 years becomes one year. With the right antenna concept, consumption can be reduced by 50%. With a multimode module on NB-IoT, LTE-M, GPRS it is quickly 75%. And with the right profiles on the SIM card, you can save much more than 5.7 mWs. The same applies to the choice of logical protocol. MQTT kills your batteries. More on this in another issue of IoT M2M Times.

Outlook

The right choice of technology or the combination of technology from 3GPP with Neomesh is the right one in this case. More articles with solutions based on other technologies will follow. We hope we could inspire you to think.

Imprint

  • ?Harald Naumann, Ludwig-Kaufholz-Weg 4, 31535 Neustadt, Germany
  • ??Contact: harald.naumann (at) lte-modem.com, Phone: +49-5032 801 9985, Mobile:+49-152-33877687

Ollencio D'Souza

Managing Director at TechnologyCare

1 年

Harald Naumann could you provide me a journal/respected publication number or title?

回复
Ollencio D'Souza

Managing Director at TechnologyCare

1 年

Very significant work - thanks!

回复
Alex L.

Founder, Dynamic Devices Ltd

2 年

Nice piece. Thanks Harald Naumann

回复

Harlad I agree with your analysis, having tested NeoMesh myself as well, but I think the only problem is that it is a proprietary protocol from a single vendor ( at least to my knowledge ) and this is a problem I think for real market acceptance.

Joel Invers

Innovation Manager,R&D Manager,Project Manager,Business Dev,IoT Design,Product Design, Electronics Design,Electrical Eng.,Digital Transformation,Manufacturing,Testing,Smart Tech,EV Mobility,eHealth,Interim Management.

2 年

Thank you for sharing. Nice article.

回复

要查看或添加评论,请登录

Harald Naumann的更多文章

社区洞察

其他会员也浏览了