Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Networks

Make right choices when building Zigbee apps

Posted: 16 Sep 2005     Print Version  Bookmark and Share

Keywords:zigbee  network  mesh  wireless  embedded 

The Zigbee low-power, low-cost wireless networking standard is making it practical to embed wireless communications into everyday appliances. Its proponents say the standard will foster rich new markets for home and building automation, energy conservation and even homeland security.

While the Zigbee ver 1.0 specification has finally been ratified, the protocol is not 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 uses a suite of technologies to enable scalable, self-organizing, self-healing networks that can manage various data traffic patterns.

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. Consequently, the first consideration a developer should address is which network configuration best suits the 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, EMI and multipath 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.


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 ver 1.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 that are 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 APIs 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.


Zigbee provides a standardized toolbox of security specs and software based on a 128bit 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, the security decisions for their applications have already been made for them, since they are predefined 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 predefined stack profiles.

At this level, developers need to decide on 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 64bit) tagged onto 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 trade-offs between message protection and overhead.

Developers must also decide on whether 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 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 suit applications that need protection against specific infrastructure attacks, such as a nefarious device maliciously inserted into the network.

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. Consequently, developers must choose between "rolling their own" Zigbee solution from multivendor components or building their applications on an integrated hardware/software platform. Lacking 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 the 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.

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, giving them freedom 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 with multinode wireless semiconductors, networking software, software tools, training and technical support. Also, the tools should be part of an integrated environment with a universal interface, or a collection of standalone tools. Lastly, the development environment should include sufficient tools for debugging.

- Zachary Smith

Chief Software Architect

Ember Corp.

Comment on "Make right choices when building Zig..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top