This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Create a Packet error rate script with Z-Tool: Do i have to implement "Message-Acknowledge/Resend" myself?

Other Parts Discussed in Thread: CC2650, Z-STACK

Hello,

(Background info)
I've got 2 SmartRF06 Eval boards running with a CC2650 (running HA-stack) attached to it. I got one running as coordinator and one as an end-device. As stated in my last thread i'm trying to do a PER (Packet Error Rate) Test with this setup. Since there's no official PER-Test from TI yet, i figured i'd create Z-Tool scripts to do some testing in the meantime.

I've been working on understanding how i can use Z-Tool to configure my devices and send messages from one to the other and think i got an okay understanding. Also been digging into creating scripts for Z-Tool.

(Actual Question)

What i am wondering in order to implement my PER-Test Script:

I've been planning on calculating my "Success-rate" based on a continuous number (indexing each message) and the number of totally received messages.
Now, as i understand it, the MAC-layer has no transmission control. AFAIK this is implemented by Zigbee, but is it part of the (HA-)stack, or do i have to implement such an algorithm myself? Meaning, do i have to implement a function, that waits for an Acknowledge of the previously sent message and if no Acknowlegde is received resend the message?

Or, if this is done automatically by the stack, are there parameters for this, that i can adjust?

Thanks in advance,

stephanie

  • If you mean to enable APS ack, you have to do it by yourself in application.
  • I've tried that by setting Options to 0x08, since the Z-Stack Monitor and Test API states: "bit 1: sets ‘Wildcard Profile ID’; bit 4: turns on/off ‘APS ACK’; bit 5 sets ‘discover route’; bit 6 sets ‘APS security’; bit 7 sets ‘skip routing’." Or is that the wrong way of enabling APS Ack?

    But, when i sniff the traffic and i look at one of my messages, it still indicates that Ack is not enabled. And i also don't see any Ack in Z-Tools log. Does Z-Tool even show, if an ACK arrives?

  • If you want to get APS ack, you have to register AF_ACK_REQUEST with zcl_registerClusterOptionList. However, I don't know how to do it in ZTool.
  • Well, i'd like to have some functionality, that guarantees (or tries to) that the message that was sent by the coordinator is delivered. Pretty much like TCP. I was under the impression, that ZigBee offers something like this, by retransmitting the message, if the sender does not receive an ack. If i can get this with APS Acknowledge, than this would be preferred.

    Maybe someone else knows if and how this could be done in Z-Tool (or scripts for it)?
  • Since your network it's just two nodes, you don't need APS acknowledgment you just can leverage the single hop acknowledgment mechanism ZigBee inherits from the MAC.

    Please send the ZNP command AF_DATA_REQUEST and then parse the AF_DATA_CONFIRM cmd coming from ZNP. The first byte of the payload of this message is the status and it will be 0x0 in case of success, otherwise it will be 0xe9 in case of a single hop failure.

    Thanks,
    TheDarkSide
  • Okay, so this means the stack does not automatically resend the message, if there is no mac ack, correct?

    This is something i would have to implement myself, right?

    So, i would listen for an AF_DATA_CONFIRM (inside the msgHandler i suppose) and then react accordingly by resending the message.

  • Yes. You have to resend message again by yourself if there is no APS ack.
  • Okay, thank you YK Chen and TheDarkSide!
  • You are welcome.
  • Just to clarify on the above: when I meant a MAC failure I mean a failure at the MAC layer, which does not mean a not receiving one MAC ACK when a packet is transmitted.
    Let me elaborate more on this.
    In ZigBee there are two layers of acknowledgment: MAC and APS.
    TI Z-Stack provides 3 levels of re-transmissions for data: MAC, NWK and APS. While MAC and NWK are 'single-hop' re-transmissions in case of failure, APS is end to end (multi-hop) acknowledgment/re-transmission level. While APS and NWK are optional and can be configured/disabled, MAC acknowledgment are mandatory as per the standard. With acknowledgements, comes the concept of re-transmissions, as stated before.

    This means that the same MAC packet is re-transmitted if there's no MAC ACK. In ZigBee, there are up to 3 re-transmissions for a single MAC packet. Which means that the same MAC packet is transmitted maximum 4 times before a failure is declared to the upper layers.

    The upper layer immediately above the MAC is the NWK layer. As you may have noticed, there's no concept of NWK layer ACK but there is a concept of NWK layer re-transmission. This happens in case the underlying layer (ie MAC) declares a failure (which as explained happens when no single ACK is received for 4 transmission attempt or in case for instance of a CSMA-CA failure).
    The NWK layer retry consists in basically sending another request for the MAC layer, which may go up to 4 transmissions at this layer as explained above. After the number of retries is exhausted, the NWK layer declares a failure to the layers above.
    The number of NWK layer retries is configurable, and defined in znp_f8wconfig.cfg in ZNP for CC26xx (NWK_MAX_DATA_RETRIES) to 2.

    If APS ACK is disabled, AF_DATA_CONFIRM is sent by the ZNP to the host when the NWK layer declares a failure. The number of MAC transmission in case of a single hop communication can therefore go up to 4*NWK_MAX_DATA_RETRIES, i.e. 8. (or less, if for instance the failure is due to CSMA-CA). Please check the status parameter in F_DATA_CONFIRM

    Long story short: yes the protocol caters for re-transmissions automatically and acknowledgment checking. You can certainly add another level of re-transmission and acknowledgment at the application, but I think that for single hop communication it is redundant with what the protocol provides already.

    I hope this clarifies things completely.
    Thanks,
    TheDarkSide
  • Thanks a lot for this detailed explanation! It does clarify definitely and helps me a lot. Again, thanks!