Using AWS IoT Core in a Low-Power Application

At AWS, we work closely with customers to assist them in building various types of IoT solutions. We often hear from customers about the need to manage power consumption appropriately in IoT. In this blog post, we’ll discuss one of the options for achieving lower power consumption while connecting to AWS IoT Core. Specifically, we’ll show how your choice of wireless transport can help extend battery life. Communication is assumed to be wireless and can use Wi-Fi or LPWAN.

In a large number of IoT projects, powering a device isn’t an issue and line power can be used. In other projects, it may not be possible to run power directly to the device – this may be caused by building regulations; the cost to run the power lines or a need for the device to be somewhat mobile. In a situation like this, battery power will be considered for the device. A constraint on any solution design will be extending the battery life as long as possible.

Wi-Fi is well known and understood however it uses more power and provides a higher transfer rate. LPWAN is a low-power wide area network that uses less power than traditional Wi-Fi.

The following design will consider the Wi-Fi mechanism and a possible design option for that scenario.

Initial Design

A device keeps its current state and event log onboard in permanent storage. To extend battery life, it leaves the Wi-Fi radios powered down. As the following diagram shows, the device periodically performs the following actions:

• Turn on the Wi-Fi radio and connect to the Wi-Fi gateway.
• Connect to the endpoint.
• Publish the event history to an MQTT topic.
• Upload its current configuration settings (state) to an AWS IoT device shadow.
• Download any new desired configuration settings (state) from an AWS IoT device shadow.
• Make any configuration setting changes based on the desired state.
• Turn off the Wi-Fi radio.

To extend battery life, you might consider the interval between data uploads. It can be set to a longer period when the device is not anticipated to be in active use.

Clusters of Devices

You can extend the initial design to include clusters of devices that are relatively close together and need to periodically communicate their state and event history.

In this scenario, not all the devices need to use energy-expensive Wi-Fi connections to transfer data. Bluetooth low energy (BLE) can provide a more energy-efficient method for getting the data from the devices to a combination BLE/Wi-Fi device in the cluster. This BLE/Wi-Fi device connects to the network and transfers data on behalf of the actual devices. We refer to this device as a device gateway in the rest of this post.

BLE allows the individual devices to advertise themselves and provides additional information about their state or offered services. The individual devices can advertise information like:

• The length of time since the event history was last retrieved.
• Important events in their history.
• The current battery level.

For an introduction to the advertising structure of BLE, see this post on the Bluetooth blog.

Internal parameters like the following govern the actions of the device gateway:

• The length of time an event history should remain on an individual device before collection is required.
• Whether the event history should be collected immediately from an individual device that has an important event in its history.

The device gateway then periodically listens for BLE advertisements that match the criteria, as shown in the following diagram.

The first BLE device in the diagram has exceeded the maximum time between uploads. The last BLE device in the diagram has important events that need to be uploaded.

If the event history for one or more individual device must be uploaded, the device gateway does the following (for each device):

• Connects to the device using BLE.
• Retrieves the device information.
  • This might include the serial number used to calculate the target MQTT topic(s) where the device data should be delivered or the MQTT topics themselves.
• Turns on the Wi-Fi radio and connect to the Wi-Fi gateway.
• Connects to the IoT endpoint.
• Publishes the individual device history to the MQTT topics generated/specified.
• Informs the independent device that the event history has been successfully transmitted.
• Uploads the independent device’s current configuration settings (state) to an IoT device shadow.
• Downloads any new desired configuration settings (state) from an AWS? IoT device shadow and transmit them to the individual device.
• Syncs the device’s time with the gateway.
• Turns off the Wi-Fi radio.
• Disconnects the BLE radio from active usage.

You can increase battery life even more by decreasing the advertising intervals for the BLE devices and reducing the transmit power of the BLE radios to a reasonable level for the distances in the cluster. Depending on the data transmit interval requirements and number of devices, you can also turn off the BLE radios for periods of time (for example, in the scenario where data collection needs to occur hourly or more frequently). If the BLE radios in both the independent devices and the device gateway were turned off for 20 minutes every hour, there would still be a minimum of 10 minutes overlap when the radios are on. If this is enough time for all the devices to send data through the gateway, then this could be an option. It works whether the times are in sync or out of sync.

Conclusion

This blog post showed you one of many power management solutions in IoT applications. It’s possible to extend the lifetime of the power source by combining BLE and Wi-Fi technologies and the selective powering of radios and sending of batches of data.

Bluetooth References

https://blog.bluetooth.com/bluetooth-low-energy-it-starts-with-advertising
https://docs.mbed.com/docs/ble-intros/en/latest/Introduction/BLEInDepth/
http://www.weightless.org/about/the-argument-for-lpwan-in-the-internet-of-things