[转]802.11协议精读10:节能模式(PSM)

注:本文转自802.11协议精读10:节能模式(PSM)

序言

在802.11主要的版本中,总共定义了四种节能模式,本文主要关注最初始的PSM模式,对于在802.11e中添加的ASPD以及802.11n中添加的PSMP,SMPS机制,我们在下一篇再进行论述。

PSM(Power Save Mode):802.11协议中初始的节能模式,其对基础架构模式和IBSS模式下的节能机制分别进行了定义,并且在DCF和PCF模式下,其具体的MAC层工作机制也有不同。
如同我们之前的描述,802.11的节能模式基本思想是:AP缓存下行数据,只有当节点休眠结束后主动向AP请求,AP才进行下行数据的反馈。这里实际上存在一个问题,即节点不知道AP上有没有自己的缓存数据。故实际思路应该是,AP周期性向对应的节点其广播缓存区情况,从而节点可以知道自己是否被数据缓存了。在休眠结束后,被缓存数据的节点就会进行数据请求,反之就继续休眠。这样可以有效避免节点进行一些无意义的数据请求(即AP上没有缓存数据,但是节点进行数据请求)。

所以本文我们首先要回答两个问题:1)AP如何广播自己的缓存区信息(即AID,TIM与Bitmap机制),2)AP什么时候广播对应节点的缓存区信息(即TSF,TBTT,Listen Interval field与CFP repetition interval)。在此之后,我们再对协议中具体的MAC层工作机制。

PS:本篇的概念又多又繁杂,且与前面描述的DCF和PCF基本工作模式关联较大。故本篇已尽量按照先需求后设计的思路进行描述,其他不足之处,还请见谅。同时在802.11的一些分支版本中也定义了一些特定的节能模式,比如802.11v的WNM-Sleep Mode,这些我们就不进行展开了。

AID,TIM与Bitmap

在802.11协议中,设计了一种用较少字段就能够广播自己缓存区信息的机制,如下图,我们首先描述其大致的思想:

实际上是AP是采用一种Bitmap结构,用来通知节点自己的buffer信息的,若将其看做一个矩阵的话,那么该矩阵的每一行有8列,最下包含1行,最大包含251行,换言之该矩阵最大的存储空间为251个By。该矩阵中每一个位置代表了一个节点,比如红色方框位置就代表了STA0,蓝色方框位置就代表STA4,紫色方框位置就代表STA24。而矩阵中具体的某一个元素则代表了Buffer的情况,若该元素为1,那么代表其对应节点有数据缓存,若元素为0,那么就没有数据缓存。AP周期广播这样一个bitmap,节点就会查看自己对应的位置是1还是0,从而再决定是否要发送PS-poll请求数据。

那么具体该矩阵中的某一个位置,对应的就是节点的关联ID(AID)。

  • AID(Association IDentifier):关联ID,该参数相当于给STA起一个别名。在AP身上有一个association ID table,其中每一个AID都是和其对应STA的MacAddr进行绑定的。AID的范围是从0~2007,所以也说明了在协议中,一个AP最多可以关联2007个节点。AID=0的位置为保留字段,并不分配给节点,用以代表所有的组播和广播。
    比如上图中,红色方框处描述了AID=0有数据缓存,也就是存在组播或者广播的缓存(即实际上STA0不存在),蓝色方框为AID=4的节点(也就是实际存在的节点STA4)其数据被缓存,紫色方框为AID=24的节点,其数据被缓存。

AID的分配:当一个节点(STA)向AP发起关联请求(Association Request)后,AP会反馈的关联相应帧(Association Response)。AID也是在这个过程中被分配,并告知节点(PS:在重关联过程中,该AID也会被分配,不过这里我们并不讨论)。如下图,是一个Association Response帧格式其中就包含了Association ID这个参数。

通常AP在分配AID参数时,应该是按照从1开始,一个个下发给节点的,同时这里虽然显示的是2 Byte,也就是16位,但是为了与我们后面提到的Duration/ID字段兼容,所以其最高的两位都是置1,作为保留字段,所以范围是1~2007。因为AID的分配不像DHCP协议那样,可以设置一个失效时间,即AP不会主动回收已经分配给某些节点的AID。所以导致新的节点加入AP时,被分配的AID有的时候会比较后,后面我们分析TIM字段中的bitmap设计对此就有所考量。下图是在抓包中,具体的AID的显示:

当AID分配之后,节点就可以利用bitmap来广播自己所缓存的buffer信息,在802.11协议中,由于该buffer也是周期性的进行反馈,所以被放置在beacon帧中,作为一个字段被携带,该字段就是TIM字段。
TIM(Traffic Indication Map):流量指示图,实际上是一个基于bitmap结构的流量指示图,用以标识AP的缓存信息。其具体结构如下:

  • Element ID:元素识别码,用来标识beacon帧中所包含的不同字段。
  • Length:长度,描述的是该Element的长度,实际上Element ID和Length是一般管理帧中information element必备的元素,这里就不详细展开了。
  • DTIM Count,DTIM Period:DTIM计数以及间隔的时间。在802.11协议中,我们可以看到三个概念,TIM,DTIM,ATIM。TIM是一种基本的流量指示图的结构,标准的TIM中仅仅指示AP缓存的单播信息,DTIM(Delivery Traffic Indication Map)是一种特殊的TIM,其除了缓存的单播信息,也同时指示AP缓存的组播信息。一般情况下,每一个beacon帧中都包含一个TIM信息,不过该TIM具体是不是DTIM,则需要考量DTIM Count和DTIM Period两个参数。DTIM Period是一个周期,是一个固定值,代表经过几个TIM之后就会出现一个DTIM。而DTIM count是一个计数值,是变化的,当DTIM count=0时,则代表这个TIM是一个DTIM。实际上如果DTIM Period设置成1,那么每一个TIM字段中,DTIM count都等于0,所以每一个TIM就是DTIM了。PS:至于ATIM,ATIM是一个帧,在IBSS模式下被使用,由于本文主要讨论的就是基础架构模式下的无线网络,所以这里就不展开了。
  • Bitmap Control,Partial Virtual Bitmap:该字段就是Bitmap的具体字段,实际上与我们一开始描述的bitmap结构还存在一些区别。以下我们重点描述下协议中具体使用的bitmap结构。
    Bitmap:在前面,我们所给出的是一个最为初始的一种bitmap结构,该结构还是有一些缺点的
    占据较长的传输时间:同时由于在802.11协议中,Beacon的实际发送一般都是采用最低速率的,其包含两个原因,1)beacon帧是一个广播帧,其没有ACK反馈,所以无法设置重传机制,2)beacon帧目的是广播AP的基本信息,所以希望所有的节点都能够有效的接收该数据,从而采用较低的速率以保证信号较差的节点也可以接收该信息。所以,如果每一个Beacon帧中,都包含一个完整的251 Bytes的bitmap,那么就会占据比较长的传输时间,降低信道的利用率,对整体的吞吐量造成影响。所以在实际应用中,对于后面没有使用到的AID位置,我们传输时可以省略,从而减少bitmap的空间。
    缺少灵活性:由于bitmap中每一位置就对应了一个节点的AID,同时在我们之前叙述,AP对于AID的分配并没有一个回收机制。所以有可能出现,AID从0~300的位置都是没有再使用过的节点信息,而真正活跃的节点都是在AID从300~330左右的位置。这样如果仅仅去除后面没用的AID位置,也会多出来300 bits左右的空间浪费(即之前0~300个没有再次使用的AID范围)。故这里不仅仅需要省略后面的bitmap空间,也要对前面的bitmap空间进行优化省略。

如上图,我们可以更明确的看到其缺点,并且想到改进的思路。比如在该图的情况下,只有AID=120~127位置的节点,存在数据缓存。其余AID<120的节点没有数据缓存,AID>127的节点也同样没有,所以具体传输时,我们只要通知AID为120~127的节点即可,其余两个部分都是冗余,也就是没有意义的,所以对此我们要进行压缩。在802.11中,具体是设计了Bitmap Control和Partial Virual Bitmap的结构来解决这个问题,如下图所示

在802.11协议中,Bitmap control和Partial Virtual Bitmap是放在一起使用的,其中Bitmap control字段还分成两个部分:

  • 第[0]位是用来指示是否有组播/广播数据包被缓存的,这个是一个特殊位。如果为1,那么有组播/广播数据被缓存,反之没有。
  • 第[1:7]位是用来标识Bitmap offset,用来指示AID的偏移情况。该参数是用来描述在Partial Virtual Bitmap中起始AID的,在上图中,由于Bitmap offset部分都为0,所以起始AID是从0开始的(PS:由于协议规定AID=0是一个保留字段,用来标识所有广播和组播信息,所以没有分配给节点进行使用。但是Bitmap control字段中的第一位也是这个功能,所以实际上AID=0是没有被使用的。),之后的AID=1就代表了节点1,而AID=8则代表了节点8。Partial Virtual Bitmap是一个变长的字段,范围是1~251,也就是说,如果后面的AID没有对应的缓存,那么就不会存放在Partial Virtual Bitmap中。(PS:这里需要注意的是,由于这里是按照Byte的形式进行存储的,所以是按照8位进行步进,如果不够8位的部分,则需要补全)

我们现在关注Bitmap Offset的使用方法,前面提到,Bitmap offset是用来描述首位AID的偏移的,若该字段都为0,代表偏移值为0,所以在Partial Virtual Bitmap中是以AID=0开始计数的。现在我们描述Bitmap Offset不为0的情况,首先我们给Bitmap control每一位标注x1~x7,这里标注顺序与一般二进制表示的顺序刚好相反。每一位代表特定的偏移量,这些偏移量计算都是以8做为奇数的,若仅仅x1为1,其余都为0,那么AID起始为28=16,若仅仅x4为1,其余都为0,那么AID的起始为168=128。以下我们再举一些例子:

  • 若没有组播/广播数据,且AID=24的节点有数据,那么Bitmap Control字段为【0 1 0 0 0 0 0 0】,Partial Virtual Bitmap为【0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0】。实际上AID=24,也就等于38,如果是二进制的话,那么可以分解成(2^1+2^0)8,也就是有两位置1即可,但是由于Bitmap Offset中最小的单元是2,而不是1(可以看到,2^0也就是x0这一位实际上是被组播/广播数据提示这一位占据了,所以用不了),所以与AID=24最接近的起始位置是AID=16,从而就确定了bitmap control字段,然后Partial Virtual Bitmap按序找到AID=24的位置,进行标注即可,最后要补全一个字节。
  • 若存在组播/广播数据,且AID=100的节点有数据,那么Bitmap Control字段为【1 0 1 1 0 0 0 0】,Partial Virtual Bitmap为【0 0 0 0 1 0 0 0】,具体计算方法和上面一样。

PS:在802.11协议中,实际上给出了Bitmap的C语言实现的demo,在07版协议的Annex L中就有给出,用兴趣可以自行阅读。

前面我们描述的是AID在AP发送的TIM字段中的应用,在节点发往AP的请求中,实际上也是用的AID参数。在节点向AP请求数据,所发送的PS-Poll帧当中,就是将Duration/ID标识为AID,下图是一个PS-Poll的帧结构:

其中Duration/ID字段直接被标识成了AID字段,其具体内容如下:

从而节点向AP发送PS-Poll帧中,直接没有包含源地址,而是采用AID作为替代,当AP接收到PS-Poll后,根据其AID,在缓存空间搜索其对应的缓存内容,进而反馈给节点。

TSF,TBTT,Listen Interval field与CFP repetition interval

按照之前的描述,AP是周期性的发送beacon帧,在该beacon帧中的TIM字段包含了对应缓存区的信息。但是如果每一个帧中都包含所有节点的TIM信息会有两个缺点:

限制了节点的休眠时间,由于每一个beacon帧都包含了TIM信息,所以节点需要定时醒来接收对应的beacon,这一点也是比较耗费能量的,如果让节点多休眠一会,那么会更节能
增加了TIM的信息,如果beacon帧中,并没有包含所有节点的TIM信息,那么就可以按照我们前面所述的Bitmap control和Partial Virtual Bitmap进一步压缩空间,减少beacon传输时间的浪费
所以802.11协议设计中,节点是周期性的醒来,并且AP知道节点对应的苏醒周期。当节点醒来之后,AP才会在对应beacon的TIM字段中,为其指示缓存区信息。(在实际情况下,AP除了在对应的睡眠周期到达后要醒来,同时也会计算DTIM到达时醒来,因为后者是广播信息,前者是单播信息)。

那么为了做到前面所述的需求,AP和节点之间首先要做到时间同步,然后要规定一个周期,进而完成周期性获取TIM信息这样一个需求。

  • TSF(Timing Synchronization Function):协议中是用TSF机制来描述定时同步功能。TSF定时器一共64位,单位是us。在基础架构模式中,定时同步是同步AP发送的beacon帧来完成的,在beacon中有一个Timestamp字段,该字段也是64位,并且是在beacon中不是按照Element形式进行存放的,所以每一个beacon帧中必定会有一个Timestamp。当STA接收到AP的beacon帧后,提取Timestamp字段的时间戳,并且添加一下本地估算出来的延迟(从天线端口接收到最后处理的本地延迟),从而完成节点与AP时间同步的功能。

上图就是beacon帧中,timestamp相应的字段,在其之后,我们可以看到一个Beacon Interval字段,该参数实际上在路由器配置中可以看到,一般被描述为Beacon时槽,且大小为100ms,即0.1s(PS:通常情况下,网速都是按照10进制进行步进的,即1kbps=1000bps这样,k是kilo的意思。而在802.11协议中,这里规定了一个时间单位TU,Time Unit,TU是少有的按照二进制进行步进的单位,1TU=1024us,这里实际上是kilo-binary的计数方法。所以一般我们设置的是0.1s,但是在实际的Beacon帧中是0.1024s,这里有一个区别),该参数与TBTT时间是一致的。

  • TBTT(Target Beacon Transmission Time):信标预定传送时间,实际上这个是一个定时后的发送/接受beacon动作的周期,其周期的时间就是由Beacon Interval所决定的。当TBTT时间到达的时候,AP会主动发送beacon帧,而节点也都会主动接受该beacon帧(包括休眠模式的节点,也会苏醒过来接受该beacon),然后利用beacon进行时间同步,并且查看TIM字段,若没有自己的数据缓存,那么节点继续转为休眠模式,直到下一个TBTT时间到来。

Beacon帧是按照TBTT时间进行周期性发送的,但是节点也不会是严格每一个beacon都需要监听的,为了更有效的设计节能模式,节点应该是每间隔几个TBTT周期,再监听一次beacon帧,从而就可以延长自己的休眠时间。

  • Listen Interval:监听间隔是指工作站两次苏醒之间,历经多少次TBTT,也就是跳过了多少个Beacon帧。较长的监听间隔,节点休眠的时间就越长,从而越节能,但是会耗费AP的缓存区空间,也增加了接入时延。

Listen Interval是节点通过Association Request帧发送给AP的,从而AP就知道节点的苏醒时间,在对应节点苏醒的时候,其才会在Beacon帧中,为其指示Buffer的状态。该字段一共16位,其单位是Beacon的周期间隔,也就是TBTT时间,若Listen Interval设置成2,那么代表节点每经过两个beacon周期,才苏醒一次。在抓包中,如下图所示:

在802.11时间周期这一块实际上规定的是比较繁杂的,由于我们讨论的是协议中完整的节能模式,该节能模式实际上也分DCF和PCF下不同的工作模式,所以我们还需要明白CFP repetition interval,即CFP周期和上面TBTT时间的一个关系。

  • CFP repetition interval:CFP重复周期是用来协调PCF和DCF两个不同工作模式的一个调度周期,其中包含CFP和CP两个部分,CFP是用来给PCF时间进行工作的,CP时间是给DCP来工作的。这一部分内容我们在讨论PCF的时候有讨论过。

最后用一张图,我们标识一下这几个调度周期之间的关系:

TBTT周期是beacon之间的周期(如图上蓝色部分),每间隔TBTT,AP就会发送一个beacon,该beacon中有可能包含TIM信息(图中红色部分),也可能包含DTIM信息(图中紫色部分),其间隔是由DTIM Period参数进行设置的。同时我们还可以关注到,beacon的发送有可能在CFP时间内,也有可能在CP时间内,其实际上就仅仅按照TBTT间隔发送即可,若在CFP时间内,beacon发送的间隔是很准确的等于TBTT,而在CP时间内,因为DCF的竞争接入机制,所以beacon的间隔会出现一些小偏差,基本是约等于TBTT时间。

CFP repetition interval是较为注意的一个间隔(图中绿色部分),CFP时间间隔是要等于TBTT时间的倍数的。实际上我们知道,CFP的NAV时间设置是通过beacon帧的NAV或者CF Parameter Set机制来完成的(具体可以查看我们之前PCF的叙述),所以CFP的起始一定会有一个beacon帧,而结束不一定。同时在CFP或者CP中,都有可能出现多个beacon帧。如上图中,第一个CFP的开始一定是一个beacon帧,而结束则不是与beacon同时的。那么CFP时间结束后,到CFP周期结束前,其剩余的就是就是CP的时间。且在这张图中,我们可以看到在第一个CFP周期内,就存在2个beacon帧。

PSM模式(Power Save Mode)

在初始的802.11 PSM模式中,DCF和PCF模式下,还有不同的工作机制。以下我们首先叙述节点如何进入PSM模式,然后叙述DCF的工作形式,最后我们叙述PCF。(PS:至于该两个时间周期的调度关系,我们已经在前面提到过了,这里就不加以展开了。)

1、如何进入PSM模式

节点如果要工作在PSM模式下,首先要告知AP,自己将要工作在节能模式。在802.11帧中,这个信息是包含了MAC层头部中的Frame Control Field中的,也就是说,任意一个帧都可以用来进行工作模式的切换,节点可以在关联上AP的时候,就切换到PSM模式,也可以在工作状态中,切换到PSM模式。在Frame Control Field字段中,我们有两个内容需要注意,如下图:

这个两个内容即Pwr Mgt(Power Management)以及More Data。

  • Pwr Mgt(Power Management): 该字段用来标识在该帧过后,节点是否会进入省电模式(PSM mode)。若为1,那么就进入PSM mode,反之就保持当前工作状态。由于在基础架构模式下,AP本身有电源供给,且AP负责整个网络的核心管理,所以AP发出的下行帧中,该字段默认设置为0。
  • More Data:该字段是AP指示节点,是否还有该节点的缓存数据没有发送。若为1,代表AP还有对应节点的数据缓存,反之则没有。由于我们前面提到过,在PSM mode中,请求数据实际上是一种“兵乓”机制,一个请求只会有一个反馈。所以AP在反馈下行帧的时候,会不断指示节点是否还存在缓存,如果有缓存的话,那么节点会继续请求数据。只有当AP中所有对应该节点的缓存都被清空以后,那么节点才会重新进入休眠状态。

2、DCF下的PSM模式

DCF是基于竞争的工作模式,所有的节点需要接入信道需要进行竞争,包含AP以及工作在节能模式下的节点。
因为节能模式有关的参数较多,用一个图例来说明比较困难,所以我们尽量尝试说清楚,不足的地方还请见谅。

那么上图描述了1个AP,2个节能节点工作的时序图,黑色的轴所代表的是数据包发送和接收的时序,紫色的线上代表节点苏醒的情况。图中STA1的Listen Interval等于2,STA2的Listen Interval=1(为了图意简便,就没有标识在图上了)。

  1. 一开始,我们假设由AP发送一个beacon帧(即1st Beacon),由于这个beacon帧是作为最初时刻的beacon,所以节点需要提前wake up并接收该beacon帧。如图中所示,beacon帧中的TIM字段标识,STA1节点有数据包待传,而STA2节点没有数据包。所以STA1在接收到beacon之后,保持wake up状态,而STA2则转为sleep状态。
  2. STA1由于已知AP中有自己的数据包,其首先要进行Backoff(这里有关DIFS,backoff,SIFS的过程与标准DCF相同,所以这里都以省略形式带过),当Backoff完成后,其向AP发送一个PS-Poll帧,用以请求数据。
  3. 当AP接收到该PS-Poll帧之后,其首先要反馈一个ACK(在初探节能模式中,我们并没有强调该ACK的反馈,实际上802.11中的单播帧都是需要ACK反馈的),当ACK反馈后,AP再将数据发送给STA1,并且在该数据的Frame control字段中,标识more data=1。
  4. 当STA1接收到AP的数据后,其首先也是需要反馈ACK,并且查看该数据帧中的More data字段,由于该字段等于1,所以STA1无法转为sleep状态。其还需要持续向AP请求数据,那么其再次经过backoff,然后发送PS-Poll帧给AP。
  5. 当AP再次收到PS-Poll后,首先还是ACK,然后反馈数据。假设这次反馈的数据包是STA1缓存在AP的最后一个数据包,那么AP在反馈中会把more data字段设置为0。
  6. 当节点收到该数据包后,由于more data=0,所以STA1会在反馈完ACK后,进入休眠。
  7. 当第二个Beacon传输时(2nd Beacon),由于STA1的Listen interval=2,所以其还是处于休眠状态,而STA2的Listen interval=1,所以每一个beacon周期其都需要醒来,接收该beacon。假设第二个beacon中,STA2还是没有数据(图上未标明),那么其接收完beacon后就转为休眠模式。
  8. 当三个Beacon传输时(3rd Beacon),STA1和STA2都会苏醒并接收该beacon。同时,该beacon中标识,两个节点都有数据包被缓存在AP中,所以两个节点都需要进行竞争接入。在上图中,我们假设STA2首先完成backoff,并接入信道。在STA2占据信道传输时,STA1会检测信道是繁忙的,所以不会同时进行发送,这点实际上就是DCF的竞争过程。
  9. 当STA2给AP发送PS-Poll,并且得到AP反馈的数据后,STA2检查该数据包中的more data字段为0,所以其接收完该数据包后,就进入sleep。而STA1由于还没有接收到数据,则还会竞争接入信道,直到接收完AP中对应其的缓存,那么其才会再次进入sleep模式。

以上,我们描述了一个PSM-DCF的基本工作模式,这里我们还需要额外注意的一点是DTIM时间,由于绘图情况较为复杂,所以我们只能够描述一下情况。在PSM模式下,节点苏醒的条件有两个,达到其中一个其就会苏醒。
节点根据Listen interval进行苏醒,即每隔Listen interval时间,节点会苏醒一次,直到接收完AP中自己的缓存,才会转为睡眠模式。

DTIM周期,由于我们知道DTIM实际上是用来下发AP上缓存的组播/广播帧的,所以所有的节点都需要在这个时刻苏醒,并且接收这个帧。所以只要该beacon携带的是DTIM,所有的节点也会苏醒(即使不在Listen interval规定的苏醒时刻)。在节点都苏醒后,AP会首先传输其缓存的组播和广播帧,节点接收完该组播或广播帧后,同时自己又不在TIM缓存中(笔者理解,由于AP知道节点的Listen interval,所以不会每一个beacon中都会携带其的TIM信息),那么该节点就会进入sleep,直到自己规定的时刻再次苏醒。

同时这里我们并没有对上行数据做具体说明,当节点本地有数据需要发送给AP时,其经过backoff后,会主动进行数据发送。至于节点会首先发送PS-Poll还是发送本地数据,笔者并没有考究。

3、PCF下的PSM模式

PCF是基于调度的接入方式,节点的接入顺序是通过AP的轮询完成的。

实际上由于PCF的调度机制,所以一般更加设置节能方案,在上图中,我们假设STA1的Listen Interval=1,STA2的Listen Interval=1,并且我们假设DTIM period为4,并且第一个beacon,即1st beacon中携带的就是DTIM。

  1. 首先AP发送一个Beacon,即1st Beacon,节点也保证在这个beacon周期之前就已经苏醒,用以保证能接收该beacon的信息。在1st Beacon中,携带的是DTIM信息,并且标识AP中有广播数据包的缓存。
  2. 当Beacon时间结束之后,AP首先会发送缓存的广播帧,由于是广播帧,所以这里不需要等待ACK的反馈。当广播帧发送之后,AP会依次向节点发送数据帧,并轮询节点。由于DTIM中携带的信息表示,STA1和STA2都有数据被AP缓存,所以在没有收到下行数据包之前,STA1和STA2都是保持wake up状态。
  3. AP会首先向STA1发送DATA+CF-Poll帧,这是一个帧,但是同时具有两个功能(即向STA1发送数据,并请求STA1的上行数据),这里在PCF工作模式介绍中,已经提到过了。
  4. 当STA1接收到该数据后,其会向AP发送ACK以及自己的缓存,同样的,该信息也是封装在一个帧中,即DATA+CF-ACK帧中一次性反馈上去,节约了一些帧间间隔。同时由于AP下发的数据中,more data字段等于1,所以STA1接收完该数据后,还需要保持wake up状态,等待AP下方剩余的数据。
  5. 在PCF中,AP是按照AID的升序对节点依次进行轮询的,所以即使发送给STA1的数据字段中,more data=1,但是其还是有先轮询下一个节点,而不会一直逗留在STA1上。AP会向STA2发送Data+CF-ACK+CF-Poll帧,可以注意这个帧有三个功能,既向STA1进行ACK确认,也向STA2发送数据,并进行数据请求。
  6. 当STA2接收数据后,其同样想AP发送DATA+CF-ACK帧,并且由于more data字段等于0,所以STA2传输完该数据后,就进入sleep状态。且由于STA1与STA2的Listen interval都等于1,所以STA2会在下一个beacon到来之前就醒来,并接收该beacon数据。
  7. 在第二个beacon中,即2rd Beacon,TIM指示STA1有数据,则STA1和AP继续进行数据交换(图中省略了),而STA2没有数据缓存,所以在接收完beacon后,STA2就进行sleep了。
  8. 在第三个beacon中,即3rd Beacon,TIM字段指示STA1有数据,而STA2没有数据。所以STA2还是接收完beacon就进入sleep了,而STA1首先接收AP发送的下行数据,这里由于我们假设DTIM period为4,所以该beacon中携带的是TIM信息,即AP没有组播/广播包需要首先发送。所以一开始AP就发送DATA+CF-Poll给STA1,并且由于该帧中,more data字段等于0,所以AP在成功接收该数据帧,并反馈ACK之后,就进入sleep了。

剑气纵横三万里

“为什么要努力?” “想去的地方很远,想要的东西很贵,喜欢的人很优秀,父母的白发,朋友的约定,周围人的嘲笑,以及,天生傲骨。”

留下你的评论

*评论支持代码高亮<pre class="prettyprint linenums">代码</pre>

相关推荐

暂无内容!