Give away medical masks when you place an order. learn more

Moving Beyond ZigBee for Star Networks

It is important to consider the actual data flow when implementing a mesh network. Despite its numerous advantages in M2M applications, ZigBee may not always be the best choice.

Multi-hop mesh protocols, such as ZigBee®, are getting a lot of press for their ability to link together low data rate, machine-to-machine (M2M) applications. ZigBee, in particular, is targeting itself as the standard bearer for wireless, low-power mesh protocols. Many of the features of a ZigBee solution touch on the requirements for the expanding wireless M2M markets. Low data rate, low power, enhanced range through the mesh, and automated on-demand routing of packet data are key aspects of ZigBee that are creating such a buzz in the M2M market space.

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 your perspective), and form a star topology. Data flows from a central server to specific end points which collect data or provide some sort of action. Data from the end points is also able to flow back to the central point. This is the basic network flow for the majority of wireless sensor and control applications including building automation, telehealth, smart energy, and retail. For a star network, a multi-hop mesh is not a requirement, but rather a feature to ensure connectivity from all nodes.

In fact, in star networks, the amount of overhead required for a ZigBee network may be restrictive to an optimal solution.

Figure 1 shows an example of a star network with multiple end nodes which all communicate to a single central sever.

Figure 1: Star network.

Review of ZigBee for star applications

ZigBee has a dual-layer addressing scheme, with a lower-layer IEEE address hard-coded on nodes and a dynamically assigned Network Address used for transport. Only the Network Address is used to route data, so an end user must translate between the IEEE address and the Network Address to properly address packets. This is analogous to how 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 Figure 2.

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. IEEE 802.15.4 is a direct sequence spread spectrum (DSSS) modulation system designed to operate in the 868 MHz, 900 MHz, and 2.4 GHz 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, 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 CE regulations — ten times the output power. This limitation reduces the overall power consumption of the module, but also limits the range of the module. ZigBee addresses this range issue with the multi-hop mesh routing.

Adding routers to provide connectivity has drawbacks. First, it increases the overall cost 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, because a node only has a single transceiver and cannot transmit and receive 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 is presented in Figure 3.

Figure 3: ZigBee packet delivery.

In Figure 3, if you assume each of the ten transmissions takes at least 10 ms (which 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 specification, addresses this by implementing source routing. Source routing can reduce the amount of route requests required, but adds additional overhead to the data packets sent across the air by including each hop's network address in the packet. The high latency can restrict a ZigBee network's ability to effectively stream data from one point to another. If the ZigBee nodes can only transmit 100 bytes of data with every packet transmission, than at 100 bytes every 100 ms, the actual data rate is only 8 kbps — less than the 9600 baud rate many applications use for data transfer. It is much less than the 115,200 bps that many more applications require. Due to these restrictions, all data must be managed as discrete packets, sent at infrequent intervals.

Finally, if additional routers are required to provide connectivity, the end user is responsible for providing the infrastructure to support the intermediate routers. Additional nodes do not just bring additional costs, they also must be located near a power source and must be located to provide optimum coverage.

Laird Technologies Solution

Coverage issues can often be resolved by substituting 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 dBm gain in the link budget — roughly a 2.5 times increase in range. In addition, for non-CE markets, such as North America, higher output powers up to 1 W are available to provide additional coverage. Once free from the constraints of ZigBee's power and data rate restrictions, end users can choose from a wealth of standard and proprietary solutions for M2M applications.

One example is Laird Technologies' LT2510 series of frequency hopping serial-to-wireless modules. Designed for industrial M2M applications, the LT2510 series offers best-in-class range and throughput in a small, cost-effective form factor. The LT2510 series features intelligent server/client architecture, ideal for point-to-point and star networks. The intelligence of these devices abstracts the complex underlying RF protocols, and their higher output power eliminates the need for multiple devices to provide connectivity over large distances. The LT2510 series allows for an unlimited number of clients to automatically sync to a single server, the central point in a star system. The end user then is presented with a direct serial link from their host device to the host connected to the central server. With ranges up to 2.5 miles, the LT2510 series provides a large coverage area for star networks. Figure 4 shows the same user data sent over a comparable LT2510 system.

Figure 4: LT2510 packet delivery.

Since the LT2510 series modules are offered with higher output power, the entire link can be managed with just the two principle nodes. There is no need for intermediate routers or a routing protocol. The data flows from the source to the destination, and the acknowledgment can be received in as little as 6.5 ms (assuming there are no retries).

Acknowledgements in less than 30 ms are typical for most networks. With optimal configurations, line rates of 115,200 bps are possible to allow for streaming data across the wireless link.

While the LT2510 series modules provide a very easy, fully certified implementation for a serial to wireless network, they also provide a number of advanced features which the OEM host can use to optimize performance. These features include a reduced idle current draw of less than 10 mA, 50 µA sleep states with the ability to wake up and transmit in less than 26 ms, and advanced API features to quickly redirect transmitted data using API headers. In addition, the LT2510 series has RF modes that allow for 500 kbps RF data rate, twice the rate of 802.15.4 ZigBee networks. The combination of easy-to-use, quick time-to-market, and global certifications allow the OEM to integrate the LT2510 modules into designs for star networks quickly and cost-effectively.


Star networks present unique challenges in 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. Identifying the key requirements and selecting a wireless solution which is optimized for star networks can reduce time-to-market and provide for a more robust solution. Table 1 highlights some of the key attributes of a typical ZigBee 10 mW transceiver and the LT2510 100 mW transceiver.

Feature Generic Zigbee Transceiver LT2510 Transceiver
Output Power Radiated in CE markets 10 mW 100 mW
Receiver Sensitivity -96 dBm* -98 dBm Rate)
Point to Point range (with 10 dBm Fade margin .5 miles 1.5 miles (2.5 miles for 125 mW module )
Number of nodes to cover a 1.5 mile distance 2- end point + 2- Routers 2- just the end points
Addressing Complex (network and IEEE) Simple (MAC only)
Latency for 1.5 mile transmission (with requests, no retries) 100 ms (assuming 10 ms per hop) 6.5 ms
Throughput <8 kbps over two hops >115.2 kbps
* Numbers based on average transceiver, not a specific transceiver

Table 1: Comparison of the LT2510 100 mW versus the generic ZigBee 10 mW transceiver.

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. Star networks can benefit from a simpler, more effective solution.