[参考译文] CC3120：在关联请求中发送的侦听间隔

您好！

您从何处获取侦听间隔？ 它不会以关联请求的形式传输到 AP。

我想您提到 long_sleep_interval 功能、对吗？

如果是、则 LSI 特性完全不涉及 AP。 它基于来自 AP 的信标间隔和 DTIM 间隔、并计算何时唤醒以接收信标(和 DTIM)。

例如、如果您设置为600mSec、并且 AP 使用102.4mSec 的信标间隔和2个信标的 DTIM 周期、这意味着您将能够在600mSec 内获得2个 DTIM (第三个 DTIM 将通过600mSec、因为它是614.4mSec)。

此致、

Shlomi

您好 Shlomi、感谢您的响应。

我能够看到关联请求的线鲨轨迹中的侦听间隔。 我认为这是客户端设备 向 路由器发送侦听间隔的唯一帧。

是的、我在这里讨论的是长睡眠间隔、但为了使实现正常运行、我认为路由器会针对器件在其关联请求中共享的监听间隔期间缓冲单播数据包。 因此、如果我们与 LI-3发送了关联请求、并且如果我们将客户端唤醒间隔保持为600ms、那么在我们读取数据包之前、路由器很可能不会为我们缓冲数据包。

此致、

Soundarya.

您好！

关联请求的侦听间隔 用于向 AP 指示在省电模式下唤醒 STA 以侦听信标管理帧的频率。  AP 可以使用监听间隔信息来确定其缓冲 STA 的帧的寿命。 我没有看到这个数字有任何问题、通常 AP 需要更多时间才能丢弃帧。

我不会担心将 LSI 设置为600mSec。

Shlomi

您好！

从我们完成的 IOP 实验室测试中、我们注意到最多2秒应该没有问题。

使用较大的数字可能会导致某些 AP 对站点取消身份验证。

此致、

Shlomi

Shlomi、您好、感谢您的答复。 是否有计划更新关联请求中发送的此监听间隔值、或者是否将其设置为3、因为它不会导致任何问题？

Soundarya.

由于 AP 实际上并不使用它、因此没有计划更改它。

如果您使用长睡眠间隔 API 并每隔几个 DTIM 信标唤醒一次、则这是专有的实现方式、AP 不会对此进行感知。