Editor’s Note: Part 1 and Part 2 of this three-part series described the popular wireless options, their key operating attributes, and design fundamentals. Here in Part 3, we will look at new technologies that have emerged to address the needs of the Internet of Things.
There are many choices when it comes to low-power wireless technologies. However, the demands of low-power wireless continue to increase and the industry is responding. For example, the special interest groups, alliances, and forums that look after the various wireless technologies are now evolving their technologies to make them more applicable to the burgeoning Internet of Things (IoT).
This article describes the most important protocol changes demanded by the IoT and their impact on design projects. Note that several of the technologies described in the first two articles, notably IrDA, Nike+, and RF4CE, don’t target the IoT so they are not discussed here. However, some new technologies have arisen specifically to meet the demands of the IoT, notably Thread and Wi-Fi HaLow, are included.
Making the connection
Many of the low-power wireless technologies were designed before the IoT was a fully formed concept. Bluetooth low energy, for example, was originally developed to link peripheral devices such as heart rate belts and pedometers to a hub unit such as a sports watch or cellphone. Sending the data from Bluetooth low energy sensors to a remote cloud server wasn’t an objective of the original specification.
When it became apparent that collating and analyzing the data from thousands of tiny wireless sensors would form a key strength of the IoT, the custodians of the competing low-power wireless protocols started to adapt their technologies to cope.
Key to these changes was the leveraging of gateways to connect the short-range wireless technology to the Internet proper. For consumer applications, a smartphone works well as a gateway, in commercial or industrial applications, Wi-Fi routers or proprietary gateways are options. A gateway operates at the network application layer disassembling the data coming in from the low power wireless network and reassembling it for transport via an Internet-friendly TCP/IP protocol stack. Similarly, information from the Internet can be reassembled and relayed back to the sensors (Figure 1).
Figure 1: A ZigBee network employs a gateway for connection to the Internet. Information can flow in both directions. (Image source: ZigBee.org)
Alternatively, some low power wireless protocols, such as Thread, include an IPv6-based low-power wireless personal area networking (6LoWPAN) adaption layer between the IEEE 802.15.4 link layer and a TCP/IP stack resident at the node itself. Such an adaption layer enables a low power wireless sensor to communicate directly with other devices on the Internet. This enables an expensive and complex gateway to be replaced by a simpler IP layer edge router or bridge to forward sensor data to the cloud.
An IP layer router is also more flexible than a network application layer gateway because connected sensors can be modified or improved with additional applications, without the need to alter the gateway.
A second key requirement for IoT sensor applications is mesh networking support. Some low-power wireless technologies, notably ANT+ and ZigBee, included mesh support from initial launch, while others such as Bluetooth low energy have included it only recently. Mesh networking allows devices to communicate with any other node attached to the network without passing information via a central “hub” device. Mesh networks extend range, flexibility, and redundancy, and are particularly suited to IoT applications.
Enhancements for the IoT
Let’s consider how each wireless protocol has evolved for IoT applications.
Near Field Communication: At first glance, near-field communication (NFC) appears to have little in common with the other IoT technologies discussed here. NFC has limited range and bandwidth, and can’t form a mesh network. In addition, NFC can’t send data to the cloud.
But the technology will play a key role in the IoT as a complement to more mainstream IoT protocols, particularly for connecting and commissioning (or “securely introducing”) a new device to a network.
One challenge to rolling out the IoT is that there is currently no industry standard for connecting and commissioning an IoT sensor to a network. The result is a proliferation of proprietary solutions. To make commissioning even more confusing, many IoT devices are “headless” units that lack a user interface.
NFC, an interoperable, open-standard-based wireless protocol, offers a solution. For example, NFC can be used to greatly simplify the commissioning of a headless Bluetooth low energy or ZigBee LED smart light to a smart home mesh network. If the smart light and associated IoT gateway are equipped with an NFC tag, the unpowered smart light can be brought into proximity with the powered gateway and a network key exchanged.
Then, when the smart light is plugged into the light socket and powered on, the key is read by the wireless SoC and used to commission the device to the network. The key is then erased from the NFC tag to protect it from being read by an unauthorized person, the networking parameters are transferred, and a secure AES-128 encrypted wireless connection established for future communication (Figure 2).
Figure 2: NFC can be used to commission headless IoT devices. In this example, an unpowered bulb obtains a network key from a gateway via NFC. The key is later used to establish encrypted communication across the network before being erased. (Image source: NFC Forum)
Rigado’s BMD-300 Bluetooth low energy module (which is based on Nordic Semiconductor's nRF52832 Arm® M4F processor-based SoC) is among wireless solutions that now include an NFC tag for commissioning headless IoT devices.
Bluetooth low energy: The custodians of Bluetooth low energy, the Bluetooth Special Interest Group (SIG) have done much to move the technology from a consumer oriented personal area network (PAN) to an IoT targeted local area network (LAN).
Key among these inclusions are:
- The ability for a device to act as a “peripheral” and a “hub” at the same time.
- Addition of a method to create a dedicated channel, which could be used for IPv6 communications (both added in Bluetooth 4.1).
- Addition of the Internet Protocol Support Profile (IPSP) to allow Bluetooth low energy devices to communicate with any other IPv6 enabled device.
- Higher strength security.
- Increase in maximum transmit power.
- Increase in packet length (all of the above added in Bluetooth 4.2).
- Increase in throughput.
- Increase in range (both of the above added in Bluetooth 5).
For more detail of these changes see Digi-Key library article, “Bluetooth 4.1, 4.2 and 5 Compatible Bluetooth Low Energy SoCs and Tools Meet IoT Challenges (Part 1)”.
More recently, the Bluetooth SIG has added Bluetooth mesh 1.0, a profile that adds a mesh topology to Bluetooth technology’s networking support. The mesh profile is not restricted to chips complying with the latest version of the specification, Bluetooth 5, rather it’s backwards compatible with all Bluetooth low energy chips (i.e. from Bluetooth 4.0 onwards).
The specification details firmware comprising seven layers on top of the standard Bluetooth low energy physical layer (PHY) and four types of nodes, including a “Low Power” type and a “Proxy” type. This latter type is notable because they enable Bluetooth low energy devices that currently don’t directly support Bluetooth mesh (for example, today’s smartphones) to connect to a Bluetooth mesh network. Such a feature will allow smart lighting manufacturers, for example, to introduce mesh networked systems that can be controlled directly from contemporary mobiles (Figure 3).
Figure 3: Bluetooth mesh features Proxy (P) nodes that allow today’s smartphones to control applications such as smart lighting. (Image source: Bluetooth SIG)
Nordic Semiconductor is one of the first Bluetooth low energy chip vendors to offer Bluetooth mesh 1.0 support with its nRF5 Software Development Kit (SDK) for mesh. Dialog Semiconductor's DA14586 Bluetooth 5 SoC is also said to support Bluetooth mesh.
ANT: Developed by Dynastream, ANT and ANT+ have always supported mesh, but recent enhancements come in the form of ANT BLAZE, a mesh networking technology for handling high-node-count IoT applications in large-scale enterprise environments.
The technology connects up to 500 nodes at once, and is available on D52 ANT SoC modules adding enhanced mesh networking to the concurrent ANT/Bluetooth low energy connectivity capability of the modules. One of the key strengths of ANT BLAZE is its relatively high immunity to interference when operating in Wi-Fi and Bluetooth low energy/Bluetooth environments.
An upgraded D52 ANT SoC Module Starter Kit (D52DK2) and a newly released D52EXT1 Extender Kit, which includes four battery-powered nodes, provide developers with the specifically designed development tools necessary to create and verify their IoT use-case solutions.
ZigBee: The ZigBee Alliance states that the technology was originally designed for cloud connectivity and mesh topology operations in mind. Because of this, ZigBee has been subject to fewer recent IoT related adaptions than competitive technologies.
Because ZigBee was always designed for mesh topologies, it is easily scalable and highly fault tolerant in IoT applications such as smart buildings. Moreover, the ZigBee protocol suite includes standard commissioning, security, network, and device management procedures. Various device types can join and be authenticated in the network, and be factory reset or decommissioned in an interoperable way.
ZigBee uses its 250 Kbits/s throughput to carry both application data to operate devices
(such as a switch toggling a light) and network management procedures like mesh and routing management.
The release of ZigBee PRO 2017 earlier this year allows a single ZigBee mesh network to operate either in the 800 to 900 MHz band in certain regions of the world (boosting range) or the 2.4 GHz band globally. PRO 2017 builds on earlier versions of ZigBee PRO offering additional features for robust deployments including enhanced security compared with ZigBee alone.
Digi International's XBee ZigBee Mesh Kit provides developers with a cost-effective entry to the world of ZigBee PRO mesh networking. The kit comes with a development board, three ZigBee modules and a web-based tutorial introducing mesh networking. The XBee kit’s modules are based on Silicon Labs' EM3587 ZigBee SoC that offers 250 Kbits/s data rates and -101 dBm sensitivity for a 90 m indoor range (Figure 4).
Figure 4: The EM3587 ZigBee SoC from Silicon Labs has a data rate of 250 Kbits/s and a sensitivity of -101 dBm sensitivity for a 90 m indoor range. (Image source: Silicon Labs)
Thread: While 6LoWPAN’s adoption promised IP connectivity at the node, it has been slow to catch on because of interoperability issues. Thread, a protocol developed and promoted by Google, Samsung and several silicon vendors who wanted to directly connect low-power wireless nodes to IP networks, was introduced to address the interoperability road block.
Thread’s advantage derives from its basis on the IEEE 802.15.4 2006 specification, integration of 6LoWPAN and mesh support (Figure 5).
Figure 5: Thread protocol builds on IEEE 802.15.4 PHY and MAC, and incorporates a 6LoWPAN adaption layer. (Image source: Thread Group)
Thread is a 2.4 GHz protocol that provides data rates of up to 250 Kbits/s and can support as many as 250 devices in one local network mesh. The final connection to the cloud is via one or more ‘border’ IP routers. This router is actually a Thread device in the network but with an additional IP-compatible interface (such as Wi-Fi, Ethernet or cellular) to complete the path from the network to the Internet. Other devices in the Thread network can transparently upgrade to routers if a main router fails, building in Internet connection redundancy to the network.
A Thread Group managed certification program enables interoperability between Thread devices. Many product manufacturers use Google’s OpenThread, an open-source implementation of the Thread networking protocol. For example, Texas Instruments' CC2538, an ARM M3 processor-based wireless SoC for IEEE 802.15.4 operation, can run the OpenThread protocol and is Thread certified. Similarly, Nordic Semiconductor’s nRF52840, an ARM M4F processor-based wireless SoC for Bluetooth low energy, ANT and IEEE 802.15.4 operation, also runs OpenThread and is Thread certified.
Wi-Fi HaLow: Wi-Fi has carved a niche in both consumer and industrial sectors as the standard for wireless local area networks (WLANs). However, its relatively high power consumption has made the technology uncompetitive for battery powered sensors. The Wi-Fi Alliance plans to change all that and take a share of the burgeoning IoT sector with a low power form of Wi-Fi, based on IEEE 802.11ah and dubbed “HaLow”.
Power consumption is minimized by leveraging the ultra-low duty cycle used by other low power wireless technologies and is claimed to be around 1 percent of that consumed by conventional Wi-Fi chips (and hence comparable with Bluetooth low energy).
HaLow operates in the 900 MHz ISM band which boosts its range to nearly twice that of today’s Wi-Fi, a range claimed to be comparable with Bluetooth 5’s 900 MHz operation. It offers more robust operation than conventional Wi-Fi’s 2.4 or 5 GHz because the signal is attenuated less by walls and other solid obstacles.
Throughput depends on the number of spatial streams, modulation technique, coding rate and channel width. Higher throughputs will inevitably compromise power consumption. Using a single spatial stream, BPSK modulation, 1/2 coding rate and a 2 MHz channel width, throughput is 650 Kbits/s. At the top end, using 4 spatial streams, 256 QAM modulation, 5/6 coding rate and a 16 MHz channel width, throughput is 347 Mbits/s.
Wi-Fi HaLow will support mesh networking, and because it’s based on existing Wi-Fi protocols, the technology will include IP support at the node, but will also be compatible with the next generation of Wi-Fi routers.
Because of its recent introduction, there are currently no commercially available Wi-Fi HaLow ICs, chipsets or modules, although several silicon vendors are working on prototype products.
IoT wireless choice depends on application
Given the nuances of each wireless technology, the choice of which to use comes down to the requirements of the application, making it useful to develop a comparative table (Table 1).
Table 1: Comparison of key protocols for IoT applications. (Data source: Digi-Key, Texas Instruments)
All technologies will do a satisfactory job, but as shown, some use less power, others offer better throughput. Some offer long range, others offer greater interference immunity. Some offer smartphone or wireless access point interoperability, and others are backed by large industry alliances. Every wireless technology is evolving, both to compete with rivals and to meet the demands of new, and often unanticipated applications.
There are several proven low power wireless technology options for every application, all backed by good design tools and vendor support. The choice comes down to the specification and the application.
It seems unlikely that the wireless sector will be dominated by a single protocol or industry grouping. It’s likely that protocols will increasingly work together to take advantage of the strengths of each of them. Expect to see more partnerships like that between Bluetooth low energy or ZigBee and NFC, and Thread, Bluetooth low energy or ZigBee and IPv6. Also, expect each to evolve to meet demands of the IoT.
- “Simplifying IoT: Connecting, Commissioning, and Controlling with Near Field Communication (NFC)”, NFC Forum, June 2016.
- “Wireless connectivity for the Internet of Things: One size does not fit all”, Nick Lethaby, Texas instruments, October 2017.