ZigBee applications - Part 1: Sending and receiving data

typedef struct zbApsdeDataIndication_tag
{
    zbAddrMode_t dstAddrMode;
    zbNwkAddr_t aDstAddr;
    zbEndPoint_t dstEndPoint;
    zbAddrMode_t srcAddrMode;
    zbNwkAddr_t aSrcAddr;
    zbEndPoint_t srcEndPoint;
    zbProfileId_t aProfileId;
    zbClusterId_t aClusterId;
    uint8_t asduLength;
    uint8_t *pAsdu;
    bool_t fWasBroadcast;
    zbApsSecurityStatus_t fSecurityStatus;
    uint8_t linkQuality;
} zbApsdeDataIndication_t;

The dstAddrMode field on the data indication may be either:

gZbAddrModeGroup_c
gZbAddrMode16Bit_c

So why not also use indirect or 64-bit mode? Because ZigBee resolves both indirect and 64-bit modes to one of the above, before sending the data request. The over-the-air packet will always be either group or 16-bit. The srcAddrMode field above is always gZbAddrMode16Bit_c.

I realized I haven't yet explained endpoints, profile IDs, cluster IDs, or security. These fields will become clear before the end of the chapter.

The asduLength and pAsdu is the length and pointer to the payload, the data that was transmitted by the data request from the other node. By the way, ASDU stands for APS Service Data Unit, the ZigBee way of referring to the packet's data payload.

You'll also note that an application can tell if a data indication was broadcast or unicast with the fWasBroadcast field. This field, combined with the aSrcAddr field can be quite useful to determine what type of response (if any) to give to the data request, and where the response should go. The source of any message is always known in ZigBee. There is no anonymity.

The last field, linkQuality, is not in the ZigBee specification for data indications, but is an extra for Freescale BeeStack users. The link quality indicator (or LQI) can be used to estimate how close the nodes are: the stronger the LQI, the closer the nodes (well, approximately). This linkQuality field will be used in Chapter 8, "Commissioning ZigBee Networks," to ease deployment of a network. LQI can also enable some location-based applications.

The example in this section, Example 1-1 ZigBee Data Requests, shows how unicasts, groupcasts, and broadcasts are used within an application. The network is composed of three nodes. The ZigBee Coordinator (ZC) and a ZigBee Router (ZR) are lights. A ZigBee End-Device (ZED) is a switch. The lights are controlled via various ZigBee data request methods, to illustrate the use of each see Figure 4.5.

The user interface on the light switch is as follows. SW1 through SW4 are labeled on the Freescale development boards. The term LSW2, or long switch 2, means to press and hold SW2 for about one second or so (see Table 4.1).

I ran this example and captured the results. I pressed SW1, SW2, SW3, SW4, LSW2, LSW3, and LSW4 in that order. The full example and capture can be found at http://www.zigbookexamples.com:

Frame 19 and 21 (Length = 30 bytes)
IEEE 802.15.4
    Frame Control: 0x8861
    Sequence Number: 61
    Destination PAN Identifier: 0x0f00
    Destination Address: 0x0000
    Source Address: 0x796f
ZigBee NWK
    Frame Control: 0x0048
    Destination Address: 0x0000
    Source Address: 0x796f
    Radius = 10
    Sequence Number = 13
ZigBee APS
    Frame Control: 0x00
    Destination Endpoint: 0x08
    Cluster Identifier: On/off (0x0006)
    Profile Identifier: HA (0x0104)
    Source Endpoint: 0x08
    Counter: 0x3f
ZigBee ZCL
    Frame Control: 0x01
    Transaction Sequence Number: 0x42
    Command Identifier: Toggle (0x02)

W1 generated frame 19, and SW2 generated frame 22. Both look the same, as shown in the capture, even though one is gZbAddrMode16Bit_c and the other is indirect through the local binding table. Why is this? Entries in the binding table always resolve to either gZbAddrModeGroup_c or gZbAddrMode16Bit_c before being sent over-the-air.

Notice in the decode, both SW3 and SW4 cause broadcasts (0xffff for the destination node at the NWK layer). SW3 causes a groupcast, so while it looks like a broadcast from the network layer, the APS layer filters the packet by group. Only an endpoint (an application within a node) which is a member of the group will receive the data indication and so, in this case, toggle:

Frame 23 (Length = 31 bytes)
IEEE 802.15.4
    Frame Control: 0x8841
    Sequence Number: 63
    Destination PAN Identifier: 0x0f00
    Destination Address: 0xffff
    Source Address: 0x796f
    Frame Check Sequence: Correct
ZigBee NWK
    Frame Control: 0x0048
    Destination Address: 0xffff
    Source Address: 0x796f
    Radius = 10
    Sequence Number = 15
ZigBee APS
    Frame Control: 0x0c
    Group Address: 0x000a
    Cluster Identifier: On/off (0x0006)
    Profile Identifier: HA (0x0104)
    Source Endpoint: 0x08
    Counter: 0x41
ZigBee ZCL
    Frame Control: 0x01
    Transaction Sequence Number: 0x44
    Command Identifier: Toggle (0x02)

LSW2 and LSW3 are acknowledged data requests, and you can see the ZigBee APS ACKs in frames 36 and 40. Notice also the IEEE 802.15.4 (MAC) acknowledgments below in frames 35, 37, 39, and 41. With unicasts, ZigBee always acknowledges each hop at the MAC level, regardless of whether APS (end-to-end) acknowledgments are enabled on that data request:

LSW4 uses the 64-bit IEEE address to communicate, in this case, to its parent. But the over-the-air frame uses only the short 16-bit NwkAddr for the destination node. All 64-bit addresses are actually resolved internally to a 16-bit address before transmission. ZigBee does not send data requests to 64-bit destinations. The 64-bit address mode is there for the sake of convenience sake.

In Freescale BeeStack, a ZDP.IEEE_addr_req or ZDP.NWK_addr_req must be initiated prior to using the 64-bit address mode (unless the node is a neighbor).