BROWSE BY TECHNOLOGY



RTC SUPPLEMENTS


TECHNOLOGY CONNECTED

Bluetooth, Wi-Fi and ZigBee

The Internet of Things and Wireless Communication Standards

History has shown that standards wars are costly for both winners and losers alike and will be no different for the IoT. Standard wars are also costly because they delay markets developing as consumers and industries will sit back and wait until “things have settled.” The IoT is an exciting opportunity, and applications are already emerging left and right, but for mass adoption, unified standardization will be essential.

BY CEES LINKS, GREENPEAK TECHNOLOGIES

  • Page 1 of 1
    Bookmark and Share

Article Media

One of the things that is often puzzling regarding technology standardization initiatives is the fact there seem to be waves of battling and then waves of useful cooperation. The classic example is the so-called “war” between VHS and Betamax (circa 1980) that resulted in delaying the development of the home video market for quite a while. More recently (around 2007) there was another standards war, this time for optical DVD’s between Blu-ray and HD-DVD.

When you look back and analyze the results of these two technology conflicts, it is apparent that standard wars are not effective and that even the winners suffer from long delays of market acceptance and growth. The rising tide of economic activity that results from industry agreement based on uniform standards is always in sharp contrast to stalling markets when standards or pseudo “proprietary standards” compete.

Standard wars usually end when a large company or a dominating party in the market makes a choice and creates critical mass. In 1999 Apple decided to use Wi-Fi in its new laptops and, within a matter of months after that decision, HomeRF was effectively gone from the marketplace. Something similar happened with Betamax and HD-DVD, when “Hollywood” put its weight behind VHS and Blu-ray. But these types of swings in favor of one or the other usually only happen after years of stalemates and expensive mudslinging from the trenches.

What is the Internet of Things Battlefield, and who are the leading Players?

After a serious standards war there always seems to be a period of cooperation. The original DVD standard (1995) came together without a lot of fighting, probably because large companies still had vivid memories of the VHS/Betamax war and the economic loss it created. Therefore the market acceptance of the DVD was stunningly fast and videotapes disappeared almost overnight. Figure 1 shows an overview of the most important contenders around the IoT Wireless Communication Standards.

Figure 1
Overview of the different IoT wireless communication standards mapped on the ISO layering model.

For reason of simplicity I have left out the cellular standards, although they do play an important role in the IoT (and the so-called M2M business) as well. However, any contention amongst these standards is a separate chapter. I also left out RFID, also very useful for the IoT for security purposes, but less contentious as it is more like an electronic bar code replacement instead ofdoing real (two-way) communication. Also for simplicity I have left out the proprietary pseudo standards like ANT+, Z-Wave and EnOcean, for the simple reason that like other “non-standard” proprietary standards, I expect they will disappear in a few years.

Therefore, the battlefield 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”) and (3) the Application Layer (“who is doing what to whom”).

The Physical/Link Layer

There have been several critical Physical/Link Layer (Figure 2) battles in our industry. In 1999 Bluetooth (Bluetooth SIG) was fighting Wi-Fi (IEEE 802.11). That ended when both found their own solid application space and were able to retrench for maybe a next round (Wi-Fi Direct attacking Bluetooth). In the 1990’s Ethernet (IEEE 802.3) was fighting with Token Ring (IBM) and ARCnet (Datapoint). So, with IEEE 802.15.4 becoming dominant in the low-power networking market, there is no surprise that two alternatives,  Wi-Fi (with “low power Wi-Fi”) and Bluetooth (with Bluetooth Low Energy) are both sharpening the knives to get a piece of the action as well.

Figure 2
The Physical Link Layer.intensive systems with limited power consumption.

But it is fair to say that in this layer, the open worldwide standards—mostly IEEE based—are dominating, and actually there is not so much a war anymore, as most of the contentions are being resolved within standardization bodies.

Even though the three major IEEE-based standards are still competing to capture  as large as possible application domain, all three – IEEE 802.11/Wi-Fi (content sharing and distribution), 802.15.4/ZigBee (low power sense & control networking) and Bluetooth (wearables) – seem to have found their core application space and will be with us for quite a long time to come.

The Network/Transport Layer

There have also been some important Network/Transport layer battles in the past. This is a somewhat more obscure area that once was dominated by companies like LAN Manager (IBM, Microsoft), Netware (Novell) and a few others until this field was “democratized” by the Internet Engineering Task Force (IETF) with TCP/IP, that we know as today’s IPv4 or the more recentIPv6, 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 (Figure 3).

Figure 3
The Network/Transport Layer

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 space. ZigBee PRO and Thread (based on the same IEEE 82.15.4 Physical/Link Layer) have certain advantages over each other. Supporting IPv6, Thread is well integrated in the IP world. In contrast, ZigBee is already widely adopted, integrated with a really 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.

At this moment the Google/Nest Thread Alliance is trying to rally as many members in order to build momentum, but the uptake has been relatively slow: less than 100 members so far, where ZigBee has more than 400 members. Interestingly, many of these Thread members are also ZigBee members! Until the Thread standard is published, the situation will continue to be unclear, and as indicated earlier, creates a wait-and-see attitude in the IoT market, unfortunately slowing down its development.

To make the situation even more confusing, there is also another party in this space trying to enter this war at the Network/Transport Layer. In the Bluetooth SiG there is a serious effort to make Bluetooth “networking capable”. In other words, Bluetooth is trying to enable its networking layer to support not only a set of “wearables” around a single device, but also to extend this to a larger set of independent devices working together in a mesh network. Although completion is not expected before 2017, it will further muddy up the water.

The question also is whether Bluetooth Mesh is 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 miserably in 2001, because overcoming “latency” was too serious a challenge for connection-oriented protocols. At this moment the main differentiator of Bluetooth meshing seems to be the Bluetooth logo.

To many people, this new Bluetooth initiative sounds like a repeat of an earlier effort (around 1997-2000) of Bluetooth to displace Wi-Fi by adding networking features: “Bluetooth will wipe Wi-Fi from the face of the earth”, was the slogan that time. As we all know: that project to replace Wi-Fi failed miserably. At this moment, Bluetooth Mesh looks more like an effort driven by engineers searching for an interesting project than fulfilling an unresolved need of the market. This new effort may soon dissipate, just as Bluetooth previously stopped competing with Wi-Fi.

The Application Layer

To really understand the battling at the Application Layer (Figure 4) it is probably good to look at the picture again but instead of looking horizontally, it is better now to take a vertical view to understand what is going on in this space.

Figure 4
The Application Layer

The Application Layer is the collection of commands and expected results of devices (“things”) communicating with each other. It is the most complex layer, because it covers so many different devices in so many different applications over such a wide range, that at this moment it is hard to see what the real requirements will end up being.

Smart systems for the home are totally different compared to smart systems for buildings, or for smart cities (managing streetlights or parking garage vacancies), while industrial sensors are a separate class on their own. It is no surprise that the Application Layer is vast and diverse. And there is also a lot of continuing learning going on in this layer as well, including interfacing with the cloud, analytics, social media, smart phone apps, etc.

The first and most mature contender in this space is the so-called “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. batteryless) 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-out security and ease of installation features. Today, it has by far the largest installed base of vendors.

The next contender is Apple Home Kit. It is a contender and not so much a standard because Apple Home Kit is proprietary to Apple. Nevertheless, because of Apple’s strong market presence and “following”, 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. 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.

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 – for a preference for Wi-Fi and Bluetooth as well, with 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 last contributor in this field 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 they quickly realized 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 too daunting a 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 initiatives to fill in the Application Layer.

To start with, there is quite an overlap in membership between these Application Layer contenders, even to the point that not only does the market, but also some of these participating companies seem to be 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 overlaps, these different frameworks also have slightly different focus 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 not surprisingly, builds this framework as an extension of the smartphone – using the smartphone as the center of the eco-system. Now, this plays very well for wearables (smartphone “accessories”), but how this for instance would play in the Smart Home still remains to be seen. Nevertheless, both with the market success of the Apple Phone and the fact that Apple is a product company, Home Kit may be with us for quite some time to come.

The OIC/IoTivity and AllSeen/AllJoyn activities 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 started by/driven by chip companies – contrary to Apple Home Kit. The question is whether they will continue separately in the longer term because both have a relationship with the Linux Foundation.

Merging the two together 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 can “benefit” from the larger framework perspective brought via Wi-Fi and Bluetooth, as this Cluster Library can run over Wi-Fi and Bluetooth alike.

An interesting last observation is that Google/Nest is completely absent from this Application Layer, and therefore (theoretically) could work with any of the other already defined application layers. However, the consequence of this absence is that Thread is not a complete standard and that on its own it will not enable interoperable products. Once the Thread standard is released it still 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 make it into a “complete” standard, or into a standard at all….

So, is this going to be real war 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.

GreenPeak
San Ramon, CA
(925) 230-6844
www.greenpeak.com