RTC Magazine

ZigBee wireless mesh technology has been developed to address sensor and control applications with its promise of robust and reliable, self-configuring and self-healing networks that provide a simple, cost-effective and battery-efficient approach to adding wireless to any application, mobile, fixed or portable. A typical IEEE 802.15.4-based, ZigBee-compliant device is shown in Figure 1.

The ZigBee Alliance released their specification to the public in June 2005, and since then the playing field has become much simpler for product designers who want to add wireless to their sensor or control application. An open and growing industry group of nearly 200 companies from product/system OEMs to applications developers to semiconductor companies, the Alliance has worked hard to provide a technology that takes best advantage of the robust IEEE STD 802.15.4 short-range wireless protocol, adding flexible mesh networking, strong security tools, well-defined application profiles, and a complete interoperability, compliance and certification program to ensure that end products destined for residential, commercial and industrial spaces work well and network information smoothly.

Zigbee Relies on the IEEE 802.15.4 Standard

The IEEE standard brings with it the ability to uniquely identify every radio in a network as well as the method and format of communications between these radios, but does not specify beyond a peer-to-peer communications link, a network topology, routing schemes or network growth and repair mechanisms.

The IEEE 802.15.4 standard, released in May 2003, was selected by the ZigBee Alliance as the wheels and chassis, upon which ZigBee networking and applications are to be constructed. This is not without its challenges, as the Alliance does not control the IEEE specification. However, many of the same people who sit in the IEEE 802.15 Working Group are deeply involved in the ZigBee standard. This relationship has meant that both the IEEE and the ZigBee specifications track one another fairly well. Figure 2 shows the relative organization of the IEEE radio with respect to the ZigBee functionality.

The IEEE standard specifies the RF link parameters, including modulation type, coding, spreading, symbol/bit rate and channelization. Currently, the standard identifies 27 channels spread across three different frequency bands (Table 1).

The 802.15.4 PHY physical layer contains specific primitives that manage the radio channel, and control packet data flow. This is a packet radio specification, and the PHY defines four different frames that have unique functions: Data, Acknowledgement, Beacon and MAC Command. The Data frame (Figure 3) can carry up to 104 bytes of payload. The Acknowledgement frame is used by a receiving station to acknowledge to the transmitting station that a data packet was received without error. The Beacon frame is used by stations that may be implementing significant power saving modes, or by Coordinator and Router devices that are attempting to establish networks. The MAC Command frame provides some unique abilities to send low-level commands from one node to another.

Figure 4 demonstrates the timing involved in a data transaction between two devices. The sensor wakes up either on an event or at the end of an interval, checks the channel, transmits its message, awaits the acknowledgement, then may go back to sleep or first receive data intended for the node before going back to sleep.

The 802.15.4 MAC medium access control layer contains over two dozen primitives that allow data transfer, both inbound and outbound, as well as management by higher-level entities of the RF and PHY. The IEEE 802.15.4 specification uses a 64-bit unique address for every radio node. The 64-bit address is used in peer-to-peer communications, where no established network is available. However, once in a network, the 64-bit address is traded for a 16-bit address to reduce packet overhead.

There are two physical types of devices specified in 802.15.4, and three logical types. The two physical types are the Full Function Device (FFD) and the Reduced Function Device (RFD). While either device may act as a sensor node, control node or composite device, only the FFD may perform routing tasks for a network. FFDs may, depending on their location in a network, have child devices for which the router performs routing functions. RFDs do not route, and therefore cannot have child devices. Figure 5 is a graphical representation of the connectivity practical in a ZigBee network using 802.15.4 devices.

ZigBee Networking

ZigBee networking is natively mesh-based. Cost-effective, simple radios cannot use high transmit power to ensure successful transfer of data. Instead, the network must be more clever ”the most robust route between source and destination may not be the obvious, shortest physical path route, but instead a route that requires other radios to relay the information.

The ZigBee networking specification provides networking mechanisms that allow a developer to create star, tree and mesh network topologies, depending on network requirements. Once formed, a wireless network can be subject to interference, propagation changes, continued growth, unintended usage and security issues.

How does a ZigBee network respond to these factors? Wireless networks bring with them added flexibility in deployment and modification, but do not carry the generally assured connectivity that twin strands of copper wire provide. By no means does that make a wireless system less useful or robust. The wireless system architect must understand the types of environments in which the wireless network is expected to be used, the usage patterns and (at least) the most common failure modes. With this information, mitigations may be crafted that improve the reliability and robustness to levels that are good enough.

ZigBee networking (NWK) sits atop the IEEE RF/PHY/MAC and provides the required functionality to create and manage mesh networks. There are two types of ZigBee networks ”a self-forming, self-healing network intended for environments where user intervention in the network is not expected nor intended; the other is designed for environments where there are persons that are network experts and regular configuration changes are expected.

Networks physically larger than 2^16 nodes are broken into multiple sub-networks, just like Internet addresses are divided into subdomains, partially for ease of use and also for added robustness and network capacity.

In a live network pictured in Figure 6, the initial network address allocation created a default tree network, but quickly the network routing devices (1, 2, 5, 7, 8, 9) begin to learn additional routes between themselves, creating a mesh network that may actually do the majority of the routing, depending on routing performance. For instance, the sensor 14 default route to the device 1 home security panel is 14>8>2>1, a total of 3 hops. However, there s a shorter route 14>8>1, which probably has a higher reliability since it has one less hop to it. Once the mesh route is learned, it is probable that data from occupancy sensor 14 will travel via the mesh route to the security panel.

Developing the Product

Creating the product first depends on how much of the ZigBee functionality is required. If the desire is to have a standard application that will be broadly interoperable with other vendors products, the best choice is to go with the ZigBee Alliance-approved profiles and device descriptions. These product profiles have been completed for the Residential Automation space, and will soon be available for the Commercial Building Automation and Industrial Sensor spaces. Other market spaces, like Automated Meter Reading, are of interest to parties within the Alliance and thus may have profiles developed in the near future.

First, a word on profiles: These are descriptions of specific applications for ZigBee technology, and a profile will contain within it descriptions of devices that are intended to be interoperable within that environment. Just because it uses ZigBee technology doesn t mean that it was intended to be interoperable. An example of that might be the 100 hp, 3-phase motor controller that s used in an industrial automation space and the $20 peel-n-stick light switch used in Grandma s den. While in concept, there s no reason that the two devices couldn t interoperate, it s not expected that they need to.

However, the $20 light switch from company A and the $20 light switch from company B, both sold out of your local home improvement store, had better be able to quickly, easily and efficiently join your home s ZigBee network and behave in a similar, predictable fashion. The profile defines the broad market space (Residential Automation), while individual device descriptions contained within (light switch, non-dimming) provide to the developer the template for coding a device that is interoperable with other similar devices within the Residential Automation space. Profiles are constructed by member companies that have an interest in that space.

If the application can map to an existing profile and device description, then product development can be very straightforward. Alternatively, a product intended for a proprietary space or application can still take advantage of the ZigBee networking functionality without the intention of broader interoperability. It all depends on what the developer and their market need.

Assume that the application is for that peel-n-stick light switch, to be sold at one of the major home improvement chains. There, it s best to start with a ZigBee Alliance-compliant platform, an intermediate product already validated as being compliant at the IEEE 802.15.4 level, with a compliance-tested ZigBee network stack, security toolbox and stack profile targeted to the developer s application space. Starting with this compliant platform allows the developer to avoid the challenges of building a ZigBee network stack, integrating the security suite, and obtaining a much broader certification verification that is both more costly and time-consuming. And, there are at least a half-dozen manufacturers of ZigBee-compliant platforms available today, with more coming as time goes on.

Once the selection of the ZigBee-compliant platform has been made, the developer can sit down with the Home Automation profile, check out the mandatory features of the device description for the light switch, non-dimming, and decide to implement strictly that or, in fact, add some extra functionality that is or may be expected by their customer. Once the design is done and the software coded and tested, the developer may want to do further interoperability testing using some store-bought golden devices, or bring the design instead to one of the ZigBee Alliance s ZigFests, a quarter-annual event that allows them to test their product for interoperability at multiple levels, in an atmosphere of confidentiality.

This important step validates the design for the developer, gives them a strong indication of the product s ability to interoperate with similar products in the space, and provides a strong assessment of the basic functionality and compliance of the product. Next, with demonstration of interoperability in hand, the developer may take their product to one of the two ZigBee Alliance approved test houses for certification testing.

Once at the test house, the developer s engineering sample product is subjected to a subset of IEEE 802.15.4 testing, some over the air measurements and compliance to the minimum functional requirements expected and defined by the Alliance in the Profile/Device Description document. Testing for simple devices like the light switch is quick ”it should be in and out within a day or two of testing. When it successfully passes testing to the Alliance s specification, the test house is authorized to provide a letter of certification, which the developer may next provide to the Alliance in exchange for authorization to use the ZigBee logo on the product. Once that authorization is received, the developer may go into large-scale production for that product, and the ZigBee logo imprinted on the product gives strong confidence to the consumer that this product, like others with the same logo for the same space, will interoperate successfully and simply.

Freescale Semiconductor

Austin, TX. (800) 521-6274. [www.freescale.com].