For the sake of argument and to keep it simple, I have left out the cellular standards, although we do recognize that they do play an important role in the IoT (and the so-called M2M business). I also left out RFID, which can be quite useful for the IoT for security purposes, but is less contentious as it is more an electronic bar code replacement instead of doing real (two-way) communication as such.
Also for simplicity we have left out the proprietary pseudo standards like ANT+, Z-Wave and EnOcean, for the simple reason that, like other “non-standard” proprietary standards, in the long run, they will not be able to survive against industry accepted international standards.
These IoT connectivity solutions can be split up into three horizontal (combinations of) layers:
1. the Physical/Link Layer (“the connector”)
2. the Network/Transport Layer (“the wireless cable”)
3. the Application Layer (“who is doing what to whom”)
The Physical/Link Layer
Within the last few decades, we have witnessed several critical Physical/Link Layer battles.
In the 1990’s Ethernet (IEEE 802.3) was fighting with Token Ring (IBM) and ARCnet (Datapoint). In 1999 Bluetooth (Bluetooth SIG) started battling with WiFi (IEEE 802.11). That ended when both found their own solid application space and were able to retrench for maybe a next round (WiFi Direct attacking Bluetooth).
Even though the three major IEEE based standards are competing to capture as large as possible application domain, all three seem to have found a core application space and will be around for quite a while – IEEE 802.11/WiFi for content sharing and distribution, 802.15.4/ZigBee for low power sense & control networking, and Bluetooth for cable replacement and wearables.
The battle has moved to the low power sector. With IEEE 802.15.4 (ZigBee) now becoming dominant in the low-power networking market, there is no surprise that two new low power IEEE-based alternatives, WiFi (with “low power WiFi”) and Bluetooth (with Bluetooth Low Energy) are both trying to enter this market to get a piece of the action.
The Network/Transport Layer
In the past, there have also been some interesting battles at the Network/Transport Layer. This somewhat more obscure area was once dominated by companies like LAN Manager (IBM, Microsoft), Netware (Novell) and a few others until this field was “democratized” by the IETF with TCP/IP, that today we know as s IPv4 or the more recent IPv6, the IETF contribution to the IoT.
The IETF also has produced a standard that is called 6LoWPAN (IPv6 over Wireless Personal Area Networks), essentially allowing IPv6 traffic to be carried over low power wireless mesh networks.
Recently Google/Nest has adopted 6LowPAN as part of Thread, giving it instant credibility and putting it in direct competition with ZigBee PRO, another contender for this low power data space. ZigBee PRO and Thread (based on the same IEEE 82.15.4 Physical/Link Layer) have certain competitive advantages over each other. Supporting IPv6, Thread is well integrated in the IP world. In contrast, ZigBee is already widely adopted, integrated with a broad and thoroughly tested application library (see below), and with proven security and ease of use features, while also very capable of bridging into IPv6. Until the Thread standard is published in Q2 of 2015, the situation will continue to be unclear, and as indicated earlier, establishes a wait-and-see attitude in the IoT market, unfortunately slowing down its development.
Adding to the confusion, there is yet another party in this space now trying to enter this conflict at the Network/Transport Layer. The Bluetooth SiG has announced an initiative to make Bluetooth “networking capable”. In other words, Bluetooth is trying to enable its networking layer to not only connect a set of “wearables” around a single device, but also to extend this connectivity to a larger set of independent devices working together in a mesh network. Although completion is not expected before 2017, this initiative will further muddy up the water for IoT and Smart Home device developers.
However, here is the really important question: is Bluetooth Mesh technically possible?
Bluetooth, like WiFi, is “connection oriented”, while IEEE 802.15 for ZigBee and Thread is packet oriented, which is very suitable for meshing protocols. WiFi meshing (under IEEE 802.11s) failed miserably in 2001, because overcoming “latency” was a too serious challenge for connection oriented protocols. At this moment the main differentiator of Bluetooth meshing seems to be the Bluetooth logo.
At this moment, to us, Bluetooth Mesh looks more like an effort driven by engineers searching for an interesting project than a solution that can successfully fulfill a need of the market. We expect that this new Bluetooth Mesh effort may soon just disappear, just as Bluetooth previously stopped competing with WiFi.
The Application Layer
To understand the battling at the Application Layer, instead of looking horizontally at the above illustration, it is better to now take a vertical view to understand what is going on in this space.
The Application Layer is the collection of commands and expected results of devices (“things”) that can communicate with each other AND is the most complex layer. Because it covers so many different devices in so many different applications over such a wide range, at this moment in time it is hard to see what the real requirements will end up being.
The first and most mature contender in this Application Layer space is the so-called ZigBee “Cluster Library” that is a part of the ZigBee standard (ZCL). In the ZigBee 3.0 version, this Cluster Library is completely integrated – including the so-called application profiles of Home Automation and Lighting, supplemented by Green Power for ultra-low power (e.g. battery-less) applications, and ZRC for ultra-low latency applications as required for Remote Controls. This ZigBee Cluster Library is very complete and includes very well thought security and ease of installation features. In addition, today it has by far the largest installed base of vendors.
Apple Home Kit is a very important and quite interesting contender for this space. It not really a standard because Apple Home Kit is, like everything else from Apple, proprietary. However, because of Apple’s strong market presence and “following”, despite not being a standard, Apple Home Kit is developing a clear market presence with applications built on top of WiFi and Bluetooth for networking and low power wearables. Today, Home Kit is not integrated with IEEE 802.15, but it does contain the bridging capabilities to integrate with ZigBee and the ZigBee Cluster Library.
Home Kit looks to be a strong contender that could successfully exist in its own proprietary universe in parallel with standards based solutions.
The third player in this Application Layer field is the Open Interconnect Consortium driven by Intel and supported by others like Cisco and Samsung. This is a group that recently started their activities and has expressed – like Apple – a preference for WiFi and Bluetooth as well as future plans for ZigBee. It has announced IoTivity, an Open Source Project under the Linux Foundation that helps perform Application Layer device identification on the network.
The fourth contender in this space is the AllSeen Alliance, which interestingly enough, also operates under the umbrella of the Linux Foundation. Their work originally started as the AllJoyn activity under Qualcomm, but Qualcomm quickly realized that the market is too large, too diversified and too dependent on the development of a complete eco-systems, and that pulling this off alone would be an overly daunting task. As a result, Qualcomm has donated all the work done until that time to this AllSeen Alliance that they still continue to chair, but that is further an independent activity.
Some observations can be made about all these competing initiatives in this Application Layer.
First, there is quite an overlap in membership between these Application Layer contenders, even to the point that not only is the market, but also some of these participating companies seem confused as well. For instance, many of the 400+ ZigBee members are also members of the OIC and the AllSeen Alliance, bridging the gaps in between. In addition to these business and market overlaps, these different frameworks also have slightly different focuses and are partially complementary.
The ZigBee Cluster Library is very focused on describing the functionality of the simple devices (lamps, thermostats, etc.) and as such it is very complete and has matured over years.
Apple’s Home Kit is focused on presenting the devices to the user (per house, per room, etc.) and builds this framework as an extension of the smart phone – using the iPhone as the center of the eco-system. Now, this works very well for wearables (smart phones “accessories”), but how this will play in the Smart Home still needs to be seen. Nevertheless, with the market success of the Apple iPhone, the fact that Apple is a product company, and finally, that many Apple customers swear strong allegiance to Apple eco-system products, Home Kit may be with us for quite some time to come.
The AllSeen/AllJoyn and OIC/IoTivity initiatives are probably the most overlapping. Both are focused on special features for discovery of the devices on the network and finding out how these devices communicate, which puts them on an immediate competitive path. Both of them were started by/driven by chip companies – contrary to Apple Home Kit. The question is whether on the longer term they will continue separately because both have a relationship with the Linux Foundation.
Merging the two together, along with the ZigBee Cluster Library, might be a possible way to go, enabling them to stay competitive with the Apple “proprietary” Home Kit. Embracing the ZigBee Cluster Library, to make use of its maturity and years of real-use hardening, would make sense for any of these frameworks, while the ZigBee Cluster Library itself can “benefit” from the larger framework perspective brought via WiFi and Bluetooth, as this Cluster Library can run over WiFi and Bluetooth alike, as well as ZigBee.
What about Google and Nest? Interestingly, Google/Nest is completely absent from this Application Layer, and theoretically could work with ANY of the other already defined application layers. However, because it does not play in the application layer, Thread is therefore not a complete standard and on its own, it will not enable interoperable products. Once the Thread standard is released, it will require integration with an Application Layer of some sort. Again it makes sense for Thread to also embrace the ZigBee Cluster Library as only then it would it actually evolve into a “complete” standard, or into a standard at all.
IoT Connectivity – Take Aways for Developers
IEEE 802.15.4 (2.4 GHz) is now generally adopted as the Physical/Link Layer standard for low power sense and control networks, along with WiFi for content distribution networks, and Bluetooth for wearables.
There is a potential war brewing at the Network/Transport Layer, where Google/Nest is trying to set the standard openly challenging the incumbent standardization body (the ZigBee Alliance). After having done the ground work, they have reformatted themselves into an open body (the Thread Alliance). However, despite the hype and the industry politics, the Thread standard itself is incomplete and needs extending to be meaningful in the market.
At the Application Layer, there is significant confusion and ongoing technology development required. Apple, Google/Nest, Intel, Qualcomm are trying to define standards and/or “provide leadership”. They are partially competing with the ZigBee Alliance, and at the same time, are partially complementary.
The ZigBee Cluster Library is the only well developed and market proven Application Layer implementation that makes sense for any of the competing Application Layer frameworks. Embracing it can make the difference in the market acceptance for each of them.
Both IEEE 802.11ah (low-power WiFi for the MAC/PHY Layer) as well as Bluetooth Mesh (for the Network Layer) are late to market (2017 at the earliest) and most likely will turn out to be irrelevant.
What does the future hold? Is this going to be a real industry battle or is there going to be reconciliation?
Hopefully for all the companies that are looking forward to reap the benefits of the IoT, it is going to be the latter. The sooner this complex material is sorted out, the better it will be for everyone – the big companies holding the leads, the service providers who need a technology that they can rely on worldwide, as well as the myriad of device and system developers who are aching to get into this sector, but still unsure of which connectivity technology to embrace.