一起来Fit TDMA over WiFi

转载：https://www.cnblogs.com/gierwu-wirelessIoT/p/8596057.html

1 概述

　　WiFI TDMA领域，2009年Sam Leffler在《TDMA for Long Distance Wireless Networks》首次系统提出了TDMA技术方案，并在FreeBSD上，基于Atheros公司的AR5212芯片，成功实现了IBSS架构的TDMA Demo。

　 I. Hussain，N. Sarma和D. K. Saikia与2014年在《TDMA MAC Protocols for WiFi-based Long Distance --Networks: A Survey》中，对当时已有的WiFi TDMA进行总结，并归纳如下：

　　此外，市场上支持TDMA类的WiFi产品，成功的有UBNT的Airmax、Cambium的 TDD和Mikrotik的NV2；另外，LogicWave的iPoll技术，也包含有TDMA的部分功效。

基于公开的资料，具体说来，基于Soft MAC的TDMA技术为主流，它们都强调严格TDMA规范，所以在时隙划分、时间同步以及现有WiFi的DCF功能修改上工作量特别大；而网上可查找到的基于Openwrt工程代码的TDMA技术文档，均在陷入超帧、时隙与时隙机会、静默与活动的处理中，最终出来的是基于一个固定速率、固定包长的ns2 Demo或openwrt Demo，无法融入商用产品。

　　更恼火的是，主流的WiFi芯片方案商，长久以来都没有推出成熟的TDMA功能，或选择性的仅支持少量客户开发自己的TDMA。从而导致TDMA over WiFi这个简单且实用的技术在诸多WiFi产品中难实现。直到最近的QCA在其新一代的11AC WaveII 芯片上，终于推出了一个PCF版的功能插件，部分实现了TDMA。但对于老方案，该PCF功能并不能起作用。由此导致，基于方案商的SDK项目代码，开发不出TDMA功能。

　　为了区别于现有的WiFi TDMA技术，本系列文档中将TDMA规范强制挪动到WiFi驱动的实现方式为“Fat TDMA WiFi”，而我们将研究和开发出来的为“Fit TDMA WiFi”。所谓的“Fit TDMA WiFi”，就是在SDK项目代码上，实现TDMA WiFi功能，不大幅度修改现有驱动代码，能持续保留现有的核心功能：如支持802.11n和802.11ac，支持速率协商等；可直接商用。

2 Fit TDMA WiFi 愿景

单点调度

TDMA_er为调度者，循环调度各TDMA_ee，缺省地，TDMA_er由AP承担，TDMA_ee由CPE承担，且AP仅能调度已关联到其上的CPE。

调度方式

　　“加权公平调度”，所谓“公平调度”，就是TDMA_er公平地调度各TDMA_ee，如每轮调度，确保每个TDMA_ee都能被调度1次，且时间窗均等；所谓“加权”，就是让不同通信链路质量的TDMA_ee，有不同的调度次数，从而能持续维持信号质量高的终端具有更佳地通信体验。

兼容TDMA与严格TDMA策略

　　兼容TDMA策略下，非TDMA终端允许接入本Fit TDMA WiFi，TDMA_er不丢弃源自非活动TDMA_ee的数据报文；严格TDMA策略下，非TDMA终端不允许接入Fit TDMA WiFi，且TDMA_er直接丢弃源自非活动TDMA_ee的数据报文。

　　综述，Fit TDMA WiFi本质就是一个收发数据报文的调度机制，所以它不会被现有的TDMA思维所限制，是可基于SDK驱动代码实现的。

3 收发流程分析与改进

　　收发流程分析涉及到具体代码，属于SDK驱动内容，不能完全公开，仅供参考，本系列文档中涉及到具体功能或代码时，请在自己的驱动代码中查找。

　　QCA驱动从9.5开始，将原来的htc的功能重构了一下，分成Direct Attach（DA）和Offload（OL）两大部分，前者支持Mips架构的所有SOC，以及非11AC 网卡；后者支持ARM体系的SOC，以及11AC网卡。

　　本内容主要以DA架构为主，OL架构只提及，OL架构的收发流程在MAC层上与DA架构类似。

3.1 流程简述

　　本小节仅涉及数据报文收发流程中与Fit-TDMA相关的关键部分，不重复QCA PDF中tx和rx flow。　　

TX流程简述

　　TX起始于dev_xmit_queue，然后会走到ath_tx_send_normal或ath_tx_send_ampdu，在ath_tx_send_XXX（normal或ampdu）中，直接调用ath_tx_txqaddbuf直接提交到HAL的硬件队列，由硬件发送；或者有ath_tx_queue_tid临时缓存到tid队列中，通过ath_txq_schedule，将报文提交的HAL的硬件队列发送。所述tid队列为软队列，一共有17个，其中0~15与DSCP域值对应，而16为管理与控制帧队列（不包含信标帧）。所述硬件队列，一共有10，其中0-3号与17个tid队列映射，也就是0-3号队列为数据队列，它们的优先级与WMM的4个AC的优先等级一一对应；9号队列为信标帧队列；队号越高，在硬件中的发送优先级越高。

　　TX发送完毕后，由ath_tx_complete_buf负责完成收尾工作，如更新统计、回收资源等。

RX流程简述

　　RX起始于ath_intr，然后走到ath_rx_process，再然后走到Ieee80211_input，最后会osif_receive处理，是提交的网络协议栈还是直接完成报文接收。在此流程中，数据报文会被ath_net80211_rx处理。

3.2 流程修改

　　基于TX流程，直接发送函数是ath_tx_send_normal和ath_tx_send_ampdu，直接调度函数是ath_txq_schedule（内部直接调用ath_tx_sched_aggr或ath_tx_sched_normal）。为了实现Fit-TDMA调度，需要将这3个发现相关的核心功能函数。此外，驱动还有个APONLY的宏，启用了该宏后，报文会从UMA直接跳转到HAL，绕过了这3个核心函数，因此，在启用Fit-TDMA功能时，需要关闭此宏。

　　在ath_tx_send_XXX中，现有逻辑是：如果可直接发送，则立即调用ath_tx_txqaddbuf，将报文直接提交到HAL层发送。而Fit-TDMA是发送报文统一调度，因此，我们需要将这个功能关闭，强制报文先进入tid队列，然后通过ath_txq_schedule来调度。而在ath_txq_schedule中，现有逻辑是：如果待调度的tid未阻塞，则将该tid的报文，通过ath_tx_sched_aggr 或ath_tx_sched_normal提交的HAL发送之。显然，在tid粒度级上的调度，是不符合Fit-TDMA调度预期的。Fit-TDMA调度是目标终端级粒度的调度。因此，在ath_txq_schedule中，在验证当前tid为非阻塞后，还需要测试tid->an->an_node所指向的目标终端，是否可以发送（即是否为Fit-TDMA Active态），如果不能发送，则同样要将此tid插入paused_tid_q，等待下次调度。

　　进一步地，在实际测试中发现，管理类帧最好不要延时发送，故在具体实施时，仅当tidno小于16，且ac的qnum小于4时，才测试报文目标终端的状态；此外，有部分报文的目标终端是VAP自己、或一个广播地址，这类报文最好也直接放行。另外，如果一个终端已经下线了，但缓存的报文还未发送时，需要直接将该tid所包含的报文空间释放，并将tid资源回收。

　　此外，还需要注意此状况：触发ath_txq_schedule的txq的tid是一个数据包，但因为其目标终端的Fit-TDMA状态为“等待”，故该报文不能被立即调度到HAL层。此时，如果AP处于低流量工作状态，例如管理的终端数小于5个，且只是简单Ping终端。则下一个同tid调度ath_txq_schedule会来的比较慢，导致回包不及时。这样就会看到ping包时断时续。简单的对策是：如果触发调度的tid是个数据包，但本次调度，未能成功下发一个数据报文时，则立即调度该sc的中sc_txq{0,1,2,3}队列中其它队列。这样，可能会出现：要么外发一个数据报文，要么就不能外发数据报文。当不能外发数据报文，则表明当前Fit-TDMA Active态的终端没有待下发数据报文，应立即通知Fit-TDMA 调度者，请求它将活动令牌传递给下一个轮询终端。

　　最后，为了通知终端可发送报文，Fit-TDMA 调度者在完成本地活动令牌轮转后，立即通过管理帧通知目标终端可发送报文到AP。

　　基于RX流程，直接在ath_net80211_rx函数中处理Fit-TDMA接收逻辑，如果启用“严格TDMA策略“，则针对数据报文，首先验证发端是否为Fit-TDMA Active态，如果验证为否，则直接释放接收到的wbuf。如果启用“兼容TDMA策略“，则继续启用现有逻辑。

　　在实际测试中，如果直接丢弃wbuf，则针对无重发保证的网络应用，会造成大量通信中断。如ping包会丢得一沓糊涂。

　　OL架构中，发送修改点在ol_tx_send函数中，接收修改点在ol_rx_indication_handler，因为网卡级的收发均在黑盒子的FW中，所以目前在offload目录下的驱动修改效果均不好，留待继续改进或换方案。

4 TDMA 调度者

　　TDMA调度者为Fit-TDMA的决策功能体，属于新开发功能模块，分调度员和被调度者2种角色，其中前者运行在AP等汇聚设备上，后者运行在CPE等接入类设备上；后者必须与前者配合才能工作，而前者可以无需后者独立运行。

　　TDMA调度者适宜作为UMAC模块的的一个子功能，LMAC层通过sc的函数指针调用TDMA功能。这样实现可以简化难度、提高能效，同时也不破坏现有的驱动架构。

4.1 状态机

　　TDMA调度功能需要保存各终端或自己的当前状态，不同状态侦听不同的事件，可以执行不同的行为，因此，需要引入FSM机制。具体的，AP侧的FSM描述如下：

　　一共有3种状态：等待、活动和下线状态。等待状态的终端，可以别调度到活动状态，从而允许将报文发送到该终端；同时，活动状态的终端在不同事件后，可变更为等待状态或下线状态。处于下线状态的终端，不会被调度。下线状态主要用于LMAC层直接丢弃报文、以及TDMA调度模块无需频繁删除和生产终端节点。

　　CPE端的状态机描述如下：

　　同样地，CPE侧也包含3种状态：等待、活动和下线状态。显然地，只有处于活动状态，CPE才能向AP发送数据报文；在转换为离线状态后，LMAC层可以将预期发送次数超过阈值的数据报文丢弃掉，也可以将全部数据报文都直接丢弃。

4.2 核心数据结构

TDMA调度员和被调度者的核心数据结构是不区分的，具体描述如下：

　　TDMA的核心就是发送调度，因此调度相关的逻辑结构是最核心的数据结构。在Fit TDMA中，调度链共有5级，其中1级为基础数据级，STA的信息均包含在此链上，为了提高增删效率，采用双向链结构；第2级到第5级链的节点均包含了指向基数数据的指针，采用单向链结构，因为针对此类链的变更操作不是特别频繁。调度时，针对每个调度链，均是从头调度到尾，然后在从更高一级的链头开始调度；在L5链调度完毕后，再转Sta链头。这样可实现：所有节点均能被调度到，且发送速率更快的节点，可以获得更多的调度机会。Hash表主要用于查找，查找功能用得非常多，而链表的查找效率低，所以增加HASH表来提升查找速率。LMAC在ath_txq_schedule中需要查询报文目的节点的状态、在数据报文发送成功后更新该节点的发送速率等，均用到了查询。

　　关于定时器，AP端和CPE端是不同的，AP端只有一个主定时时间间隔，就是为所有的终端一次调度，均分配4ms时间片，超过此时间片后，定时操作函数会立即调度下一个终端；而CPE的定时时间间隔至少有2个，长时间和短时间。长时间用于等待状态，因为无法预知活动令牌指示何时到达、或者就是活动令牌指示会未收到但又收到了AP的数据报文，所以，在等待状态下，还需要定时来触发检测工作；短时间周期主要用于活动态，它的主要作用就是向AP发送返回令牌，同时让自己进入等待状态。

5 Fit TDMA效果

　　在开放环境下，基于QCA9342 HT20模式，每终端跑4条流，启用Fit TDMA功能后，ping 包时延会由1ms增加到5ms左右，单台CPE或网卡的吞吐量依旧是93Mbps左右，上下行差距不到1M；2台终端时，吞吐量与1台终端相同；10台终端时，总吞吐量降低到90Mpbs；20台终端时，总吞吐量降低到88Mbps；32台终端时，总吞吐量降低到84Mbps左右。而如果关闭Fit TDMA功能后，32台终端的总吞吐量不超过75Mbps。因此，启用Fit TDMA在多用户场景下确实有明显地效果。

　　进一步地，人工造异常，在10台终端模式下，让其中的2台终端摘去天线，并用金属板盖住，但同时又保证它能有1-2M的流量。此时，其它8台终端的流量还能各自维持在8.5M左右，不会越跑越慢；而一旦关闭Fit TDMA，则整体吞吐量会越来越慢，低速终端拖慢全局流量效果非常明显。

6 其它

　　在ath_txq_schedule以及HASH查询中，每增加一条printk打印，ping包时延会增加2-3ms，故在调试完毕后，请立即关闭此类打印；ah_txq_schedule是带锁运行的，不要在类函数中调用其他带锁运行的函数，除非你能确认不会死锁；最好不要在现有发送流程中再次增加需要调度的报文。

　　CPE在启用Fit TDMA后，未收到AP的活动令牌通知消息时，是不能向AP发送数据报文的。故最好遵循：1）AP侧将新节点插入到活动调度指针的后边，这样保证它会被立即调度，从而能加快DHCP过程；2）CPE侧在确认对端AP是支持Fit TDMA后，才是能TDMA。

　　在安全性上，为了防止恶意第3方，AP的Fit TDMA支持信元应与AP和CPE的MAC地址相关，CPE在收到该信元后，基于AP和CPE的MAC地址，利用同样的算法，确认信元真实可靠，才能开启Fit TDMA。