ZigBee throughtput test

[Nicolas Kauffmann]

Hi,

I would like to test the ZigBee throughput like the examples ("ATT_MTU Throughput Example" for BLE and "Thread Throughput Measurement Application").

I'm not familiar with ZigBee (I read about it but I'm still learning). I started from the example (Zigbee Light Control with touchlink commissioning). I don't know if it's a good idea.

I implemented a function to send data with the API described in the documentation (zb_zcl_start_command_header, zb_zcl_finish_and_send_packet).

And as a first test, I call periodically ZB_GET_OUT_BUF_DELAYED and it works but, if I send at a too short period (ex: 500ms), the target blocks for a while then receives then it blocks and again and again...

When I say it blocks, it means that I don't get any trace from zcl_device_cb (callback for handling ZCL commands).

Is my method good or am I mistaken ?  Do I need to implement my own cluster ?

Best Regards,

Nicolas

[Jørgen Holmefjord]

Hi,

I got some help with this from one of our Zigbee developers. We have created an example that you can use for testing throughput.

There is at least one issue in your code, you should not use "ZB_APS_ADDR_MODE_16_GROUP_ENDP_NOT_PRESENT". Groupcast is actually a broadcast and is limited. There is a special table to keep track of broadcast messages, because those packets are just retransmitted by every node couple of times. All nodes try to keep track of which messages they've already transmitted, so they do not cause a broadcast storm.

A couple of things you should consider when measuring throughput:

1. You should not use broadcast transmission to measure throughput (groupcast).
2. It is worth having a second device that will accept those "custom" commands to avoid traffic containing error messages.
3. Going from light sample example with coordinator may be easier (there is an explicit place where you read light bulb's address). Although to avoid going through coordinator to the second node it is worth powering it off after the commissioning and reset all devices.

The attached file contains an example based on the light_switch example in the SDK for Thread and Zigbee v1.0.0. It have been tested with 50ms intervals and there seems to be pretty traffic without crashes at this rate. Please check the patch file for diff towards original example. 

light_switch_throughput.zip

diff.patch

Hope this helps!

Best regards,
Jørgen

[Jørgen Holmefjord]

Hi,

When you are talking about 250 kbps, I suppose you are referring to the on-air datarate of the 802.15.4 radio? This is the datarate on the PHY layer, specified in 802.15.4 specifications. You will noe be able to achievable this throughput in application.

This is mainly because of protocol architecture and limitations, i.e.:

• A payload with data is only a part of 802.15.4 frame, a big portion of the frame is consumed by different headers e.g. MAC header, NWK header, etc.
• Before another packet is sent the source node has to wait for an ACK frame from the destination node to get a confirmation that current frame reached the destination.
• 802.15.4 specification implies that two consecutive packets cannot be sent without waiting IFS (Inter-frame spacing) time – this is to give the other side time to process packets.
• CSMA-CA procedure delays sending a packet if channel is busy due to another radio activity.

We do not have throughput measurements for Zigbee yet, but for Thread a point to point throughput in a typical condition is about 80 kbps. Zigbee should have similar numbers.

Best regards,
Jørgen

[Nicolas Kauffmann]

Ok perfect. Thanks !

Nicolas