Make the right choices when building ZigBee applications

While the ZigBee v1.0 specification has finally been ratified, the protocol isn't a one-size-fits-all blueprint for companies wishing to tap into this market. At its most basic level, ZigBee ensures interoperability with other standard-compliant products. The deeper application, architectural, and platform issues developers must weigh are as wide ranging as the potential applications themselves.

The ZigBee standard provides network, security, and application support services operating on top of the IEEE 802.15.4 Medium Access Control (MAC) and Physical Layer (PHY) wireless standard. It employs a suite of technologies to enable scalable, self-organizing, self-healing networks that can manage various data traffic patterns (Fig. 1).

While ZigBee is often thought of as synonymous with wireless mesh networking architectures, the standard actually supports several network topologies, including star, cluster tree, or star/mesh hybrid networks (Fig. 2). Consequently, the first consideration a developer should address is "which network configuration best suits my application needs?"

If data reliability is key, mesh network architectures offer the best protection against the inherent vagaries that cause signal degradation in any wireless environment, such as RF attenuation, electromagnetic interference and multi-path signals. By placing ZigBee receivers and transmitters closer together, the destructive effects of all three conditions are reduced. And the redundant paths of mesh networks ensure alternate data paths and no single point of failure.

Other applications may require ZigBee routers to extend the network's range by acting as relays for nodes that are too far apart to communicate directly. Moreover, the deployment may rely on battery-powered routers that need a significant amount of "sleep" time to increase their lifetime. Consider a crop-monitoring network or similar agricultural application. Here, a cluster tree configuration would work best. It can aggregate multiple sub-networks into a long-distance ZigBee wide-area network in which low data rate traffic trickles along the tree, awakening the battery-powered routers only when needed to send or receive data between the appropriate sub-nets. Conversely, some shorter range applications may be better suited to a star topology where the communications overhead of mesh network routing may not be necessary.

Interoperability
While ZigBee is an open standard, it also grants OEMs great latitude in how much of their product should be open to third-party vendors. Because the ZigBee standard defines only the network, security, and application interface layers, developers can license the entire ZigBee stack, which can include application profiles for a specific product, or merely license the networking layer for basic network level interoperability.

At the application layer, developers must decide whether to use a public application profile or develop their own private profile. ZigBee v1.0 has already defined basic public profiles for lighting, with application profiles for HVAC, industrial sensors and other sensors in the pipeline. Any company may design products compatible with products sporting public profiles. For example, a fluorescent lighting ballast vendor using the public ZigBee lighting profile can interoperate with third-party light-switch dimmers using the same profile. Developers can add their own look and feel to the public profile. ZigBee devices are modeled using application objects, which communicate with other devices by exchanging the profile objects and their attributes.

While it may seem contradictory to ZigBee's spirit of openness, some OEMs may develop products that don't provide open interoperability at the application layer. Developers can design private application profiles to create a closed "ecosystem" of single-vendor devices, or select third-party devices. ZigBee defines an abstract interface while platform vendors provide application programming interfaces (API) that define rules for how applications integrate into the ZigBee stack. A "closed" system still benefits from third-party product manufacturers at the network level. Required interoperability at ZigBee's lower stack provides data routing as well as medium access control, network formation and maintenance, and device and service discovery.

How that data is transported is another key concern for developers because ZigBee doesn't define a transport layer. Developers must decide whether to build the transport mechanism themselves, or they can build their applications using a ZigBee chip with a built-in transport layer. For example, Ember provides a transport layer with its ZigBee stack as a way to simplify application development and ensure reliable end-to-end messaging. The transport layer provides the framework on which developers define private ZigBee profiles.

Security
Most ZigBee solutions will require some level of security. Fortunately, ZigBee provides a standardized toolbox of security specs and software based on a 128-bit AES algorithm and incorporates the security elements of 802.15.4. ZigBee stack profiles define security for the MAC, network, and application layers. Its security services include methods for key establishment and transport, device management, and frame protection.

If developers choose to use a public ZigBee profile, then the security decisions for their applications have already been made for them; they're pre-defined in the profile. Chances are that even if a developer intends to build a private profile application, he'll choose the security mode in one of ZigBee's pre-defined stack profiles.

At this level, developers need to decide issues such as whether they need to encrypt the data frame's payload, as well as the length of the authentication code (8-, 16- or, 64-bit, etc.) tagged on to the end of the frame. Basic applications may not require authentication, and thus can benefit from a smaller packet payload. These data integrity options let developers make tradeoffs between message protection and overhead.

Developers must also decide where to apply security: at the MAC, network, or application layers. If the application needs the strongest security possible, secure it at the application layer. Security implemented here uses a session key that can only be authenticated and decrypted by another device possessing the key. This approach protects against both internal and external attacks, but requires more memory to implement.

Security at the MAC and network layers serve essentially the same purpose: to secure single-hop transmissions. The MAC layer inherently mediates access to the shared medium and controls single-hop transmissions between neighboring devices. The ZigBee Alliance added a network-layer security option to add functionality not available at the MAC layer, including the ability to reject data frames if their freshness can't be verified. Both these security layers use a global key that all ZigBee devices on the network share. MAC and network-layer security suits applications that need protection against specific infrastructure attacks, such as protection against a nefarious device maliciously inserted into the network. If a developer needs to establish a route between two devices and the network layer frames weren't secure, that device could intercept the packets.

ZigBee security also introduces the concept of a "Trust Center," which lets devices into the network, distributes keys, and enables end-to-end security between devices. Here, developers must choose between two Trust Center modes based on their application: residential or commercial. Residential mode is lightweight, but doesn't establish keys or scale with the size of the network. Commercial mode establishes and maintains keys and scales well, but at the cost of significantly more memory.

Platform considerations
ZigBee provides a standardized network and application framework upon which developers can build applications without worrying about the intricacies of networking and RF issues. Yet ,by itself, ZigBee's standardized framework doesn't ensure easy product development. The market is flush with a diverse vendor mix of components needed to build ZigBee-compatible applications, including RF transceivers, microcontrollers, flash ROM, vendor-specific protocol stacks, and application development tools. Consequently, developers must choose between "rolling their own" ZigBee solution from multi-vendor components or building their applications on an integrated hardware/software platform. Lacking both the expertise and inclination to tackle the tough integration effort, most developers will probably opt for the latter approach.

The first decision they must make is at the chip and networking software levels. The biggest challenges stem from the complexities and incompatibilities between hardware and network software. Problems found in development of a new application are rarely confined to just one stack layer . For example, a bug found in the MAC layer of a prototype can rarely be detected and debugged by network layer providers. Hence, developers must carefully consider the integration depth of their chosen platform.

A ZigBee solution requires an RF transceiver, a microcontroller or DSP for application processing, and a ZigBee network stack. Until recently, most were multi-chip, multi-software solutions born from multi-vendor partnerships. Today, a new generation of fully integrated, single-vendor platforms are hitting the market. Multi-vendor platforms sometimes offer lower upfront costs. But a single-source platform, while often more expensive, lets developers avoid the headaches and product development delays inherent in solutions built from different vendors' hardware and software products.

Developers must also consider the depth of the networking stack. Typically, the deeper the stack, the easier the development effort. A stack that provides everything from the physical network layer to transport layer all the way up to ZigBee profiles will shield developers from the inner workings of the network, freeing them to focus on application development. For example, a ZigBee application built with a mixed-vendor solution would require developers to factor in how their application handled dropped network packets between nodes. This kind of networking complexity would be already accounted for in a single-source, full-stack platform.

Tool choices can also make or break a ZigBee development effort. Developers need to carefully consider the breadth and functionality of their platform's development environment. It's important that the vendor provide a full development kit complete with multi-node wireless semiconductors, networking software, software tools, training and technical support. Also, the tools should be part of an integrated environment with universal interface, or a collection of standalone tools. Lastly, the development environment should include sufficient tools for debugging.

About the author
Zachary Smith is a chief software architect for Ember Corp. He holds a bachelor's degree in music from Hampshire College and a master's in computer science from the University of Massachusetts. Smith can be reached at zachary@ember.com.