CMSA/CA碰撞避免机制和DataRequest时间设置的问题

如果我記得沒錯，这个延迟等待时间是沒算在设置NLME_SetPollRate(1000)这个1s里

这个比较偏底层，需要跟zigbee team讨论一下再过来更新

我这边思考下，这个应该也是不算在这边的，想确认下

好的，谢谢，还有以下疑问：
1、协调器有数据发送时，会先进行CCA检测，查看相关信息，得出这个CCA检测时间大概是1ms，这边想确认下这个时间是多少？然后这个时间确定了后，还有相关疑问。
2、协调器再发送DataRequset之前，会进行CCA检测，此时DataRequest会等待检测结果处理，等待这个时间跟CSMA-CA机制的第一次延迟时间是同一个时间？如果不是，麻烦您解释下这两个时间。

可以參考一下 TheDarkSide 在 e2e.ti.com/.../1198704 的說明

很好奇确认NLME_SetPollRate(1000)这个设置时间對你來說可以作什麼呢？

协议栈的休眠机制这块，我们开发者是不能进行控制何时进入休眠以及休眠时间的问题，然后就是使用其他方法进行处理，处理中遇到E会出现掉网情况，但是这个掉网的情况协议栈这边是发现不了的，我查了相关资料，这个问题数据链路层的问题，最后查看DataRequest发送返回的错误类型好像是0xC2（记不太清楚了也可能是0x2C），为了解决此问题然后使用了NLME_SetPollRate，然后就了测试了从设置到调用mac层的数据请求函数的时间大概在10ms，然后之后又根据无线数据的处理机制，所以才有相关疑问

而且涉及到无线数据问题，无线数据的丢包问题，无线数据接收延迟问题，这些都暂时没有摸清楚

掉网的情况跟SetPollRate應該沒多大關聯吧

当时情况是这样，就是在测试中，发现设备E1接收不到C的控制指令，然后脱网指示灯也没有亮（设备脱网脱网指示灯会亮），然后就尝试按键查看情况，发现按键操作也是无效的，只有把此设备进行重启才能解决此问题（这个问题的根本原因可能是我自己写了一个休眠处理，进行强制休眠），为了解决此问题，就找下合适的方法，然后就问题重现，重现之后进行单步调试，查看网络状态正常，就是发送数据返回结果这边没有返回成功，返回的结果是链路层数据发送失败，所以就从NLME_SetPollRate进行尝试解决问题，然后发现在测试中暂时没有出现此问题，然后就考虑这个NLME_SetPollRate设备的时间等一系列问题

基本上 延迟等待时间是沒算在设置NLME_SetPollRate(1000)这个1s里

条件：1个协调器设备C，无路由设备R，1个终端设备E
操作：
1、E的休眠时间，小于C对E的数据缓存时间，这样可以确保E唤醒后进行数据请求，C这边有缓存数据，然后在E休眠时间内，C发2帧数据给E，E在休眠中，所以会缓存到C中，待E休眠唤醒后发送DataRequest进行接收数据，我抓包查看发现，此时E发送第一个DataRequest请求去接收C中的第一帧数据后，会立刻发第二个DataRequest去接收C中的第二帧缓存数据，这两次的DataRequest是连续的，跟NLME_SetPollRate(1000)无关
2、在1的发现下，E不进入休眠，然后C连续发送2帧数据，抓包查看结果同问题1的结果，抓包查看到的两个DataRequest时间相差在100ms左右，
3、根据问题1和问题2，想问下，这个第一次发送DataRequest接收数据后开始，到第二次发送的DataReques，期间存在DataRequest的窗口期进行竞争？目前我测试后发现是不存在，如果不存在那这段时间是怎样一个处理机制？

看相关资料说,在CCA检测时，会附带C占用信道的时间信息，这样方便E调整自己的网络分配向量NAV，存在这种机制？如果存在，是不是其他E检测到相关信息后，怎么处理（跟CSMA-CA的延迟机制会不会冲突？）？