ZigBee applications - Part 1: Sending and receiving data

To send data from one node to another in the Freescale platform, for example, simply call:

AF_DataRequest(&addrInfo, iDataSize, pPtrToData, NULL);

That's it. ZigBee takes care of the rest!

ZigBee uses standard networking terms for data transmission, as defined by IEEE. This includes:

• Data Request (which means to transmit data)

• Data Confirm (which means the acknowledgment of a data request)

• Data Indication (which means to receive data)

Data requests are initiated by the application, as shown in Figure 4.1. A data confirm is the direct result of a data request: Each time an application generates a data request, it will receive exactly one data confirm to indicate the success (or failure) of that request. A data indication, however, may arrive at any time.

Data requests come in a variety of flavors. The options include:

• Unicast with end-to-end acknowledgment

• Unicast without end-to-end acknowledgment

• Broadcast

• Groupcast/Multicast

Unicasts are transmitted from one node to exactly one other node. Unless the nodes are neighbors (within radio range of each other), route discovery takes place the first time these nodes speak together. If end-to-end is acknowledged, the unicast will be retried up to three times, perhaps even initiating a new route discovery if the old route is broken.

Broadcasts are transmitted from one node to all of the nodes in the network, within a sender-definable radius.

Groupcasts, and the upcoming Multicast in ZigBee 2007, broadcast to a specific set of nodes. Any node (actually, any endpoint, but I'll explain it in detail later) not part of the group will discard the packet. For example, assume the dark nodes in Figure 4.2 belong to group A. If a node groupcasts to group A, the packet will reach the applications in these specific nodes and no others.

The example in the next subsection, Example 1-1 ZigBee Data Requests, demonstrates how to initiate all these various data request mechanisms, and how it looks from the standpoint of data indication.

While this chapter describes how to use ZigBee unicasts, broadcasts, and groupcasts, if you would like to understand how they work from a stack standpoint, see Chapter 7, "The ZigBee Networking Layer."

ZigBee is an asynchronous protocol; any node may transmit or receive data at any time. When a user flips a light switch, the data is sent immediately, even if that light switch is a battery-powered device designed to run for years on a couple of AAAs. If you have read the 802.15.4 specification, you may have read about beacons. ZigBee is beaconless.

Due to the nature of ZigBee, one thing that is difficult to predict is packet latency. A good rule of thumb is to assume that transmitting a packet requires about 10 milliseconds per hop. The difficulty comes in when retries or route discoveries are needed. Route discoveries require a broadcast across the network and the initiating node must wait until the results are received. Retries come in the form of both per-hop MAC retries and endto-end APS retries.

In Figure 4.3, a node is transmitting to another node, four hops away. Expect the packet to be received 40 ms later (on average) with the acknowledgment returning 80 ms later.

When using acknowledged unicast data requests, up to three end-to-end retries occur with approximately a 1.5-second delay between each. This means the latency could be, in the worst case, nearly five seconds for a packet to successfully be delivered, or to indicate to the application that it failed to get through. Freescale BeeStack allows the duration between retries to be adjusted through the gApsAckWaitDuration_c property in BeeStackConfiguration.h.

ZigBee applications must allow for a broad range of latency for the worst-case scenarios.

The size of the packet doesn't affect latency much if the channel is fairly clean, as the random wait times dwarf the transmission times. But, if the channel is particularly noisy, then the length of the packet exponentially increases the chance of retries, which means an increase in latency.

A good policy is to keep the packet length as short as possible for the given transmission. Keeping packets short is good for two reasons: decreasing latency and reducing bandwidth usage, allowing more for other applications. Granted, if you are transferring bulk data, send as much as you can to reduce the number of packets, but for other kinds of data, think about how to keep it short.