Delving deeper into dotdot -- ZigBee's new 'Universal Language for the IoT'
The ZigBee Alliance recently announced a new "Universal Language for the IoT," and -- in an arguably brilliant and daring display of marketing moxie -- they've named it dotdot. As a long-time observer (and sometime partaker) of the IoT hype cycle, I wasn't too surprised to see "yet another" standard being promoted.
We've all become accustomed to a seemingly unending stream of new protocols, initiatives, and alliances, all aiming to usher in the era of ubiquitous sensing and control. You know -- the IoT we've all been waiting for, with tens of billions of devices! For over 10 years now, ZigBee has been a prominent player in the IoT standards game. As the ZigBee family of specifications evolved through numerous revisions, I would from time to time quip: "Nobody really knows what technology will ultimately win in the IoT, but whatever it is they'll call it ZigBee!" So, what's with the new name? Let's delve a bit deeper into dotdot and explore what's really happening here.
Application layer interoperability
Head over to Zigbee's dotdot promo website, and you'll soon learn that it's all about the application layer. That is to say, dotdot comprises the "upper" layer of ZigBee's technology stack -- the part that defines the objects and actions. Consider, for example, how an interoperable digital light switch would talk to a light. Some "smart lighting" devices might support only simple on/off control, while others may also include dimming, color, power measurement, etc. Defining those attributes and interactions is key to interoperability. Without a common application layer specification, even devices with connectivity can't interoperate. Consider sending an email to a colleague: irrespective of whether you're on the same LAN or connected via multiple intermediate networks (Wi-Fi, GSM, fiber, etc.), the fact that you're using the same application layer protocol (SMTP -- email) makes the messaging work.
(Source: ZigBee Alliance)
The important thing that's going on here is the separation of these application layer definitions from the networking and physical-layer connectivity concerns. Prior to this, having a "ZigBee Certified Product" meant that it complied at the application layer and at the ZigBee network and physical layers. Now, there is the possibility of having dotdot-compliant devices that are compatible at the application layer but with differing physical layers.
Let's get physical -- Connecting the "things"
ZigBee has long been associated with its 2.4 GHz IEEE 802.15.4-based network stack, now called "ZigBee PRO." In 2013, they added "ZigBee IP" as an option. This is based on 6LoWPAN and aimed at the smart-grid market. And then there's "ZigBee RF4CE," and... But this is not just a case of ZigBee being fickle; the rest of the world doesn't seem to be satisfied to converge on a common connectivity standard for IoT either. Pick up your smartphone and you're holding a device with Wi-Fi, Bluetooth, and Cellular radios. All three of these radio types are often used for connectivity in IoT applications. The IEEEE802.15.4 market is growing both in 2.4 GHz and sub-GHz implementations, and there are proprietary as well as emerging standards like Thread competing with ZigBee to provide IoT connectivity.
By now, you'd think we'd have settled on a common connectivity layer for IoT devices. Is this just a bad case of "not invented here" syndrome? Maybe a little, but -- in fact -- there are some technical factors that have posed quite a challenge to finding a common interoperable solution to connectivity. It comes down to tradeoffs among cost, radio range, data rate, and power consumption. Throw in global compliance concerns and antenna size for good measure, and you can see the difficulty in finding a one-size-fits-all answer. So, what's an "IoT Standards" alliance to do? We already know the answer: head for the high ground -- to the application layer where everything is software and the laws of physics don't apply!
ZigBee's magnificent cluster
A very impressive accomplishment that ZigBee has achieved over the past 10 years is to amass a large collection of "Application Profiles." This catalog of objects and attributes covers a broad range of industries and device types. Download the ZigBee Cluster Library (ZCL) specification, and you'll find a very fine-grained breakdown of device attributes across a wide variety of application areas. The usual suspects like lighting and HVAC are here, but also voice, text-chat, and a long list of generic as well as industry-specific sensing and control interfaces. Following our "smart lighting" example, basic control functions would fall under the General.Basic cluster, which provides On/Off and Level control clusters respectively, as illustrated below. Many additional lighting-specific clusters are also defined for advanced features such as color temperature and ballast configuration.
(Source: ZigBee Alliance)
The ZCL is mature and comprehensive, representing years of work defining and cataloging how "things" will interoperate. Decoupling this standards specification from the connectivity layer makes sense, and that's exactly what dotdot represents.
Begun, the application layer war has: Alliance vs. Foundation
While the ZCL legacy of dotdot gives ZigBee a substantial head-start in defining the application layer, with the fate of billions of devices at stake and the IoT hype-cycle in full swing, the ZigBee Alliance is not alone in this game. For example, do you remember Universal Plug and Play (UPnP)? Back in 2013, the UPnP Forum re-branded their Sensor Management services as the IoT Management and Control Architecture. Check out their interoperability diagram below -- this certainly crossed over into ZigBee territory when it was published.
(Source: Open Connectivity Forum)
Similar efforts at application layer standardization were underway in the Allseen Alliance, led by Microsoft and Qualcomm. Separately, at that time, we had Intel, Broadcom, and Samsung leading the Open Interconnect Consortium (OIC) to establish the standards for how the IoT interoperates. All these competing camps with overlapping standards call to mind a favorite quote that's still relevant 30 years after it was published in Tannenbaum's Computer Networks text:
"The nice thing about standards is that you have so many to choose from; furthermore, if you do not like any of them, you can just wait for next year's model." -- Andrew Tanenbaum
Last year, things got even more interesting, with rapid consolidation among these players. Here's a breakdown of the action in 2016:
- January 2016: The Open Interconnect Consortium (OIC) acquired the assets of the UPnP Forum.
- February 2016: The OIC changes its name to the Open Connectivity Foundation (OCF).
- October 2016: The Allseen Alliance merges with the OCF.
So now we have the Open Connectivity Foundation (OCF), which is well-positioned to promote their IoT vision. It's like Star Wars with the Alliance (ZigBee) facing off against the Foundation (OCF) in an epic battle to control the universe (the "Things")!
Show me your clusters!
In contrast to Zigbee's Britannica model, with committees deliberating for years in hallowed halls to catalog all the possible application interactions, you might say OCF is taking more of a Wikipedia approach.
OCF's oneIoTa is an online data modeling tool that provides both a catalog of device models and a forum for the crowd-sourced development of new ones. Let's stay with our simple lighting example and see what OCF has to offer.
As you'll see, at present, oneIoTa's level of comprehensiveness and detail is not on par with ZCL. However, through the sponsorship of the open source software project, IoTivity, the OCF appears to be pursuing a strategy to grow a user base that will flesh it out quickly as real-world applications are fielded.
Naturally, Google, Apple, and Amazon all have their respective IoT initiatives. From an application layer standardization perspective, Google's Weave project stands out. The Weave developer site presents a few "Device Schemas," including an HVAC Controller and a Light Device. There's not much content there yet, but the fact that they're starting to define schemas puts them in the game.
What about Bluetooth?
At the consumer level, Bluetooth-enabled devices are the most prevalent example of application layer interoperability among "Things" (if we define a "Thing" as a highly-constrained device -- say a microcontroller with just a few kbytes of RAM).
Bluetooth has its own set of application layer profiles that currently revolve around the familiar "peripheral" roles traditionally fulfilled by Bluetooth classic (headsets, speakers, mice) and Bluetooth Smart (fitness trackers, etc.). While there are Bluetooth Low Energy (BLE)-controlled lighting products on the market today, there is no standardized application layer protocol to provide multivendor interoperability. But Bluetooth Mesh is due out any day now, gunning for the same IoT network use-cases as Thread and ZigBee, and with it will surely come an expanded set of standard application profiles including lighting, HVAC, etc.
Layers and logos
Zigbee has begun to demonstrate dotdot's interoperability across different connectivity stacks, with an initial demonstration of Thread-based devices using dotdot at CES 2017. Conceivably, then, a consumer could have Thread devices interoperating with Zigbee devices at the application layer -- even though they don't use the same connectivity technology. In practice, achieving this would require some sort of gateway device(s) at the TCP/IP level to adapt dotdot to each connectivity layer being used. This pattern of "protocol convergence at the TCP/IP level" is a common theme of application layers.
An interesting consequence of separating the application layer interoperability from the connectivity layer is "logo confusion." For example, our hypothetical smart-lighting product would need two certifications: one for "Thread Certified Component" and another for "dotdot." If we expect a light switch to communicate directly with a light fixture, we'd have to look for both logos to match. It remains to be seen whether or not this "dual logo" situation will totally confound the market.
So, where is all of this going?
Imagine how difficult it must have been for Tim Berners-Lee and the rest of the Internet pioneers to painstakingly catalog and codify all the application protocols we use today. Facebook, Twitter, YouTube... Did they think of everything back then? Of course not. No one could have anticipated all of the useful applications that have evolved through the years (not to mention the popular but utterly useless ones!). The Internet as we know it today evolved by virtue of programmable devices that dynamically adapt via software -- "apps," if you will.
Looking just a few years into the future, will Britannica win, or will Wikipedia emerge triumphant? Or will you just download the latest apps to control your "Things"? Your smart lighting application may be connected, but will it be using Twitter or Facebook for its posts and status messages?
For the present, we don't have an "app ecosystem" for "Things," and it may be some years until that's feasible with low-cost, low-power devices. Each of the application layer specifications (dotdot, oneIoTa, Weave, and others) has its strengths and weaknesses, which we as designers must consider carefully as we develop new IoT products.
David Ewing has a 25-year track record of innovative product development and commercial success with technology startups in the electronics, software, communications, and IoT sectors, and he holds more than 20 patents. Joining telecom startup ADTRAN in 1992, David helped launch the company to IPO in 1994. Following that, David led engineering teams at DiscoveryCom, Nokia, and Teracruz. Most recently, as part of the founding team of IoT startup Synapse Wireless, David was CTO and the principle architect of its core technology, SNAP -- creating software and wireless hardware modules as well as development tools for microcontrollers. David currently serves as President of Firia, Inc., an IoT focused design firm helping companies achieve their product development goals through software and hardware consulting services.