Wireless sensor networks

Compact Application Protocol (CAP): Uniting the Best of IP and ZigBee

The popular ZigBee mesh network protocol has caught on as a means of distributed sensing and control. Mating it with IP networks has until now been problematic. A new protocol definition now brings the two together.


  • Page 1 of 1
    Bookmark and Share

In several industries over the past three decades, ubiquitous automation has occurred hand-in-hand with the emergence of industry-standard application protocols. Starting with HART in 1980 for process control and continuing with BACnet and LONtalk for building automation and Common Industrial Protocol (CIP) for manufacturing, application protocols have provided a way to integrate different kinds of devices, potentially from different vendors, into an operational network, and to configure the devices to the task at hand.

Historically, such protocols were defined for a specific, widely used communication link–e.g., RS485 for BACnet and DeviceNet for CIP–and they specified the physical medium (layer 1), the link and its addressing (layer 2), and the application data representation, naming and services (layer 7) in a vertically integrated solution. Each protocol defines a distributed object abstraction, where each device is treated as a named object containing a set of attribute-value pairs and possibly supporting a set of commands. An application profile defines the attributes in each type of object (i.e., device) and how to get and set the associated values. The protocol defines how to discover these services, how to bind objects together to form specific relationships, and the formats of all the messages exchanged between them.

Invariably, these industrial application protocols evolved to support additional communication links. And to take advantage of technological innovation without redefining the application protocol, they invariably adopted IP. IP’s layered architecture separates the link layer from the application layer by a network layer that provides link-independent host addressing and routing of datagrams, and a transport layer that provides application-independent reliability and service naming.

Starting in 2004, ZigBee followed suit by defining a vertically integrated protocol suite that provided a distributed object abstraction for devices on a new low-power wireless link, IEEE 802.15.4. The broad utility of this link led to the definition of a wide variety of application profiles–including home automation, commercial building automation and, most recently, smart energy–which cut across industry segments. Moreover, the short range of this low-power link meant that multihop routing, not just link connectivity, was required in most applications, and the ZigBee organization defined and redefined a series of network layers.

One silver lining in the perennial, often incompatible, evolution of the network protocols is that the application protocol remained somewhat independent of the specifics of the IEEE 802.15.4 link layer and the ZigBee network layer. Its compact encodings do reflect the small packet size and limited bandwidth of this link, so it is suitable for use on this and any more capable link.

Finally, in 2007, the link used by ZigBee (and other industry standards) became a full-fledged member of the IP family with the IETF’s adoption of the 6LoWPAN adaptation layer, which specifies how to carry IPv6 datagrams in a compact form over 802.15.4. Just as with Ethernet or Wi-Fi, applications can be built for 6LoWPAN networks by simply opening a UDP or TCP socket and sending/receiving messages to/from an IP address and port number. Indeed, the two parties in the communication need not be on the same physical link, because routers take care of getting the packets from one to the other.

The Compact Application Protocol (CAP) completes the unification of IP and ZigBee by transforming the Zigbee application profile so that it is defined for UDP transport over any IP link (Figure 1).CAP does everything that ZigBee can do when two devices are in the same 802.15.4 network, but it allows any device on any link to operate in the same manner. Furthermore, the links and routing layers can continue to advance beneath CAP without changes to the application or the application protocol.

CAP in Action

The main concepts in CAP are illustrated with an example application scenario (Figure 2). This scenario reflects a typical residential setting and is easily generalized to a building or commercial or enterprise setting. From a network point of view, the usual home router is connecting an Ethernet LAN and Wi-Fi (802.11) wireless LAN to form a private IP network. It connects to the Internet over a WAN link through a firewall with network address translation, so any of the hosts can access Internet resources but outside hosts cannot access private resources. The one addition to the typical home network is that the router also has a 6LoWPAN (802.15.4) interface.

The embedded wireless devices, including the electric meter, dryer with load control device, switches, lamp, thermostat and handheld all have IPv6 addresses (in addition to unique IEEE 802.15.4 MAC addresses) and can send and receive messages using UDP or TCP sockets to and from each other or the other hosts in the home network. The flow of communication may be quite asymmetric, but the ability for general communication is provided by the IP network layer. In this scenario, the LAN and Wi-Fi are an IPv4 subnet, with the LAN containing a home server and an inverter for solar panels on the roof. The Wi-Fi WLAN is used by the laptop and handheld device, as well as an ambient display, such as the common digital picture frame, which displays Smart Energy status. The home router provides standard DHCP to assign IP addresses for those hosts that are not configured with static addresses and performs IPv6-to-IPv4 translation.

The Compact Application Protocol raises the level of abstraction so the user can view this collection of devices as one or more plug-and-play applications. In CAP, as in the ZigBee Application Layer, services are provided by an endpoint on a physical device. Each endpoint is associated with a particular application profile. The application profile defines a set of device types and for each type a set of clusters, which provides the functionality of the service with a standard interface and data representation. In particular, each cluster provides specific attributes and commands.

In this scenario there are two application profiles, both of which naturally span multiple kinds of communication links. The Home Automation (HA) profile includes a switch, lamp, thermostat, laptop and server. The Smart Energy (SE) profile includes an electric meter, dryer, thermostat, home server and ambient display. The thermostat has two endpoints, one for each profile, while the rest of the embedded devices have a single endpoint. The home server has two services, perhaps from different vendors, each with a single endpoint.

The lamp, an on/off light device in the HA profile, serves the OnOff cluster by providing an on/off attribute (the state of the lamp) and two commands to control that state. This endpoint is bound, via the CAP binding protocol, to a particular on/off switch device in the HA profile that is the client side of the on/off cluster. It maintains an attribute that is the position of the switch and issues the on and off commands to the lamp endpoint. Thus far, the application is identical to what it would be with ZigBee.

The implementation of the CAP library is written using a conventional UDP socket interface rather than a ZigBee-specific API; the addressing that is hidden inside of it uses IP addresses rather than 802.15.4-specific MAC addresses. The power of this small change is manifested when the Wi-Fi-connected laptop is used as a remote control for the lamp. The laptop is also in the HA profile and has an application built on CAP, but in this case it is a Windows application using a CAP library that is implemented using the WinSock API. The laptop is also bound to the on/off light endpoint in the lamp. It can query the lamp’s on/off attribute with a ReadAttribute request and can actuate the lamp with the on and off commands.

The home server also has an endpoint in the HA cluster, perhaps using a CAP library written for the sockets API in Linux or Mac OS X, so it can operate as a client of the Thermostat cluster of the thermostat endpoint in the HA profile, allowing the homeowner to program the thermostat using a convenient GUI. Indeed, another wireless 6LoWPAN switch could be bound to the multimedia application on the home server to act as a remote control for the entertainment center. While these devices happen to be attached to different IP links and offer different operating system environments, they provide a consistent set of interoperable application profiles through CAP. The system operates as if all the devices were on an 802.15.4 network in ZigBee, but IP addressing and UDP transport are used for the physical communication so that the application is link- and platform-independent.

This additional level of generality is even more important with regard to the second Smart Energy application in this network. The electric meter is a metering device in the SE application profile and serves the Simple Metering cluster, which provides an InstantaneousDemand attribute, in addition to other attributes. The ambient display is the client of this cluster, providing a convenient graphical presentation of real-time energy use. But these devices, as well as the thermostat, dryer load control unit and energy services portal, also provide the Demand Response cluster within the SE profile.

In times of peak demand, a DR command is sent from the utility to the energy services portal, which utilizes the homeowner preferences to decide how to reduce demand, and issues load control commands to the thermostat, dryer and ambient display, which alerts the homeowner. The DR command may arrive directly through the meter, over the Internet, or via a dedicated out-of-band path, depending on the utility; but the IP networking capability allows it to be routed to where the action is initiated.

The extensibility offered by CAP is also worth noting: the grid tie inverter for the solar energy system is also on the network, and, though no such device is currently defined in the SE profile, provisions are made for vendor-specific clusters. In addition, all the resources described here are contained within the private IP network, but select portions could be moved out to remotely hosted services with established security mechanisms, including VPNs and SSL, to protect them.

CAP also enables the system installer or homeowner to confirm that a new device is present on the network, determine its capabilities, and configure its relationships with other devices in the network. In addition, CAP includes its own security infrastructure to protect communication between devices.

After the new device connects to the IP network and gets an IP address, the installer can use a simple handheld configuration tool to discover the device and enumerate its capabilities. With CAP, this tool might be a specialized physical device, and it might also be an application running on a regular PC or laptop. The configuration tool uses the CAP discovery protocol to query devices for information about the application profile, device type and specific clusters supported on each of their endpoints, and then presents this information to the installer in a friendly way. CAP can use broadcast communication in small networks, and in large networks can make use of a secondary CAP discovery server with which each device automatically registers at startup time.

Once the installer confirms that the new device is in the network and has the desired functionality, the configuration tool can be used to draw connections with other devices. To establish a connection, the tool sends a CAP binding command to the device, which connects a particular client or server cluster in that device with a matching cluster on another device. Inside each CAP binding is the IP address, UDP port and endpoint ID number of the peer device, which is used to transparently connect the light and the switch, for example, or the meter and the ambient display.

Certain high-security devices and applications may also need application-layer authentication and encryption when communicating, analogous to secure HTTP or secure sockets. CAP supports shared encryption keys, which may be pre-assigned or requested from a Trust Center service running on a different IP host.

CAP Considerations

The most important consideration when choosing an application protocol is the industry-specific decisions that have been collected and invested in its design. These decisions provide a shared understanding of how to define and describe devices and their functions. As mentioned above, while BACnet and LONtalk are chiefly focused on building automation and industrial control, the ZigBee work so far has produced common definitions for home automation and smart energy. Choosing CAP preserves this design investment.

A second key consideration is the technologies on which the application protocol depends. Choosing an application protocol that depends only on the presence of an IP network increases the variety of devices and applications that can be included in the system, decouples the system design from any particular link technology, and helps to future-proof the upgrade path. For the application domains covered by ZigBee, the CAP architecture presents a unified approach to networked embedded systems development.

Arch Rock
San Francisco, CA.
(415) 692-0828.