PLEASE ROTATE ME
Telink Staff
June 19, 2019
Standards
According to psychologist John Antonakis, “The only way a smart person can signal their intelligence appropriately and still connect with…people is to speak in charismatic ways.” In other words, no matter how intelligent an individual may be, their effectiveness in most endeavors depends on their ability to connect and communicate with other people.
As with humans, so with Internet of Things (IoT) devices.
The ability to exercise control over an assortment of networked smart devices is the fundamental value proposition of the IoT. When IoT devices are unable to communicate with each other, we’re left with just…things. And while it’s in every IoT stakeholder’s interest to ensure device interconnectivity — to endow each smart device with sufficient “charisma,” so to speak — doing so is easier said than done.
In short, this interconnectivity challenge stems from the tripartite structure of IoT devices. Every device is comprised of three distinct layers: a hardware layer built around a radio designed to a technical standard like IEEE 802.15.4, a network layer that enables devices to form mesh networks and communicate with each other, and an application layer that allows end users to orchestrate such communication.
To (over)extend our metaphor, the hardware layer amounts to the fact of being human, the network layer amounts to the ability to hear and speak, and the application layer amounts to the language one speaks. As such, it’s particularly important for device developers to facilitate alignment at the application layer, as even if two devices are otherwise compatible — i.e. they are the same “species” and are theoretically capable of communication — they won’t be able to communicate if they don’t speak the same language (at least not without the intervention of an intermediary).
In truth, perfect linguistic alignment is even more important to device communication than to human communication. Whereas a Mandarin speaker and an English speaker might be able to communicate in a basic way using nonverbal cues, even minor differences in two devices’ application layers will result in a total breakdown of communication. If one device only speaks 0/1 and another only speaks 0-100, no command — no matter how rudimentary — is going to register.
The all-or-nothing nature of application layer alignment has caused considerable issues as the IoT has crept toward mainstream adoption. Since there are still very few IoT submarkets in which there is a large installed user base, device developers lack a clear set of design imperatives. Decisions about which language a device should speak continue to be made rather haphazardly, and are often guided less by strictly technical considerations than by corporate allegiances or even simply developers’ past work experience.
Encouragingly, in recent years, a number of major industry players have made a point of attempting to address this issue. Indeed, the clear need for improved cross-manufacturer device interoperability was the impetus for the development of Thread, a network protocol that supports both mesh and IP connectivity right out of the box and is designed with scalability in mind.
Early specifications of Thread were distinctive in their “openness,” particularly as it pertained to the handful of application layers the protocol defined. Beyond its offering easy IP connectivity and end device addressability, Thread’s primary pitch was that it would be a unifying network layer for a variety of application and hardware layers. As attractive as this was in theory, its lack of standardization ended up putting off many developers. Why would they opt for a piecemeal solution when standards like Zigbee were offering a full hardware-network-application stack?
Until recently, there wasn’t an obvious answer to this question, but that changed with the introduction of Dotdot, an application layer based on the Zigbee Cluster Library (ZCL) designed to function as the “universal language” of the IoT.
Dotdot has functioned as the default application layer for Zigbee devices since it was unveiled in 2017, but it is also increasingly becoming the de facto application layer for devices that feature a Thread network layer.
This dual prominence means there are a growing number of devices that are built on an 802.15.4 radio hardware layer, rely on either a Zigbee or Thread network layer, and “speak Dotdot” at the application layer. Because these devices have compatible hardware and communicate using the same language, they are able to interface with each other even though their network layers are distinct.
Among other things, this makes it exponentially easier to integrate these devices into local mesh networks, enabling developers and consumers alike to “have the best of both worlds” — to leverage Thread’s inbuilt IP functionality via a Zigbee device, for instance.
Effectively since its inception, the IoT has struggled to surmount the obstacles presented by excessive complexity. For consumers, this has meant prohibitively diverse smart device ecosystems, the management of which ends up being more trouble than it’s worth. For developers and device vendors, this has meant frustratingly incompatible systems architectures that undercut any attempts at broad-based interoperability.
And while the rise of Dotdot as an application layer capable of serving as the default language for not one, but two network protocols hasn’t delivered universal standardization across all IoT ecosystems, it represents an important step in the right direction. In short, Dotdot provides a shortcut to mainstream adoption for Thread devices while simultaneously extending Zigbee’s claim on application layer market share (after all, Dotdot is essentially an alliance-agnostic version of ZCL).
Perhaps most importantly, at the end of the day, not only does Dotdot give smart device developers one less thing to worry about, but it pushes us ever-closer to the realization of the potential of a fully interoperable Internet of Things.