With the increasing adoption and growth of embedded networking technologies such as IEEE 802.15.4 and 6LoWPAN, a new class of embedded systems has emerged. These are different from previous systems because they can interoperate natively with IP-connected devices (both IPv4 and IPv6). As vendors introduce more wireless products in the marketplace, an end-to-end framework for enabling standardized communications between those devices becomes critical. Although a number of IP-based solutions tailored for the network layer lend themselves to interoperability, few products target the application layer.
The solution to this dilemma could lie in combining ubiquitous, industry-proven IP networking with emerging smart-energy profiles from the ZigBee Alliance. As it turns out, this approach offers an interesting solution to users looking to operate devices produced by different vendors on existing networks without using an inefficient, stateful, gateway translation layer. The Compact Application Protocol (CAP), proposed by Arch Rock, is an open framework designed to combine the IP world with ZigBee technology.
Enter ZigBee
The ZigBee application layer (ZAL) and ZigBee Cluster Library (ZCL), which runs on top of the application layer, enable device interoperability on IEEE 802.15.4 wireless links. ZAL and ZCL describe a set of structured communication primitives for exchange of data and commands, a protocol for binding and service discovery, a security protocol, and a profile system that enables the definition of interfaces for specific classes of devices that can discover each other and interoperate.
The primary design goal of the two ZigBee components is to define a compact and low-traffic message format that supports embedded systems attached to low-bandwidth, lossy networks. A secondary goal is to create a protocol that can be implemented using a small amount of code and RAM to enable embedded systems running on microcontrollers. These design principles make ZAL and ZCL particularly well suited for communications among networked embedded systems for instrumentation, monitoring, and control.
Problems
Despite its positive attributes, ZAL was originally designed to operate only over IEEE 802.15.4 wireless networks. This made it less than ideal for applications that cross diverse media or networks. In fact, the full ZigBee specification defines a network layer that also operates only over IEEE 802.15.4, and ZAL is defined solely in terms of this network layer and the addressing primitives provided by the 802.15.4 link layer. Furthermore, the specification does not address how such an application protocol is carried over other well-established communication links or how a conventional TCP/IP or UDP/IP host can participate in such an application protocol.
Introducing CAP
CAP is an adaptation of ZAL that enables devices with native UDP/IP stacks to exchange application-layer data while using the higher-level primitives defined by ZAL (Figure 1). CAP ports the ZAL from its original IEEE 802.15.4-specific network layer to a native UDP/IP implementation.
 Figure 1. ZigBee application profiles over IP |
When ZAL messages are placed in UDP messages, modifications to the ZAL protocol must be made because the substrate now consists of IP hosts with IP addresses instead of 802.15.4 hosts with 802.15.4 addresses. By choosing to run the ported ZAL service, IP hosts at all levels (e.g., embedded, mobile class, PC class, and server class) can benefit from the data, binding, discovery, and profiles defined by ZAL.
It is, however, important to understand that CAP is not a tunneling mechanism, by which multiple ZigBee networks can be interconnected over an IP substrate to carry unmodified ZigBee messages. Neither is CAP a gateway mechanism, by which messages from ZigBee nodes can be changed by an intermediate host (possibly with address reassignment or payload modification) and placed into an IP message for transmission to other IP hosts.
The designer of a host running CAP (which can be an embedded device, server, or another class of system) can choose to implement devices and clusters of any of the published ZigBee application profiles over CAP, including (but not limited to) ZigBee Smart Energy and ZigBee Home Automation. Designers can also implement unpublished ZigBee application profiles or define their own manufacturer-specific application profile for a new application domain.
Several other application-layer standards claim to provide structured communications, binding, discovery, and profiles over IP networks. These include the Devices Profile for Web Services (and its underlying XML-based Web services standards) and Universal Plug and Play. ZAL and CAP differ from these standards in that they were designed to have a compact message format and a simple implementation. In contrast, the first two standards use HTTP and XML as a data exchange format. HTTP and XML are more verbose than the binary messages used by CAP, and thus they are less suitable for use with low-bandwidth, low-power networks. HTTP and XML require more host resources to encode, decode, and process, which does not fit the model of extremely resource-constrained, IP-connected hosts running on microcontrollers.
CAP Usage Model
CAP may be applied to a variety of use cases, but energy, the current focus of the ZigBee Alliance, offers a good place to illustrate its application. As applied to a smart energy system—a connected set of energy-consuming, energy-producing, or energy-transmitting devices and human-interactive displays and controllers—CAP offers many benefits (Figure 2).
 Figure 2. Smart energy profiles over CAP |
One such smart energy system intended for home use can include a number of load-controlled appliances, a connected electricity and gas meter plus one or more submeters, an interactive wall-mounted display, and a host whose purpose is to apply an energy-usage policy to the devices in the system (sometimes called an energy services portal).
Agreement among vendors can result in the development of an application profile for the smart energy application domain, which includes a set of device classes that fit the domain and a concrete description of the functionality provided by each device. The ZigBee smart energy profile is such a document.
The devices implementing this profile will use the ZigBee Application Protocol over UDP (CAP) to communicate over the network and exchange data (Figure 3). The protocols will be used, for example, when the meters send energy usage information to the display and when the energy services portal sends policy control messages to the load-control units. The ZigBee Security Protocol portions of CAP can be used to authenticate, encrypt, and decrypt the data protocol messages.
 Figure 3. How a ZigBee message runs over IP |
When the network is created or devices are added, the network administrator can use the management portions of the ZigBee Application Protocol over UDP to discover the presence of devices and their capabilities. Standard IP tools such as DHCP and DNS will be used to bootstrap the discovery process. The administrator will then establish communication links between devices by manipulating a binding table resident on each device, using the management protocol. The binding table contains IP addresses and ports of peer devices running CAP, as well as cluster identifiers used to connect compatible interfaces.
What's Next?
Arch Rock demonstrated CAP in June at this year's Sensors Expo and has recently submitted the CAP specification to the IETF as an Internet draft. The company is also working with a number of other industry players to refine and advance the architecture.
There is a great deal of interest in finding a way to leverage existing investments in ZigBee while at the same time expanding its scope beyond the 802.15.4 realm. CAP offers a means of having the best of both worlds. It is now up to the industry to choose how to adopt it and move it forward.