The new ZigBee protocol provides an open standard for low-power wireless networking of monitoring and control devices. Working with the IEEE 802.15.4 standard?which focuses on low-rate personal area networking and defines the lower protocol layers (i.e., the physical layer, or PHY, and the medium access control layer, or MAC)?ZigBee
The new standard targets home and building control, automation, security, consumer electronics, PC peripherals, medical monitoring, and toys. These applications require a technology that offers long battery life, reliability, automatic or semiautomatic installation, the ability to easily add or remove network nodes, signals that can pass through walls and ceilings, and low system cost.
ZigBee and the underlying 802.15.4 standard offer the system designer several classes of devices: the reduced-functionality device (RFD), the full-functional device (FFD), and the network coordinator. All ZigBee networks have at least one RFD or FFD and a network coordinator. Most sensor applications fall natively into the RFD class, with extended networks making use of both FFDs and network coordinators to form bridges and links required by the network topology. ZigBee networks can form autonomously, based on connectivity and function.
Reliable data delivery is critical to ZigBee applications. The underlying 802.15.4 standard provides strong reliability through several mechanisms at multiple layers. For example, it uses 27 channels in three separate frequency bands (see Figure 2).
Figure 2. IEEE 802.15.4 provides three frequency bands for communications. Global utility, propagation, path loss, and data rate differences let ZigBee profile developers optimize system performance.
Once on a specific channel, the 802.15.4 radio relies on a number of mechanisms to ensure reliable data transmission. First, the PHY layer uses binary phase shift keying (BPSK) in the 868/915 MHz bands and offset quadrature phase shift keying (O-QPSK) at 2.4 GHz. Both are robust and simple forms of modulation that work well in low SNR environments.
The information is coded onto the carrier with direct sequence spread spectrum (DSSS), an inherently robust method of improving multipath performance and receiver sensitivity through signal processing gain. The receiver sensitivity and selectivity is well suited for inexpensive silicon processes, with most vendors promising to meet or beat the standard. The size of the data payload ranges from 0 to 104 bytes, more than enough to meet most sensor needs. Figure 3 shows the construction of the data frame, also called a data packet.
Figure 3. The data packet is one of four packet structures provided in 802.15.4/ZigBee. In the MAC protocol data unit, the data payload is appended with source and destination addresses, a sequence number to allow the receiver to recognize that all packets transmitted have been received, frame control bytes that specify the network environment and other important parameters, and finally a frame check sequence that lets the receiver verify that the packet was received uncorrupted. This MAC frame is appended to a PHY synchronization and PHY header, which provides a robust mechanism for the receiver to quickly recognize and decode the received packet.
After receiving a data packet, the receiver performs a 16-bit cyclic redundancy check (CRC) to verify that the packet was not corrupted in transmission. With a good CRC, the receiver can automatically transmit an acknowledgement packet (depending on application and network needs), allowing the transmitting station to know that the data were received in an acceptable form. If the CRC indicates the packet was corrupt, the packet is dropped and no acknowledgement is transmitted. When a developer configures the network to expect acknowledgement, the transmitting station will retransmit the original packet a specified number of times to ensure successful packet delivery. If the path between the transmitter and receiver has become less reliable or a network failure has occurred, ZigBee provides the network with self-healing capabilities when alternate paths (if physically available) can be established autono-mously.
In many applications, you can?t afford to make regular trips back to a sensor to change the battery. Ideally, the sensor is good for the life of the battery.
The basic 802.15.4 node is fundamentally efficient in terms of battery performance. You can expect battery lifetimes from a few months to many years as a result of a host of system power-saving modes and battery-optimized network parameters, such as a selection of beacon intervals, guaranteed time slots, and enablement/disablement options.
Consider a typical security application, such as a magnetic reed switch door sensor. The sensor itself consumes almost no electricity; it?s the radio that uses the bulk of the power. The sensor is configured to have a ?heartbeat? at 1 min. intervals and to immediately send a message when an event occurs. Assuming dozens of events per day, analysis shows that the sensor can still outlast an alkaline AAA battery. The configuration allows the network to update the sensor parameters remotely, change its reporting interval, or perform other remote functions and still have (theoretical) battery longevity well beyond the shelf life.
The network configuration plays an important part in the equation; most networks are expected to be stars or cluster trees rather than true meshes (see Figure 4), allowing the individual client devices to conserve battery energy.
Figure 4. Star networks are the most common, basic structure with broad utility. For larger physical environments, the cluster tree is a good way to aggregate multiple basic star networks into one larger network. Some applications will make best use of the mesh structure, which provides alternate route flexibility and the capability for the network to heal itself when intermediate nodes are removed or RF paths change.
Nodes that form the hubs or coordinator routes in the cluster tree can take advantage of beacon-based operation for synchronization across a widely dispersed network with only moderate impact on their own battery life.
System, individual node, service, and battery costs are all important. ZigBee and 802.15.4 maximize utility over this multidimensional space. There is sufficient flexibility in both standards to provide the sensor system developer with an assortment of tradeoffs to optimize cost with respect to system performance. For example, battery life can be optimized at the expense of service interval, and node cost and complexity can be traded for network complexity.
First-generation silicon is only now getting to the early adopters, and the system simplicity and the underlying flexibility of 802.15.4 promise that system developers will find ZigBee-based platforms more cost effective (at the same unit volumes) than Bluetooth or proprietary bidirectional wireless solutions. While platform hardware cost is always a critical part of the overall system cost, you must also consider the less tangible costs of system maintenance, flexibility, and battery life.
ZigBee relies on the basic 802.15.4 standard to establish radio performance. As a short-range wireless standard, 802.15.4 doesn?t try to compete with high-powered transmitters but instead excels in the ultra-long battery life and low transmitter power. The standard specifies transmitter output power at a nominal ?3 dBm (0.5 mW), with the upper limit controlled by the regulatory agencies of the region in which the sensor is used. At ?3 dBm output, single-hop ranges of 10 to more than 100 m are reasonable, depending on the environment, antenna, and operating frequency band.
Instead of pure power, ZigBee augments the basic 802.15.4 simple transmitter and protocol with an extensible, sophisticated network function that allows multi-hop and flexible routing, providing communication ranges that can exceed the basic single-hop. Indeed, depending on the data latency re-quirements, you can practically create networks that use dozens of hops, with cumulative ranges in the hundreds to thousands of meters. Networks can have star, cluster tree, or mesh structures; each comes with its own strengths.
It may not be obvious why a simple temperature or intrusion sensor needs to transmit data at 250 Kbps (at 2.4 GHz) or even 20 Kbps (at 868 MHz), but the reason becomes clear when you consider the need to prolong battery life. Even when the sensor is transmitting only a few bits or bytes, the system can be more efficient if it transmits and receives the data quickly. For instance, a 0.5 mW transmitter consumes many milliwatts whether it?s transmitting 100 or 100,000 bps. For any given quantity of data, transmitting at a higher data rate allows the system to shut down the transmitter and receiver more quickly, saving significant power.
Higher data rates at a given power level mean there?s less energy per transmitted bit, which generally implies reduced range. But both 802.15.4 and ZigBee value battery life more than raw range and provide mechanisms to improve range while always concentrating on battery life.
Sensor systems have a broad range of data-latency requirements. If sensor data are needed within tens of milliseconds, as op-posed to dozens of seconds, the requirement places different demands on the type and extent of the intervening network. For many sensor applications, data latency is less critical than battery life or data reliability.
For simple star networks (many clients, one network coordinator), ZigBee can provide latencies as low as ~16 ms in a beacon-centric network, using guaranteed time slots to prevent interference from other sensors. You can further reduce latencies to several milliseconds if you forego the beacon environment and are willing to risk potential interference from accidental data collision with other sensors on the network.
Data latency can also affect battery life. Generally, if you relax data-latency requirements, you can assume that the battery life of the client nodes will increase. This is even truer of network hubs, which are required to coordinate and supervise the network.
Consider a simple network that has de-manding latency requirements (e.g., a wireless computer keyboard and mouse). The user expects that a keyboard stroke or mouse movement will be reflected on screen in one or two screen-refresh intervals, generally between 16 and 32 ms. For this kind of star network, you can achieve data latency that beats this requirement.
As silicon processes and radio technology progress, transceiver systems shrink in physical size. Forty years ago, a simple radio transceiver was the size of a shoebox and weighed 10 kg. Today, a similar transceiver might easily fit inside a thimble. In the case of ZigBee systems, the radio transceiver has become a single piece of silicon, with a few passive components and a relatively noncritical board design.
Microcontrollers that have native ability to interface with sensors (e.g., built-in digital I/O and A/D converters) have eclipsed even the radio?s rapid reduction in size. Today, the 8-bit MCU that hosts the application may already include dozens of kilobytes of flash memory, RAM, and various hardware-based timer functions, along with the ability to interface directly to the radio transceiver IC. The MCU requires only a few external passive components to be fully functional.
With the minimal overhead added by a ZigBee transceiver, the MCU can often continue to host the application along with the ZigBee protocol. Therefore, the silicon system size of a ZigBee solution (excluding sensors or batteries) is generally smaller than the batteries themselves. This compact form factor lends itself well to innovative uses of radio technology in sensor applications. Cer-tainly, with the advances in silicon-based sensors that have been coming to market over the past five years, it?s practical to design entire systems that take up <10%?20% of the volume of current-generation batteries. In-tegration is the key here, and even higher levels of integration are planned for future ZigBee and 802.15.4 platforms.
It?s important to provide your sensor network with adequate security to prevent the data from being compromised, stolen, or tampered with. IEEE 802.15.4 provides authentication, encryption, and integrity services for wireless systems that allow systems developers to apply security levels as required. These include no security, access control lists, and 32-bit to 128-bit AES encryption with authentication. This security suite lets the developer pick and choose the security necessary for the application, providing a manageable tradeoff against data volume, battery life, and system processing power requirements. The IEEE 802.15.4 standard doesn?t provide a mechanism for moving security keys around a network; this is where ZigBee comes in.
The ZigBee security toolbox consists of key management features that let you safely manage a network remotely. For those systems where data security is not critical (e.g., a set of sensors monitoring microclimates in a forest), you may decide not to implement security features but instead optimize battery life and reduce system cost. For the developer of an industrial or military perimeter security sensor system, data security?and more importantly the ability to defend against sensor masking or spoofing?may have the higher priority. In many ZigBee-approved applications, security will already be a seamless part of the overall system.
ZigBee and the underlying 802.15.4 communications technology could form the basis of future wireless sensors, offering data reliability, long battery life, lower system costs, and good range through flexible networking. IEEE 802.15.4 is ready for release, and the ZigBee network, security, and profile specifications are scheduled to be released latter in the year. The first products are expected in the first half of 2004. ZigBee membership is open to all.