March 2015 |
[an error occurred while processing this directive] |
Wireless Communication Standards for the Internet of Things White Paper |
|
Articles |
Interviews |
Releases |
New Products |
Reviews |
[an error occurred while processing this directive] |
Editorial |
Events |
Sponsors |
Site Search |
Newsletters |
[an error occurred while processing this directive] |
Archives |
Past Issues |
Home |
Editors |
eDucation |
[an error occurred while processing this directive] |
Training |
Links |
Software |
Subscribe |
[an error occurred while processing this directive] |
This white paper provides an overview of the most important contenders around the IoT Wireless Communication Standards. We are looking at wireless networking technologies.
Overview of the different IoT wireless communication standards (mapped on the ISO layering model)
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:
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 802.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 is 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.
[an error occurred while processing this directive] 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
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.
About the Author
Cees Links is the Founder and CEO of GreenPeak Technologies
Cees [“case”] Links is a pioneer of the wireless data industry, a visionary leader bringing the world of mobile computing and continuous networking together. Under his responsibility, the first wireless LANs were developed which ultimately became house-hold technology integrated into the PCs and notebooks we are all familiar with. He also pioneered the development of access points, home networking routers and hotspot base stations, all widely used today.
In late 2004 Cees started with GreenPeak Technologies (originally under the stealth name of Xanadu Wireless). GreenPeak is a fabless semiconductor company with a strong focus on wireless for sense and control networks in combination with battery-less technology, targeting communication devices working on ambient energy. Cees’ vision is to “build a smarter world” by developing a communications platform between devices sensing and enabling us to control our lives.
Cees started his career at NCR Computers where he was responsible for the development and launch of the world’s first wireless LAN product in 1990, a major innovation at that time. Throughout several acquisitions and divestitures (NCT, AT&T, Lucent Technologies and Agere Systems), Cees continued his work in the wireless LAN area, which he turned into a multi-hundreds million dollar business for Agere Systems. He directly closed a deal with Apple Computer in 1999 that ignited the growth of the wireless LAN industry. Though this deal, wireless LANs went on to become a standard notebook feature.
Cees was involved in the establishment of the IEEE 802.11 standardization committee and the Wi-Fi Alliance. He was also instrumental in helping to establish the IEEE 802.15 standardization committee to become the basis for the ZigBee sense and control networking technology and standardization.
Cees
Links holds a Masters degree in Applied Mathematics and a Bachelor of
Electrical Engineering from the Twente University of Technology in
Enschede, The Netherlands.
[an error occurred while processing this directive]
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]