This page will help you understand Zigbee network architectures. Click on a sub-page for more information on a specific network topic.

Network Node Types

A Zigbee network is made up of entities called nodes. A Zigbee network can have 3 different kinds of nodes: Coordinator, Router, or End Device. The Zigbee specification dictates that a network can include multiple Routers and End Devices, but only one Coordinator - or none. These node types are described below.

Coordinator

Zigbee Coordinator (ZC) is responsible for forming the network.
A coordinator can be seen as a router with additional functionality.
Can only be one coordinator in a single network.
May have additional responsibilities, such as being the Trust Centre or Network Manager . Typically defined by application developer but often decided by stack profile.

Routers

Zigbee Router (ZR) provides routing services to the network devices.
Can also serve as end devices.
Not designed to sleep so should generally remain on as long as network is established.

EndDevices

End Devices (ZED) are leaf nodes.
Communicate only through their parent nodes and unlike routers cannot relay messages intended for other nodes.
Depending on the network stack, end devices can be of several types [ Sleepy end device, Non-sleepy end devices, Mobile end device ].

On This Page

In This Chapter

Related Content

Filter by label

There are no items with the selected labels at this time.

Mesh Networking

Zigbee uses a mesh network architecture for communication and Zigbee uses radio waves for communication. Embedded mesh networks make radio systems more reliable by allowing radios to relay messages for other radios. For example, if node A cannot send a message directly to node B, in an embedded mesh network an intermediate node can 'relay' the message.

Below is a rudimentary illustration of a Zigbee PRO Mesh Network. Note that when a Router is out of range of the Coordinator, it may route messages through its nearest neighbour Router. Also note that End Devices have no child nodes and that the Coordinator may also be the parent of an End Device.

There are actually 3 possible mesh network topologies :

Star Network
- One hub is the central point to all communications.
- Can become bottlenecked with network bandwidth.
Full Mesh Network
- All nodes are router nodes, including the coordinator after it forms the network.
- Least vulnerable to link failure.
Hybrid Mesh Network
- Combines both start and mesh strategies.
- Several star networks exist, but their hubs can communicate as a mesh network.
- Allows for longer distance communication than a star topology and more capability for hierarchical design than a mesh topology.

The choice of topology must take into consideration which nodes are line-powered or battery-powered, expected battery lifetime, amount of network traffic required, latency requirements, the cost of the solution, as well as other factors.

Routing

Routing is how messages are passed through the network from device to device. Several options exist for routing and MMB uses a combination of the following routing mechanisms, depending on the scenario.

Table Routing

Routes are formed when one node sends a route request to discover the path to another node. After a route is discovered between the two nodes, the source node sends its message to the first node in the route, as specified in the source node's routing table. Each intermediate node uses its own routing table to forward the message to the next node (that is hop) along the route until the message reaches its destination. If a route fails, a route error is sent back to the originator of the message who can then rediscover the route.

Broadcast Routing

Broadcast routing is a mechanism to send a message to all devices in a network. Network-level broadcast options exist to send to routers only or also to send to sleeping end devices. A broadcast message is repeated by all router-capable devices in the network three times to ensure delivery to all devices. While a broadcast is a reliable means of sending a message, it should be used sparingly because of the impact on network performance. Repeated broadcasts can limit any other traffic that may be occurring in the network. Broadcasts are also not a reliable means of delivery to a sleeping device because the parent device is responsible for buffering the message for the sleeping child but may drop the message before the end device wakes to receive it.

Multicast Routing

Multicast routing provides a one-to-many routing option. A multicast is used when one device wants to send a message to a group of devices, such as a light switch sending an on command to a bank of 10 lights. Under this mechanism, all the devices are joined into a multicast group. Only those devices that are members of the group will receive messages, although other devices will route these multicast messages. A multicast is a filtered limited broadcast. It should be used only as necessary in applications, because over-use of broadcast mechanisms can degrade network performance. A multicast message is never acknowledged.

Many-to-One Routing

Many-to-one routing is a simple mechanism to allow an entire network to have a path to a central control or monitoring device. Under normal table routing, the central device and the devices immediately surrounding it would need routing table space to store a next hop for each device in the network, as well as an entry to the central device itself. Given the memory limited devices often used in Zigbee networks, these large tables are undesirable.

Under many-to-one routing, the central device, known as a “concentrator,” sends a single route discovery that established a single route table entry in all routers to provide the next hop to the central device. This yields a result similar to that of table routing, but with a single many-to-one route request rather than many individual, one-to-one route requests from each router towards the concentrator.

All devices in the network then have a next hop path to the concentrator and only a single table entry is used. However, often the central device also needs to send messages back out into the network. This would result in a more significant increase in route table size, particularly for those nodes closest to the concentrator, since they are relay points in the concentrator’s many outbound routes to the rest of the network. Instead, incoming messages to the concentrator first use a route record message to store the sequence of hops used along the route. The concentrator then stores these next hop routes in reverse order as “source routes” in a locally held table known as a “source route table”. Outgoing messages include this source route in the network header of the message. The message is then routed using next hops from the network header instead of from the route table.

Addressing

Zigbee uses a stochastic address assignment mechanism where the coordinator is used to star the network. Each device that joins the network is given a randomly assigned address from the device it's joining. The device conducts conflict detection on this address using network level messages to ensure the address is unique. This address is then retained by a device, even if the parent address changes.

In Zigbee 3.0 a commissioning Tool can be used to assign address manually.

Extended PAN IDs

Zigbee has added an 8 byte extended PAN ID (EPID or XPID) to facilitate provisioning and PAN ID conflict detection. The extended PAN ID is now included in the beacon payload, following the existing 3 bytes. This extended PAN ID [EPID] can be thought of as an extension of the basic, 16-bit PAN ID [PID]. The EPID is a 64-bit value set for the entire network by the Zigbee Coordinator [ZC] at the time the personal area network [PAN] is formed and must not change while the PAN is operating (unlike the PID). Like the PID, all nodes within the same PAN share an EPID.

The EPID is stored in non-volatile memory once the node associates into the network, so it won't change over the lifetime of the device, until the device leave the network.

Choosing an EPID

While the PAN ID is meant to be randomly chosen and unique to each network, the EPID is often used like the SSID field of a WIFI network to give them a user-friendly designation.

NOTE: EPID conflicts cannot be resolved so using a fixed EPID for all deployments is not recommended.

EPID vs PID

Here is a quick overview of differences between the Extended PAN ID and the standard PAN ID:

EPID is 64 bits; PID is 16 bits
EPID is usually used as stack's criteria for matching to the requested network; PID is only used for matching criteria when
EPID is all 0x00 bytes.
EPID is only present in a few kinds of packets (beacons, Network Update messages); PID is present in almost all 802.15.4 frames (except MAC ACKs).
EPID is used as criteria for uniquely identifying the network and for resolving conflicts of PID; PID is used for MAC destination filtering at the radio receiver.
EPID may help provide some indication of the network's identity in the scan results; PID should always be completely random, so it is not as useful in determining which PAN is the "right one".

Group Addressing

Group addressing is provided by the Zigbee Standard with the Group Cluster (0x0004). This allows multiple device endpoints to be targeted with a single message broadcast. That is, any endpoint on any device MAY be assigned to one or more groups, each labeled with a 16-bit identifier (0x0001 – 0xfff7), which acts for all intents and purposes like a network address.

Once a group is established, frames sent with the DstAddrMode of 0x01(group addressing), will be delivered to every endpoint assigned to the group address named in the DstAddr parameter of the outgoing request on every device in the network for which there are such endpoints. Group membership on each device and endpoint is implemented by the APS, but the over-the-air messages that allow for remote management and commissioning of groups are defined in the cluster library.

Please see the ZCL specification for more details on the Group Cluster.

The Scenes Cluster (0x0005) can also be used in collaboration with the Group Cluster, the Scene Cluster provides attributes and commands for setting up and recalling scenes. Each scene corresponds to a set of stored values of specified attributes for one or more clusters on the same end point as the scenes cluster.

Supporting Materials

Zigbee Mesh Network_V2.mp4

References

Zigbee: UG103.2: Application Development Fundamentals

Browser not supported