Parent Polling Mechanism

In ZigBee networks, an indirect data delivery mechanism is used to send data to sleeping end devices over the last hop (that is, from a parent node to its end device child node). The parent does not transfer data destined to the end device child directly, but buffers the data frames instead. An end device sends a data poll request to its parent and if the buffer contains messages for the child, the parent then delivers the buffered data right after such data poll requests. CS_NWK_BUFFERS_AMOUNT includes the indirect messages buffered for sleeping end device children on router/coordinator. If the CS_NWK_BUFFERS_AMOUNT is greater than 5, then the amount of buffers allocated for sleeping end-device children would be CS_NWK_BUFFERS_AMOUNT/4 or it is less than or equal to 5, the buffer amount allocated for sleeping end-device children would be 1.

Figure 5-6 illustrates parent polling mechanism and retrieval of the buffered frame from the parent. Figure 5-6. End Device Polling Mechanism

End Device Parent

Buffer Data for ED

Poll for data

Deliver buffered data

Poll for data Tx own data

Indicate that buffer is empty

Sleep

Sleep

Active

5.9.1 Parent Polling Configuration on End Devices

Polling is handled by the lower stack layers but application can control it with the help of certain ConfigServer parameters and requests to the stack.

To poll the parent, an end device shall have CS_RX_ON_WHEN_IDLE set to false (see the example in Section 4.1.1.2), indicating that the radio is kept in listening mode only for short periods of time when the device is actually sending and receiving data frames and hence data polling mechanism will be used for frame reception. After an end device enters a network, it cannot change CS_RX_ON_WHEN_IDLE as a usual parameter via the ConfigServer interface.

If sleep-when-idle feature (see Section 7.1) is started then an end device under normal conditions after network join will poll its parent with interval configured in CS_END_DEVICE_SLEEP_PERIOD parameter. Such polling mode can be called “slow polling” as normally these data polls are meant as notification of end device presence to the parent and hence CS_END_DEVICE_SLEEP_PERIOD can have larger values from several seconds to several hours.

However during ongoing data transactions when stack expects a response for pending request (for example an APS Ack or a ZDO/ZCL response) stack will automatically reduce the polling interval and send them every

CS_INDIRECT_POLL_RATE until expected response is received. This mode can be considered as “fast polling” as

CS_INDIRECT_POLL_RATE is normally kept rather small (100-1000ms) to ensure fast retrieval of expected responses from the parent.

In addition to automatic control from the stack, application can request the “fast polling” mode as well by subscribing to

BC_EVENT_POLL_REQUEST event and returning 1 in the data argument if it wants the next poll to occur in

CS_INDIRECT_POLL_RATE ms. It doesn’t need to change the data argument if there is no need for a fast poll from application perspective. Here is a code example how this can be done.

//define event callback function, event receiver and a status flag static void isPollRequired(SYS_EventId_t eventId, SYS_EventData_t data);

static SYS_EventReceiver_t appPollRequestEventReceiver = { .func = isPollRequired}; static bool fastPollRequiredFlag; // 1 means is poll is requried and 0 means is not …

// subscribe to the event

SYS_SubscribeToEvent(BC_EVENT_POLL_REQUEST, &appPollRequestEventReceiver); …

//event callback handler

static void isPollRequired(SYS_EventId_t eventId, SYS_EventData_t data) {

bool *check = (bool *)data;

if (BC_EVENT_POLL_REQUEST == eventId) *check |= fastPollRequiredFlag; }

Caution: Same as for any other BitCloud events same memory is used for the data argument by all

BC_EVENT_POLL_REQUEST event receivers. Hence bitwise or operation (|) is be used in the event callback handler to ensure that if a single component requires a fast poll in CS_INDIRECT_POLL_RATE interval then the data value stays as true independent on values set in other event callback

functions.

With sleep-when-idle enabled there’s generally no need to change CS_INDIRECT_POLL_RATE and

CS_END_DEVICE_SLEEP_PERIOD parameters over time unless special polling behavior is needed for certain periods. When sleep-when-idle feature is not used (see Section 7.2) then stack will send data polls with

CS_INDIRECT_POLL_RATE interval when device is awake.

An end device application also can control the sending of poll requests. The ZDO_StopSyncReq() and

ZDO_StartSyncReq() synchronous requests stop and restart the sending of poll requests to a parent, respectively. Additionally an application can issue data poll requests manually with the NWK_SyncReq() function.

5.9.2 Polling Configuration of End-device Children on Fully Functional Devices

Special care should be taken when configuring fully functional devices (routers and the coordinator) that communicate with sleeping end devices. The CS_MAC_TRANSACTION_TIME parameter determines how much time a cached frame is being stored on a sleeping end device’s parent. Upon receiving a frame for a sleeping child, a parent calculates the time when the child is expected to wake up by adding the CS_END_DEVICE_SLEEP_PERIOD parameter value to the time when the last poll request was received from the child. If the time till the calculated moment is greater than

CS_MAC_TRANSACTION_TIME, the frame is not stored and the parent responds to the originator with an error, since the end device is not likely to wake up during the timeout. Otherwise, the frame is saved to the buffer and is transferred to the destination upon receiving a poll request from it. If a poll request is not received within CS_MAC_TRANSACTION_TIME after frame arrival, then the buffered frame is dropped.

Note that if the frame is stored for a long time, the originator may cease waiting for a response, since its timeouts have exceeded, and hence consider the delivery as failed even though the frame may successfully reach the destination. Thus, the application developer should track a frame storing timeout on functional devices with care. Note also that a parent is not informed about an end device sleep period automatically. Instead, it uses the

CS_END_DEVICE_SLEEP_PERIOD value, the same for all children. This implies that if an end device has an actual sleeping period that is longer than the parameter value configured on the parent, then messages for such a child may be dropped.If the parent has multiple end devices with different sleep periods, it is advised to set the maximum sleep period as the CS_END_DEVICE_SLEEP_PERIOD on the parent.