Sending messages to sleepy end devices

In EmberZNet 2.x you can call emberSendUnicast() to send a message to a sleepy end device.  Because the destination device is very likely to be asleep, this message must be buffered by the parent of the sleepy end device until the device next wakes up and polls for data from the parent.  When the parent receives the message for its child, it will set the message pending flag for that child.  When the child polls the parent for data, in the poll response it will see that the message pending flag it set and that will cause the sleepy end device child to leave its radio on for <17ms after the poll, to allow the parent to deliver the message to the child before it goes back to sleep.  It does not matter if the sending device is also the parent of the destination device.

 

There are 3 main limiting factors to this mechanism;

 

1. Each buffered message on the parent uses up some of its packet buffers, for a small message this might be 2 packet buffers per buffered message, up to a maximum of 4 packet buffers per message (32 bytes x 4 = 128 bytes including header).  If the parent runs out of packet buffers to allocate for these buffered messages, it will no longer buffer messages for its children until some packet buffers are freed up.  For example, if a router has allocated 24 packet buffers, and messages are short, it may be possible to have 12 messages buffered at one time for sleepy end device children.  If the router has more than 12 children, this is less than one message per child.

 

2. The duration between polls to the parent by the sleepy end device (i.e. the time spent sleeping) directly influences the latency in the delivery of the message to the sleepy end device.  Unless the delay between polls is less than the APS message timeout (as calculated by multiplying EMBER_MAX_HOPS * 50ms), then the sender of the message is going to get a timeout and message failure in the emberMessageSent() callback for that message.  It may be prudent to not set the EMBER_APS_OPTION_RETRY option when sending the Unicast so that at least for messages that are delivered via a router, the sender will receive the MAC level acknowledgement from the next hop device.  As end-to-end APS acknowledgements in this scenario are not available, it may also be prudent to have the application send a unicast back to the sender to act as an acknowledgement.

 

3. The maximum time that a parent will buffer a message for a sleepy end device child is 30 seconds.  This value is configurable by modifying the indirect transmission timeout, by adding the following line to the project's CONFIGURATION HEADER file (this example shows the maximum 30 second timeout). 

#define EMBER_INDIRECT_TRANSMISSION_TIMEOUT 30000

Because the maximum timeout is 30 seconds, this effectively limits the sleep cycle of sleepy end devices to < 30 seconds, otherwise they are likely to miss any messages sent to them, because the parent will sometimes remove the buffered message before the child next polls for data (depending on at what point during the sleep cycle the message is sent).

 

In summary, when sending APS Unicast messages to sleepy end devices;

- Maximize the number of packet buffers on router (or coordinator) devices.

- Minimize the number of messages sent to sleepy end devices joined to any particular router at a time.

- Do not use the APS retry option

- Create an application-level "Acknowledgement" from the sleepy end device

- Sleepy end devices should sleep for less than 30 seconds before polling their parents for data

 

Note: There are other mechanisms for delivering messages to sleepy end devices that do not have these limitations, however this is the simplest way currently to send a message to a sleepy end device without involving the application on the sleepy end device's parent.  The limitations imposed by this mechanism may be worth living with for the simplicity it brings to the application.