Home arrow Blog arrow Zigbee arrow Z-Wave versus Zigbee - A Quick Intro to the Z-Wave Protocol Followed By A Biased Editorial
Z-Wave versus Zigbee - A Quick Intro to the Z-Wave Protocol Followed By A Biased Editorial | Print |
Written by Akiba   
Saturday, 29 March 2008

There's been more and more attention being focused on wireless home automation recently and the two biggest candidates for it is Zigbee and Z-Wave.

Readers of this blog probably don't need much of an introduction to Zigbee because this blog is basically about it, or at least my adventures diving into Zigbee as I write my software. You're also probably aware that there has been a lot of mudslinging (ie: shit talking) between both camps, Zigbee and Z-Wave, as well as an ongoing flame war. So in an interest to educate myself on the real issues behind the talk, I decided to do some research and comparison between Z-Wave and Zigbee. I should note that a lot of the information was just pieced together via the internet since the Z-Wave specification is not public. A lot of the material in this post borrowed heavily from the information found in this article. Since there is not a lot of technical data publicly available for Z-Wave, I recommend perusing this article in Dr. Dobbs Journal since it's an excellent introduction.

Z-Wave and the Z-Wave Alliance is a group that was established around the proprietary wireless networking protocol developed by a Danish company called Zensys. The Z-Wave protocol was designed to be a lightweight protocol for home automation that would be low cost yet still could support mesh networking.

Lets begin with a look at the device types specified by Z-Wave...

There are two types of devices: controllers and slaves. Controllers are the head honcho in the Z-Wave network. They are the only ones that can initiate transmissions, have a complete knowledge of the network, maintain the network, and control provisioning. There can only be one primary controller in the network and that one handles all of the provisioning and maintains the routing tables. All other controllers get their information from this controller. Controllers come in two different forms:
  • Portable Controller: 
    • These are like your standard remote control and are meant to be moved around the house. These are typically used to provision the node since they can be brought near the node and the "join network" button on the controller can be pushed to include the device. Since they are portable, they constantly need to ping the surrounding devices to know who their neighbors are so that they can send messages. especially since they are the only ones that can send messages.
  • Static Controllers:
    • As their name implies, these controllers are well… static. They must be at fixed locations in the network and are always on and listening.
Slaves are reactive devices. They cannot initiate any types of transmissions and they cannot contain any routing tables. There are three types of slaves:
  • Slave:
    • This is the generic slave. It cannot do any routing, and only responds to transmissions that it receives.
  • Routing Slave: 
    • Yeah, yeah. I said that slaves can't contain any routing tables. Routing slaves are assigned predefined routes from  the controller. Interestingly enough, these are called "controller-defined routes".
  • Enhanced Slaves:
    • These are slaves with extra hardware peripherals, probably using a more advanced chip from Zensys. They have software support for external EEPROMs and RTC so that they can have more functionality.

The protocol structure itself is similar to Zigbee in that it consists of four layers: PHY, MAC, Networking, and Application.

PHY Layer
The PHY layer consists of radio technology that is proprietary to Zensys. It uses either 868 MHz (Europe) or 908 MHZ (US) frequencies, both of which are ISM bands and are free for public usage. In both of these frequencies, the data rate is 40 kbps using a single channel with FSK (frequency shift keying) modulation. In their next generation chips, Zensys mentioned that they will also be supporting 2.4 GHz operation, although the details are not yet public.

MAC Layer
The MAC layer supports acknowledge and retransmissions, however they seem to be
application level ACKs and retries versus MAC level. In order to clarify that statement, Zigbee has two levels of ACKs and retries, one on the 802.15.4 MAC layer and one on the Application SubLayer. The MAC retry is part of the 802.15.4 spec and is usually hardware generated upon successful receipt of a packet and sent only to the node that directly sent the frame. The Application level ACK in Zigbee is software generated, signals successful reception and processing by the APP layer, and is sent back to the original sending node, even if it was multiple hops away.

A node is addressed by using two IDs: a home ID and a node ID. The home ID is like a PAN ID in 802.15.4 and the node ID is like a short address. The Home ID is 32-bits wide and is unique to the home, although multiple home IDs (ie: networks) can exist in the same home. The node ID is 8 bits wide. Both are assigned by the primary controller when it joins the node to the network.

There are four types of frames in Z-Wave: Unicast, Multicast, Broadcast, and ACK. All frames use a similar structure, consisting of header, payload, and checksum. They are sent using a simple collision avoidance mechanism that just listens for traffic. If traffic is detected, then it will do a random backoff and try again.

NWK Layer
The primary controller controls the routing table and builds it based on the devices that it joins to the network. Upon being joined to the network, the primary controller will request the node's neighbor list which consist of all node's within broadcast range. The primary controller uses this information to build the routing table.

The routing table is maintained as a binary bitmap. This means that it is a table with all joined device IDs on the row and column header. If a device A is part of device B's neighbor list, then there will be a 1 in row A, column B. Otherwise it will be a zero. The good thing about a binary bitmap is that it is simple and also easily compressible. Thus it requires little RAM to hold the routing table. Even if the maximum table size of 232 x 232 nodes is reached, the routing table will be what's called a sparse matrix so various methods of compression can be used on it to make it small.

In contrast, Zigbee requires a routing table entry for each routing node, which consists of the destination address (the entry just points to the first hop towards the destination), status of the route, and various other fields. There is almost no way to calculate how big your routing tables are going to be in Zigbee, since it's possible that each node in the network will require its own entry. At 65k max nodes, this is a bit daunting.

 To send the frame, the Z-Wave controller accesses its routing table and calculates a path from it to the destination. It then embeds this path into the frame and sends out the frame to the first hop in the path. The nodes then successively forward the frame based on the path embedded inside it. This method of routing is called source routing, as opposed to table-based routing methods such as AODV.

APP Layer
The application layer is responsible for decoding and executing commands in a network. It accomplishes this using command classes and application frames. Command classes are similar to Zigbee profiles. They are a group of related commands for a certain application. Some examples are: advanced light control, thermostat, or garage control. They mostly consist of GET/SET/REPORT functions.

Application frames are embedded inside the Z-Wave frames and are decoded to send commands to the application layer. These frames carry information about the command class, the command, and the command parameters.

There is also a special frame called the node information frame. It carries all the information about the node and is used for the node discovery process.

Well, that about sums up my research on Z-Wave. So what are my conclusions regarding Z-Wave versus Zigbee?

Lets start with the good:
Z-Wave is much simpler than Zigbee. Truth be damned, I cannot lie. I can already hear the Zigbee Alliance sharpening their knives. The Z-Wave protocol is actually all that you need for a home automation protocol, as long as there are no high-reliability constraints such as a medical alert system.. This simplicity allows it to be much smaller than a full Zigbee implementation, so it would require less flash and RAM than Zigbee.

Now for the bad:
The first problem is that Zensys isn't in the business of selling software, or even protocol standards. They're in the business of selling radios. Their current radio covers 868 and 908 MHZ frequencies with plans to include 2.4 GHz in the future. Uhhh…802.15.4 already covers that. Plus, IEEE 802.15.4 is accepted as a true industry standard meaning that there is an independent governing body that controls the specification. On top of that, its popularity is only increasing which means that the price will be heading downward. Pretty soon, Zensys will be competing with just about every wireless sensor protocol out. Already 6LowPAN, Synkro, MiWi, SP100, Wireless HART, and many other protocols have pledged their loyalty. In this matter, their ongoing war with Zigbee is a bit trivial since they should be concentrating their efforts on 802.15.4.

The second problem is that the Z-Wave feature set is a subset of the Zigbee features set. Yes, Zigbee is the fat pig of wireless sensor networking, however it can also be trimmed. In fact, there are a number of ways trim it to maintain compatibility. Here's one:

Its possible to have a Zigbee router that does not use routing tables yet still maintain compatibility with the spec. You just need to support tree routing for compatibility which is very inexpensive. From there, you can just implement source routing similar to Z-Wave and yes, source routing is part of the Zigbee 2006 specification. Nobody seems to know that. Getting rid of the AODV routing removes the routing tables, route discovery tables, discover route service, and the buffer queue and logic required to hold frames while their routes are being discovered. This alone is a huge savings in flash and RAM size.

I could go on and on about different ways to hack the stack and still be compatible. Why haven't other Zigbee  companies done this? Because you limit the target market by making these modifications. Currently software is deliberately general because semiconductor companies need to appeal to the broadest customer base possible. If an individual or company wanted to do this, they would need access to the source code to make the necessary cuts. Unfortunately, you rarely get access and you can't hack a binary lib file.

The third problem I have is that their protocol is proprietary. In general, it's dangerous to adopt a proprietary technology because it can disappear if anything happens to the company. The software and API is all property of Zensys and completely closed. Even if the software is in escrow, if something happens to the company, nobody will be maintaining it. Source code is overvalued because it has no use without developers supporting and maintaining it. The recent news that they just accepted another round of funding doesn't help. Companies that require more funding send out the following messages:

  1. They're not profitable. Otherwise, they'd be supporting themselves off their own revenue.
  2.  They're running low on funds. Very few companies would dilute their ownership if they didn't need the money.
  3. They don't control the direction of the company; the board does. They just accepted a loan with some very harsh terms on who calls the shots. My experience with VC funded companies is that the CEO doesn't call all the shots. A lot of his/her time is spent just fielding calls from their investors and flying around for monthly board meetings.

Anyways, that's about it for me and my opinions. Let me know if there's a mistake in this post or if you think I'm full of sh*t.

Hits: 54152
Comments (1)Add Comment
written by Brant, May 12, 2009
Excellent commentary. The it's hard to find such concise and fruitful discussions. Thanks to Peter for his defense of Z-wave, it helps. I design homes that have complex lighting, media, environmental and security systems and advise my clients on contractors that do media integration/installation. Very helpful. Thanks.
report abuse
vote down
vote up
Votes: +2

Write comment


Discuss (4 posts)
Z-Wave versus Zigbee - A Quick Intro to the Z-Wave Protocol Followed By A Biased Editorial
Jul 08 2008 20:32:22
This thread discusses the Content article: Z-Wave versus Zigbee - A Quick Intro to the Z-Wave Protocol Followed By A Biased Editorial

I have worked in embedded software development for many years and have been doing some work on these two protocols a while ago.

The comment above is not really fair to Z-Wave.

Instead of finding the weakpoints of Z-Wave it's far more important to find the strengths.

One good advantage of Z-Wave is the fact it's driven by a centralized group managed by Zensys maintaining fairly strict compatibility between devices and with focus on SIMPLICITY.

Measured on quantity of features Z-Wave is not matching Zigbee but the market segment of residential home automation see little motivation in a bloated protocol and expensive components.

Too often protocols get bloated with needless features that might be something you can optionally choose.

What happens when things are not mandatory and the group defining protocol requirements just include all member requests as options?

The answer is usually that compatibility sucks and QA departments scream when they realize the complexity of testing various generations of products from various vendors with various options chosen. Protocols with many optional features are long-term nightmares in maintaining compatibility.

Z-Wave is popular because it's simple and is doing exactly what it needs to do. Adding more features to Z-Wave will only insignificantly impact the usability of it as there are only so many ways you can control your light, aircondition, home security etc.

So the point is...for Zigbee to succeed against Z-Wave it must have a very clean and simple mandatory base protocol profile that nobody violates.

MINIMIZING options should be a primary goal for residential use because options lead to compatibility nightmares over time.

As I often say in my profession...real men are the ones who can keep things simple by firmly saying "no" to all non-essential requirement requests.
Zensys seem to have a better handle of this I believe. Am I wrong in that?

Re:Z-Wave versus Zigbee - A Quick Intro to the Z-Wave Protocol Followed By A Biased Editorial
Jul 08 2008 23:00:02
Thanks for the comment on the post. You brought up many good points and I do think that Zigbee does suffer from complexity due to feature creep. Also Z-Wave does do a good job of keeping things simple for small networks, such as using source routing, limiting the maximum depth of the network and the number of router hops.

On the bad side, the Z-Wave spec is completely controlled by Zensys where they provide both the chips and the software. A closed environment prevents the diversity and competition that would occur in a more open environment where an industry standard radio and networking protocol could be used. On the hardware side, the 802.15.4 radio prices should fall faster than the Zensys radios. And the diversity of the 2nd and 3rd generation radios that are coming out now are much more sophisticated than the radios that were even available when I wrote that post.

On the protocol side, the Zigbee spec is big and fairly bloated. I think everyone pretty much agrees on that. From a compliance point of view, the Alliance has tightened up the certification testing and the profile compliance for the 2007 specs.

"The ZigBee specification has a number of options, which, if exercised in different ways by different vendors, will hamper both compliance testing activities and future product interoperability. This document, which is, for the most part, a set of restrictions on the Protocol Implementation Conformance Statement (PICS) documents corresponding to the three main sub-clauses of the specification, further restricts those options so as to promote interoperability and testability."

That quote is from the Zigbee Feature Set Profile documents for both Zigbee 2007 and the Zigbee 2007 Pro. So the Alliance is trying to address and improve the issues of maintaining interoperability.

As for the feature set, it may be overkill for the Home Automation Profile as compared to Z-Wave and I do agree that Z-Wave does do home automation well. In fact, I think Z-Wave will have less competition from Zigbee in Home Automation than it will from the RF4CE group that has recently been formed. This group has the benefit of learning from the good and bad points of both Z-Wave and Zigbee and enjoys backing from some strong manufacturers. They also will be using 802.15.4 radios which will enjoy the same price curves as Zigbee, 6LoWPAN, ISA100, and Wireless Hart.

On the plus side, Zigbee is moving ahead in creating interoperability profiles for a lot of applications, with the "Security and Safety", "Wireless Sensor Network", and other profiles coming up soon. So in the sense that the spec is bloated, I guess it depends on the application domain. If they were just targeting home automation or smart energy, then they could definitely lean up on a lot of things. But since the application domain is quite wide, then they are pretty much providing a framework of services and each profile will consume different parts of those services.

Also, the spec is constantly pruning redundant or unused areas as can be seen from the original 2004 spec to the 2006 and now the 2007 versions. It would be nice if they informed the stack implementors about the changes too, though.
Re:Z-Wave versus Zigbee - A Quick Intro to the Z-Wave Protocol Followed By A Biased Editorial
Jul 23 2008 15:01:59
I liked the editorial very much, thanks! I'm probably very biaised too since I'm involved in the ZigBee Alliance but I found it quite balanced.

The comment below regarding the simplicity of Z-Wave is quite fair and this is probably one of the downsides of ZigBee, at least the consequence of a willingness to address many different applications using the same protocol. Relying on a consortium of 250+ members is obviously much more difficult to manage and direct than driving alone a spec. That said, the main issues about ZigBee and Z-Wave are more strategic than technical. My company is a large OEM producing millions of devices that need sometimes to operate for 10 to 20 years (not consumer electronics). We need a global, worldwide standard, and we need multisourcing. Competition is key to boost innovation and decrease cost. That's the real nice thing about ZigBee.

We have had experience with both ZigBee and Z-Wave. Although Z-Wave has a well designed stack, hardware is the real weak point. Zensys cannot be competitive (in terms of performance and cost) compared to the 802.15.4 players. Whether ZigBee will dominate or not the WSN space is still a question mark, but what is now sure is that 802.15.4 is the real reference driving the most promising standards (ZigBee, ISA100, WiHART, 6loWPAN).

That was my one cent contribution. Congratulations for this site and good luck with the stack!
Re:Z-Wave versus Zigbee - A Quick Intro to the Z-Wave Protocol Followed By A Biased Editorial
Aug 25 2008 20:09:17
I think that the price of the zensys ic is very expensive too.

The open standards create new oportunities and the world is adopting.

< Prev   Next >