By employing standard hardware and software, you can quickly develop low-cost, bug-free systems.
Anyone interested in wireless networking applications is probably aware of the ZigBee Alliance and movement. The promise of the Alliance is a standardized protocol for large mesh networks with low cost and low power. Perhaps the biggest benefit to come from the Alliance's activity is the availability of low-cost hardware for the IEEE 802.15.4 LR-WPAN (low-rate wireless personal-area network) wireless standard in the 2.4-GHz industrial, scientific, and medical (ISM) frequency band. The availability of low-cost silicon and software for this standard's applications has opened many opportunities not just limited to the environment as defined by the ZigBee Alliance. These applications can range from simple point-to-point cable replacement to complex, large multinode mesh networks.
The low-cost hardware is 802.15.4 compatible at the over-the-air level by its design, but as communication services become more complex or have higher levels of compatibility with standards, the software and development demands can become more costly. As with any product, a wireless application will have certain cost, performance, and time-to-market goals that will drive the selection of the communication services.
Network-aware devices, whether wired or wireless, are commonly described by the Open Systems Interconnection (OSI) Reference Model, as shown in Figure 1. This abstraction model was developed by the International Standards Organization (ISO), starting in the 1980s, to describe communication-related protocols and services. The generic seven-layer model applies to all network and media types. Not all networks use the full model, in fact most don't, but the model is a useful reference with which to relate communication networks.
Starting with Layer 1 closest to the media, the physical layer (PHY) describes the physical properties of the communications network. This can include the electrical properties, signaling properties on the media (wireless or wired), connectors, or data encoding, in other words, anything to do with the actual raw data transmission.
Layer 2 or the Data Link Level is divided into the Medium Access Control (MAC) sublayer and the Logical Link Control (LLC) sublayer. The MAC sublayer is closest to the PHY, is serviced by the PHY and typically provides service to the LLC. The MAC generically determines who is allowed access to the physical medium at a given time. Generically, the LLC sublayer sits above the MAC and provides multiplexing of protocols transmitted over the MAC, optional flow control, and any requested detection and retransmission of dropped packets.
The five additional layers (from bottom to top) are:
- Network (Layer 3)Path determination and IP (logical addressing)
- Transport (Layer 4)End-to-end connections and reliability
- Session (Layer 5)Inter-host communication
- Presentation (Layer 6)Data representation and encryption
- Application (Layer 7)User application running on top of the network
The IEEE 802.15.4 standard, which is limited to the PHY and MAC Layers, can be related to the OSI model. Note that the 802.15.4 standard isn't meant to be “all things to all people.” Figure 2 shows how the OSI model has been adapted in the 802.15.4 standard.
The standard specifically targets the following goals:
- 250-kbit/s over-the-air data rate
- Star, tree, or peer-to-peer operation
- Guaranteed time slots (GTSs) and beaconing for communication
- CSMA-CA channel access
- Acknowledged messaging for reliable data transfer
- Low power
- Short range operation
- Reasonable battery life
- Simple and flexible protocol
For the IEEE 802.15.4 standard PHY, two services are provided to the upper levels: the PHY data and management services. The PHY's features include radio transceiver activation/deactivation, radio channel selection, energy level detection (ED) and received signal quality (LQI), clear channel assessment (CCA), and transmitting and receiving packets across the 2.4-GHz ISM frequency band.
An IEEE 802.15.4 standard MAC provides the MAC data service and management services. The data service enables transmission of MAC protocol data units (MPDU) across the PHY data service. The MAC sublayer features include beacon management, channel access, GTS management, frame validation, acknowledged frame delivery, and association and disassociation. The MAC also provides support for implementing defined security mechanisms.
Generically, the LLC sublayer sits above the MAC and multiplexes the protocols transmitted over the MAC, and provides optional flow control and any requested detection and retransmission of dropped packets. However, the IEEE 802.15.4 standard has modified and defined Layer 2 to:
- Allow an IEEE 802.2 LLC to access the 802.15.4 MAC sublayer through a service specific convergence sublayer (SSCS) as defined in Annex A of the standard. Use of the LLC and SSCS is one defined path, but isn't the path typically used by applications or by ZigBee networks.
- Allow direct access to the MAC by the upper layers. Proprietary networks and ZigBee networks use this path.
The 802.15.4 standard shows the OSI upper layers as having been collapsed to just two layers as shown in Figure 2 . The Network Layer typically provides network configuration, manipulation, and message routing. The Application Layer provides the intended function of the device sitting on the 802.15.4 standard network. The network and application layers aren't specifically defined by the standard and are up to the user.
The model can now be extended to the ZigBee environment, as shown in Figure 3.
A ZigBee stack is built upon the 802.15.4 standard and uses the 802.15.4 model where the Network Layer has direct access to the MAC. The ZigBee Network Layer provides network topology and MAC management, routing, discovery protocol, and security management. The ZigBee network can overlay its security service to the additional security service available in the MAC layer. The user application builds on the ZigBee stack through its application interface (API). The ZigBee Alliance has what are called application profiles for specific application categories. These allow standardization of the functionality, which helps compliance and interoperability among different vendors' products. It's also important to note that the ZigBee stack doesn't use all the features of the 802.15.4 standard MAC, which can lead to smaller code size but not include a service desired by the user.
Comparing compliance levels
The available 802.15.4 standard hardware ranges from transceivers that require support of a separate MCU, to full system-on-chip (SoC) or system-in-package (SiP) solutions where an integrated MCU and other protocol acceleration hardware can be present. 802.15.4 Standard transceiver hardware typically provides the PHY functionality and some measure of the MAC functionality, and the rest of the MAC functionality is software driven. Vendors recognize the range of applications for which their 802.15.4 standard devices can be used and offer a wide range of software tools to enable and expedite application development.The applications generally fall into three basic categories:
- Proprietary communication services, compliant only with the IEEE 802.15.4 standard PHY Layer
- IEEE 802.15.4 standard MAC compliant services with proprietary upper layer/applications services
- Full ZigBee network compliance built on the 802.15.4 standard and a ZigBee software stack
More complex models and applications imply larger memory footprints, more MCU performance, and higher cost that are demanded by greater capability.
An IEEE 802.15.4 standard PHY that complies with proprietary MAC and communication services benefits little from standardization or interoperability. Also, the supplied services of the 802.15.4 standard MAC may not meet the needs of the communications service, nor provide useful services to speed application development. There can be a number of reasons to go to a proprietary solution:
- Product cost (consumer applications)A low performance or consumer application can be very cost sensitive. A small memory footprint with a low-end MCU can translate to the lowest cost solution.
- Protocol requirementsAn example could be an RS232 wireless link. This isn't a true networking application with a point-to-point link, so the 802.15.4 standard MAC offers no significant advantage. Packet formats and timing are completely defined by the developer and because applications are custom and usually smaller in scope and complexity than a standards based solution, initial application prototyping may be faster. Quality of service (QoS) becomes most important with reliability of data “going through” uppermost, even at the sacrifice of link bandwidth. Unique protocol features regarding retries and flow control are required, while trying to retain maximum throughput.
- Unique application requirementsWith low power and cost, and reasonable bandwidth, 802.15.4 standard hardware has been used in a wide range of unique applications, such as RF monitoring and ID for cattle, remote controls, and low-rate video and sensor monitoring. Sleep times can be very long and battery life is the most important parameter. Maximizing the limited bandwidth (250 kbits/s over-the-air) can be most important. Highly variable data rate and reporting can also be important. The ultimate conclusion is that the 802.15.4 standard capabilities for these applications don't fit the bill.
Ultimately, the primary reasons for proprietary solutions seem to be cost (inexpensive MCU with limited memory) or unique protocol/application requirements. These may be benefits, but tradeoffs exist that the developer should consider before embarking on a proprietary solution. Because packet timing isn't inherently defined by proprietary systems, the embedded system must be written to allow easy portability across differing architectures. Also, “MAC” layer timing, packet messaging, channel management, and addressing schemes, among others, must be defined by the developer to provide a scalable solution.
To maximize the benefits of a proprietary solution, approaches to a proprietary “MAC” layer should be simple in nature or different than the 802.15.4 standard approach. If the custom MAC solution is complex, the development time and validation of the complex approach will begin to undermine the benefit of rapid prototyping and lower system costs. In addition, as the developer adds features to their proprietary MAC layer over time, the solution may begin to approach the functionality of the 802.15.4 standard MAC. If this occurs, starting with the 802.15.4 standard MAC solution may be faster, cheaper, and more reliable. Another disadvantage of proprietary solutions is that no standard security service is provided.
Proprietary communication services
The next compliance level uses a full 802.15.4 standard service through the MAC layer. The advantages of this approach are the additional features and services available through the standard:
- Star or cluster tree or peer-to-peer operation for true networked applications
- Channel management using CSMA-CA services or channel scan
- Guaranteed time slots (GTS) for communication and beaconing
- Acknowledged messaging for reliable data transfer
- Standard, simple, and flexible protocols
- Optional AES-128 security
- Expandable to other compliant applications
From a business perspective, larger volume customers may have a requirement sourcing from multiple vendors. Also, on a standards-based application, it's typically easier to port only the application to different platforms using the standard MAC rather than a proprietary solution. With more vendors having a standard solution available, this can provide competition in cost, quality, and delivery. From a reliability point of view, a standard has many more developers than a proprietary solution, so the 802.15.4 standard code base is shared across a larger group of users. This means that reliability will improve over time faster than a proprietary solution.
The higher layer functions, such as the network and application layers, must still be written. The question arises: why not use the full set of ZigBee network services? The answer is similar to the full proprietary solution where the application network architecture and services require unique features that aren't met by the ZigBee network services. Also, in some cases the full application can still yield a smaller memory footprint than a full ZigBee stack.
Tradeoffs for the 802.15.4 standard MAC approach provide a mixed benefit. The MAC certainly has a richer set of functionality and services from which to build. The application software needn't develop services such as address management, acknowledged messaging, and use of time slots for better communication. Another key advantage in some applications is embedded security services. The potential downside is the need for the application to develop the network architecture and service; however, this is really the compelling reason not to use the ZigBee stack. To justify use of the MAC without the higher level standard ZigBee services, there must be a need to meet special network features such as ROS, net architecture, or GTS and beaconing (which ZigBee networks don't support).
Although there's 802.15.4 standard compliance, a proprietary network layer probably won't allow compliance to other vendors. Development time can also be longer to write and test potentially complicated network protocol. As in the proprietary arena, vendors supply software tools to support the 802.15.4 standard MAC.
Full ZigBee stack
A ZigBee network stack is built upon the IEEE 802.15.4 standard and adds upper-level services. The application interfaces to the standard stack through an API, providing the advantages of a fully standardized communications stack, including full compatibility across applications and vendors. There are also the marketing benefits of a public certification process, and leveraged marketing awareness and branding via the ZigBee Alliance. Time-to-market can also benefit because the user needn't develop all the protocols and services associated with the upper-layer services, such as the Network layer.
The ZigBee network solution preserves many of the advantages of the 802.15.4 standard (low power, reasonable cost, services) with the benefit of the standardized upper-level services. In addition to a defined API, the ZigBee network offers several “application profiles” such as home automation for vendors doing similar functions. These profiles ensure an even greater level of compatibility across vendors. A developer may be able to purchase part of a system solution as opposed to developing it in-house. The goal of the full ZigBee network approach is to maximize the market applications and nodes through standardization and drive system cost down even further.
Table 1 summarizes the communication software stack solutions versus features.
The available range of low-cost IEEE 802.15.4 hardware and software has enabled a wide span of applications. Cost-sensitive consumer applications will drive solutions that tend to be unsophisticated and proprietary. Special requirements or non-standard applications may also drive proprietary solutions, although they may not be lowest cost due to memory size or development time. Using some level of standard services, whether it be the 802.15.4 standard or full ZigBee networks, can sometimes cut development time and maintain reasonable cost. Also, the promise of greater standardization is greater compatibility between applications and vendors which can lead to long-term lower cost.
Tom Balph is a senior systems and applications engineer at Freescale Semiconductor. He provides support for the company's ZigBee and IEEE802.15.4 products. Balph can be reached at .
Larry Roshak is an applications engineer for 802.15.4 transceiver products for Freescale Semiconductor. Roshak received a masters in computer science from Florida Atlantic University and a bachelors in electrical engineering from the University of Arizona. He can be reached at .