Use Multi-Protocol, Multi-Band Wireless SoCs to Simplify Deployment of IIoT Networks

As a result of constant innovation, there are multiple, incompatible wireless options for Internet of Things (IoT) applications. While it’s always good to have choices, this also complicates the deployment of wireless networks—especially in the case of legacy Industrial IoT (IIoT) installations where multiple wireless networks may already be deployed, and where hundreds or thousands of sensors now need to be added throughout multiple facilities.

To address this problem, manufacturers of IoT transceivers have developed low-cost, low-power system-on-chip (SoC) solutions that support multiple protocols across multiple RF bands, all in a single device.

This article briefly looks at the design challenges presented by the widespread use of multiple short-range wireless communications standards and specifications. It then introduces system-on-chips (SoCs) from NXP, Texas Instruments, Silicon Labs, and Analog Devices that provide designers with the flexibility to accommodate multiple RF interfaces and explore their capabilities and the wireless protocols they support.

The wireless options challenge

Only a few years ago there were very few IoT transceivers or microcontroller SoCs that supported more than one wireless protocol, so manufacturers of edge devices chose one and used it throughout their product lines. In home automation, for example, the first visible IoT application, one manufacturer of “smart” lighting products might have used Zigbee, while another Z-Wave, and yet another Wi-Fi, making an already complex new technology even more confusing for consumers.

The IIoT market now faces the same challenges but on a much larger scale. Unlike in the case of homes which are geographically well-defined areas, large manufacturers might have facilities throughout the world with the need to support a wide variety of equipment and regulatory requirements. The emergence of multi-protocol, multi-band transceivers and microcontroller SoCs makes this easier for engineers deploying such devices, as well as the systems and network architects. As these SoCs are increasingly employed in edge devices, it is becoming possible to configure a network using several wireless protocols at the edge using SoCs from a single vendor.

Typical IoT SoC features

A typical SoC for the IoT includes a baseband and an RF section based on the IEEE 802.15.4 physical layer (PHY) wireless interface for low-rate wireless personal area networks (LR-WPANs); an Arm host processor and coprocessor; some degree of encryption, such as AES-128; and a true random number generator (TRNG). Also included are power and sensor management circuits, multiple clocks and timers, and several I/O options (Figure 1). As Zigbee has become a very popular protocol for industrial applications, it is almost universally supported in these devices, along with similar low data rate protocols such as Thread.

Figure 1: The Texas Instruments CC26xx series of SimpleLink SoCs, as shown in this block diagram, is representative of wireless IoT SoCs. The host processor is an Arm Cortex-M3, supported by an Arm Cortex-M0 coprocessor. (Image source: Texas Instruments)

Bluetooth Low Energy (Version 4) is also included in this instance, and increasingly Bluetooth 5 (Version 5.1) is being supported. In version 5.1, mesh networking was adopted, making Bluetooth another contender for large-scale IoT. However, not all SoCs support this version, so it’s important to determine if a candidate device for IIoT supports Version 5.1.

Some devices also support IPv6 over low-power wireless personal area networks (6LoWPANs), an open standard defined by the Internet Engineering Task Force (IETF) based on the 802.15.4 PHY. 6LoWPAN incorporates the IP header compression (IPHC) required for implementing IPv6, standard TCP/UDP layered on the 802.15.4 PHY and media access control (MAC) layers and operates at 900 megahertz (MHz) (or lower) frequencies as well as at 2.45 gigahertz (GHz).

The uplink to the internet is handled through an IPv6 edge router, to which multiple PCs and servers are also connected (Figure 2). The 6LoWPAN network itself is connected to the IPv6 network router using its own edge router.

Figure 2: An IPv6 network with a 6LoWPAN mesh network. The uplink to the internet is handled by an access point acting as an IPv6 router, connected to an IPv6 edge router, to which multiple PCs and servers may also be connected. The 6LoWPAN network is connected to the IPv6 network using an edge router. (Image source: Texas Instruments)

One of 6LoWPAN’s differentiating characteristics is its ability to provide end-to-end packet delivery anywhere using standard internet protocols, which allows designers to use high-level messaging protocols such as MQTT, CoAP, and HTTP with all applications.

Like the other protocols mentioned in this article, it also can run on “sub 1 GHz” radios in addition to 2.4 GHz so it has good propagation characteristics. For example, demonstrations of 6LoWPAN have covered distances up to four miles at 900 MHz using a transceiver with RF output power of +12 dBm. Lower frequencies are particularly useful indoors as they can better penetrate walls. Configured appropriately and with a suitable bridge, 6LoWPAN is interoperable with any other IP network such as Ethernet, Wi-Fi, or even cellular data networks.

Essential protocols

At the moment, no SoC supports all the wireless protocols used within the IoT. That’s not especially important for designers of IIoT networks because some of the protocols, like Thread and Z-Wave, are being adopted mostly in the consumer market. This reduces the contenders to Zigbee—by far the most popular protocol for Industrial IoT—along with 6LoWPAN and Bluetooth. That said, any SoC that supports the 802.15.4 standard should be able to function with Zigbee, LPWANs, Thread, and possibly proprietary solutions if those solutions can operate in the same bands.

Wi-Fi is typically not included in multi-protocol SoCs for low-power edge device applications powered by a tiny battery due to its relatively high power consumption. Its primary use in IoT has been for backhaul and gateway-to-internet access where power consumption is not a crucial metric. However, Wi-Fi is essential when cities upgrade their lighting, surveillance, and other infrastructure due to its high data rates and near ubiquity.

For these applications, Wi-Fi-on-a-chip SoCs have been available for several years, and their use is growing as the technology is an essential part of so many IoT applications in which very high data rates are essential. One of these Wi-Fi-only SoCs is Texas Instruments’ CC3100R11MRGCR Wi-Fi network processor, featuring a 2.4 GHz Wi-Fi radio and network processor with on-chip Web server and TCP/IP stack. When combined with a microcontroller from TI or any manufacturer, it forms a complete Wi-Fi solution in two small devices.

That said, quite a few SoCs are available that combine Wi-Fi and Bluetooth as both protocols are so popular and complementary as well. For example, Texas Instruments’ WL1831MODGBMOCR in the company’s WiLink 8 Wi-Fi/Bluetooth combo module family supports Bluetooth and Bluetooth Low Energy. For Wi-Fi, it includes IEEE 802.11b/g/n at a maximum data rate of 100 megabits per second (Mbits/s) along with Wi-Fi Direct. Its 2 x 2 MIMO capability provides 1.4 times the range of a device using a single antenna, and in Wi-Fi mode it consumes less than 800 microamps (µA). Bluetooth features include Bluetooth 4.2 Secure Connection compliance, a host controller interface for Bluetooth over UART, and an audio processor supporting a sub-band codec for Bluetooth’s Advanced Audio Distribution Profile (A2DP).

Within its 13.3 × 13.4 × 2 millimeter (mm) package are RF power amplifiers and switches, filters, and other passive components, as well as power management and other resources, such as a 4-bit SDIO host interface.

The Mighty Gecko EFR32MG13P733F512GM48-D multi-protocol SoC from Silicon Labs takes an interesting approach by combining a microcontroller with a transceiver that operates at key frequencies between 169 MHz and 2.450 GHz. This makes it compatible with Bluetooth Low Energy and Bluetooth 5.1, Zigbee, Thread, and even 802.15g, a variant of the standard designed for very large utility applications in smart grid networks that may have millions of fixed endpoints over a widely dispersed area.

Some devices in the Mighty Gecko family support networks operating below 1 GHz allow tailoring for specific applications, and so support a variety of modulation schemes such as OOK, shaped FSK, shaped OQPSK, and DSSS modulation.

Texas Instruments’ SimpleLink platform includes hardware supporting Bluetooth Low Energy and 5.1, Thread, W-Fi, Zigbee, and “sub 1 GHz” solutions such as 6LoWPAN, as well as wired standards including Ethernet, CAN, and USB. Two or three wireless protocols are supported in a device depending on the model. Every model in the family is supported in a single software development environment.

For example, the CC2650F128RHBR SimpleLink multistandard wireless MCU includes support for Bluetooth, Zigbee, and 6LoWPAN, as well as for remote control applications such as Zigbee Radio Frequency for Consumer Electronics (RF4CE). The latter protocol is an enhancement to IEEE 802.15.4 and has networking and application layers to create multi-vendor interoperable solutions. The CC2650 uses a 32-bit Arm Cortex-M3 as the host processor that is matched to a power sensor controller that acts autonomously, even when the overall system is in sleep mode. The Bluetooth controller and 802.15.4 MAC use a separate Arm Cortex-M0 processor, freeing up memory for application support.

The MKW40Z160VHT4 SoC from NXP Semiconductors accommodates Bluetooth Low Energy and 802.15.4 for Zigbee and Thread, operates between 2.36 GHz and 2.48 GHz, and uses an Arm Cortex-M0+ CPU, Bluetooth link-layer hardware, and a 802.15.4 packet processor. In addition to its primary use as a complete subsystem, it can also act as a modem for adding Bluetooth or 802.15.4 connectivity to an existing embedded controller, or as a standalone wireless sensor with an embedded application where no host controller is required.

The LTC5800IWR-IPMA#PBF multi-protocol SoC from Analog Devices combines support for the 802.15.4-based protocols already mentioned, as well as another protocol called SmartMesh, which has an interesting history. It was developed by Kris Pister, a professor of electrical engineering and computer sciences at the University of California Berkeley in the late 1990s with funding from DARPA’s Smart Dust project. The goal of the program was to create a tiny, highly reliable radio that could be powered by a battery or with energy harvesting. Key customers would be pipeline utilities with widely spread infrastructure that often operates in environmentally hostile conditions.

To commercialize the technology, Pister co-founded Dust Networks to produce a meshed wireless sensor network called SmartMesh. In 2011 the company was acquired by Linear Technology, which was itself acquired in 2017 by Analog Devices, where SmartMesh lives on, now in IIoT as well.

SmartMesh comprises a self-forming, multi-hop mesh of nodes (called motes) that collect and relay data, and a network manager that coordinates performance and security and exchanges data with a host application (Figure 3). As reliability was one of the core requirements of the DARPA program, SmartMesh has retained this capability with uptime of 99% even when operating in rough environmental conditions. Its communication protocol is a spread-spectrum variant called time-slotted channel hopping (TSCH) that synchronizes all motes in the network to within a few microseconds.

Figure 3: In a SmartMesh network every node acts as a router, so new nodes can be connected at any point. The technology supports up to 50,000 nodes. (Image source: Analog Devices)

All motes in the network are synchronized to within less than 1 millisecond (ms) and can have a battery life of more than 10 years. Only power supply decoupling, crystals, and an antenna are needed to create a complete wireless node. When using an omnidirectional 2 dBi gain antenna, the LTC5800-IPM has a typical range of 300 meters (m) outdoors and 100 m indoors.

Conclusion

With all the variations in wireless protocols, it is difficult to select the right wireless interface and protocol to use for IIoT deployments as there are also legacy systems that may need support. As shown, IoT SoCs that support multiple short-range wireless protocols across multiple RF bands can greatly simplify the deployment of IIoT networks by offering designers greater flexibility.