CC2530: In zstack 3.0.2, if end device lost parent when wait APS-ACK, it will miss afDataConfirm.

How to force my application to trigger "afDataConfirm" as "APS-Ack timeout error" after end device trigger "ZDO_SyncIndicationCB"?  Will APS-Ack waiting timer be freed when "ZDO_SyncIndicationCB" trigger?

Has TI known this issue and fixed it for newer Z-stack? Dose this issue appear on simplelink SDK?

You could directly call afDataConfirm using the EP, transID, and Status (ZMacTransactionExpired) in question.  ACK counters are handled by the RTG layer of Z-Stack and will be expired/cleaned regardless of ZDO behavior.

I have not confirmed whether such behavior exists on the SIMPLELINK-CC13XX-CC26XX-SDK, whether it is an issue depends on the interpretation of the problem.  If the device is orphaned then it clearly will not be receiving APS ACK packets.  This could again be something interpreted by the application.

Regards,
Ryan

If ZED become orphan, its waiting should be finished early.

My program needs to get which AF-Request is in waiting while ZED orphan.  Is there a APS-Ack waiting timer in zstack?

There is not an APS ACK timer in Z-Stack.  It is recommended to make the APSC_ACK_WAIT_DURATION_POLLED*2*APSC_MAX_FRAME_RETRIES shorter than MAX_POLL_FAILURE_RETRIES*POLL_RATE.  This is to avoid orphaning before messages are still waiting to be acknowledged.  If the ZED becomes orphaned then it knows that it is finished waiting for AF Requests.

Regards,
Ryan

My APSC_ACK_WAIT_DURATION_POLLED is "3000", but why does the sender transmit retry-packet after 6 second?

When end device loses its parent, it will take time to reconstruct routing path and I think it's normal not to receive APS ack. I would suppose your application can do re-send the message when there is no APS ack received.

AF_DATA_CONFIRM_CMD event should be triggered when AF_DataRequest return "Success" anytime. If ZED lose its parent when it is waiting APS-Ack, the stack lower-layer should trigger AF_DATA_CONFIRM_CMD event to notify application.

From Z-Stack user point of view, I don't expect this happens so I would use workaround as I mentioned in my previous reply.

I want to add a function into "ZDO_SyncIndicationCB" to execute "afDataConfirm", but how can I do?

When "ZDO_SyncIndicationCB" trigger, what endPoint and transID is in waiting?

If all of AF_DateRequest can trigger confirm event. Applications can malloc buffer before send, and free buffer when get confirm event.

With APS ack enable, I usually send messages one-by-one after I receive APS ack. In such case, I will create a timer event (with longer timeout) to wait check if APS ack is received for previous sending message until next message can be sent. For message with APS ack received with AF_DATA_CONFIRM_CMD event, my application will cancel the timer for next message to send.

I also use AF_DATA_CONFIRM_CMD event as a timer. Whatever message is sent Success or Failed,  AF_DATA_CONFIRM_CMD event will trigger.

I actually create a separate timer event not  using AF_DATA_CONFIRM_CMD event as a timer for my approach.

APSC_ACK_WAIT_DURATION_POLLED is in units of 2 ms, hence a value of 3000 is 6 seconds.

Regards,
Ryan

In nwk_global.c, there are some parameter

// Maximums for the data buffer queue
#define NWK_MAX_DATABUFS_WAITING    8     // Waiting to be sent to MAC
#define NWK_MAX_DATABUFS_SCHEDULED  5     // Timed messages to be sent
#define NWK_MAX_DATABUFS_CONFIRMED  5     // Held after MAC confirms
#define NWK_MAX_DATABUFS_TOTAL      12    // Total number of buffers

which is the APS-Ack waiting buffer size?

I don't think there is APS-Ack waiting buffer. APS-ACK should go to AF incoming message directly.

But when a AF_REQUEST is waiting Aps-ack and be timeout, it will trigger "afDataConfirm". So there must be a APS-Ack timeout timer.

As I know, Z-Stack would allocate a new buffer attach to a pointer for APS ack checking. The size of this will keep adding until Z-Stack cannot allocate memory.

Messages which have not been APS ACKed will go from a state of NWK_DATABUF_SENT back to NWK_DATABUF_SCHEDULED which expire after the wait time has elapsed, meanwhile the original buffer is marked as NWK_DATABUF_DONE so that it can be removed/refreshed for the next retry (if warranted).

It appears a solution has been developed for the SimpleLink SDK: https://e2e.ti.com/f/1/t/1092052 

Regards,
Ryan