Last December, the Zigbee Alliance launched “Project Connected Home over IP” (CHIP) with the ambitious goal of enabling plug-and-play consumer IoT devices. Led by Amazon, Apple and Google, Project CHIP aims to deliver specs and open source code later this year. Now that the initial press and analyst coverage has settled down, Project CHIP deserves a closer look because large, high profile companies only join together around an audacious goal like this one if they actually believe they can achieve it.
What problem is Project CHIP trying to solve? Can it actually be solved?
Consumers expect small, connected devices to work like USB — they want to be able to buy any product, plug it in and have it “just work.” Today, we’re a far cry from meeting this plug-and-play expectation. Buying a connected gadget like a door lock, light bulb, switch, window shade, thermometer, scale or security sensor is quite complicated. You have to consider compatibility with your home device network (Z-Wave, Zigbee, Insteon), virtual assistant (Alexa, Siri, Google Assistant) and other devices that are already installed. While other industry defragmentation attempts have failed, I believe Project CHIP is likely to succeed for three reasons.
First, each participating company agreed to change its connectivity strategy so that IoT devices can plug-and-play with any application, including competitors’. For example, a device should be able to work with Alexa, Siri or Google Assistant. By announcing a strategic transition to an open device ecosystem, Amazon, Apple and Google are signaling strong commitment to the project – and this is a big deal.
Second is the fact that the group isn’t starting from scratch. Participating companies already have mature device protocols such as Alexa Smart Home, Apple HomeKit and Google Weave. Project CHIP is in a good position to additively build on existing solutions with the possibility of achieving some backward compatibility.
Third, and most important, Project CHIP is based on existing standards. Instead of creating yet another device network standard (we already have too many of those), Project CHIP will be a lingua franca for device communication using industry-standard Internet protocols (IP) over any IP-bearing network. In other words, they are putting the Internet in the Internet of Things.
To understand why this is the right thing to do, and why it hasn’t already happened, let’s review how connected devices evolved into non-interoperable device ecosystems.
Small devices have unique requirements
If you think the Internet of Things is already based on Internet protocols, you’re partly right. Mainstream IP-based networks like Ethernet, Wi-Fi and cellular are the nerve fibers connecting clouds, servers, PCs, mobile devices, hubs and many types of IoT devices (such as smart speakers, security cameras, thermostats and industrial equipment). These “unconstrained” devices have plenty of processing power to communicate over mainstream networks using standard Internet protocols.
Historically, IP-based protocols did not extend down to everyday things like switches, lights, door locks, thermometers, window shades and small sensors. These small, low-power, constrained gadgets have various combinations of five unique characteristics that preclude the use of mainstream networks and protocols:
- Low cost – Limited-function devices have limited prices
- Low power – Run for years on a battery
- Small size – Unobtrusively integrate with real-world things
- Specialized wireless – Low power; mesh extends coverage
- No-UI setup – No keypad, no display, simple user experience
Consequently, there are two distinct classes of IoT devices–large and small. Large devices have always used IP networks and protocols while small “constrained” devices had to take a much different evolutionary path.
Device network fragmentation
Twenty years ago, when connected embedded devices first emerged, IP networks and application protocols were too power-hungry, range-limited, verbose and complicated for small, constrained IoT devices. To fill this gap, “full-stack” device networks such as Z-Wave, Zigbee, Bluetooth, Insteon and others were created by combining low power radios with specialized, efficient (non-IP) application protocols.
Without a dominant standard, device manufacturers balkanized into silos of incompatible networks, each with its own unique application protocol. This fragmentation resulted in non-interoperable products with inconsistent user experiences, sold in a confusing and inefficient marketplace. No “Darwinian” convergence ever took place, so we’re still living with this situation today. Device network and protocol fragmentation is undifferentiated friction that impedes IoT industry growth.
Constrained Internet protocols: The 37-year oldsolution, now available in “small”
Let’s take a step back and contrast the fragmented world of IoT connectivity with the more familiar world of PCs, phones and tablets. We live our digital lives on WiFi, cellular and Ethernet networks and we don’t usually care which one we’re using. When we leave a WiFi network, our phones automatically transition to 4G/5G and our apps (should) continue working as if nothing has happened. We take these seamless transitions for granted because mainstream networks use Internet protocols that were designed for interoperability from the start.
At the heart of these protocols is a 37-year old layered model that organizes network protocols hierarchically (ARPAnet started using TCP/IP in 1983). Each layer abstracts the details of all the complicated stuff below it and provides a consistent interface to the layer above it. Applications at the top of the stack are (mostly) unaware of what’s going on in the lower layers so they communicate the same way regardless of the connection—wired or wireless, fast or slow, WAN or LAN. The industry-standard Internet protocol suite, with its familiar acronyms (IPv4, IPv6, TCP, UDP, DHCP, HTTP and others), evolved on this layered model. That’s why applications and devices can plug-and-play over any network connection.
Although constrained IoT devices can’t always use the standard IP protocol suite as-is, the good news is that over the past 15 years a scaled-down version has been standardized and is now readily available. These new standards provide efficient alternatives to established Internet protocols:
- 6LoWPAN – Compact, efficient way of doing IPv6 addressing
- UDP / DTLS – Low-overhead alternative to TCP transport with TLS-like security
- CoAP, MQTT-SN – Low power alternatives to HTPP, MQTT application protocols
6LoWPAN (IPv6 Low power Wireless Personal Area Networking) is the key to running Internet protocols over small device networks. The other constrained protocols listed above are optional methods for improving the efficiency of IP device communication. For instance, a 6LoWPAN device network may use CoAP over UDP to minimize network traffic or may use HTTP over TCP at reduced efficiency. This is an important point because existing TCP/IP-based applications can work over both Wi-Fi and constrained networks with minimal modification.
If IP protocols for device networks have been available for years, why haven’t they been universally adopted? The main reason is there’s no business case for a single company to lead the way all by themselves. If they just want to control some small device like a light or a plug, existing full-stack non-IP networks like Zigbee and Z-Wave can do the job just fine. Clearly, the big companies in Project CHIP are looking at a much bigger picture–device industry defragmentation. This requires replacing the hodge-podge of full-stack device networks with standard IP-based application protocols running over IP-bearing networks. The networks are ready now and Project CHIP is creating the missing piece–an industry standard IP application protocol for small devices.
Constrained IP networks
Constrained IP wireless networks are already available. No new hardware is needed because they use radio technologies that full-stack solutions have deployed for many years. For example, Thread is a secure IP-based mesh network built on the same industry-standard 802.15.4-2006 radios that Zigbee uses. Thread can support any IP app layer so it’s a great fit for Project CHIP. According the Project CHIP website, initial network targets are Wi-Fi through 802.11ax, Thread over 802.15.4-2006 at 2.4 GHz and unspecified “IP implementations of Bluetooth Low Energy.” Silicon, modules and software stacks are readily available for Wi-Fi and Thread so there’s no deployment barrier.
Application protocols: The role of Project CHIP
Application protocols like Alexa Smart Home, Apple HomeKit and Google Weave perform the same kinds of functions but do them differently. Project CHIP aims to make it easier to build devices that are compatible across all applications, but the scope of the standardization effort is a little unclear. Their website says that it “may include a proposed standard for lifecycle events such as provisioning/onboarding, removal, error recovery and software update.” Standardizing just these device management functions goes a long way towards enabling plug-and-play but I think it’s safe to assume they’ll address operational protocols as well. It wouldn’t make sense for Alexa Smart Home, HomeKit and Weave to use different commands to, say, turn on a light. We don’t know how far beyond basic lifecycle functions Project CHIP will go, but we’ll be watching.
IoT in 2022
Why should we care about any of this? Here’s my optimistic view of what the world of IoT might look like in a few years if Project CHIP succeeds:
- Device manufacturers build single-SKU IoT products that plug-and-play with multiple networks and applications right out of the box.
- Consumers select devices based on features and quality without worrying about network and application compatibility.
- Consumers use Siri, Alexa, Google Assistant or other compatible applications with all of their devices.
- Special device hubs and gateways are no longer needed.
- Builders install future-proof home automation that works with owner-specified applications.
- The cost of IoT devices drops as manufacturers build fewer SKUs at higher volumes.
The result is a simple, efficient, de-fragmented marketplace where IoT devices simply plug-and-play like USB peripherals. This vision is motivating major IoT players to place big bets on the transition to Internet protocols–and on Project CHIP.
Project CHIP is sharply focused on consumer markets, but what about commercial and industrial IoT applications? Many Project CHIP-enabled smart home devices such as lighting, HVAC, door locks, window blinds and the like should find commercial applications right away. It’s also easy to support additional industrial devices by extending Project CHIP’s IP-based application protocols. Jorg Kennis of OSRAM wrote an excellent blog about this topic and you can find it here on the Thread Group website.
I was initially skeptical about Project CHIP. Other well-intentioned standardization efforts have attempted to unify application layers by building “one framework to rule them all” with little success. Some of these efforts failed, others have been slow to get traction and all of them took a long time to produce anything. Project CHIP is different because it is backed by big companies, it’s based on proven Internet design principles and it builds on protocols that are already deployed rather than starting with a blank whiteboard. By collaborating in Project CHIP, some of the biggest names in the industry are signaling that they intend to differentiate their products based on features, quality, value and services rather than building closed device ecosystems. Bravo!