The last letter of the alphabet is suddenly very popular among developers of wireless sensors networks. It was just a year or two ago when marching bands of articles about 802.15.4 and ZigBee networks paraded on the pages of most technical magazines and journals. Interestingly enough, at about the same time, the Z-Wave protocol was introduced by the small Danish company Zensys.
For many people, Z-Wave's introduction passed unnoticed; slowly but surely, Z-Wave has built momentum and has now become a direct competitor to ZigBee in the home automation arena. Still, certain similarities with ZigBee's functionality, application, and name are keeping Z-Wave in the shadows for many ordinary developers.
What is Z-Wave?
Z-Wave is a proprietary wireless protocol oriented to the residential control and automation market. Conceptually, Z-Wave is intended to provide a simple yet reliable method to wirelessly control lights and appliances in your house. To meet these design parameters, Zensys's Z-Wave package includes a chip with a low data rate that offers reliable data delivery along with simplicity and flexibility.
Z-Wave works in industrial, scientific, and medical (ISM) band on the single frequency using frequency-shift keying (FSK) radio. The throughput is 40Kb/sec (9.6Kb/sec using old chips) and suitable for control and sensor applications. Each Z-Wave network may include up to 232 nodes and consists of two sets of nodes: controllers and slave devices. Nodes may be configured to retransmit the message in order to guarantee connectivity in multipath environment of residential house. Average communication distance between two nodes is 100 feet, and with message ability to hop up to four times between nodes, it gives enough coverage for most residential houses.
Zensys offers an integrated IC coupled with the Z-Wave stack. The 8-bit MCU has an RF radio with carefully selected peripherals and minimum external components.
The Z-Wave Alliance is an consortium of manufacturers who build products based on Z-Wave (www.z-wavealliance.org). Quite a few well-known companies have signed on as Z-Wave supporters—Leviton, Intermatic, and Honeywell among them. I find it convenient to monitor Z-Wave proliferation by reviewing Alliance's site for new Z-Wave"enabled products.
The first Z-Wave devices introduced to market were residential lighting control packages and can now be found in retails stores or on the Internet (for example at www.smarthome.com). Typically, a bundled start-up package includes two light dimmer modules and master controller. Z-Wave's products now consist of mostly light and appliance control modules, light switches and portable controllers, and other devices such as the Z-Wave thermostat, X10 bridge, and serial interface controller for a personal computer.
Protocol stack overview
One of Zensys's goals was to offer a simplified wireless protocol that would reliably transfer messages within a residence. The Z-Wave stack consists of just the bare minimum (as shown in Figure 1): a PHY/MAC layer to control access to RF media; a transport layer that handles frame integrity checks, acknowledgments, and retransmissions; and a network layer with all its routing magic and application interfaces.
Z-Wave operates at 908MHz (U.S.) and 860MHz (Europe) in unlicensed ISM bands. It uses FSK modulation with Manchester channel encoding. Originally the protocol was introduced with a 9,600 bits per second data rate, but it was extended later to 40Kbps. New devices are backward compatible with the old bit rate, but Zensys indicated their intention to obsolete the low data rate in the future. Data is transferred in 8-bit blocks, and the most significant bit is sent first.
Each PHY/MAC frame starts with a synchronization preamble, following a Start of Frame (SoF) delimiter, then payload data, and finishes with an End of Frame (EoF) delimiter as shown in Figure 2. Maximum size of payload data is 64 bytes.
The Z-Wave protocol uses standard collision-avoidance methods when the transmission is postponed by a random number of milliseconds when media is busy.
The Z-Wave transfer layer controls the transfer of data between two nodes including retransmission, checksum check, and acknowledgements. It uses four types of frames that share the same layout structure. Payload data is preceded by a frame header that contains information about network ID, source node ID, size of payload, and type of the frame, such as data, ACK (acknowledgement), and routing frame. To verify integrity of the data, a checksum byte is transmitted in the end of frame.
If message successfully received, ACK frame is sent back to the source node. The ACK frame has same form as regular frame but size of payload is zero.
If the destination address is set to 0xFF, the frame is treated as a broadcast, and all the nodes in the network receive the payload. At the same time, the frame may carry more then one destination address, which makes it a multicast frame. In that case, the same payload will be delivered to selected nodes only. Multicast frames are transmitted to a number of nodes ranging from 1 to 232 nodes. This frame type as well as the broadcast frame doesn't support acknowledgement.
The Z-Wave routing layer controls the routing of frames from one node to another. Both controllers and slaves can participate in routing of frames in case they're always listening and have a static position. The layer is responsible for both sending a frame with a correct repeater list and ensuring that the frame is repeated from node to node. In the case of the controller device, the routing layer is also responsible for scanning the network topology and maintaining a routing table.
The Z-Wave application layer is responsible for decoding and executing commands in a Z-Wave network. The application layer frame contains a header that describes the type of frame, command information, and associated parameters. Commands are divided into two classes: Z-Wave protocol commands and application-specific commands. For most devices protocol-related commands cover only Home ID and Node ID assignment logic, but in more complex devices, such as the Static Update Controller (SUC) or SUC ID Server (SIS), additional network management functions are added.
Each Z-Wave network has a unique 32-bit identifier called Home ID. Controller devices have a preassigned network ID, slave devices obtain the Home ID from the controller upon joining the network. If another controller device joins the network, it inherits the Home ID from the primary controller.
Individual nodes in the network are addressed using an 8-bit Node ID that is assigned by the controller as well. The Node ID is unique only in the scope of its network.
To obtain node-specific information, Z-Wave uses a node information frame. This frame is part of the Z-Wave protocol and specifies the capabilities of the node. These capabilities are the node type, whether the node is able to repeat frames, and other protocol-relevant issues. The node information frame also contains the Home ID and the Node ID.
It is possible for the application to ask for the node information frame from all nodes in the network and hence enable any node to acquire information regarding any node's features in the network at any given time.
Device types
There are two main types of devices defined in Z-Wave protocol: controllers and slaves. Controllers are able to initiate transmission as well as hold all the smarts related to network routings. Slaves, on the other hand, are just end devices with general-purpose input output (GPIO)-type functionality that blindly execute the controller's requests. It's true for message retransmission as well: in the received packet the controller instructs a particular slave whether the message should be retransmitted or not.
Controllers are differentiated further depending on their functionality in the network. Major types are portable and static controllers.
Portable controllers
The definition of portable controllers implies that this device may change its location in the network freely. It has ability to discover and rediscover its position in the network by pinging the surrounding nodes. Usually portable controllers are battery-operated devices that are used by the user to send commands to the network.
A secondary but important function of the portable controller is to include or exclude devices in the network. Each Z-Wave network should have one primary controller that manages the inclusion/exclusion process and holds the latest network configuration. Other controllers copy this information from the primary controller. The node inclusion operation involves exchanging data between the selected node and the primary controller using low-power transmission. It greatly simplifies network configuration from the user's standpoint but also stipulates that one of the portable controllers assumes the role of the primary controller.
Static controllers
Static controllers assume a fixed position in the network and are powered from the main line. They are always in "listening mode" hence other devices may communicate with them at any time. In a more elaborate network, a static controller may extend its functionality and become a device for storing the latest network configuration, called Static Update Controller (SUC). The static controller may even become a primary controller in the network and use portable controllers as proxies to include/exclude other nodes. In that case the static controller is called SUC ID Server (SIS). Naturally, static controllers may work as bridges to other elements of the home ecosystem, like TCP/IP network or trivial X10 devices. Interestingly enough, a Z-Wave network may support up to 125 virtual nodes using a dedicated bridge controller(s). The bridge controller, where the virtual node functionality is implemented, makes it possible to seamlessly migrate to a Z-Wave network in the places where other home automation technologies have already been used. In other words, you can add Z-Wave devices (such as X10 devices) to an existing network and use a bridge controller to provide an interface between the different networks. On the Z-Wave network, the X10 modules look like regular Z-wave nodes, and vice versa. Later you may want to upgrade your system and substitute all X10 devices with Z-Wave modules. This task can be done on a Z-Wave network by simply removing existing virtual nodes and substituting them with real nodes.
Slave devices have much simpler functionality than controllers. They can't initiate transmission unless responding to the controller's request. Therefore, to obtain information from a regular slave device, the controller has to poll the device status at periodic intervals. Slave devices may be used to re-transmit the message; in this case such devices called routing slaves, but they should have main power to be in "listening mode" all the time. Since routing slaves are able to transmit unsolicited messages, such devices may be used where periodical polling is not acceptable, such as in fire or burglar alarms.
If a slave device is intended to be used as a battery-operated sensor that periodically wakes up to communicate with the static controller (as used in motor sensor-type products, for example), it's the developer's responsibility to implement the logic in the controller application that will put the slave into deep-sleep mode for a period of time and to create a matching logic in the slave application to notify the static controller each time the slave wakes up.
Network operation
Management of Z-Wave nodes constitutes of two main operations, inclusion/exclusion and association.
The inclusion initiates a new node in the network. The reverse is exclusion, which describes process of removing nodes. Only primary controllers can include and exclude nodes to and from a network.
The include process begins with activating the include initiator on the controller and the slave simultaneously. An initiator can either be a physical button, a special activation of a button (such as activating a button for two seconds), a combination of buttons (such as activating two buttons simultaneously), or an item in a menu system.
When a node information frame is received from an uninitialized node the primary controller will assign a Home ID and a Node ID to the slave or other controller. In that case, the device automatically becomes a secondary controller.
As part of the inclusion of additional controllers in the network, a replication of routing tables and optionally other information will automatically take place between the primary controller and the new controller. This ensures that the new controller has the newest routing information available. At later stages, when the primary controller has been updated with new nodes (or nodes have been deleted), a new replication can be initiated by activating the include initiators on both controllers. This network information updating can also be done semiautomatically using the SUC functionality.
The association is a creation of the logical connection between devices. In other words, it's used to instruct what controls what. Both primary and secondary controllers can set up associations. If the inclusion process is handled by the Z-Wave protocol internally, association functionality is the responsibility of the application. Similar to inclusion, association initiates when the initiator is simultaneously activated on the controller and the slave.
Routing principles
During the inclusion process, the primary controller "asks" a slave device for a survey of other Z-Wave devices reachable from its location. This information is stored in a routing table, as shown in Figure 3, and represents the instant topology of the network. If position of the nodes change, the network's topology has to be rediscovered and the controller's routing tables updated.
Z-Wave uses a source routing mechanism when the controller device that initiates the message generates a complete route to the end destination through a number of hops. The route is placed in the frame, and every hop that receives the frame with route information forwards it according to the content in the frame.
The source routing allows implementation of a lightweight hop protocol with no distributed network information. The downfall of this approach is an increased frame length since the route should be included inside of the payload.
Generally speaking, since controllers are mobile devices (except static controllers such as SUC and SIS), they have to determine their positions in the network each time before sending a command to slave nodes.
Considering the average size of a house, the controller will try to reach a node directly first. If this fails, the controller has to determine its current location in the network; to accelerate this process the controller maintains two records--the most used node's list and the preferred repeater's list.
The most used node is a list of the nodes that the controller has been able to contact directly, prioritized by how often the controller has been able to reach them. Using this information, the controller will ping other nodes to find its location.
Then the controller tries to reach any preferred repeater, which is the smallest group of nodes that is necessary to reach all nodes in just one hop.
After the controller has found a node that can be used as a starting point for repeating a frame, it calculates the shortest route to the destination.
Hardware platform
Currently Zensys is offering the second generation of its single chip product for Z-Wave nodes. ZW0201 is built around an optimized 8051 microcontroller core that runs off a 32MHz external crystal. (The internal system clock is 16MHz.) The RF part of the chip contains an FSK transceiver for a 908.42MHz or 868.42MHz frequency that is software selectable. Besides radio, it includes a hardware implemented modem and frame handler to unload MCU resources. The digital part of the IC consists of 32KB of FLASH memory, 2KB of SRAM, and a handful of control-centric peripherals. With power supply between 2.2 and 3.6 volts, ZW0201 consumes 23mA in transmit mode (about -5dBm) and 21mA and 3A respectively in receive and deep-sleep modes.
MCU peripherals consist of standard modules like UART, SPI, timers, external interrupts, power management and brownout detection, as well as specific modules for control applications: 12-bit ADC (analog to digital converter), pulse-width modulation, and enhanced TRIAC control with zero crossing detection line. Ten GPIO lines are multiplexed with other peripheral I/O functions as shown in Figure 4.
A typical application circuit for ZW0201 includes the bare minimum of discreet components: 16MHz crystal with two capacitors and LC filter circuitry for the RF part of the chip. To prove its point and make Z-Wave integration easier, Zensys is offering ZM2102, an FCC-compliant module that contains the integrated ZW0201 Z-Wave Single Chip, system crystal, and RF front-end circuitry, shown in Figure 5. In single quantities, the ZM2102 module costs $10 and requires only an RF antenna and power to run the Z-Wave slave device. The controller device will require additional serial EEPROM to store the network topology.
Application development
To simplify application development, Zensys provides a set of libraries differentiated by device type: controller, static controller, bridge, slave, and routing slave. As Figure 1 shows, for each type of device, the Z-Wave library includes not only the protocol stack but also the system components (scheduler and timers) and the main loop as well. Depending on device functionality (such as controller vs. slave), developers are left with a dozen or so libraries--API functions that address Z-Wave protocol administration, system and application timers, power management, and peripheral interfaces on the chip.
The application is implemented as a state machine, periodically polled from the Z-Wave main loop. It interacts with the Z-Wave system using library calls defined in the device API, event notification upon receiving data from the other node and callback functions to synchronize state machine transitions in case of time-conflicting library calls.
Z-Wave uses an application frame format to represent sent or received data at the application level. As I previously described, application frames carry information about the class of a command, the command itself, and a list of parameters defined for this command. Command Classes are a collection of functionally related commands. A device can have several functions and therefore support one or more Command Classes. The majority of Command Classes are composed of a SET, GET, and REPORT command structure. (Command SET allows you to modify the data record on the remote node. GET is a request to obtain a value of the data record, and REPORT is a response to such request.) To ensure device interoperability, all commands that belong to a particular Command Class must be implemented if the device supports that Command Class.
Currently about 50 Command Classes are defined in Z-Wave. It includes basic and advanced light control, binary and multilevel sensors, thermostat, garage control, and others. To communicate that the command's classes are supported by a particular device, Z-Wave is using a node information frames exchange. As I mentioned earlier, this happens during the inclusion process, but the node information frame can be requested whenever it's appropriate.
Besides the supported Command Class information, the node information frame contains data about device classes. Z-Wave defines three categories of device classes:
The Basic Device Class defines the Z-Wave protocol's functionality based on the library used. Depending on device type (slave, controller, static controller, or other), different software libraries are defined in the software development kit. Those libraries enable functionality specific to a particular device type in respect to network operation.
Generic Device Classes specify the minimum functionalities required to implement a device and the set of mandatory Command Classes that the device supports and controls as well as an optional set of Command Classes.
Specific Device Classes are optional descriptions and are tailored for specific uses. They inherit all mandatory Command Classes from the Generic Device Class and specify additional mandatory and optional Command Classes that the device supports.
Z-Wave vs. ZigBee
Although wireless sensor networks (WSN) is a fairly new area, the majority of readers have most likely heard of other names associated with low data-rate wireless networks. ZigBee is a standards-based wireless networking protocol that operates securely and reliably using low data rates on a low power-consumption network. Targeting sensors, automation, and control applications for industry, commercial, and residential buildings, ZigBee constitutes a logical network and application layer, but physical radio interface, PHY and MAC layers, are based on the 802.15.4 IEEE standard.
Similar functionality, applications, market timing, and product names creates a great deal of confusion for people trying to understand the differences between ZigBee and Z-Wave. Table 1 concisely compares the two technologies without diving too deeply into all aspects of the protocols; it emphasizes the principal differences and limitations.
Based on a 2003 version of the 802.15.4 specification, ZigBee operates in three ISM bands with a maximum data rate of 250KBps. But in the lower bands, 908/860MHz, the latest Z-Wave chips provide the same (or higher) bandwidth compared with the 802.15.4 specification. The RF performance of Z-Wave and ZigBee modules measured in an unobstructed environment, such as in an open field with a line of sight between the devices, is equivalent. But the 802.15.4 radio has a definite advantage in noisy environments, since it uses a more advanced modulation technique and spread-spectrum transmission.
The network capabilities provided by ZigBee are significantly wider than Z-Wave can offer: a much bigger network size, multiple topologies, extensive node hopping, and so forth. From the side, it appears that the whole functional capability of the Z-Wave network can be implemented as a small subset of ZigBee functionality. This is true, because from the start Z-Wave was designed as a lightweight wireless protocol for residential control applications. This assumption defined the size of the network, its topology, and other vital protocol parameters. All of that enabled the design of a simple but reliable, compact, and easy-to-use protocol. For example, by limiting the maximum number of message hops between nodes to four, Z-Wave was able to employ a simpler routing mechanism and reduce requirements for node's RAM size. Perhaps for industrial applications it would be a significant limitation, but as far as the homeowner is concerned, it will cover his or her property.
A definite downfall of Z-Wave is the proprietary nature of the protocol. Zensys and other members of the Z-Wave Alliance are hoping that Z-Wave protocol becomes the standard in home automation, but it's not there yet. From a logistic point of view, Zensys is still a single source supplier for silicon, integrated modules, and protocol stack software libraries.
Will it fly or will it falter?
After spending the last five years studying different aspects of low-rate wireless networks, I find that it's very difficult to cover all practical cases and scenarios with one tool set and am reluctant to bet my money on simply one technology, either ZigBee or Z-Wave. Nevertheless, paraphrasing some people from Missouri, I want to say "show me the product" as the ultimate scoring point from a consumer's point of view. Z-Wave has a clear advantage over ZigBee in that field. Light control devices, dimmers, switches and remote controllers from Leviton and Intermatic are readily available in the stores such as Fry's Electronics. They work well and provide unmatched user experience compared with "old faithful" X10 devices. So, ZigBee, your move next?
Mikhail Galeev is a senior engineer at Motorola with 10 years' experience in firmware design for embedded systems. He holds a BS degree in applied physics from Rostov State University, Russia, and an MSEE from the University of South Alabama, Mobile, AL. In his spare time, Mikhail enjoys designing embedded system projects based on 8-bit MCUs. You may reach him at Mikhail.Galeev@motorola.com
Resources:
Z-Wave Protocol Overview Rev 1.04, Zensys, January 2005.
Z-Wave Device Class Specification Rev 2.0, Zensys, August 2005.
Z-Wave Node Type Overview and Network Installation Guide Rev 1.0 Zensys, April 2005.
Galeev, Mikhail. "Home networking with ZigBee," Embedded Systems Programming, April 2004.
Can I say Control4 [control4.com]
--Grant Macdonald
President
PeakLifestyles Ltd.
Calgary, Canada
