Much has been written about the IoT and how it has the potential to open up opportunities and maximise the efficiency of current processes. However, the time for talking about potential is now over - it’s time to begin thinking about how to actually implement an IoT solution and reap the benefits. Mark Patrick of Mouser Electronics explains.
The IoT itself is based around collecting huge amounts of data from a multitude of sensors, then storing and processing that data to provide a unique insight into any process. The opportunities offered by the IoT are expected to open up numerous types of new business model, many of which will be service orientated.
The wireless protocol choice
From the sensor to the Cloud, and back again through the feedback loop, the IoT will mainly be in the domain of the traditional embedded designer. Because the IoT is expected to always be connected, while many systems are anticipated to be fully wireless, one of the earliest key decisions for the engineer is which wireless method and protocol will offer the best mix of attributes. Of course, as the IoT is a new trend, many companies have developed protocols that are competing to transmit data from the sensor to the Cloud. Each of these protocols has different specialisations. So what’s the benefit of each particular one?
There’s no real standard model of an IoT system. Some sensors may only send data back to the Cloud in small amounts, either at regular intervals, or when polled. Other sensors may send large amounts of data constantly. Each of these examples, as well as everything in between, requires different paths to implementation.
Above: Figure 1. The main components of the Thread protocol. Thread targets appliances, access and climate control, energy management, lighting, safety and security
As one of the pioneers associated with the Cloud, Google is at the forefront of IoT devices and applications. The company acquired Nest Labs in 2015. Nest Labs was the developer of the Thread protocol, an early wireless protocol intended for the IoT and, more specifically, to control Nest’s smart thermostats and smoke detectors. The Thread protocol has established itself and gained adoption in these areas and many more.
Much of this adoption has been because of a partner and user community that Google has fostered. The strong community and the protocol’s technical credentials make it a good option for any IoT implementation, and a strong contender in a field that also contains ZigBee, Z-Wave and Bluetooth Low Energy (BLE). One reason for Thread’s current success could be the fact that it isn’t a new protocol built from the ground up – Google chose to base it around the established IEEE 802.15.4 standard.
Technically, Thread has been created to satisfy the needs of IoT design teams. For instance, it has very low latency, typically around 100ms. It’s also designed to accommodate up to 300 devices on one network. To ensure data is safe, it features AES 128-bit security. However, even with all these attributes designed specifically for IoT applications and the backing from Google, there’s no guarantee that Thread will dominate the field.
Bluetooth Low Energy (BLE)
Possibly the nearest protocol to Thread for basic IoT applications is Bluetooth Low Energy (BLE). One advantage Thread offers over BLE, and something that’s usually essential for IoT implementations, is the ability for the network to be implemented in a mesh network that can self-heal if required. IoT networks need constant connectivity to maintain data transfer, so in most cases, having a network that maximises up-time is essential.
Despite BLE not being able to offer self-healing, the protocol remains popular for many IoT implementations. Bluetooth has progressively evolved since its initial introduction in 1994. Each new iteration has offered enhancements and additional features, as well as performance increases that keep the protocol relevant in today’s marketplace. The participants in the Bluetooth Special Interest Group (SIG) are continuing to improve its capabilities for IoT applications. These SIG members include companies such as Broadcom and Qualcomm.
One example of a current, highly integrated BLE system on a chip (SoC) for IoT implementations is Broadcom’s BCM20737 WICED SMART Bluetooth device. As well as BLE functionality for IoT networking, the SoC offers additional security features, such as RSA 4,000-bit encryption and decryption. Low power iBeacon technology enables the chip to work passively in many situations. It also supports A4WP Rezence wireless charging.
As mentioned earlier, Bluetooth currently has no capability to offer self-healing, mesh networking capability. However, this is set to change in the near future, as the Bluetooth Smart Mesh Working Group is developing an architecture that will enable Bluetooth mesh networking capability as standard. The working group already has more than 80 companies supporting the initiative, which shows the demand for mesh support.
Other IoT wireless options
Of course, BLE and Thread aren’t the only two competing protocols in this area. Figure 3 shows the projected growth of the IoT - with the information from potentially billions of sensors being transmitted to the internet, the market is more than large enough for other protocols to carve niches for themselves.
These other protocols all usually have several attributes in common - limited processing power, low energy usage, low data rates and built-in encryption. IPv6, IEEE 802.15.4, 6LoWPAN, ZigBee and Z-Wave are just some examples of the types of protocols targeting the lower end of the market. So how do these other contenders compare?
ZigBee 3.0 makes a strong case for IoT installations, with support from around 400 vendors. In its mesh network, the protocol can support many more devices than Thread - potentially thousands in a single network. ZigBee 3.0 operates at 2.4GHz and each node can transmit data at up to 250kb/s, up to a maximum range of around 100ft. The protocol also supports IPv6 and features 128-bit AES encryption. One advantage ZigBee 3.0 offers developers is support for the wide range of profiles developed for previous versions of the standard.
Staying with variations of ZigBee, the next contender is a new iteration of the protocol, ZigBee Pro. This version of ZigBee has been built from the ground up for IoT applications. For flexibility, ZigBee Pro can operate at both 2.4GHz and in the unlicensed ISM spectrum between 800-900MHz. Targeted at electrically noisy environments, ZigBee Pro uses spread spectrum modulation over 16-channels to provide some immunity from other networks.
The protocol is also well suited for sensor clusters situated in areas where battery power is not practical. It uses extremely low amounts of energy, meaning it can operate efficiently using only energy scavenged from the environment by energy harvesting technology.
Z-Wave is a protocol for the 800-900MHz ISM bands. The protocol is supported by around 375 organisations. A network can support up to 232 nodes, with a data rate of 100kb/s and a range of 100ft.
The next two protocols on the list have been developed by the Linux Foundation. Firstly, there’s the AllSeen Alliance’s open source AllJoyn framework. This has been designed to offer maximum flexibility in IoT designs by facilitating the development of applications for different brands, categories, transport mediums and operating systems.
The applications developed needn’t even use the Cloud or the internet, although the framework has been designed to support both. AllJoyn can also support other communication standards, such as WiFi, Ethernet and power-line transmission. To be as flexible as possible, the framework supports most of the operating systems used for IoT applications. These include Windows, macOS, RTOS, Arduino, Android and, of course, Linux.
The second IoT initiative from the Linux Foundation is IoTivity, which specifically concentrates on interoperability. The purpose of the project is to ensure IoT devices can connect securely and reliably to the internet and any other device. To accomplish this, IoTivity provides a communication framework for wireless connectivity and manages the flow of information from all types of IoT devices, no matter which operating system they use or their form factor.
Figure 3. Projected growth in wireless enabled devices, showing the exponential growth of the IoT
On your marks
The race to become the wireless protocol for the IoT has barely begun. Having the backing of an industry giant like Google means Thread is potentially the early favourite. However, there are other options that tackle the connectivity challenge in different ways. Other emerging Cloud providers may look to adopt one or more of those rival protocols for their own benefits. Even without the backing of Cloud providers, the expected size of the market should ensure there’s room for different protocols for different applications.
It will be an interesting time for the market over the next few years, and only then will we have a clearer picture of which will likely emerge to win the race to be the IoT’s wireless protocol of choice.