• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 55 subscribers
  • Views 906 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.

CC2531: Data From MAC Layer Post Association

Abhay Joshi
Intellectual 810 points
Part Number: CC2531
Other Parts Discussed in Thread: Z-STACK

Hello,

I am running the Z-Stack Mesh 1.0.0 configured as End-Device on CC2531. On the other CC2531 device, I have a Zigbee Co-Ordinator. Post Association Request - Association Response and Device Announcement, the End-Device would keep consistently polling the parent for any data available through the Data Request.

I am observing some Data Packets being sent by MAC Layer (TI-MAC) of the Co-Ordinator, which automatically stops after a few data requests from the end-device. Please find attached the Sniffer Logs. Is this expected behavior?

Also, When an MLME_Start_Request is issued, will the PAN Co-Ordinator start periodic advertising (Link Status)?

Association_Captures.zip

  • 0
    TI__Guru**** 219997 points
    Hello Abhay,

    There are cases where empty data packets are intentionally sent, for example when there are too many ZEDs in the MAC source matching table. If there isn't any space then you just set the pending bit for all MAC Data Requests to frame pending temporarily as a work around until the buffers are cleared to guarantee that devices can receive their messages before they expire. The relevant define is MAC_SRCMATCH_SHORT_MAX_NUM_ENTRIES. So although not typical it is possible for data packets of zero length to exist, however generally expected behavior is that the data requests are acknowledged but not replied to as shown later in your log.

    After a routing device has joined the network it should send out a link status every NWK_LINK_STATUS_PERIOD seconds (nwk_globals.h).

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 810 points

    Hello Ryan,

    In my network, I have only one End-Device trying to connect to the Co-Ordinator. The MAC_SRCMATCH_SHORT_MAX_NUM_ENTRIES is set to 24. Under high traffic conditions, we might expect this behavior. But with the current setup, do you see any other reason why this behavior is observed?

  • 0 in reply to Abhay Joshi
    TI__Guru**** 219997 points
    I only mentioned source matching as an example, not a suggestion as to what the issue was. Are you using TI examples or a custom application? I wouldn't be concerned with short-term behavior, does it always disappear after a few seconds?

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 810 points

    Yes Ryan,

    It does always disappear after a few seconds. At times, there are no empty data packets exchanged as well. I am running the sample application (GenericApp) from Z-Stack Mesh 1.0.0.

  • 0 in reply to Abhay Joshi
    Intellectual 810 points
    Hello Ryan,

    In a Security enabled Network, Is there any requirement that the Network Key be shared immediately after Association Response through APSME-Transport-Key-Request?
  • 0 in reply to Abhay Joshi
    TI__Guru**** 219997 points
    Hello Abhay,

    The network key should be transported to the joining device or else it is not going to be able to communicate on the network. This is automatically handled for new devices in the ZDApp_ProcessSecEvent of ZDApp_event_loop.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 810 points
    Hello Ryan,

    My query was with respect to the delay that can be tolerated by the end-device between receiving the Association Response and the Transport Key Packet which contains the Network Key. Ideally, both packets should be queued one after another, but a delay of few data requests is tolerable.
  • 0 in reply to Ryan Brown1
    Intellectual 810 points
    This was caused due to the mismatch in the PAN ID when putting the data in the pending queue meant for the associated end-device (Address Is Good, PAN ID Is Wrong). A fix to that eliminated this issue.