| This article is based on an interview with Phil Ware and Sandro Sestan, u-blox —Martin Rowe |
Time equals power when transmitting data to and from NB-IoT and LTE-M devices. How you use communication protocols can affect power use.
When designing an IoT device using a cellular wireless module, you have many factors to consider in minimizing power consumption. Data sheets can provide guidance on power supply design, module placement, and connections. That will get you through the hardware design of your product, but it’s not the whole story. How you use the module makes a difference as well.
“How you use the module” means that protocols make a difference in power consumption. Your goal is to keep the module operating at the lowest possible power level for the maximum amount of time while still achieving the desired performance.
The protocols you use and how you implement them at the application level make a difference in power use. Some power consumption is inevitable regardless of module or protocol because all modules must first connect to the cellular network. Thus, they all need to go through the cellular protocol stack. All modules have a boot time and must physically scan for a network in the bands of interest. That time is generally fixed. Once a module is registered on the network, you’re in the application space where your choices make a difference.
Suppose you’ve designed a module into a utility meter. You might use a “fire and forget” protocol that minimizes power consumption by simply sending a meter reading and shutting down the module. That’s the lowest power (and cost) way to send a message. If a reading gets lost, there’s always tomorrow. To accomplish this exchange, simply send a User Datagram Protocol (UDP), Message Queue Telemetry Transport for sensor networks (MQTT-SN), or Constrained Application Protocol (CoAP) message. The application can either shut down the module or use the 3GPP power-saving mode (PSM).
When the application requires an acknowledgement from a server, the module needs to wait for a downlink message. During this time, the radio is still connected, waiting for the ACK message. Some modules use NB-IoT because of low power, but then use “chatty” protocols that take time and use unnecessary power.
Experimental results
As an experiment, we tried using Cat-M1 and NB-IoT modules to send messages of 150 bytes. When sending that amount of data, the NB-IoT module used less power than the Cat-M1 module. Cat-M1 gets more efficient as the number of bytes increases. At 500 bytes and up, low-data-rate protocols mean your transmitter is on for longer. Cat-M1 modules support ten times the data rate as NB-IoT and thus they’re on for less time for a given amount of data.
With the NB-IoT protocol stack, when it reattaches to the network, the attached message and the customer’s message are all part of the same transmission. Cat-M1 does not yet have these optimizations and the application messages must travel over the User Data Plane. This is less efficient than sending messages over the Control Data Plane for shorter messages, say less than 200 bytes. The power efficiency crossover seems to occur somewhere between 150 and 200 bytes.
Figure 1. A typical CoAP handshake process. Source: Constrained Application Protocol for Internet of Things https://www.cse.wustl.edu/~jain/cse574-14/ftp/coap/.
If you look at Lightweight M2M (LwM2M), you’ll see that its protocol is message heavy. Modules must negotiate lots of information with the host. The good news is it has lots of features. The day-to-day operation of an IoT device might not need LwM2M. It can use MQTT-SN or CoAP instead. Figure 1 shows the typical CoAP protocol sequence. Module users can change protocols depending on the application and should take advantage of that option. Keep that in mind when developing application software for your device. Protocol stack libraries are available for that purpose. Clients can be built into modules; you don’t need to develop your own client. There’s no cost in switching protocols. It’s just a matter of sending a few TCP or UDP packets.
3GPP power saving
3GPP specifies power-saving modes. For example, a module could go into a listening mode for a specified amount of time before going back into sleep mode, called Extended Discontinuous Reception (eDRX). A module’s power-saving features depend on its chipset, although most implement Release 13/Release 14 features. In listening mode, a chipset might only consume microamps of current. Some modules don’t need to fully boot when they wake up from sleep mode. Other modules need to boot, which can take four or five seconds when the module is powered but no sending useful data.
The difference in power consumption from transmit to receive may depend on distance. A short distance to a base station means less transmit power. Receive current could be less than 100 mA but transmit current could be much higher. It depends on distance to base. The network defines the transmit power needed by the remote device. For the receiver, the network will determine how often (duty cycle/C-DRX) the module will listen to the network’s signaling. Figure 2 compares a typical transmit and receive current for a wireless module.
Figure 2. A wireless module will consume considerably more power when transmitting than when receiving, but the power consumption when transmitting will differ depending on distance to the base station.
As you can see, the protocols you use can make a difference in your IoT device’s power consumption. Choose your protocols based on data-transfer rates and size. The right choices result in lower power use and lower power costs for the final device user.
