Why is ZigBee needed?
There are a multitude of standards like Bluetooth and WiFi that
address mid to high data rates for voice, PC LANs, video, etc. However,
up till now there hasn't been a wireless network standard that meets the
unique needs of sensors and control devices. Sensors and controls don't
need high bandwidth but they do need low latency and very low energy
consumption for long battery lives and for large device arrays.
There are a multitude of proprietary wireless systems manufactured
today to solve a multitude of problems that don't require high data
rates but do require low cost and very low current drain. These
proprietary systems were designed because there were no standards that
met their application requirements. These legacy systems are creating
significant interoperability problems with each other and with newer
technologies.
The ZigBee Alliance is not pushing a technology; rather it is
providing a standardized base set of solutions for sensor and control
systems.
- The physical layer was designed to accommodate the need for a low
cost yet allowing for high levels of integration. The use of direct
sequence allows the analog circuitry to be very simple and very
tolerant towards inexpensive implementations.
- The media access control (MAC) layer was designed to allow
multiple topologies without complexity. The power management
operation doesn't require multiple modes of operation. The MAC
allows a reduced functionality device (RFD) that needn't have flash
nor large amounts of ROM or RAM. The MAC was designed to handle
large numbers of devices without requiring them to be
"parked".
- The network layer has been designed to allow the network to
spatially grow without requiring high power transmitters. The
network layer also can handle large amounts of nodes with relatively
low latencies.
ZigBee is poised to become the global control/sensor network
standard. It has been designed to provide the following features:
- Low power consumption, simply implemented
- Users expect batteries to last many months to years! Consider
that a typical single family house has about 6 smoke/CO
detectors. If the batteries for each one only lasted six months,
the home owner would be replacing batteries every month!
- In contrast to Bluetooth, which has many different modes and
states depending upon your latency and power requirements, ZigBee/IEEE
802.15.4 has two major states: active (transmit/receive) or sleep.
The application software needs to focus on the application, not on
which power mode is optimum for each aspect of operation.
- Even mains powered equipment needs to be conscious of energy.
ZigBee devices will be more ecological than their predecessors
saving megawatts at it full deployment. Consider a future home that
has 100 wireless control/sensor devices,
- Case 1: 802.11 Rx power is 667 mW (always on)@ 100
devices/home & 50,000 homes/city = 3.33 megawatts
- Case 2: 802.15.4 Rx power is 30 mW (always on)@ 100
devices/home & 50,000 homes/city = 150 kilowatts
- Case 3: 802.15.4 power cycled at .1% (typical duty cycle) =
150 watts
- Low cost to the users means low device cost, low installation cost
and low maintenance.
- ZigBee devices allow batteries to last up to years using
primary cells (low cost) without any chargers (low cost and easy
installation). ZigBee's simplicity allows for inherent
configuration and redundancy of network devices provides low
maintenance.
- High density of nodes per network
- ZigBee's use of the IEEE 802.15.4 PHY and MAC allows networks
to handle any number of devices. This attribute is critical for
massive sensor arrays and control networks.
- Simple protocol, global implementation
- ZigBee's protocol code stack is estimated to be about 1/4th of
Bluetooth's or 802.11's. Simplicity is essential to cost,
interoperability, and maintenance. The IEEE 802.15.4 PHY adopted
by ZigBee has been designed for the 868 MHz band in Europe, the
915 MHz band in N America, Australia, etc; and the 2.4 GHz band
is now recognized to be a global band accepted in almost all
countries.
ZigBee/IEEE 802.15.4 - General Characteristics
- Dual PHY (2.4GHz and 868/915 MHz)
- Data rates of 250 kbps (@2.4 GHz), 40 kbps (@ 915 MHz), and 20
kbps (@868 MHz)
- Optimized for low duty-cycle applications (<0.1%)
- CSMA-CA channel access
- Yields high throughput and low latency for low duty cycle
devices like sensors and controls
- Low power (battery life multi-month to years)
- Multiple topologies: star, peer-to-peer, mesh
- Addressing space of up to:
- 18,450,000,000,000,000,000 devices (64 bit IEEE address)
- 65,535 networks
- Optional guaranteed time slot for applications requiring low
latency
- Fully hand-shaked protocol for transfer reliability
- Range: 50m typical (5-500m based on environment)
ZigBee/IEEE802.15.4 - Typical Traffic Types Addressed
- Periodic data
- Application defined rate (e.g., sensors)
- Intermittent data
- Application/external stimulus defined rate (e.g., light
switch)
- Repetitive low latency data
- Allocation of time slots (e.g., mouse)
Each of these traffic types mandates different attributes from the
MAC. The IEEE802.15.4 MAC is flexible enough to handle each of these
types.
- Periodic data can be handled using the beaconing system whereby
the sensor will wake up for the beacon, check for any messages and
then go back to sleep.
- Intermittent data can be handled either in a beaconless system or
in a disconnected fashion. In a disconnected operation the device
will only attach to the network when it needs to communicate saving
significant energy.
- Low latency applications may choose to the guaranteed time slot (GTS)
option. GTS is a method of QoS in that it allows each device a
specific duration of time each Superframe to do whatever it wishes
to do without contention or latency.
The IEEE 802.15.4 PHY and MAC along with ZigBee's Network and
Application Support Layer provide:
- Extremely low cost
- Ease of implementation
- Reliable data transfer
- Short range operation
- Very low power consumption
- Appropriate levels of security
There are two physical device types for the lowest system cost. The
IEEE standard defines two types of devices:
- Full function device (FFD)
- Can function in any topology
- Capable of being the network coordinator
- Capable of being a coordinator
- Can talk to any other device
- Reduced function device (RFD)
- Limited to star topology
- Cannot become a network coordinator
- Talks only to a network coordinator
- Very simple implementation
An IEEE 802.15.4/ZigBee network requires at least one full function
device as a network coordinator, but endpoint devices may be reduced
functionality devices to reduce system cost.
- All devices must have 64 bit IEEE addresses
- Short (16 bit) addresses can be allocated to reduce packet size
- Addressing modes:
- Network + device identifier (star)
- Source/destination identifier (peer-peer)

Security
When security of MAC layer frames is desired, ZigBee uses MAC layer
security to secure MAC command, beacon, and acknowledgement frames.
ZigBee may secure messages transmitted over a single hop using secured
MAC data frames, but for multi-hop messaging ZigBee relies upon upper
layers (such as the NWK layer) for security. The MAC layer uses the
Advanced Encryption Standard (AES) as its core cryptographic algorithm
and describes a variety of security suites that use the AES algorithm.
These suites can protect the confidentiality, integrity, and
authenticity of MAC frames. The MAC layer does the security processing,
but the upper layers, which set up the keys and determine the security
levels to use, control this processing. When the MAC layer transmits
(receives) a frame with security enabled, it looks at the destination
(source) of the frame, retrieves the key associated with that
destination (source), and then uses this key to process the frame
according to the security suite designated for the key being used. Each
key is associated with a single security suite and the MAC frame header
has a bit that specifies whether security for a frame is enabled or
disabled.
The ZigBee Network
Coordinator
- Sets up a network
- Transmits network beacons
- Manages network nodes
- Stores network node information
- Routes messages between paired nodes
- Typically operates in the receive state
|
The ZigBee Network
Node
- Designed for battery powered or high energy
savings
- Searches for available networks
- Transfers data from its application as
necessary
- Determines whether data is pending
- Requests data from the network coordinator
- Can sleep for extended periods
|
Network Routing Overview
Perhaps the most straightforward way to think of the ZigBee routing
algorithm is as a hierarchical routing strategy with table-driven
optimizations applied where possible.
- NWK uses an algorithm that allows stack implementers and
application developers to balance unit cost, battery drain, and
complexity in producing ZigBee solutions to meet the specific
cost-performance profile of their application.
- Started with the well-studied public-domain algorithm AODV and
Motorola's Cluster-Tree algorithm and folding in ideas from Ember
Corporation's GRAd.
Network Summary
The network layer builds upon the IEEE 802.15.4 MAC's features to
allow extensibility of coverage. Additional clusters can be added;
networks can be consolidated or split up.
Application layer
The ZigBee application layer consists of the APS sub-layer, the ZDO
and the manufacturer-defined application objects. The responsibilities
of the APS sub-layer include maintaining tables for binding, which is
the ability to match two devices together based on their services and
their needs, and forwarding messages between bound devices. Another
responsibility of the APS sub-layer is discovery, which is the ability
to determine which responsibilities of the ZDO include defining the role
of the device within the network (e.g., ZigBee coordinator or end
device), initiating and/or responding to binding requests and
establishing a secure relationship between network devices. The
manufacturer-defined application objects implement the actual
applications according to the ZigBee-defined application descriptions
Patrick Kinney (pat.kinney@ieee.org)
is an Independent Consultant specializing in Wireless Communications.
Previously he was the Vice President of Communication Technologies at
Invensys responsible for directing communication efforts throughout
Invensys's divisions. He received a Bachelors of Science in Electrical
Engineering from the University of Notre Dame, Notre Dame Indiana. He
has 26 years experience in the design and development and of
communication systems and products. He is the Secretary of the IEEE
P802.15 Working Group for Wireless Personal Area Networks and vice-chair
of the IEEE 802.15.4 Task Group. He is also a Working Group Chair and
the Secretary of the ZigBee Alliance, an association of companies
working together to create a very low-cost, very low power consumption,
two-way, wireless communications standard. |