TI中文支持网使用场景：
协调器C， 路由R。
正常情况下：R通过短地址0x0000，AF_DataRequest发送消息给协调器，显示返回状态0，为成功；
抓包文件看到C有mac层的ack确认帧；
出现问题的情况：将C断电后，R通过短地址0x0000，AF_DataRequest发送消息给协调器，仍旧显示发送成功。
抓包文件发现有重发三次，并且C没有返回ACK（C都断电了，让然没有ack了）。
分析：AF_DataRequest的返回状态应该只表明了发送成功，但是没有处理接收成功；
问题：
我应用层如何知道C没有接收到，因为消息不可以丢失，我可以怎么处理？
是否可行的方案：
1. 通过协调器收到消息后，应用层再返回数据帧；
2. 是否有应用层可以处理mac层的ack超时事件，用于择机重发。
YiKai Chen：
使能並檢查APS ack就可以了
user4356936：
回复 YiKai Chen:
感谢 YK Chen，我要在哪里使能此项？
YiKai Chen：
回复 user4356936:
AF_DataRequest的options參數上去使能AF_ACK_REQUEST
user4356936：
回复 YiKai Chen:
我试试，谢谢。
user4356936：
回复 Alvin Chen:
我已经加上 AF_ACK_REQUEST,并且ubiqua下也能看到这个ack；
我把协调器C断电后，ACK没有了，但是这个依旧似乎 status= afStatus_SUCCESS；
我看了其他你之前的帖子：
提示说： 你有沒有用zcl_registerClusterOptionList去註冊要收APS ACK；
还有 ：e2e.ti.com/…/using-the-af-data-confirm-cmd-system-event-in-the-z-stack-to-track-acknowledgements-zigbee.aspx， 这个文件我打不开了。应该是地址变化了吧。
具体还有些不知怎么操作，需要你指点。
YiKai Chen：
回复 user4356936:
可以參考 sunmaysky.blogspot.com/…/how-to-check-aps-ack-in-ti-z-stack.html
user4356936：
回复 YiKai Chen:
sunmaysky.blogspot.com 我们国内无法访问吗？
user4356936：
回复 YiKai Chen:
我启用AF_ACK_REQUEST后，在SAPI.C里面的 SAPI_ProcessEvent() 下的SYS_EVENT_MSG事件里面的case AF_DATA_CONFIRM_CMD: 下pDataConfirm->hdr.status 变量如果为0，表示协调器接收到。
如果不为0（典型的是0XE9）,表示协调器没接收到（我此时关掉了协调器）。
以上看起来满足了我的需求。
但是，但是，我将AF_DataRequest 里面的option选项 将 AF_ACK_REQUEST修改为0后，上面的pDataConfirm->hdr.status仍旧可以用。看起来是我的使用方法不对。但是又不知道问题出在哪里。。。
而下面这个访问不了，比较尴尬
sunmaysky.blogspot.com/…/how-to-check-aps-ack-in-ti-z-stack.html
user4356936：
回复 YiKai Chen:
另外一个问题： 我只有一个R和一个C，但是看整个空中报文很多。不知道红框内的报文是干嘛的？
因为我一个C下面挂60-80个R，每个R会根据状态随时汇报数据给C，只是一个R就这么多报文，我怕到时候那么多的R，整个网络都拥挤不堪。
已经启用了MTO。
附件里的是：一个R，大概7-8秒发送一个报文给C。这样的报文密度是否正常，我是否可以优化一些网络参数？
AAA.c
