序
在前面我们叙述过,在802.11的MAC层中,分成了两种基本工作模式:
- DCF(Distributed Coordination Function)
- PCF(Point Coordination Function)
我们已经介绍过了DCF的工作模式,而PCF模式当前只有协议中进行了规范,而在实际产品中几乎很少见到。所以就像在802.11权威指南和CWNA书本中所述一样,对于PCF的机制仅仅是协议规定,而几乎没有产品,所以纯粹对协议希望有深入了解的话,那么才需要对此进行阅读。这里仅仅是将笔者读协议以及相关资料中,所理解的PCF工作模式进行整理。
PCF简介
PCF的全称是Point Coordination Function,即点协调工作模式。在802.11的MAC层协议结构中,PCF是基于DCF之上的协议,同样的还包含EDCA和HCCA两种模式,后两种主要是为了QOS进行设计的,具体如下图
![](https://i-blog.csdnimg.cn/blog_migrate/6e65935ec13dd99dac55aa9298c1246f.png)
由于PCF是以DCF作为基础扩展的,所以PCF与DCF是可以兼容工作的。在PCF模式中,两者的兼容实际上是基于一种交替工作的机制,即PCF和DCF各占据一段时间,交替进行工作。该交替周期即是CFP重复周期(CFP repetition interval),在该周期内,包含CFP和CP两个部分,如下图
![](https://i-blog.csdnimg.cn/blog_migrate/4099aa7fa478750898fd0fa83ad300d5.png)
- 无竞争时间(PCF):Contention-Free Period,即CFP时间是为了PCF工作所设定的一段时间。该时间是利用虚拟载波监听(NAV)的机制进行保护的,该NAV是由Beacon帧进行设置,并由CF-END帧用来终止。
- 竞争时间(CP):Contention Period,该CP时间是用来给DCF工作的一段时间,在该周期内,协议按照DCF的模式进行工作。
这里我们还需要更细一些说明该CFP时间设置的原理。在之前描述DCF模式中,我们基本已经描述了NAV的工作机制,其主要是利用无线数据帧MAC头部中的Duration字段进行设置。在CFP准备启动的时刻,AP首先利用beacon帧设置NAV时间至CFPMaxDuration,其具体设置方案如下:
- 利用数据帧的MAC头部中的Duration字段,设置CFPMaxDuration。标准的Duartion字段共有16个字节[0:15],其中倒数2个字节,即[14:15]是标志位,且其存放方式应该是属于小端模式的,即后面的是高位,前面的是低位。如果是CFP设置NAV时,对应第14位置0,第15位置1,其余各位都是0。故解析出来,那么NAV的时间即设置为2^15=32768 microsecond。其对应结构如下图:
![](https://i-blog.csdnimg.cn/blog_migrate/33b742e90f9aa5b8c5c41d7f0aec3ae8.png)
- 除了利用MAC头部的Duration字段,在CFP对应的beacon帧中,还有一个CF Parameter Set字段。利用该字段中的CFP MaxDuration,也同样设置该参数。在802.11中设置两次CFPMaxDuration参数的原因在于,是在于避免无法识别CF Parameter Set字段的节点,只要其能识别标准MAC头部的Duration字段,那么其也会被置为NAV状态,从而无法争夺信道的使用权。
![](https://i-blog.csdnimg.cn/blog_migrate/ee084b46266053493fd658b048ea469b.png)
由于这里NAV是被设置为最大时间,所以NAV的技术与之前我们描述在DCF的RTS/CTS模式下存在差别。在DCF中的RTS/CTS模式下,NAV是通过倒数置0,从而释放信道。在PCF模式中,NAV的释放是通过CF-END帧,按照笔者记忆中,中间传递的各个帧中也会重复将NAV置为最大,只有在最后的CF-END中,才会将duration字段写成0,从而结束NAV时间,换言之,NAV时间的设定是可以被覆盖的。CF-END的帧结构如下:
上图,CF-END是一个广播帧,其类型是控制帧,子类型是CF-END,而且Duration部分设置为0,其余该帧内没有什么特殊的地方了。
通过以上的机制,PCF能够很好的与DCF进行兼容。在下面的内容中,我们开始解释PCF具体的工作模式。
PCF工作模式
在这一段中,我们叙述PCF的具体工作模式。PCF的主要思想为:”AP充当中心协调控制器(PC)的角色,根据其内部的轮询表(polling list)依次轮询与之连接的节点(CF-Pollable STA),看其是否有数据待传。在CFP时间内,节点由于NAV机制,故无法主动竞争信道。故除非基站轮询节点,要求其反馈数据,节点不可以主动进行传输动作。“
在上述描述中,已经包含了,在PCF中的两个新的角色:
- PC(point coordinator):即点协调器,一般情况下,都是由AP做点控制器。
- CF-Pollable STA:支持PCF机制的节点。
在PC身上,我们还会引入轮询表(polling list)的概念。在PCF中,PC按照轮询表的顺序,按照升序,依次对节点进行轮询。在免竞争期间,除非基站以轮询帧提出要求,否则工作站不得进行传输数据。轮询具体会采用CF-POLL帧来执行,节点接收到CF-POLL之后,向PC反馈数据。在标准的PCF中,一次CF-POLL只会反馈一个数据帧。只有在启用APSD(Automatic Power Save Delivery)的设计下,才会使用其他的请求方式(Trigger Frame),才会一次请求,反馈多个数据帧,不过这里由于我们没有讨论节能方面的内容,故不展开讨论。
并且在PCF中,还会引入多种新的帧结构,比如前面叙述中出现的CF-END,在PCF中还存在其余的各种帧如下:
- 仅PC发送:Data+CF-Poll、Data+CF-ACK+CF-Poll、CF-Poll 和CF-ACK+CF-Poll
- PC与CF-Pollable STA发送:Data、Data+CF-ACK、Null和CF-ACK
接下来,我们还是假设讨论与DCF同样的拓扑,并且在该PCF讨论中,我们同时关注上下行流:
![](https://i-blog.csdnimg.cn/blog_migrate/24e52ff5f69d1dec4ec6ab559455f2bc.png)
由于PCF不同种帧类型其功能会有一些不同,为了说明清楚,我们选取几个典型的工作流程,进行具体的示例说明,其余的一些工作流程可以类比得出。
- CF-Poll -> Data -> CF-ACK工作流程
![](https://i-blog.csdnimg.cn/blog_migrate/30eed40b7bd77afd8847a23bc6226aef.png)
- 首先AP发送Beacon,利用其中的duration参数,将所有节点设置成NAV状态。
- AP本地没有发往节点STA1的缓存数据,故AP直接发送CF-Poll,让节点可以上传数据。
- 节点发送DATA给AP。
- 最后AP反馈CF-ACK给节点,从而结束一次传输轮询。
上图是最简单的请求反馈过程,除了首先是由AP触发这次传输意外,其余基本和DCF的工作是相同的。这里我们还需要注意的是,若AP成功接收了Data的数据,那么其反馈ACK信息。若AP没有成功接收Data的数据,那么其等待PIFS时间,若PIFS时间内,没有检测到节点存在反馈,那么AP就认为这次传输失败,跳过该节点,继续轮询下一个节点,具体如下图:
PIFS的时间实际上是由一个SIFS和一个SLOT组成,即PIFS=SIFS+SLOT。结合我们在DCF部分论述Slot和SIFS具体组成的内容,这里之所以PIFS这样设计,实际上是利用Slot里面的CCA机制,AP利用该CCA判断是不是存在反馈帧,若存在反馈帧,那么就进行接收。这里并没有采用DCF中的ACK timeout的简单机制来判断是否反馈,而是具体采用这种CCA检测的具体机制,是除了这里反馈CF-ACK以外,还有可能反馈其他类型的帧,比如CF-ACK +CF-Poll等,具体内容我们在后面进行叙述。
- DATA+CF-Poll -> Data+CF-ACK -> CF-ACK工作流程
![](https://i-blog.csdnimg.cn/blog_migrate/a8faff2c703b892b2f490497b8e0653b.png)
第二种情况较为复杂一些,我们先描述其时序图:
- 首先AP发送Beacon,利用其中的duration参数,将所有节点设置成NAV状态。
- AP本地存在发往节点STA1的缓存数据,故AP将自己的DATA以及CF-Poll同时发送,让节点在接收数据后,可以上传数据。
- 节点发送DATA+CF-ACK给AP,其意在首先确认之前AP发送的下行数据,再反馈自身的数据给AP。
- 最后AP反馈CF-ACK给节点,从而结束一次传输轮询。
我们现在讨论上面工作机制的一些细节内容。
- 首先叙述AP缓存节点数据的机制,在PCF模式以及节能模式下,缓存机制都会被有效利用起来,这里的缓存是指公网发往节点的信息,由于没有及时传给节点,从而缓存在AP身上。该缓存信息在每一个beacon周期内,也会在其TIM字段内利用Bitmap信息进行标识。Bitmap是一种映射的数据结构,其中每一个位就代表一个节点,即每一位都是和节点的二层地址进行关联。若该位为1时,那么代表该节点存在缓存数据,若为0,那么对应没有缓存数据。故节点在接收到beacon帧后,就知道在这个周期内,我会不会收到来自与AP的数据。
- 其次我们需要强调的是,这里的DATA+CF-Poll是一个帧,不是分别的两份帧。这里实际上是对应到一种特殊类型的帧,这里不同帧的类型实际上是通过在MAC头部第一个字段Frame control下的两个字段:Type和SubType组成的,如下图
![](https://i-blog.csdnimg.cn/blog_migrate/8e7200733d2c917d3c82a268ee2c8c2e.png)
我们总结在PCF中,type有关的具体相应参数如下:
![](https://i-blog.csdnimg.cn/blog_migrate/b4fcfe62db7ee0ffc94b9ac601f7a32f.png)
注:CF-ACK与标准的ACK帧不同,标准的ACK为控制帧,而CF-ACK为数据帧。
- 最后我们需要理解,为什么在PCF这里协议选择用一个帧的功能来代替分别传输两个帧,其主要原因就是节省时间,这里不仅仅节约了额外帧交换中需要等待的SIFS时间,也减少了单独传输帧所花费的时间。比如说对比DCF中执行类似DATA+CF-Poll这样的发送流程,其发送大致为DATA+SIFS+ACK+CF-Poll+SIFS+DATA+ACK这么长的流程才可以完成,而采用合成帧的形式,那么就简单很多,并且对性能有好的提升。
- CF-Poll -> Data -> CF-Poll + CF-ACK -> Data 工作流程
在了解前面的内容之后,我们描述另外一种合成的帧,CF-Poll+CF-ACK帧,还是首先描述其工作流程:
- 首先AP发送Beacon,利用其中的duration参数,将所有节点设置成NAV状态。
- AP通过CF-Poll请求节点STA1,让STA1可以上传数据。
- 节点STA1发送DATA给AP。
- AP发送CF-Poll+CF-ACK,其中CF-ACK是发给STA1用以确认其发送的数据,CF-Poll是用来请求下一个节点发送数据,即发给STA用以请求数据。
- 节点STA2反馈数据给AP。之后的工作流程我们这里省略。
大体上和之前的工作模式是类似的,唯一区别的是CF-Poll+CF-ACK帧,该帧既是发送给STA用来做CF-ACK确认,又是发送给STA2用以请求数据,而我们知道802.11帧的目的地址只有一个,所以这里是存在疑惑的,目前还没有在协议中发现具体描述这种帧结构的部分,目前猜想应该是类似CF-END+CF-ACK帧的结构:
在无线帧中,ACK帧是没有源地址,只有目的地址的,这点ACK和CTS同样。而在上图所示结构中,除了在ACK中存在的RA(Receive address)地址,还存在额外的一个BSSID地址。故我们初步猜测是,RA是用来作为ACK反馈的目标地址,在我们所示流程中,即为STA1的地址。而用来作为CF-Poll请求的目的地址可能是放在BSSID这个位置中,标准的BSSID是用来表示AP相应的地址(即SSID具体对应的BSSID地址),但是这里由于目的地是一个节点,故在CF-Poll+CF-ACK帧中,这里也许就是放的Polling的目的地址。即这里猜想在CF-Poll+CF-ACK这个帧中,该处还是一个地址,不过不是BSSID,而是Polling的目的地址。从而才可以利用一个帧,同时向两个节点传达目的。
- CF-END与CF-END+CF-ACK
在PCF的无竞争周期最后,是利用CF-END帧来作为终止信息的。其中CF-END也有两种可能性,即CF-END和CF-END+CF-ACK。同时,由于其可以终止CFP时间的特性,故协议中,这两种帧的类型都被定义为控制帧,与其余的PCF帧存在一定的区别。由于在该帧中的duration字段设置为0,并且这是一个广播帧。当所有节点接收到该帧后,修改自己的NAV时间为0,从而即是结束利用虚拟载波监听NAV机制所保护的无竞争时间,转入竞争接入状态。具体该帧结构如下:
其中Duration字段为0,RA字段为广播地址,而BSSID字段为AP上SSID所对应的BSSID地址。CF-END和CF-END+CF-ACK帧结构一样。
综上所述,我们阐述了有关PCF工作模式中,具有典型意义的几个工作流程,由于PCF的帧类型总数较多,所以能组合成多种不同的具体工作流程,所以我们就完整列举了。其余的情况应该都可以基于以上几个典型的情况进行类比。由于PCF的整理还是较为繁杂,所以难免会存在不清楚的地方。以上叙述中,如果有不清楚,或者存在有错误的地方,还请见谅。