• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 482 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2652R: MAC Retries and Route Discovery

Damon Stewart
Prodigy 120 points
Part Number: CC2652R


Hello,

We are using the SimpleLink CC13x2 26x2 SDK 4.20.01.04 stack and have a deployment with several dozen routers in a small space (high congestion) periodically send data to the coordinator.  APS acknowledgments are disabled.

We are seeing a lot of route discoveries taking place in the sniffer capture (not continuously, but much more regularly than we would like).  Just prior to most of these route discoveries, a middle hop in a route sends a Network Status packet back to a message originator, either with a "Non-tree Link Failure" or a "No Route Available" status code, and the message originator sends a route discovery broadcast to create a new route.  The middle hop did have a good route though - it was routing packets to the coordinator just fine before it sent the Network Status packet to one of the message originators.

I'm speculating that if the middle-hop router fails to receive a MAC ACK from the coordinator, it sends a Network Status packet back to the message originator.  Further, if the message originator receives a Network Status packet indicating an error, I'm speculating that it sends a route discovery broadcast to create a new route.  Is that accurate?

If this is the case, we would like to make the network much more tolerant of packet failures and not request a new route because a single packet failed.

We found the MAX_MISSING_MAC_ACK_LINK_FAILURE define.  Does this value also set the number of MAC retries?  If not, I assume if we changed the MAX_MISSING_MAC_ACK_LINK_FAILURE from 3 to 21, then the middle hop router might not send the Network Status packet until 7 different packets failed??  If that is not correct, does anyone know what this value does?

Are there any other stack values we could change in our routers that would cause them to be more tolerant of packet failures and not request a new route if one packet (3 retries) fails?

  • 0
    Prodigy 120 points

    I just noticed the following code in zstacktask.c:

        if ( pPtr->pReq->has_maxMissingMacAckLinkFailure )
    {
        zgMaxMissingMacAckLinkFailure = (uint8_t)pPtr->pReq->maxMissingMacAckLinkFailure;
      osal_nv_write( ZCD_NV_POLL_FAILURE_RETRIES,
            sizeof(zgMaxMissingMacAckLinkFailure), &zgMaxMissingMacAckLinkFailure );
    }

    This makes it seem that the MAX_MISSING_MAC_ACK_LINK_FAILURE might pertain only to end device polls.  Is that correct?  If so, then adjusting this would not improve packet failure tolerance in our routers.

    I guess we could increase the MAX_DATA_RETRIES and NWK_MAX_DATA_RETRIES values to force more mac retries.  I'm actually not clear what the difference is between these two.  There is also a APSC_MAX_FRAME_RETRIES define, and the comment above this says this is the "maximum number of MAC frame transmission attempts allowed".  I assume that is incorrect and that APSC_MAX_FRAME_RETRIES is the number of APS retries, which doesn't pertain to us since we are not using APS Acks, but am not certain.

    So here are my questions from the above.

    1. Is my understanding correct that MAX_MISSING_MAC_ACK_LINK_FAILURE only relates to end device polls and has no impact on a router?

    2. What is the difference between MAX_DATA_RETRIES, NWK_MAX_DATA_RETRIES, and APSC_MAX_FRAME_RETRIES?  Which of these could help increase the number of MAC retries?

    3. Are there any other options we can configure in the TI stack that would cause our routers to be more tolerant of packet failures and not request a new route if one packet (3 retries) fails, as I described in the original post?

  • 0 in reply to Damon Stewart
    TI__Guru**** 219567 points

    Hello Damon,

    I apologize in advance if I repeat anything from our previous E2E conversations.  

    1. zgMaxMissingMacAckLinkFailure also applies to routers during RTG_UpdateNeighborEntry to force expiration of a link if the maximum missing ACKs is surpassed.

    2. MAX_DATA_RETRIES is unused and could be removed from code.  The device will first try to send the packet a total of ZMAC_MAX_FRAME_RETRIES, if these fails then it will increment the packet frame counter by 1 and attempt up to NWK_MAX_DATA_RETRIES times.  APSC_MAX_FRAME_RETRIES applies to retries based on not receiving APS ACKs, which you've already mentioned are disabled.  Relevant response here.

    3. Are you using MTO routing and have you reviewed the SWRA650 application report? ` There is also LINK_DOWN_TRIGGER which applies after X number of link status messages have been missed, sent every NWK_LINK_STATUS_PERIOD (15 seconds by default).  I feel that you've touched on the important parameters thus far and would encourage you to retry your test after modifying these values.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 120 points

    Thank you Ryan - that is super helpful!  We will tweak these values and retest.  (I am familiar with MTO routing, but this is a legacy system and we don't have the ability to adjust the coordinator firmware to enable MTO routing for now.  I will review the SWRA650 report - thank you for sharing it.)