While the MAC layer provides per-hop acknowledgments, the APS layer is what provides end-to-end acknowledgments, also called ACKs.
To illustrate, take a look at Figure 4.27. Suppose a switch (the ZED) wants to turn on a light (the ZR), and it wants to verify that the light received the command. The switch uses the optional ACK feature in the AF_DataRequest() txOptions field.
Figure 4.27: APS Retries
The distance between the nodes is irrelevant. They could be neighbors, or 10 hops away. The effect is the same.
Suppose the initial data request got through to the ZR. It then processes that command immediately, perhaps toggling the light. But the APS ACK did not make it back, for some reason. So APS will automatically retry after the time-out period (which defaults to 1.5 seconds). But this retry, labeled (2), doesn't make it through. APS tries again, and this time it succeeds. Only then does APS inform the sender that the results were successful.
By the way, this scenario is extremely unlikely. It is used merely as an illustration. ZigBee uses up to three MAC ACKs per hop, so unless the channel is so noisy that communication is impossible, or the path is broken because one node has dropped off the network, or the physical environment has changed (one of the routers along the route can no longer hear its neighbors), APS ACKs are rarely called into play.
APS is smart enough not to send the packet up to the application twice. In Figure 4.27, both (1) and (3) make it through, but because the data request was already heard at (1), the copy at (3) will be dropped by the APS layer after it sends the ACK to the sender. Your application doesn't have to have any special logic to handle duplicates. ZigBee does it for you.
4.7.2 APS Binding
Binding in ZigBee allows an endpoint on one node to be connected, or "bound" to one or more endpoints on another node. Think of a switch controlling a light, or a temperature sensor sending its data to a thermostat. The sender (switch or temperature sensor) is "bound" to the receiving device (light or thermostat).
Binding is unidirectional, in that the switch is bound to the light, but the light isn't bound to the switch.
Bindings are stored locally by the sending node (the switch or temperature sensor). Each binding table entry stores the following information:
- Source endpoint
- Destination NwkAddr and endpoint or destination group
- Cluster ID
The binding table size defaults to five entries in BeeStack, and can be set by changing gMaximumApsBindingTableEntries_c in BeeStackConfiguration.h.
If multiple entries from the same source endpoint exist in the table, then multiple destinations will be sent also. For example, say the binding table contains the entries shown in Table 4.12.
Table 4.12: ZigBee Binding Table
If the application then issues an AF_DataRequest()from endpoint 5 with address mode gZbAddrModeIndirect_c, then three data requests will be sent over the air, one to node 0x1234 endpoint 12, one broadcast to group 0x9999, and one to node 0x5678 endpoint 44 in that order:
addrInfo.dstAddrMode = gZbAddrModeIndirect_c;
addrInfo.srcEndPoint = 5;
addrInfo.txOptions = gApsTxOptionDefault_c;
addrInfo.radiusCounter = afDefaultRadius_c;
(void)AF_DataRequest(&addrInfo, 10, "ToggleLed2", NULL);
Is it starting to become clear just how powerful binding is?
Unless constrained by too little memory, there is no reason not to include binding in all ZigBee devices. Binding, coupled with the over-the-air ZDP binding commands, allows any endpoint on any node to be connected easily with any endpoint on any other node. Binding (or determining which nodes in the network talk together) is one of the critical steps when setting up a ZigBee network. Binding makes it just that much easier.
Local binding commands are supported by the APS layer. Over-the-air binding commands are supported by the ZigBee Device Profile (ZDP).
The local (APSME) binding calls (shown in Table 4.13) return immediately in the Freescale solution. After all, they just manipulate in-memory tables. The over-the-air (ZDP) binding calls issue a callback, but I'll describe that in detail in Chapter 5, "ZigBee, ZDO, and ZDP. "
Table 4.13: ZigBee Binding Commands
Binding is not required, at least not in Manufacturer Specific Profiles. Feel free to send directly to individual nodes, groups, or to use a broadcast mode, but binding does make the commissioning process easier and more flexible.
Use binding to simplify the commissioning process.