802.11协议精读36：再论HCCA

前面写过一次HCCA《802.11协议精读28：802.11e（EDCA/HCCA）》，不过现在看来有点划水，所以把HCCA几个特质的点在写一下。本文的理解要基于之前PCF《802.11协议精读4：PCF工作模式》，Addmission Control《802.11协议精读27：再谈802.11e的优先级（Admission Control）》两篇文章基础上，并且需要对802.11的接入机理有一定理解更合适一些。另外，为了阅读的简单，这里概括一下就是HCCA通过设置CAP这种方式，将原始只能够工作在CFP时间范围内的PCF给搬到CFP以外的时间点来用，这样就可以提供QoS属性了。再简单点而言，就是AP根据业务的需求，在特定的时间点上开辟一个轮询服务时间CAP，然后在里面跑轮询。这样差不多就是HCCA的核心特点。下面我们还是根据HCCA具体跑的需求大致分别说一下几个细节点：

HCCA的TS

HCCA和EDCA不同，EDCA直接是定义了默认的4种流量类型（称为TC）可以直接上的。但是HCCA没有，需要用TSpec进行定义。这里需要参考之前写的《802.11协议精读27：再谈802.11e的优先级（Admission Control）》中关于TSpec和ADDTS的流程，对于需要保护的QoS流量进行定义。

比如上图中所显示的TS Info字段，其中就显示了我们可以定义什么样的流量属性，比如传输的平均速率，峰值速率，Delay上限等等。根据流量的属性，中心控制端HC才可以去计算服务时间的分配和优先级的分配，以保证可以提供QoS的服务。

其实这里还有一个细节，就是TS Info的字段实际上包含的流量定义的内容，既可以用在HCCA上，也可以用在EDCA上面，所以我们可以看TID的定义。

其中还有一个特性就是HEMM (HCCA and EDCA Mixed Mode)，实际上就是该TS可以同时工作在HCCA和EDCA模式下面。其实这里也对应到上面的TS_Info，其中包含的属性是通用的。

HCCA由于是依赖流量特性的，所以想要使用它，就需要进行ADDTS的流程，然后做Admission Control看资源够不够，如果够的话，那么才可以执行HCCA。

CAP和CFP

从我理解的角度来看，HCCA在接入具体工作机制上，其实和PCF是基本一致的，我们简单理解就是提供了QoS属性的PCF。那么传统PCF的问题是啥米呢？主要是PCF只能够工作在CFP时间范围内，这就会限制了工作场景，比如一些延迟敏感的业务，那么即使不在CFP时间范围内，也需要为其提供“PCF”的接入服务。所以在HCCA中就相对于CFP提出了一个新的概念，就是CAP时间（Controlled access phases），这里的phase实际上可以理解成一个时间段。

根据以上描述，实际上我们就可以将HCCA机制基本理解成，一个可以在特定时间点（根据QoS流量所需要的周期所定义的时间点），开辟出来的一个轮询服务时间CAP。在该CAP时间范围内，可以提供类似PCF的轮询接入方式。同时，由于是可以在CFP时间点以外开辟CAP时间，所以HCCA既可以用在无竞争的CFP时间，也可以用于基于竞争的CP时间。

具体可以参考这张图

在这张图空白的就是CAP时间，我们可以明显的看到CAP时间既可以放在CFP时间范围内，也可以放在CP时间范围内，而EDCA只能够放在CP时间范围内。另外，如果CAP是在CFP时间范围内，那么直接整个CFP里面就可以直接跑HCCA了，把PCF给替代了。这里图上在一个CFP里面包含多个CAP实际上是针对不同流量而言的，也就是这里初始的CFP时间内有三个CAP时间，实际就可以理解成3种TS流量。

根据上面描述，个人感觉HCCA的核心特点已经阐明了，下面主要是三个细节。

• 1）关于如何提供QoS服务的，也就是CAP这个时间片要怎么放，能够提供QoS功能？
• 2）CAP时间片如何开启？
• 3）在一个CAP时间片内的工作机理是什么？

所以下面其实就是围绕着这三个问题进行阐述了。

Simple Scheduler

HCCA里面是根据Simple Scheduler机制来计算给流量提供QoS服务的，这里需要注意的时，QoS一般都是面向流量进行保障的，节点可以算是流量里面的一个属性。

Simple Scheduler的核心工作就是根据定义的TS流量特征，来计算每间隔多少时间生成一个CAP轮询时间片（也就是CAP周期），以及该CAP时间片设置的大小应该是多少。

这里CAP的周期我们可以对应TS的Element里面（也就是本文的第一张图），关注比如Minimum Service Interval，Maximum Service Interval之类的参数，这几个都是流量本身所需要的服务间隔的参数。那么HC，可以按照最大，最小，或者平均的方式来计算CAP的周期，从而在对应的时间点去开辟CAP时间。

那么CAP时间片设置的大小，这个主要跟三个部分有关，1）数据包个数，2）单个数据包的物理层传输时间（其实包含数据包大小，以及物理层传输速率），3）用于接入过程的overhead时间，比如调度所用的开销。那么根据TS的Element以及TS Info，比如Norminal MSDU Size，Maximum MSDU Size，Minimum Data Rate等，这些参数综合计算出一个合适的CAP时间大小。

所以实际上在协议中，给出了TS这么多的参数，但是并没有规定一个具体的算法，如何应用这些参数来设置CAP和CAP时间片大小。所以很长一段时间内，其实包含当下（其实当下就是基于机器学习的方法做），都还有研究继续关注这一块，换言之根据流量参数，来计算如何设置CAP时间的。

CAP时间片开启

简单回顾下PCF时间是如何开启的，参考之前PCF的文章《802.11协议精读4：PCF工作模式》。

PCF的时间开启实际上是将Beacon帧作为开启帧，然后通过数据帧头部的Duration，以及Beacon中的CF Parameter Element，这两个参数所提供了机制，同时对Beacon之后的一段信道时间进行保护，从而确立出一个CFP时间。这里双重保护的设置机制，我直接复制之前写的了，如下：

• 利用数据帧的MAC头部中的Duration字段，设置CFPMaxDuration。标准的Duartion字段共有16个字节[0:15]，其中倒数2个字节，即[14:15]是标志位，且其存放方式应该是属于小端模式的，即后面的是高位，前面的是低位。如果是CFP设置NAV时，对应第14位置0,第15位置1，其余各位都是0。故解析出来，那么NAV的时间即设置为2^15=32768 microsecond。其对应结构如下图：

• 除了利用MAC头部的Duration字段，在CFP对应的beacon帧中，还有一个CF Parameter Set字段。利用该字段中的CFP MaxDuration，也同样设置该参数。在802.11中设置两次CFPMaxDuration参数的原因在于，是在于避免无法识别CF Parameter Set字段的节点，只要其能识别标准MAC头部的Duration字段，那么其也会被置为NAV状态，从而无法争夺信道的使用权。

其实当时做双重保护的目的其实估计是为了稳当一些。

但是现在CAP和CFP时间有一个很大的区别，也就是CAP不一定是追在Beacon之后了。CAP其实我们可以当做这个时间片在任意一点都可以出现。所以现在CAP的开启方式实际上就是完全依赖Duration来实现了，这种方式其实越往后面的802.11协议应用越多。

CAP的开启帧其实和TXOP的开启帧是类似的，可以是RTS/CTS握手，或者单个CTS，或者直接跑QoS-Data都行，主要是利用其中的Duration字段将信道保护起来。但是和TXOP不同的点在于，该CAP开启帧是不跑backoff的，简单点而言我们也可以理解成不竞争。其接入机制和Beacon帧本质是一样的，即等待PIFS时间，然后直接进行发送（即设置CWmin=CWmax=0）。

所以，CAP时间其实就是一个节点在特定时间段，由HC直接开启的一段轮询时间片。其实这里是HCCA提供QoS的原理所在，但是也是HCCA没有被广泛采用的核心原因所在。

HCCA没有被广泛采用的原因和PCF类似，最大的缺点还是在OBSS模式下。由于这两者的接入都是一下子开辟一个较为大段的时间片使用，而且这个时间片还是通过直接抢占的方式来获得，所以其冲突概率还是很大的。如果是PCF的话，由于beacon是没有握手机制的，所以如果beacon发生冲突，那么直接损失最大就是一个CFP周期。到HCCA里面，虽然可以通过RTS/CTS握手，来减少直接冲突造成的损失，但是不同BSS的Admission Control实际上是独立的，所以很有可能分配的CAP周期就直接撞，那么照样是大周期的冲突，造成利用率低下。这些问题造成了HCCA和PCF一样，到现在而言，应用的实际很少。

CAP时间内的轮询TXOP

在接入时间片内，HCCA和PCF的不同就是在于传输帧的type不同，HCCA里面我们可以认为都是QoS+的类型，具体到帧结构中，就是MAC Header多了一个QoS Control的字段。

那么合理的应用该字段，就可以将原来的PCF中的“乒乓”轮询的过程，改成Trigger，多帧反馈的过程。也就是这里所谓的轮询TXOP。就如同前面写的，在传统的PCF中，轮询节点是采用CF-Poll帧，该帧每一次只可以轮询一个数据。在HCCA中，发送的是QoS（+）CF-Poll的帧，该帧可以直接起始一个TXOP时间。

至于Trigger多帧的流程，其本质实际上还是一个TXOP传输的特性，除了HCCA，在U-APSD里面也同样采用，所以这一点另外再单独写一下吧。

另外还有一点细节发现的就是，在协议中把这个时间片内的传输称为HCF-Sequence。协议中有多种类型的HCF-Sequence，这里记录下这种发送组播广播case下的，主要是其中特意强调了一个PIFS。

在Cambridge那本书里面，其实特意简单讨论了下关于CAP接入时间片内，帧间间隔的问题。其本质和CFP时间内帧间间隔是一致的。

这一块的主要目的是HC，或者说AP要把握住整个信道的接入权限。在连续传输中，帧间的最小间隔是SIFS，比如说连续发送两个帧（目前没有讨论到802.11n，到n里面最小是RIFS），或者发送一个帧，等待对方的反馈。这个间隔都是SIFS。那么如果HC发送了一个数据，需要下面反馈，那么等待SIFS时间。但是如果对方没有反馈呢，在SIFS时间之后，HC还会再继续监听一个Slot，那么总时长就变成了PIFS。如果这个时间内还没有人反馈，那么HC就继续使用信道继续后面的传输了。

那么对应到上面HCF-Sequence中特意截出来这张图而言，其实个人感觉这句话也比较难写，合适点的意思应该是把+group和+broadcast这两个设置成可选项，而不是必选项。因为组播广播是没有直接的反馈的，那么实际上SIFS时间才对，只有在可能需要等待下面反馈的时候，才会需要最长等待PIFS时间。所以这里就当一个细节记笔记了。

以上就把HCCA的一些细节特点给补充了一下。以上叙述中，如果有不清楚，或者存在有错误的地方，还请见谅。

本文为原创文章，如需转载须注明出处和原文链接。

欢迎大家关注我们的微信公众号：无线技术大讲堂，请搜索公众号（must_wireless）。