Development and design of more robust ZigBee solutions

ZigBee has received a lot of attention in the field of wireless sensors, mainly because ZigBee promises to provide global unified standards for reliable, cost-effective and low-power wireless communications. And in the current wireless device market, the ZigBee Alliance has made a big step forward in its status through unremitting efforts. In just a few years, the alliance has developed more than 200 alliance members. ZigBee chipsets and protocol stacks are already easily available from many suppliers. The first set of ZigBee terminal products appeared on the market last year.

By carefully defining the network and application layers in the ZigBee specification, the ZigBee Alliance hopes that independent equipment manufacturers can develop excellent interoperable terminal products. Members have high expectations for ZigBee chipsets, hoping to help OEM manufacturers further reduce costs and provide low-cost terminal products for system integrators and end users.

With the growth of market demand and the large number of volunteers working on the ZigBee specification, it is time to provide a feasible solution for a low-cost, low-power wireless communication system. This article will discuss some important factors that should be considered when designing and integrating a ZigBee solution. Much of the content in this article comes from the experience gained by MaxStream in developing its first ZigBee certified product, the XBee OEM wireless module.

1. ZigBee Network

ZigBee defines three types of nodes: coordinators, routers, and end devices. The coordinator can start a ZigBee network by selecting the network's operating channel and personal area network identification mark (PAN ID). Once the network is started, routers and end devices can join the network. Coordinators and routers can both transmit and route data through the network and allow other routers and end devices to join. End devices cannot participate in routing data, so they can sleep when not transmitting or receiving data. When a device joins a ZigBee PAN, a parent-child relationship between the devices is formed, with the device that joins being the child and the device that allows joining being the parent. A simple ZigBee network is shown in Figure 1.

2. ZigBee Addressing

ZigBee devices support two types of addresses: a 64-bit IEEE address and a 16-bit URL. The 64-bit address is unique among all ZigBee devices and contains a 24-bit manufacturer-specific organization identifier (OUI) assigned by the IEEE and unique worldwide.

When a device joins a ZigBee personal area network, it can obtain a 16-bit URL from the parent device that allows it to join. This URL is specified to be unique within the personal area network. This URL is used for data transmission and packet routing. The routing table used to route packets stores the network addresses of each target device and the next hop device. Therefore, each device in the personal area network must have a clear and unique network address to ensure that data can reach the correct device.

However, under certain conditions a device's address may change, or multiple nodes may receive the same address. For example, if an end device is removed or loses contact with its parent device, it must reconnect to the network, which may cause it to receive a new address. In addition, if the coordinator is replaced by a new device, the new coordinator will not know which addresses were issued by the previous coordinator. It is easy for the addresses issued by the new coordinator to overlap with existing addresses.

The ZigBee Alliance is working hard to solve these address problems and integrate the solutions into the ZigBee specification. However, some protocol stack and module providers, such as MaxStream, have already developed solutions to these problems. [page]

3. ZigBee Routing

ZigBee includes a basic framework for AODV mesh routing. If a device needs to send data to other devices, it first needs to find a route that may pass through multiple routers to reach the target device. Mesh routing allows the transmission path to be dynamically established, modified or replaced, thereby maintaining a reliable path between devices.

However, in addition to mesh routing, the ZigBee specification often relies on tree routing, where data is transmitted strictly from parent to child or from child to parent on a "tree"-like route between source and destination devices.

Routing problems can occur when nodes are moved or removed. If a single node cannot be isolated from a route, the entire tree routing cannot locate the point of failure. The mesh network can find a new route when an existing route fails. The ZigBee protocol stack is built according to the ZigBee 1.0 standard that uses tree and mesh routing. The interaction between the two types of routing is quite complex and the interaction between the protocol stacks is constantly changing. However, the enhanced ZigBee specification (2006) added a nwkUseTreeRouting function that can completely disconnect the entire tree routing and then force route discovery as needed by the (NLME) route discovery request primitive. These features can solve the problems associated with tree routing and allow developers to fully utilize the advantages of mesh routing.

4. ZigBee interoperability

The ZigBee specification includes several configuration features that can be used to define various networks. Developers can easily configure the following parameters: the number of routers and/or end devices in the target system; the security level; the size of the routing table and neighbor table; the maximum depth of the network (the depth of the connection from the coordinator to the farthest derived device); the maximum number of child routers and end devices allowed by the coordinator/parent router.

The ZigBee Alliance has developed a common framework for these different protocol stacks to establish common settings - configurable parameter tables. In order to complete common tasks within the framework (such as the home control protocol stack framework defines the cluster ID for turning on, off, or switching a light), the framework also defines some interfaces called cluster IDs.

Terminal devices must be designed around the same interoperable framework. Therefore, application developers must set their protocol stack parameters to match the parameter values ​​specified by the public framework to ensure interoperability with other solutions using the same framework. In addition, developers are free to modify protocol stack parameters by using a dedicated (customized) framework to meet their design. However, the cluster ID defined in the dedicated framework does not have the ability to interoperate with devices based on the public framework.

Because developers have the flexibility to choose a framework, not all ZigBee devices are interoperable. Although this flexibility will cause some confusion in the market at first, it allows developers to decide whether their products are to interoperate with other vendors' equipment. Where interoperability is not required, the powerful ZigBee can be developed around a dedicated framework and the protocol stack parameters can be tailored to meet the needs of specific applications. [page]

5. ZigBee Certification

Certified ZigBee hardware platforms (chipsets and modules) and software layers (PHY layer, MAC layer and network layer) must undergo ZigBee Certification Platform (ZCP) testing. Hardware platforms and software protocol stacks that pass ZCP certification are suitable for the development of ZigBee terminal products.

Terminal products developed on a ZigBee compatible platform can directly undergo product certification testing. Terminal product certification allows products to appear on the ZigBee Certified Products list and be marked with the ZigBee logo. The ZigBee Alliance has developed relevant test standards to certify whether terminal products based on public and private frameworks are qualified ZCP products.

Unresolved ZigBee Issues

The ZigBee specification is continuing to improve and provide more features, but the ZigBee Alliance also recognizes that there are still some problems with the specification:

1. Change the network address

As mentioned earlier, the network addresses assigned to nodes in a ZigBee PAN can change and even have duplicate names under certain conditions. This forces the network to work around unreliable addressing mechanisms to ensure data is sent to the correct device.

The ZigBee Alliance is considering changing the addressing mechanism to provide a more robust addressing mechanism. Meanwhile, some module providers, including MaxStream, have developed solutions based on unique 64-bit addresses to ensure reliable data transmission.

2. Fixed working channel

Because ZigBee uses Direct Sequence Spread Spectrum (DSSS) modulation as specified in the 802.15.4 MAC/PHY specification, it can work on fixed channels. The working channel is selected after screening out channels with higher energy through energy scanning. However, once the initial energy scan is completed, the ZigBee network cannot reset a new channel when the quality of the selected channel deteriorates. This can be a big problem because there are many devices (including cell phones, microwaves, and 802.11 networks) occupying the 2.4GHz band. Currently, end-equipment developers must address interference issues in their designs. The ZigBee Alliance is also studying solutions to this problem. A new version of the ZigBee specification may address this issue.

3. Capacity Limitation

ZigBee was initially intended to use 64K flash memory. However, for advanced applications that require reliable data transmission, mesh networking, higher security levels, and low-power end devices, this space will be difficult to meet the requirements of 802.15.4 MAC/PHY, ZigBee network layer, and other desired application functions. As ZigBee continues to develop, advanced applications seem to need to migrate to microcontrollers with more flash memory.

ZigBee Implementation Solution

As market demand grows and ZigBee's own elements improve, deploying a certified ZigBee solution will be extremely valuable. With the latest progress in the ZigBee specification, reliable ZigBee solutions can be developed using existing ZigBee architectures. Developers must make a careful choice between developing their own hardware and software from scratch or integrating proven ZigBee module solutions.

MaxStream has invested a lot of time and effort in the ZigBee specification to develop a robust ZigBee solution. The following suggestions are based on our actual experience and will be helpful to developers who intend to adopt ZigBee solutions.

1. Hardware selection

When developing a ZigBee solution, the first thing to do is to determine the hardware platform. Usually, the hardware platform consists of a chipset or module. As mentioned earlier, the ZigBee Alliance has defined a ZigBee ZCP for platform verification, which can be used to verify whether the platform supports the ZigBee solution. If a ZigBee terminal product wants to carry the ZigBee logo and be listed as a ZigBee certified product, the hardware platform and ZigBee software protocol stack used must be certified by the ZigBee Alliance as a ZigBee compatible platform. [page]

2. Adopting modules

Modules offer many advantages over chipsets. Choosing modules can save developers money and eliminate the pain of RF front-end design, prototyping, product testing, and EMC testing. Module providers have passed rigorous application testing and network protocol stack testing, and have added some features to simplify the ZigBee interface. In particular, MaxStream XBee modules also provide firmware that provides robust mesh networking, reliable addressing, and even channel migration strategies to solve unresolved ZigBee problems.

If the module firmware does not meet the needs of a particular application, some module providers also provide a flexible option. In some cases (including MaxStream XBee modules), designers can develop their own applications on the module hardware and customize the ZigBee application to meet their needs. Although such an approach requires some firmware development, it still saves the time and cost associated with RF design, prototyping, and EMC testing.

3. Chipset

If a chipset is used, the designer must be prepared to support the extensive design, testing, and production requirements needed to support wireless designs. Using a chipset on a custom board requires support for the hardware production process, including board-level testing, debugging, and rework. If this option is chosen, a 24-bit OUI must be obtained from the IEEE in order to assign a unique 64-bit address to each device.

When custom boards use chipsets, designers must also select a ZigBee network layer protocol stack. Designers must connect the protocol stack to their hardware, carefully test ZigBee applications, and evaluate network performance. Many or even all of the unresolved ZigBee issues listed above must be addressed in the application, which can significantly increase development time.

4. Equipment development

The following steps will be useful if you have to develop custom firmware on a chipset or module platform.

5. Select the framework type

Before starting to develop ZigBee devices, designers must determine whether a public framework or a dedicated framework can better meet their needs. Does the device need to be compatible with other common ZigBee products, or is it only suitable for specific applications? Do the protocol stack parameters need to be adjusted for optimal performance? If a dedicated framework is more suitable, you need to apply for a dedicated framework from the ZigBee Alliance.

6. Determine the routing strategy

Developers should be clear about whether tree routing is allowed. For simple static networks, tree routing will be sufficient. If some nodes may be removed, or reliable data transmission is required, tree routing will be insufficient. In this case, you need to spend some time to evaluate when the protocol stack calls route discovery.

If the chosen ZigBee stack complies with the Enhanced ZigBee specification, the application layer can use the route discovery request primitive and the nwkUseTreeRouting property to control route discovery and removal of tree routing. If mesh routing is used, developers should consider how the system will perform when all routing table entries are occupied. Because the ZigBee specification does not regulate aging routes and expired routing table entries, some ZigBee stack implementations do not remove old routing table entries. Once all routing table entries are occupied, the device will no longer be able to participate in route discovery. If the protocol stack is unable to age or replace expired entries, the application layer should add its own supervision measures to achieve this.

7. Consider fixed channel operation

For many applications, ZigBee networks can work reliably on fixed channels even in the presence of sudden interference. However, for systems that must work with other systems in the same frequency band, or systems that cannot tolerate occasional packet loss, it is necessary to support channel migration. Because the current ZigBee specification does not define a channel migration mechanism, application developers can decide the conditions for migrating the network to a new channel and develop corresponding implementation solutions. [page]

8. Overcoming addressing limitations

In many applications, the current network address allocation mechanism is sufficient. However, to prevent the possibility of address duplication, a more robust ZigBee solution should have the ability to reset the network address (such as when the coordinator is replaced).

Since a device's network address is unreliable and can change (for example, after a power cycle or reset when the device cannot find its parent), the application layer may also require a solution that can uniquely identify each node.

To ensure data is sent to the correct device, MaxStream

Some ZigBee solutions, including XBee, rely on unique 64-bit addresses. If such a solution is used, there must be a configuration function in the application layer to convert the 64-bit address into a 16-bit network address before transmitting data.

9. Testing

Testing should include verifying how the system reacts to the scenarios described in this article. How does the system react when the router is turned off? How does the system perform when interference is present on the operating channel? If the device receives a new network address, how is the new address discovered? It is important to reiterate that some module and protocol stack developers have developed configuration solutions to address these issues, greatly reducing the development burden on application developers.

Conclusion

Although ZigBee faces some important issues on the road ahead, the ZigBee Alliance has strong perseverance, great leadership, and a large number of excellent designers who actively contribute to the standard upgrade. Even in the early stages, the important foundation work of the ZigBee specification that can provide designers with powerful network layer functions and application layer flexibility has been completed.

ZigBee is becoming an important player in the embedded device market due to a strong leadership alliance in the embedded device field. The ZigBee Alliance is currently discussing configuration issues to increase the value of ZigBee and trying to solve many legacy issues that have not been resolved in the ZigBee specification. ZigBee-certified modules and network protocol stacks are beginning to appear on the market, providing powerful mesh solutions and effectively solving many (if not all) of the limitations that exist in the current ZigBee specification. Now is the time to start developing reliable, low-power and more cost-effective ZigBee solutions.