Routing Mechanisms Breakdown



Overview

This section will give users a brief overview for each routing mechanism and why they might be used.

Unicast

Unicast routing is used to transmit a message to a single device on the network. The device address is used as the target.

Multicast

Multicast routing is used to transmit a message to a group of devices in a particular PAN, within a given transmission radius(measured in hops).

Broadcast

Broadcast routing is used to transmit a message to every device in a particular PAN, belonging to one of a small number of statically defined broadcast groups.

Broadcast Groups:

0xFFFF = All Devices
0xFFFD = All Non-Sleepy Devices
0xFFFC = All routers and coordinator


On This Page

In This Space



Important Routing Attributes

When specifying a routing mechanism, there are some important attributes that will determine the success or failure of a message reaching it's target. Some of the more obvious attributes used are the destination address, destination endpoint, and group ID. However, some of the more complex attributes are covered below.

Radius Attribute

  • Type: Integer
  • Range: 0x00 - 0xFF
  • Description: The distance, in hops, that a frame will be allowed to travel through the network.
  • Used By: Multicast and Broadcast message routing mechanisms


The Radius attribute represents the maximum number of hops a message will be allowed to traverse when being routed to a target device.

R1. 'Every device has an associated depth that indicates the minimum number of hops a transmitted frame must travel, using only parent-child links, to reach the ZigBee coordinator. The ZigBee coordinator itself has a depth of 0, while its children have a depth of 1. Multi-hop networks have a maximum depth that is greater than 1. The ZigBee coordinator also determines the maximum depth of the network.'

Setting the Radius attribute value to 0x00 will result in the sum of 'nwkMaxDepth' * 2 being used instead. The nwkMaxDepth value is how many hops it would take to reach the furthest away child device in network (populated during the discovery phase).

Example:


Non-member Radius Attribute

  • Type: Integer
  • Range: 0x00 - 0x07
  • Description: The distance, in hops, that a multicast frame will be relayed by nodes not a member of the group. A value of 0x07 is treated as infinity.
  • Used By: Multicast message routing mechanisms

R1. 'The non-member radius attributes indicates the range of a multicast when relayed by devices that are not members of the destination group. Receiving devices that are members of the destination group will set this field to the value of the MaxNonmemberRadius(calculated at stack level) sub-field. The originating device and receiving devices that are not members of the destination group will discard the frame if the non-member radius has value 0 and will decrement the field if the non-member radius field has a value in the range 0x01 through 0x06. A value of 0x07 indicates an infinite range and is not decremented.'

Example:





Responses and Acks

The following responses and acks are possible when sending a command, depending on wether they are enabled or not. Below you will find a concise overview of each.

Status Response:

The Status Response is a response that is sent from either the Module to the Host or from the Host to the Module upon receipt of a command from the RHA protocol.


ZDO/ZCL Response Received:

Certain commands, such as the Read Attribute commands expect a response from a target device when sent. The ZCL/ZDO Response Received command is sent by the Module to the Host on reception of ZCL/ZDO message from the network. That is, the command is generated if the Host had configured an outgoing Send ZCL/ZDO Unicast or Send ZCL/ZDO Broadcast with Response Options indicating that a response is expected (i.e. enable reception of ZCL/ZDO Response Received with corresponding Transaction Sequence Number.


APS Acks:

The ZCL/ZDO APS Ack command is sent by the Module to the Host on reception of an equivalent acknowledgement from the network, triggered by the initial transmission of a ZCL/ZDO message that required an APS Ack among its Response Options. The Module will also generate the command when a given acknowledgment is not received and therefore times out.


Some responses or acks will not be sent, depending on the the type of table routing used. Below you will find the expected responses and acks for each type of table routing.


One-to-one / Table Routing

Status Response:

A status response will be returned by the Module when a command is sent by the Host which is intended for a single target device.

ZDO/ZCL Response Received:

If the command being sent to the target device, expects a response, then a single ZDO/ZCL Response Received command is expected in return.

APS Acks:

An APS Ack is expected from the target device APS Layer...dependent on whether the option is selected.

Multicast Routing

Status Response:

A status response will be returned by the Module when a command is sent by the Host which is intended for multiple targets using group addressing.

ZDO/ZCL Response Received:

If the command being sent to the target devices, expects responses, then a  ZDO/ZCL Response Received command per target device is expected in return.

APS Acks:

No APS Ack is expected from the target device per the Zigbee HA1.2 and Zigbee 3.0 Specification


Broadcast Routing

Status Response:

A status response will be returned by the Module when a command is sent by the Host which is intended for all target devices on the network.

ZDO/ZCL Response Received:

If the command being sent to the target devices, expects responses, then a  ZDO/ZCL Response Received command is expected, per target device, in return.

APS Acks:

No APS Ack is expected from the target device per the Zigbee HA1.2 and Zigbee 3.0 Specification







R1. Zigbee Specification. ZigBee Document 053474r20-September 19, 2012.

Legal Notices

Copyright © 2020 MMB Networks, Inc. All rights reserved.
Confidential materials prepared and delivered by MMB Networks for receipt and review only by any partner subject to a valid and enforceable MMB Networks confidentiality agreement. Any receipt, review, or misuse of any of the content exchanged hereunder by any party not a party to this confidential exchange shall be subject to any and all rights available under the law. All rights, title and interest to the materials shall remain with MMB Networks.
Any suggestions provided to MMB Networks with respect to MMB Networks' products or services shall be collectively deemed “Feedback.” You, on behalf of yourself, or if you are providing Feedback on behalf of your employer or another entity, represent and warrant that you have full legal authority to bind such entity to these terms, agree to grant and hereby grant to MMB Networks a nonexclusive, perpetual, irrevocable, royalty free, worldwide license to use and otherwise exploit such Feedback within any MMB Networks products and services.