In 2013, three engineers—a stack vendor and two competing door lock manufacturers—sat in a windowless conference room in Boston. They were there to come to an agreement on building their IoT devices. Both manufacturers had their own special sauce for their door locks, and both wanted to work in the Zigbee ecosystem and have their products communicate in the same way. This meeting of the minds was a somewhat contentious process, but over the course of several days, these engineers came to an agreement that would become the Door Lock Cluster in the Zigbee Cluster Library (ZCL).
At the application layer, Zigbee provides a standardized communication protocol through entities called “clusters.” Clusters define what commands a device can send or receive, and what pieces of data or attributes a device cares about. The Door Lock Cluster defines everything from how a door is locked and unlocked to schedules and pin codes for the lock. Thus, at the absolute top of the Zigbee protocol stack, a door lock has a very specific and standardized way that it communicates with the rest of the Zigbee network and the outside world.
This may seem like a boring and simple anecdote, but the important thing to note is that the work these engineers performed has been replicated within Zigbee literally hundreds of times. Over the course of the last 10 years, the member companies of Zigbee have built up the ZCL, covering the application functionality of everything from lights to window sensors, from thermostats to smart meters. This is the heart of the ZCL, and it’s the real value that Zigbee brings to the table when being ported over other network transports.
In the Internet of Things, every smart device has to understand and speak the same language at the application layer. How else is a smart hub expected to know how to communicate and control an off-the-shelf door lock or thermostat? Without a common application layer, it really doesn’t matter how well the networking layers perform. This is the one crucial element that IoT network standards lack, and it’s the core value of porting the ZCL into a universal, standalone application language, an effort that Zigbee has named Dotdot.
Dotdot is a universal, standard application language for smart devices to communicate over any network.
The Reason for Thread: An IP-Friendly Networking Layer
The Thread networking protocol uses 6LoWPAN, a compressed form of IPv6. This enables Thread devices to interact directly with other IP devices without having to pass through a gateway as they would in Zigbee 3.0. The border router on the Thread network acts as a pass-through for IPv6 traffic bound for the cloud and vice versa. As a result, devices that are on the Thread network can interact directly with other IP devices.
The Reason for Dotdot: An IP-Friendly Application Layer
Dotdot uses common, IP-friendly protocol specifications defined by the Internet Engineering Task Force (IETF), such as the Constrained Application Protocol (CoAP) and the Concise Binary Object Representation (CBOR). As a result, open libraries are available for developing an application implementation, greatly speeding the process of device development.
A Combined, Higher Level of Security
Dotdot over Thread (see figure) requires the use of Datagram Transport Layer Security or DTLS. This enables devices on the Thread network to ensure that they’re not only talking to a trusted device, but also that their communication is secure.
Dotdot is the application layer that runs over the Thread network protocol.
In addition to the use of DTLS, Dotdot also requires the use of Authentication and Authorization for Constrained Environments (ACE), commonly referred to as Access Control. Access Control allows a provisioning device to specify exactly what resources are available on a device, so that even though a thermostat may share a DTLS connection with a door lock, it can’t directly control a lock unless it’s given the proper access privileges.
To date, product developers have had to choose between technologies that either a) support reliable, local, device-to-device interoperability, but often strand products (and their data) behind third-party gateways, or b) connect those products directly to the internet, introducing reliability, interoperability, and user-experience challenges to connect products together in useful ways.
Dotdot over Thread provides a best-of-both-worlds solution.
Device-to-Device Communication
The Zigbee Cluster Library was built and optimized for device-to-device communication over low-power and lossy networks, and with battery-operated devices in mind. This means the messaging is compact, with most fitting in a single 127-byte 802.15.4 packet. In addition, messaging patterns are based on minimizing communications and unnecessary “chatter” between devices, and battery-operated devices initiate much of their communication since they can’t receive reliably when asleep.
The development of Dotdot has kept these basic principles and lessons from the ZCL to ensure it’s also suitable for these low-power and lossy networks while transitioning to known IP-friendly protocols.
Networking Directly to the Cloud
The use of Thread obviates the need for a gateway on the mesh network, which directly understands how to talk to each device. With the use of a common Thread border router, it’s possible to create a DTLS connection from anywhere on the internet to a device on the local mesh network and securely communicate with that device. This allows the “brains” of the IoT system to be in the cloud and communicate directly with devices on the network without having to worry about the version of the firmware on a gateway.
The Thread border router acts as a pass-through; therefore, it doesn’t need to have its firmware updated as the composition of the mesh network changes and new devices are added or upgraded. This means that it’s possible to do something complex such as update the firmware of a device on mesh directly from the cloud over a secure communication channel, greatly simplifying the management of mesh devices.
Dotdot-to-Zigbee Communications
Because Dotdot is derived from the ZCL, it’s straightforward to use a gateway to translate between the two. This is critical as it means new Dotdot devices can be seamlessly bridged to existing Zigbee devices, ensuring a smooth user experience and interoperability. It also means existing Zigbee devices can be bridged to the cloud using Dotdot and the IP-friendly protocols, simplifying the remote device control and management.
Dotdot Certification Program
Zigbee has been certifying application-layer functionality for 10 years (the ZCL). The Zigbee Alliance is also developing an automated test environment for Dotdot. This test environment ensures Zigbee and its members will be able to certify Dotdot devices and their application-layer functionality, as well as ensures devices from a diverse group of vendors will interoperate on the same mesh network. When you choose Dotdot as the application layer for your IoT devices, you have the benefits of a robust and proven certification program behind you.
Dotdot Over Other IP Networks
While the initial focus is Dotdot over Thread, it’s relatively simple to extend to other IP networks. Dotdot is based on IP-friendly protocols and IPv6, so usage can easily be extended to Wi-Fi or Ethernet. For transports like Bluetooth that don’t natively support IPv6 or IP protocols, some adaptation can be expected.
Ezra Hale is a Software Engineering Manager at Silicon Labs and Chairman of the Zigbee Alliance’s Mesh IP Technical Subcommittee.
