Wireless communication standards for the IoT
20 March 2015
Cees Links, GreenPeak Technologies, provides an overview on some of the most important contenders around the IoT wireless communication standards and looks closely at wireless networking technologies.
IoT connectivity solutions can be split up into three combinations of layers. One being the physical/link layer (the connector), two the network/transport layer (the wireless cable) and third the application layer (who is doing what to whom).
The physical/link layer
Within the last few decades, there have been several critical physical/link layer battles.
Ethernet (IEEE 802.3) has had battles with Token Ring (IBM) and ARCnet (Datapoint) and Bluetooth (Bluetooth SIG) started battling with Wi-Fi (IEEE 802.11). That ended when both found their own solid application space and were able to retrench.
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. IEEE 802.11/Wi-Fi has claimed 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, Wi-Fi (with “low power Wi-Fi”) and Bluetooth (with Bluetooth Low Energy) are both trying to enter this market.
The network/transport layer
This area was once dominated by companies like LAN Manager (IBM, Microsoft), Netware (Novell) and a few others until this field was “democratised” by the IETF with TCP/IP, known today as 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. ZigBee PRO and Thread 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 and with proven security and ease of use, 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 establishes a wait-and-see attitude in the IoT market, unfortunately slowing down its development.
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, is Bluetooth Mesh technically possible? Bluetooth, like Wi-Fi, is “connection oriented”, while IEEE 802.15 for ZigBee and Thread is packet oriented, which is very suitable for meshing protocols. Wi-Fi meshing (under IEEE 802.11s) failed 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, some argue that 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. It is expected that this new Bluetooth Mesh effort may soon disappear, just as Bluetooth previously stopped competing with Wi-Fi.
The application layer
The application layer, the most complex, is the collection of commands and expected results of devices that can communicate with each other. As it covers many different devices in different applications over a wide range, 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 ZigBee “Cluster Library” that is part of the ZigBee standard (ZCL). In the ZigBee 3.0 version, this Cluster Library is completely integrated – including the application profiles of Home Automation and Lighting, supplemented by Green Power for ultra-low power applications, and ZRC for ultra-low latency applications as required for Remote Controls. This ZigBee Cluster Library is complete and includes well thought security and ease of installation features. In addition, it has one of the largest installed base of vendors.
Apple Home Kit is an interesting contender for this space. Due to Apple’s strong market presence, despite not being a standard, Apple Home Kit is developing a clear market presence with applications built on top of Wi-Fi and Bluetooth for networking and low power wearables. 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 Wi-Fi 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 also operates under the umbrella of the Linux Foundation. Work originally started as the AllJoyn activity under Qualcomm, but Qualcomm quickly realised that the market is too large, too diversified and too dependent on the development of a complete eco-system, and that pulling this off alone would be an overly daunting task. As a result, Qualcomm has donated all the work to AllSeen Alliance.
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 appearing confused. 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, the frameworks also have slightly different focuses and are partially complementary.
The ZigBee Cluster Library is focused on describing the functionality of the simple devices 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 and builds this framework as an extension of the smart phone – using the iPhone as the centre of the eco-system. This works well for wearables 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 have strong allegiance to Apple eco-system products, Home Kit may be with us for quite some time.
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 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 Wi-Fi and Bluetooth, as this Cluster Library can run over both, as well as ZigBee.
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 evolve into a “complete” standard.
1. IEEE 802.15.4 (2.4GHz) is now generally adopted as the physical/link layer standard for low power sense and control networks, along with Wi-Fi for content distribution networks, and Bluetooth for wearables.
2. There is a potential war brewing at the network/transport layer, where Google/Nest is trying to set the standard, openly challenging the incumbent standardisation 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.
3. 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.
4. 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.
5. Both IEEE 802.11ah (low-power Wi-Fi 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.
Hopefully, for those that are looking forward to reaping the benefits of the IoT the sooner this complex material is sorted out, the better it will be for 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 still unsure of which connectivity technology to embrace.
Contact Details and Archive...