WiFi6之I-TWT分析
时间:06月26日 人气:...

今天聊一聊wifi6的一种新节能机制twt,咱只分析Individual TWT,下面主要分三部分来说,如果只想看交互实例的话就直接看第二部分就可以了。

一. 原理简述

这节的内容基本上都是从网上抄来的,如果看着眼熟那就对了,我看网上的描述大概意思也没啥毛病,所以就搬过来了。

在802.11ax之前,Wi-Fi协议采用的节能机制有“legacy PS”和“WMM-PS”技术,前者STA可以在一个或多个beacon的间隔之间睡眠,当唤醒时可以发送上行的报文,也可以通过监听beacon的DTIM字段获知是否有需要接收的下行报文,如果有需要接收的报文,STA可以发出trigger获取相关的报文。这个机制被验证有效单节电效果有限,通常STA需要在一秒内唤醒多次来读取DTIM。后者在802.11e中提出,主要针对voice-over-Wi-Fi设备对于节电的需求。语音设备往往需要以固定的短间隔传输报文(如20ms)。该节能机制允许设备在一个beacon周期内多次休眠和传输报文。同时,考虑到语音通信的对等特性,U-APSD设计了通过上行报文触发下行发送的机制。

但是上述低功耗机制也存在效率低,延时大等问题,对于采用legacy PS机制的STA,每次要获到缓存于AP中的数据,必须通过发送PS-Poll帧,完成一次完整PS-Poll->ACK握手,效率很低;并且STA每次根据DTIM间隔定时醒来接收AP的广播帧,而DTIM一般Beacon(100ms)时间的整数倍,所以STA与AP进行数据交互的时延比较很大,不能应用于延时敏感的场景,并且通常STA每秒必须唤醒几次来读取 DTIM。虽然在实时性业务方面WMM-PS做了很大的改进,减小实时性要求高的业务在电源管理过程中的延迟,但是其灵活度依然限于AP与STA单点“沟通”,休眠时间上依然受限于Beacon周期。

相对于专门针对IoT市场的BLE等协议的功耗劣势比较明显,于是802.11ax提出了一种新的TWT(Target Wake Time)“目标唤醒时间”机制来增强IoT场景的低功耗性能,据称采用此项技术之后采用电池供电的STA可以拥有更长的待机时间,电池消耗最多减少7倍。

802.11ax新引入的节电机制TWT(Target Wake Time),拥有更大的弹性,允许更长的节电周期,以及多设备的休眠调度。借助TWT,AP与STA之间不再与Beacon周期绑定。TWT允许AP和STA之间单独协商休眠和通信的周期,AP可以在任何约定的请求时间表来唤醒STA(几分钟,几小时甚至天级别),这就为电池供电的设备(尤其是物联网领域中的设备)节省了大量电能。TWT的一个相关但重要的好处是借助新OFDMA调度功能,它还可以使用似于UL-OFDMA的上行链路调度方法。利用OFDMA同时唤醒以便它们可以同时通信并共享信道,从而增加网络容量,减少竞争降低延时。由于AP与每个STA单独协商,因此它可以分组或分别按计划发送,以实现最佳流量效率或适应来自其他STA的流量要求。同时每个STA都可以与AP针对几种不同类型的应用程序协商多个单独的唤醒协议。

TWT除了上述individual模式之外,还可以有broadcast模式,被TWT调度的STA可以加入特定的广播TWT(通过广播TWT ID和TA),许多STA希望接收的多播流量可以由AP按照信标中发布的时间表进行设置。另外802.11ax还支持一种Opportunistic 节能功能,其允许AP公布任何即便在 OFDMA环境下STA也可以醒来并请求数据包交换的时间间隔,AP之间没有任何协商,醒来之后进入竞争模式。

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

Individual TWT,就是AP和STA一对一的协商TWT服务时间,每一个STA仅仅知道自己和AP协商的TWT时间,不需要知道其他STA的TWT时间。

一个一个协商实在太费事,于是Wi-Fi 6又新定义了一种Broadcast TWT。如果说,Individual TWT是私聊模式的话,Broadcast TWT就是群聊模式。Broadcast TWT由AP负责管理,在该机制下,TWT服务时间是由AP宣告,STA可以向AP申请加入Broadcast TWT,加组完成后,STA就可以获得AP的广播TWT服务时间了。

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

下面仅是分析Individual TWT过程,不对其他两种模式做介绍。

I-TWT模式STA会和AP协商特定的TWT时间,该时间会被存放在AP的时间表中。STA会在特定的时间醒来并和AP进行帧交换。每一个STA仅仅直到自己和AP协商的TWT时间,不需要知道其他STA的TWT时间。I-TWT还分为显式和隐式工作模式。

其大致工作流程如下:

1. STA想要建立一个TWT连接,其会将自己的节能调度信息告知给AP

2. AP将会分配TWT周期,并将该周期反馈给STA

3. STA会在指定的TWT周期时苏醒,并和AP进行数据帧交换

4. 在本轮交换中,会分成显式和隐式两种工作模式

    显式工作模式时

            在本次数据帧交换中,AP会显式告诉STA,下一轮的TWT周期

            STA会在新的指定的TWT周期时苏醒,并再一次和AP进行数据帧交换

    隐式工作模式

           在本次数据帧交换中,AP不会告诉STA,下一轮的TWT周期

           STA会自己计算出下一轮的TWT周期(通过在当前TWT周期上增加一个特定的时间)

           STA会在自己计算的TWT周期时苏醒,并再一次和AP进行数据帧交换

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

STA和AP可以关于TWT时间周期进行协商,STA可以要求取消TWT参数,或者向AP请求特定的TWT时间。如果AP同意STA的请求,其会反馈“Accept TWT”。

二. 交互实例

1. 这个过程可以通过抓包看到,先观察AP是否支持TWT,然后观察协商过程

AP会在管理帧(一般为beacon、probe resp、asso resp)中携带TWT支持情况,主要包含在这俩IE中:

当然在STA联网时,通过观察STA发送的asso req帧中的这俩IE也能知道STA对TWT的支持情况。

2. 进行协商时,STA先发送setup:

3. AP收到会回应accept:

之后STA就会进入睡眠了。

从收到accept帧开始计时,一直可以睡到wake time时间到来,唤醒之后需要保持工作wake duration的时间,此即为sp期。sp期结束后继续睡眠,如此循环。。。

wake time时间计算:STA需要根据AP的beacon同步时间(tsf),wake time即为tsf时间。

wake duration时间计算:先观察twt control第5位的值,为1则wake duration的单位是1TU(1024us)、为0则wake duration的单位是256us,所以wake duration得实际时间为wake duration * unit。

4. 当STA不再需要TWT节电时,可以发送teardown告知AP;当然AP也可以主动发送给STA解除:

对方收到后不会再回应action帧。

三. TWT现状

目前,WiFi6生态还是不太成熟,市面上支持的TWT的AP很少,支持TWT的STA几乎没有,想找个支持TWT的手机之类的商业化的STA辅助分析一下就很难了。 甚至有些大厂的AP号称支持TWT,实际上支持不是很完善,一协商TWT就会出问题。。。 所以预计还要好长一段时间市面上才会能买到各种完善支持TWT的STA和AP,到那时候我们才可以充分使用和方便分析和学习了。。。

热门评论