Design networks for wireless M2M applications

by Chris Downey, Laird Technologies , TechOnline India - February 14, 2012

Zigbee has some great features which make it a powerful protocol for M2M communications, but that does not mean it is optimized for all networks. Identifying the key requirements and selecting a wireless solution which is optimized for star networks can reduce the time to market and also provide for a more robust solution.

Multi-hop mesh protocols, such as Zigbee®, possess the capability to link together low data-rate machine-to-machine (M2M) applications. These applications operate through a point-to-multipoint network, otherwise known as a star network. Touching on many of the requirements of star networks, like low data rate, low power, enhanced range through the mesh, and automated on-demand routing, Zigbee, in particular, has been positioning itself as the standard bearer for wireless, low-power meshing protocols.

Requirements for Star Networks

It is important to consider the actual data flow through the network when implementing a Zigbee-type mesh. While all nodes may be capable of communicating with each other, in reality, most networks are point-to-multipoint (or multipoint-to-point, depending on the perspective), and form a star topology. Data flows from a central server to specific end points, which in turn collect data or provide some sort of action. Data from the end points is also able to flow back to the central point. For a star network, a multi-hop mesh is not a requirement; but rather a feature to ensure connectivity from all nodes. In fact, for star networks, the amount of overhead required for a Zigbee network may be restrictive to an optimal solution.

Below is an example of a star network with multiple end nodes, in which all nodes communicate to a single central sever.

Figure 1: Star Network

Zigbee for Star Applications

Zigbee has a dual-layer addressing scheme with a lower layer Institute of Electrical and Electronics Engineers (IEEE) address being hard coded on the nodes, and a dynamically assigned network address being used for transport. Because only the network address is used to route data, an end user must translate between the IEEE address and the network address in order to properly address the packets. This is analogous to how the Address Resolution Protocol (ARP) operates in traditional Ethernet networks. This dual-layer addressing is common for routed networks and provides a layer of abstraction from the hardware (IEEE) layer. For star networks, it only serves to provide another layer of complexity to a simple issue of connectivity, as seen in the figure below.

Figure 2: Star Network Implemented Over a Multi-hop Mesh



The Zigbee mesh is based on an underlying RF protocol defined by the IEEE 802.15.4 standard. The 802.15.4 standard is a direct-sequence spread spectrum (DSSS) modulation system designed to operate in the 868 MHz, 900 MHz, and 2.4 GHz industrial, scientific and medical (ISM) bands. In practice, most transceivers operate at 2.4 GHz, as it provides worldwide acceptance and the higher 250 kbps RF data rates. In many parts of the world though, including Europe, 2.4 GHz DSSS transceivers are limited to 10 mW of radiated output power. Compare this to frequency-hopping systems such as Bluetooth and proprietary RF, which can radiate up to 100 mW per Conformité Européenne (CE) regulations (10x the output power). This limitation reduces the overall power consumption of the module, but it also limits the range of the module as well. Zigbee addresses this range issue through multi-hop mesh routing. 

Adding routers to provide connectivity has drawbacks though. First, it increases the overall costs of the system as there is a requirement for more transceivers. Second, as each packet is routed through an additional node, the overall latency of the system increases due to the node possessing single transceiver that prevents it from transmitting and receiving at the same time. The latency can be further increased if there is a need to perform a route request prior to transporting the data packet.

The complexity of the data traffic can be seen in the following data flow diagram below.

Figure 3: Zigbee Packet Delivery


In the above figure, if it is assumed that each of the 10 transmissions takes at least 10 ms (and that would not take into account the need to retransmit any data), then it would take over 100 ms for the user to receive their acknowledgement back. 

Zigbee Pro, the third major revision of the Zigbee spec, addresses this by implementing source routing. Source routing can reduce the amount of route requests that are required, but adds additional overhead to the data packets sent across the air by including each of the hops’ network addresses in the packet. The high latency can restrict Zigbee networks from being able to effectively stream data from one point to another. If the Zigbee nodes above can only transmit 100 bytes of data with every packet transmission, then at 100 bytes every 100 ms, the actual data rate is only 8 kbps; less than the 9600 baud rate that many applications use for data transfer. It is much less than the 115,200 that many more applications require. Due to these restrictions, all data must be managed as discrete packets which are sent at infrequent intervals. 

Finally, if additional routers are required to provide connectivity, then the end user is responsible for providing the infrastructure to support the intermediate routers.  Additional nodes result in additional costs, additional power sources and must be placed in a location that enables them to provide optimum coverage.  


These coverage issues can often be resolved by substituting for the lower power intermediate router with higher power transmitters at each end of the link. Moving from 10 mW to 100 mW will provide a 10 dB gain in the link budget; roughly 2.5x increase in range. In addition, for non CE markets such as North America, higher output powers up to 1W are available in order to provide additional coverage. Once free from the constraints of Zigbee’s power and data rate restrictions, end users can select from a wealth of standard and proprietary solutions that suit their M2M applications.   


Star networks present unique challenges, from managing the number of end nodes, ensuring connectivity, and balancing data from and to the source point. These challenges are enough without adding the unnecessary overhead from a multi-hop mesh solution. Star networks can benefit from a simpler, more effective solution. Zigbee has some great features which make it a powerful protocol for M2M communications, but that does not mean it is optimized for all networks. Identifying the key requirements and selecting a wireless solution which is optimized for star networks can reduce the time to market and also provide for a more robust solution.

About the Author:

Chris Downey has been with Laird Technologies for over three years. He has been responsible for the network design and troubleshooting for a Tier 1 data communications network, systems administration in a nationwide enterprise network, and also was formally a field applications engineer for embedded wireless modules. Mr. Downey is currently a product manager for wireless modules at the Lenexa, Kansas facility. He has a BS in Electrical Engineering.

About Laird Technologies, Inc:

Laird Technologies designs and manufactures customized, performance-critical products for wireless and other advanced electronics applications. For more information, see

Article Courtesy: Microwave & RF DesignLine


blog comments powered by Disqus