Introduction

The Internet of Things (IoT) (Atzori, Iera & Morabito, 2010) is not just about new sensors and actuators but will include, in the domestic realm, many consumer devices that are not currently networked and do not draw electricity when they are not in use. Bringing these devices into the IoT ecosystem will require the addition of communications interfaces, which will mostly be wireless. A naive approach to adding communications interfaces (e.g. a Wi-Fi module on each device) could lead to substantial additional energy consumption without any corresponding benefit in functionality, if an inappropriate design option is chosen. While this effect may be marginal for a single device, energy efficiency in communications design will be important for individual households and in aggregate may have considerable effect (for example, see chapter 14 of Weldon (2016)).

A variety of wireless network communications interfaces have been considered as enablers of the IoT, with a wide range of characteristics (e.g. bit rate, topology and energy consumption) (Atzori, Iera & Morabito, 2010; James, 2014). They include Bluetooth (Classic and Low-Energy), 802.15.4/ZigBee, 6LowPAN, Z-Wave, Thread, DECT-ULE, EnOcean, Wi-Fi, NFC, ANT/ANT+, WirelessHART and a number of proprietary protocols. Here, we compare the energy consumption characteristics of five common commercial off-the-shelf (COTS) wireless interfaces, which represent today’s dominant COTS interfaces for IoT application and are expected to see significant growth in the near future (OnWorld, 2017; OnWorld, 2018). They are Bluetooth Classic (BT), Bluetooth Low Energy (BLE), ZigBee, Wi-Fi and 433 MHz module (referred to as RF433 in this study). Power consumption of the COTS interface options was measured for their various states of operation and combined to determine their energy use in different scenarios.

To examine the options for energy-efficient communication using these COTS devices, we employ a simple stock control application involving a domestic toaster communicating with a gateway hosting an inventory system. This application is rich enough to encompass the full range of communication options while being simple enough to enable a straightforward analysis of energy consumption. The application choice is in line with developing interest in ‘smart kitchens’ (Pal Amutha, Sethukkarasi & Pitchiah, 2012) and automated stock control for online reordering of basic grocery items (Hsu et al., 2006; Yang et al., 2014) as part of assisted living.

While the example given here may be somewhat contrived, it illustrates the point that careful design for energy usage and efficiency in the IoT will be important. The type and volume of data, the frequency of data transmission, and the type of communications interface should all be considered.

In this paper, we first give a brief description of the five wireless network communication protocols and describe the measurements obtained through experiments. We then combine these measurements using the example IoT application to determine the energy consumption of several communications paradigms. We use these results to describe energy-efficient design options for future domestic IoT applications.

Wireless Network Protocols

There are several short-range wireless network communications protocols that are considered as part of the enabling technologies of the in-home IoT. In this section, we present a brief description of the five commonly employed wireless network protocols for IoT applications: Bluetooth Classic; Bluetooth Low Energy; Wi-Fi; ZigBee; and Radio Frequency 433 MHz (RF433).

Bluetooth Classic

Bluetooth technology, based on the IEEE 802.15.1 standard, is designed to support short-range, ad-hoc connectivity amongst devices. Traditional or Bluetooth Classic (BT) operates in the 2.4 GHz Industrial Scientific and Medical (ISM) band using adaptive Frequency Hopping Spread Spectrum (FHSS) channel access (1600 hops/sec), with 79 defined channels of 1 MHz channel width, 32 of which are used for device discovery (Ferro & Potorti, 2005). BT devices can operate either as a master or slave, with one master interconnecting up to seven active slave devices – hence a star topology. BT is capable of data rates up to 2 Mb/s. However, BT has some major disadvantages, which limit its widespread implementation in IoT applications. These disadvantages include a relatively high power consumption, large data packets with huge overhead, a complex protocol stack with large memory demand, and long connection time (Mackensen, Lai & Wendt, 2012). Additionally, while BT has some low power modes (e.g. sniff mode), it lacks an effective sleep-mode regime, which is critical for minimising energy consumption in the case of battery-operated IoT devices.

Bluetooth Low Energy

Bluetooth Low Energy (BLE) is defined in the Bluetooth Specification 4.0 (Bluetooth-SIG, 2010) as the low energy version of BT, designed for IoT-like applications – low cost and complexity, low duty cycle and infrequent transmission. Like BT, BLE (or Bluetooth Smart) is also based on the 2.4 GHz ISM band and uses FHSS but with 40 channels (including 3 advertisement channels for device discovery) of 2 MHz channel width, and a data rate of 1 Mb/s. BLE can either operate as a central (master) or peripheral (slave) device, with a slave able to connect to only one master device at a time (i.e. star topology). An important feature of BLE is its sleep-mode capability, which, in combination with a low duty-cycle application, significantly reduces the device energy consumption. A slave may broadcast a limited amount of data in an advertisement packet or, alternatively, a communications link between a master device and a slave device may be established for dedicated or higher volume traffic applications. The latest version of BLE is defined in Bluetooth Specification 5.1 (Bluetooth-SIG, 2019).

Wi-Fi

Based on the IEEE 802.11 series of standards for wireless local area network (WLAN), Wi-Fi operates on multiple frequency bands (e.g. 2.4 GHz, 5 GHz, 60 GHz) and is a widely used short-range wireless protocol. The Wi-Fi protocol has undergone several revisions (802.11a/b/g/n/ac) with 802.11ac capable of achieving broadband speeds in excess of 500 Mb/s (Perahia & Stacey, 2013). Wi-Fi supports two operating topologies: Peer-to-Peer (Ad-hoc) network topology and Star (Infrastructure) network topology. While Wi-Fi was originally designed for high-speed, short-range (up to 100 m) communication, its ubiquity in homes and places of work has resulted in an increasing use in a number of IoT applications (e.g. Smart Light Bulbs or Smart Appliances).

ZigBee

Based on the IEEE 802.15.4 standard, which defines the PHY and MAC layers, ZigBee has an established set of specifications for low power, low data-rate and short-range applications. The ZigBee Alliance defines the Network and Application Support layers (ZigBee, 2012). ZigBee operates on the class-licensed 868 MHz, 915 MHz and 2.4 GHz bands with data rates of 20 kb/s, 40 kb/s and 250 kb/s, respectively. ZigBee defines three types of devices: (a) ZigBee Coordinator (ZC) – acts as a gateway/hub and delivers the greatest capability; (b) ZigBee Router (ZR) – acts as an intermediate router in addition to application functions; (c) ZigBee End-Device (ZED) – performs application functions and is the least capable device. ZC and ZR are classified as fully functional devices, while ZED is a reduced-function device. The ZigBee protocol was designed for low complexity and low energy usage with a sleep-mode capability. In addition to its star and cluster-tree networking capabilities, the ZigBee protocol can be configured for mesh networking, which offers long reach by means of data relay. Through its mesh networking functions, ZigBee offers a “self-healing” capability, which is the ability to create alternate paths when one node fails or a connection is lost.

RF433

Based on the ISM 433 MHz band, RF433 can be used for wireless data transmission, including in wireless sensors and home automation systems. Its frequency range is 433.05-434.79 MHz. RF433 is not a standardised protocol like Bluetooth, ZigBee and Wi-Fi but is a widely employed, inexpensive wireless communication option for many IoT devices and applications. Based on this background and the general belief that RF433 will be a common hardware selection in future IoT applications, it is included in this study.

Related Studies

There are a number of comparative studies in the literature, many of which feature two or more wireless network communication protocols. Some of these studies have focused on the energy utilization of the wireless protocols irrespective of any specific application domain. For example, while using representative device datasheets, one study compared, among other metrics, the power consumption of four wireless protocol standards (BT, ZigBee, Wi-Fi and Ultra-Wideband) (Jin-Shyan, Yu-Wei & Chung-Chou, 2007). They showed that, while BT and ZigBee consume remarkably less power, they are far less energy-efficient than Wi-Fi and UWB (Ultra-Wide Band) for higher data rates. A more comprehensive survey of the characteristics of BT and Wi-Fi, using an experimental study of similar example chipsets programmed with the same data rate for a single connection scenario showed that Wi-Fi consumes five times more power than BT (Ferro & Potorti, 2005). Applying datasheet values in a simulation study of raw data transmission for BLE, ZigBee and Wi-Fi modules, Shahzad & Oelmann (2014) showed ZigBee being more energy efficient for low data payloads, while Wi-Fi was least energy efficient; but the reverse for high data payloads. The difference is mainly attributed to the shorter connection time of ZigBee as compared to Wi-Fi, but the larger frame size of Wi-Fi enabled more data transmission per Tx/Rx transaction for high data payloads. From the measurement-based comparisons, Mikhaylov, Plevritakis & Tervonen (2013) examined the energy consumption of BLE, ZigBee and SimpliciTI (proprietary) transceivers in different modes of operation. Siekkinen et al. (2012), on the other hand, compared only BLE and ZigBee transceivers, with their result showing the energy efficiency of BLE being 2.5 times better than that of ZigBee. Dementyev et al. (2013) compared and reported power consumption of BLE, ZigBee and ANT+ protocols in varying cyclic sleep intervals. They showed that a device sleep current draw is not always indicative of its long-term energy consumption, highlighting the importance of shorter start-up connection time.

While these studies aim to show one protocol as being more energy efficient than the other, it should be noted that energy consumption ultimately depends on the device hardware implementation and this may vary from one manufacturer to the other. With some IoT services now mainstream (e.g. Home Automation), and an increasing use of wireless protocols in such applications, there is a need for application-specific studies. IoT applications vary in requirements of bit rate, latency, packet sizes and QoS; and these must be taken into account while assessing the energy-efficiency of wireless network protocols.

Measuring Energy Consumption

We measured the power consumption (energy consumption) characteristics of each of the above communication technologies, in order to be able to compare their performance in typical applications. A description of the experiment and measurement setup is given in this section. It is assumed that, for each deployment scenario, each COTS wireless interface communicates with an always-on gateway device (i.e. master, ZC, etc.).

Measurement Setup

The components used in the measurements include two COTS short-range RF modules for each communication protocol, an Arduino Duemilanove (Due) board (Arduino, 2009) equipped with Atmel’s Atmega 328P-PU microcontroller (MCU), a dc power supply and power meter unit, a test computer (PC) and smartphone. The Arduino acts as a data source. A block diagram of the experiment setup is shown in Figure 1.

Figure 1. Block diagram of experiment setup.

Earlier RF modules might include separated transceiver circuitry, antenna, MCU and serial interface, but modern RF modules today are most commonly designed as a System-on-Chip (SoC) with integrated transceiver module and MCU. Hence, the RF modules in this study are measured as one SoC unit, given that in practice they may be deployed as such.

The power meter records power consumption, current draw (mA) and voltage (V) of the device under test (DUT)/end-device, and the measurements are logged on a PC for post-processing. The Arduino Due generates a pre-set 10-byte (10 B) test payload and is independently powered (not measured). Measurements are recorded at an average of 1 ms intervals with an accuracy of 10 µA and 5 mV voltage. With the exception of the RF433 modules, which are either transmit-only or receive-only, each RF module has 4 leads connected: +ve power input (VCC), Ground (GND), transmit (Tx) and receive (Rx). Figure 2 displays an image showing this setup with an XBee ZigBee RF module as an example. A similar measurement format was used for modules with a USB connection; the power line within the USB cable was interrupted and voltage and current measured, while the data lines were passed through uninterrupted. For accurate measurements of the DUT power consumption, the VCC and GND leads are directly connected to the dc power supply via a power meter, while the Tx and Rx leads are either connected to the transmit and receive ports on the Arduino board or a USB port. A steady voltage of 5V (or 3.3V where applicable) is supplied to the modules during the tests.

The master/coordinator (gateway device) modules are powered either from the power rails on an Arduino board, a USB interface of a PC or the smartphone battery but these are not measured. Packets received from the DUT are recorded with timestamps. Measurements are collected over 5 minutes. In one case, a digital oscilloscope (e.g. Digilent Analog Discovery USB Oscilloscope) in a setup with a 10 Ω current metering shunt resistor was used for the measurement.

Figure 2. Measurement setup for an XBee ZigBee module.

In the experiment, the data source for the DUT is programmed to send the pre-set 10 B data payload every 5 seconds while the master/coordinator receives the transmitted data, which is displayed on a serial monitor using a terminal emulator such as Tera Term or Bluetooth Smart Data app.

RF Module Power Measurement Setup

Table 1 gives details of the RF modules used in the experiments. For BT measurements, a JY-MCU HC-06 module, compliant with Bluetooth v2.1 standard, was used. The serial interface of the BT DUT (slave) was configured at 9600 Baud. Bluetooth v2.0 standard lacks the very low power sleep-mode; therefore, it is assumed that the module, when not operated continuously, is turned off after every Tx and Rx operation of the DUT.

Table 1. RF modules used in experiments.

For the measurement of BLE, the Redbear BLE Nano v2 (Redbear, 2018) was used. The BLE Nano is a breakout board that simplifies prototyping or small-scale production of new IoT products, based on the Nordic nRF52832, which is a SoC including the RF module and an ARM Cortex-M4F processor at its core. The BLE Nano comes with Bluetooth v4.2 protocol stack (although Bluetooth 5 ready) and can be configured as a central or peripheral device. As the DUT, the BLE Nano was configured as a peripheral device (see Figure 1).

For ZigBee measurements, the Digi International’s XBee Series 2 radio modules (Digi, 2011) were used. Using Digi’s XCTU software, one of the modules was configured as an end-device and the other as a coordinator, both with their respective firmware. Transparent mode communication was set in both XBees (AT mode) for an asynchronous serial interface of 9600 Baud. Since ZigBee modules have sleep-mode capabilities, the end-device RF module was configured in cyclic sleep mode, waking up at regular intervals to transmit its data payload before returning to sleep. The power consumption and duration for the different stages were recorded.

The ESP-12F Wi-Fi SoC module was used as a representative Wi-Fi RF module. The ESP-12F is based on the ESP8266EX chipset and is IEEE 802.11b/g/n compliant. To avoid significant variation in power due to dynamic transmit power control, the Wi-Fi module (end-device) and Access Point (AP), i.e. master, were configured in Infrastructure mode while maintaining a separation distance between 0.5 and 1 metre.

For the measurement of an RF433 module, the FS1000A transmitter and ZRW-01 receiver radio modules were used. They both use ASK modulation or On-off keying and permit bit rates up to 9.6 kb/s. Since the transmitter and receiver are independent modules, two sets of experimental configuration were needed – one for the transmitter and the other for the receiver. Our examination of a range of commercial wireless sensor devices that use RF433 radio modules showed that they are mostly transmit-only devices, designed to re-send each packet multiple times to compensate for the lack of acknowledgement (ACK) packets from the receivers. This redundancy mechanism is implemented in our application case-study described below, assuming each message is sent three times.

Power Consumption Measurement

This section describes the measurements, power consumption plots and values for examples of each type of wireless technology considered in the experiments. In addition to the main communication task (i.e. Tx and Rx), we monitor and report on other housekeeping functions (e.g., listening, wake-up, sleep) with each technology and their associated energy consumption. Power consumption values generally depend on the device hardware implementation, and may vary slightly between examples of each module type.

Table 2 lists the power draw of the RF modules during their main operational phases, while Table 3 lists their respective duration (in milliseconds) for transmitting a 10-Byte packet. Some of the values reported in this paper were previously published in Gray & Campbell (2016). For simplicity, the duration of the wake-up, pre-processing and synchronization phases was concatenated into one, i.e. wake-up, as given in Table 3. A small amount of energy is incurred to turn off or shut down the modules but these are insignificant in comparison with the other phases.

Table 2. Power consumption of RF modules in different operational phases.

Table 3. Duration of operation in different operational phases.

While the individual power consumption values are discussed in the following section, an observation of Table 2 reveals not so subtle differences between the DUT modules. For the Tx/Rx power, we see magnitudes between 3 and 6 times the lowest recorded value (i.e. BLE), while a more significant difference (28 times) can be seen in the standby power consumption. The latter is important in this study as some applications require modules to remain in the standby state, which could result in much higher disparity in total energy consumption. We acknowledge that the above comparisons are for different wireless technologies and also that the same technology from different manufacturers may show different results. For similar modules like BT and BLE, however, we recorded a notable difference ( 5 times) indicating some energy efficiency improvement trend, while improving communication range and other metrics.

BT Measurements

A Bluetooth link controller has a number of connection states including standby, inquiry (scan/advertise), paging, connected/active, sniff, park and hold states (Ferro & Potorti, 2005). Figure 3(a) shows the power consumption of the BT module in a non-connected standby state depicting the advertisement and scanning phases. The device sends advertisements on different channels, each round lasting about 5 ms. During advertisement, the BT module draws an average of 79 mW, consuming about 0.4 mJ each round. During scanning with nearly 100% duty cycle (duration ≈ 320 ms), the module draws about 208 mW consuming 67 mJ, which is over 50 times more than its advertisement phase. Such a huge disparity in energy usage explains the reasoning for slave/end-devices (which are often energy constrained) being limited to sending advertisements, while master devices (often with more resources, e.g. PC/Smartphone) engage in scanning during the discovery process.

Figure 3. Power trace of BT module: (a) in standby state showing the scanning and advertising phases; (b) showing the state transitions from standby to pairing, connected and sniff states.

Figure 3(b) gives a much wider view of the major stages a BT device undergoes. The figure shows the standby state, when scanning and advertisements are performed; the pairing stage, when the paging and synchronisation process occurs; the connected stage, which includes data Tx, Rx and ACK; and lastly the low-power sniff state (i.e. listening), when the module is less-active but listens for transmissions at set intervals (125 ms in this case), depicted by the spikes on the right-hand-side of the figure. The average power consumption in the low-power sniff mode is about 16 mW. For BT, a complete data frame is transmitted per timeslot (1 timeslot = duration in 1 frequency state) in 0.625 ms, with an ACK packet received in a subsequent timeslot. Since the power meter can only resolve variations down to 1 ms, we assume a lowest duration to be 1 ms.

BLE Measurement

The measurement was conducted for the BLE non-connected and connected/active states. Figure 4(a) shows the power consumption trace of a BLE peripheral device advertising at 200 ms intervals, and in connected mode, with connection events depicted on the right-hand-side. Each advertisement payload was 30 B long and was transmitted to three advertisement channels. For one advertisement round, the peripheral device consumed about 0.08 mJ, lasting about 2 ms (0.625 ms per timeslot). Figure 4(b) shows the power consumption trace of a non-connected BLE central device scanning three advertisement channels with a 20% duty cycle (i.e. scan window = 200 ms, scan interval = 1s). The steps in Figure 4(b) can be attributed to its post-processing activities, drawing  23 mW. For scanning, the central device consumes 14.4 mJ per cycle.

Figure 4. Power consumption trace of BLE module configured as (a) peripheral (slave) device showing advertisements and connection events; (b) central (master) device in scanning mode.

The energy consumption of a BLE module in its non-connected states ultimately depends on the choice of a number of parameters (e.g. connection interval), which would be selected based on an application usage scenario. The measured power draw and duration of BLE connected phases are given in Table 2 and Table 3.

ZigBee Measurement

With ZigBee, the measurement was carried out on a configured XBee ZigBee end-device as the DUT, which connects to an XBee ZigBee coordinator (i.e. gateway). The DUT was configured for cyclic sleep mode with reverse polling. In reverse polling, the end-device (in sleep mode) wakes up at regular intervals (default = 100 ms but can be modified in firmware) and polls its coordinator to request any data sent to its address while sleeping. The end-device sends a poll once after its wake-up sequence and again before going to sleep. In sleep-mode, the XBee draws a maximum of 50 µA at 3.3V (Digi, 2011).

Figure 5. Current draw of the XBee ZigBee end-device module during a connection event.

Figure 5 shows a detailed plot of a ZigBee end-device module current draw for one connection event. The plot shows the wake-up sequence, which includes MCU wake-up, pre-processing and synchronisation. The initial poll is shown in the next phase, starting with the channel access process, which is the contention-based CSMA/CA as defined by the 802.15.4 MAC specification. The duration of the CSMA/CA process may vary depending on channel availability. The power consumption and duration values are reported in Table 2 and Table 3 for an operating voltage of 3.3V.

Wi-Fi Measurement

In measuring the Wi-Fi module, an infrastructure operating mode was used. The Wi-Fi module and the AP were configured for the IEEE 802.11g standard, with a maximum theoretical data rate of 54 Mb/s (the highest of all the RF modules considered). At start-up the Wi-Fi module scans the channels for periodic beacons from the AP before a connection process is initiated. Regular beacons are received from the AP at 100 ms intervals and a block of data is transmitted to the gateway every 3 sec. Figure 6 shows a power consumption plot of the ESP-12F module depicting the beacons and data transmit phase. (There is some variation in the magnitude of the initial spike, due to the brevity of the spike duration compared with the power meter sampling interval.) As with every TCP/IP process, Tx packets are followed by ACK. However, the Rx process is indistinguishable from that of the Tx in the figure. The Wi-Fi module power draw in different states is reported in Table 2 and their duration in Table 3.

Figure 6. Power consumption trace of ESP-12F Wi-Fi module.

RF433 Measurement

The RF433 transmitter and receiver modules were measured separately. Figure 7(a) shows the power trace of the 433 MHz Tx module sending 10 Bytes of data and Figure 7(b) shows the Rx module receiving the same amount of data at 5 sec intervals.

Figure 7. Power trace of an RF433: (a) transmitter module sending a 10 B message; (b) receiver module receiving the same amount of data.

The transmitter module consumes a small amount of power (≈ 0.03 mW) when in standby and about 45 mW on average when transmitting. This is depicted by the spikes in Figure 7(a), indicative of its on-off keying modulation. Table 2 and Table 3 list the power draw and duration values of the RF433 modules. Because the Tx and Rx modules lack an integrated MCU, there is no substantial wake-up time for the transmitter and very little for the receiver (about 3 ms). The receiver module, however, maintains a steady but relatively higher power consumption level (≈29 mW) when in standby (i.e. listening mode), as can be seen from Figure 7(b). The RF433 module has the longest over-the-air transmission time due to its low data transfer rate (9.6 kb/s max), which is several orders of magnitude less than that of the other RF modules. Furthermore, while the Tx and Rx duration are similar for the same data transfer, the receiver remained at a higher power level for an additional duration of about 280 ms for post-processing or data verification.

Domestic Stock Control IoT Application – A Case Study

Application Architecture

The basic application architecture of the IoT is considered to include a large number of end devices (sensors and domestic appliances), communicating via a short-range wireless medium to a gateway device (a “home gateway”) and being controlled by that gateway. In some cases, the home gateway will communicate through an external network with cloud-based applications. While the popular wireless interface options discussed in the preceding sections have propagation or performance characteristics that may be important in particular applications, the focus of this case study is on the energy efficiency of each option in the context of a domestic operation