zoukankan      html  css  js  c++  java
  • TWT节能机制

    原文地址:https://zhuanlan.zhihu.com/p/79572297

    TWT节能机制简介(Target Wake Time)

    TWT定时唤醒机制(Target Wake Time,TWT)首次出现在802.11ah “Wi-Fi HaLow”标准中,其用于支持大规模物联网环境下的节能工作。随着IEEE 802.11ax标准的发展,TWT的功能获得了进一步的扩展,这使得IEEE 802.11ax标准能够更加优化设备的节能机制,提供更可靠,更节能的传输机制。在802.11ax中,TWT机制在ah的基础上,已经被修改为支持基于触发的上行链路传输,从而扩展了TWT工作的范围。

    在TWT中,终端和AP之间建立了一张时间表(该时间表是终端和AP协定的),时间表是由TWT时间周期所组成的。通常终端和AP所协商的TWT时间周期包含一个或者多个beacon周期(总体时间比如几分钟,几小时,甚至高达几天)。当终端和AP所协商的时间周期到达后,终端会醒来,并等待AP发送的触发帧,并进行一次数据交换。当本次传输完成后,返回睡眠状态。每一个终端和AP都会进行独立的协商,每一个终端都具有单独的TWT时间周期。AP也可以将终端们根据设定的TWT时间周期进行分组,一次和多个终端进行连接,从而提高节能效率。

    如上图所示,User 1和User 2分别和AP协定了两个TWT时间周期,分别为TW1和TW2。终端User 1和User 2默认就工作在睡眠模式下(sleep mode),保持一个较低的功耗。当TWT时间周期到达时,AP会发送一个触发帧(Trigger)给终端,终端进而苏醒并和AP执行数据交换,当数据交换完成后,终端恢复睡眠模式。TWT和传统PSM模式的差别是,终端只在TWT时间开始的时候苏醒,而在PSM模式中,从该beacon周期开始,终端就会通过该beacon帧中的DTIM信息,观察是否AP是否由缓存自己的数据帧,如果有的话,那么就保持苏醒,直到接收完成后,才恢复到睡眠模式。在上图中,如果是传统的PSM的话,若本轮beacon帧中提示有User 1的信息,那么其不会在TW1时间内睡眠,会保持苏醒,直到数据交换完成后,才恢复睡眠。

    TWT的三种工作模式

    TWT一共有三种工作模式,分别是:1)Individual TWT,2)Broadcast TWT,3)Opportunistic PS。

    • Individual TWT:该模式下终端会和AP协商特定的TWT时间,该时间会被存放在AP的时间表中。终端会在特定的时间醒来并和AP进行帧交换。每一个终端仅仅直到自己和AP协商的TWT时间,不需要知道其他终端的TWT时间。Individual TWT还有多种工作模式,比如说显式工作模式。

    其大致工作流程如下:

    • 终端想要建立一个TWT连接,其会将自己的节能调度信息告知给AP
    • AP将会分配TWT周期,并将该周期反馈给终端
    • 终端会在指定的TWT周期时苏醒,并和AP进行数据帧交换
    • 在本轮交换中,会分成显式和隐式两种工作模式
      • 显式工作模式
        • 在本次数据帧交换中,AP会显式告诉终端,下一轮的TWT周期
        • 终端会在新的指定的TWT周期时苏醒,并再一次和AP进行数据帧交换
      • 隐式工作模式
        • 在本次数据帧交换中,AP不会告诉终端,下一轮的TWT周期
        • 终端会自己计算出下一轮的TWT周期(通过在当前TWT周期上增加一个特定的时间)
        • 终端会在自己计算的TWT周期时苏醒,并再一次和AP进行数据帧交换

    如上图所示,终端会在苏醒的时候,首先和AP发起一个TWT建立请求,终端和AP协商一个TWT时间(即图中Negotiate a schedule),当协商完成后,终端就进入睡眠状态。在该图上,AP发送Beacon时,也会包含了公开的TWT信息,在Individual TWT工作模式下,该信息终端时不需要的。终端一直保持睡眠状态,直到TWT时间到达。终端苏醒,并接收AP的触发帧,即TWT Trigger。当终端接收到该触发后,其会和AP进行数据帧交互。于此同时,AP会告知终端下一次的TWT时间(在显式TWT中,睡眠间隔的逐次设定的),终端会在新的TWT时间上,定时苏醒,并执行数据帧交换。TWT的一次苏醒间隔有可能是小于一个beacon周期,也有可能是大于一个beacon周期的,相比于传统的PSM,APSD之类的节能方式,更加具有一般性。

    终端和AP可以关于TWT时间周期进行协商,终端可以要求取消TWT参数,或者向AP请求特定的TWT时间。如果AP统一终端的请求,其会反馈“Accept TWT”。还有多种协商的具体参数,可以参考上图,即协议中的Table 10-19a。

    • Broadcast TWT:广播TWT机制是一种由AP负责管理的工作机制。在该机制下,TWT时间周期是由AP宣告,通常AP会在每一个beacon帧中宣告本轮的TWT时间周期。在一些特殊的情况下,AP也会在其他的管理帧中宣告,比如Association帧,Reassociation帧或者Probe Response帧等等。我们需要注意在Broadcast TWT中,存在加入组和离开组的交互动作,终端需要向AP申请加组才可以执行Broadcast TWT,这个加组交互动作也是通过在终端和AP交换管理帧中,通过携带TWT elements完成的。当终端完成加组后,终端会按照最近接收到的TWT时间周期进行工作,此时这一类型的终端也被叫做“TWT Scheduled STA”,AP被称为“TWT Scheduling AP”。终端在TWT时间周期到达后进行苏醒,AP会发送广播的触发帧,发现哪些终端正在处于苏醒状态(加组后的终端们),并向这些终端发送数据帧,这里由于是广播通信,所以只有AP向节点发送。当AP发送完成后,终端恢复到睡眠状态,直到下一次广播TWT时间到达。通常,这种广播TWT中的时间间隔,我们也称为“TWT SP (Service Period)”。

    如上图所示,AP会在Beacon帧中,进行TWT Broadcast时间周期(即TWT SP时间)的宣告。终端们苏醒并接收该Beacon信息。然后在对应的TWT时间到达时,对应的终端们会提前苏醒,接收AP发送的TWT trigger,以及AP发送的下行数据帧,在此过程中,AP也由可能发送新的一次的TWT Broadcast时间周期(即TWT SP时间)。终端接收完成后,进入睡眠状态,并在新的TWT SP时间到达时,再次苏醒,以后以此类推。

    • Opportunistic PS:机会PS模式和前面两种工作模式是类似的,但是没有AP和节点的协商过程。AP会在每一个Beacon内,公开宣告一个TWT时间。任意终端可以选择在这个公开TWT时间内进行苏醒,并和AP执行数据帧交换。这个交换可以是单个节点的,也可以是采用OFDMA机制进行交换。

    如上图所示,AP在Beacon帧中宣告了一个公开的TWT时间,任意终端都可以直到该TWT时间。当该TWT公开时间到达后,AP会发送触发帧,此时苏醒的节点可以和AP进行交互,并执行数据帧的交换。在图中,由多个节点苏醒,从而触发了一次OFDMA类型的数据帧交互。

  • 相关阅读:
    mysql 时间戳 转 时间
    VSCode搭建VUE 开发环境
    虚拟通信
    JavaScript 获取客户端计算机硬件及系统信息
    Thinkphp关联模型BELONGS_TO
    docker部署rancher踩坑篇
    青龙面板 脚本 依赖库下载安装
    Linux 随记
    Tekton DAG代码
    手写Spring valar
  • 原文地址:https://www.cnblogs.com/liuyufei/p/12656606.html
Copyright © 2011-2022 走看看