[5] FLEW: Fully Emulated WiFi 论文精读
作者
简要介绍下作者：
以及其导师：
目前为止，这位PhD就两篇文章，一篇是今天要精读的文章，另一篇作者也是他一个人和他老师，叫《BlueFi》，今天精读这篇文章的时候也会cue到。
摘要
摘要首先用一段话阐明了当前社会IoT和WIFI发展现状，即IoT设备需要低功耗、轻量级、低成本的芯片，而WIFI已经无处不在，但是WIFI设备一般无法直接用于IoT设备，那有没有一种办法，实现IoT设备直接与WIFI通信呢？于是本文提出来了“完全模拟WIFI”这个概念，即FLEW，它使用单个FSK芯片来完全模拟WIFI的收发，使得配备fsk的物联网设备能够直接与WIFI进行通信。
介绍
本文的Introduction写的层次分明，任何一句话都不多余，多一句少一句都不如现在。
P1：说WIFI已经有数百亿设备接入互连网，这是事实上的标准（de facto），为了支持处理各种WIFI波形的电路，包括高吞吐率的波形，物理上WIFI设备需要更大的芯片，更高的能耗和更高的芯片成本（抛出WIFI当前的现状）。
P2：开始针对上述提及的WIFI的特点，在IoT中反着说，即典型的IoT设备需要小芯片尺寸，更低的能耗和更低的成本，而不太需要多高的数据速率。因此说，WIFI不能直接部署在IoT设备上。但是，作为蓝牙和BLE的硬件，FSK芯片应用于IoT设备是一个非常合理的方案，其调制方案简单，有足够的吞吐量和体面的噪声抗性，低成本，小电路，低功耗。作者选取了最小的WIFI芯片和最小的FSK芯片作比较：
将WIFI的优势和IoT的劣势联系起来。
P3：点出现如今物联网和WIFI的尴尬局面：物联网设备无法直接与WIFI通信，就意味着不能利用起无处不在的WIFI基础设施，而需要一个物联网网关，那么在部署物联网设施的时候总需要额外部署一个网关，就阻碍了物联网应用的使用。而这种网关在市场上并不存在一种主导的协议，因此不同物联网设备往往需要配备一个单独的网关。
P4：提出本文的motivation：有没有一种可能，我让FSK芯片直接与WIFI进行通信，那么这样的话，只要在有WIFI覆盖的位置，物联网设备就能保持连接！
P5：引出本文主要贡献：有可能，我们做了一个直接用FSK芯片与WIFI AP通信的玩意，叫FLEW，对FSK进行了一些改造，使其能够享受已经被广泛部署的WIFI APs。
P6：之前没有人做过这种事吗？你们的工作新在哪里？（再一次明确自己的idea）
之前也有人做过这种CTC（cross technology communication），但是之前的工作都是以WIFI为中心的，即他们往往都是通过修改WIFI AP，而本工作是修改FSK设备；此外，以前的工作比如BlueFi（我喷我自己）实现的是WIFI ap到 FSK的单向通信，而单项通信简直就是玩具，就一个节点加入到一个网络还需要ACK机制，因此双向通信是一件必要的工作，本文填补了这个空白。此外，以前都是修改WIFI AP，但是WIFI AP大量部署是事实，本文能够直接利用这些已经部署好的WIFI AP，而不是再去修改WIFI AP，这是不同于以前工作的场景的。
P7：继续喷老工作。
P8：从双向通信的重要性继续喷老工作，捧自己的工作。
P9：这段进一步踩了一下老工作，随后说了自己工作的一个trade off，即不直接使用蓝牙的协议栈，而是直接用底层的FSK硬件，同时把它完全作为一个WIFI设备接入网络中，而trade off掉BLE的功能，因为这样可以避免BLE在软件层面的一些限制，从而使得实施这个工作更加容易，也为了尽可能最大的保证未经修改WIFI设备兼容性。
P10：点出这个工作的三个insight，总的来说就是，WIFI以PSK形式编码信息，而PSK的调制类似于FSK，顾PSK可以通过频率移位被FSK解调，而带有DSSS信号的PSK可以直接将数字波形连接到混频器来传输。（具体这一段为什么，我们后面详细讲）
P11：讲物联网拓扑，即这篇文章想做的事，WIFI AP和FSK设备具有高度的不对称性，这提供了使用FSK芯片的机会，高效节能简单，同时可以利用到WIFI的优势，相对于ZigBee来说，快四倍，更灵敏，具有更高的编码增益。（PS：编码增益，类似物理的天线增益gain，一个是从硬件上保证鲁棒性，一个是从算法上保证鲁棒性。）
P12：虽然不是安全文章，但是提一嘴安全：
如果没有WIFI加密，FLEW和现有的FSK协议一样安全；如果使用WIFI的安全框架，可以直接利用数十亿设备依赖的可靠WIFI安全框架。
P13：大致总结一下前面12段话：我们使用商用设备实现FLEW，实际上就是用COTS FSK chips去模拟WIFI芯片，从而实现与WIFI AP的通信。而FSK是蓝牙和BLE的基础，因此，单个FSK同时支持蓝牙，BLE，WIFI是一件可能的事情！
P14：进一步吹嘘自己的实验结果：一句很狂的话“我们实现了以前被看做不可能实现的连接和用例”，我们不仅实现了WIFI和FSK的双向通信，更演示了在FSK设备上实时播放高质量音乐和720P的YouTube视频。
P15：阐明为何选取1Mbps为传输速率。
1、1Mbps的速度与BLE4相当，比ZigBee快4倍，足以满足IoT设备需求；
2、速度太高是不稳定的，对WIFI来说，1Mbps是WIFI发挥性能最稳健的速率，比如大部分AP用1Mbps的速度来管理身份验证，关联等关键帧，而在高速的WIFI AP传输时，如果传输的数据包不被确认，则会降低速率，比如尝试用1Mbps的速度重传。
P16：综上，我们的FLEW使用1Mbps
P17/18：与本文关系不大的一些展望，这里不再赘述。
结论
我们直接看一眼结论，结论写的非常简单，直接把汉语贴上来：
我们展示了flew，它使低功耗FSK芯片能够直接与未经修改的WiFi ap通信。我们利用了一些关于FSK和WiFi调制的见解。我们对FLEW进行了广泛的评估，以证明它与所有主要WiFi芯片制造商的芯片兼容，性能良好。
这里的“广泛的评估”真的十分广泛，他的evaluation部分甚至占到了半篇文章的篇幅，相反System Design才两页纸。
前导知识
首先简要介绍WIFI和FSK的调试机制和包结构。
FSK也叫移频键控，类似的还有PSK，ASK等，FSK发送数字的时候，其波形取决于输入电平，比如比特1就输出一个频率比中心频率高一个频率的偏差的波形，相反的，对于0比特，就低一个偏差。一个FSK接收器，首先对接收到的波形进行滤波，过滤出中心频率附近的波形，随后使用鉴频器将过滤后的信号转化为数字信号，鉴频器的输出可能包含一些非线性失真和杂散分量。为了减小这些非线性失真和杂散分量的影响，可以在鉴频器后面添加一个滤波器，当然有的时候可能不需要这个filter，之后就完成了解调。
而FSK的报文形式如上，前面有一个前后交替的01序列，称之为前言，用于稳定接收机的解调器；随后是一个SFD，这个字段可以配置，表示接收方应该在SFD之后开始接受信息，即Data，如果打开CRC，后面也有一个CRC字段，对数据包进行循环冗余校验。
随后来看WIFI这边：
WIFI相对来说就复杂一些，首先进行扰频：
扰频打乱后的比特流被差分二进制相移键控（DBPSK）进行调制。
DBPSK和BPSK都是PSK的一种，其中BPSK是常见的比较基础的PSK调制方案，即二进制PSK，只能传输01序列，一般将0字段编码到负相位，1字段编码到正相位；而DBPSK则是引入了差分编码的概念，即相邻相位之间的相位差才表示01序列，而不是让具体的某个相位值表示信息，这样做更鲁棒。
将DBPSK之后的数据扔入DSSS调制器中。
随后就是介绍WIFI数据包的格式（802.11b）
首先是128位长1，用于稳定接收端；后面是一个稳定的SFD，作为数据包的开始；随后就是PLCP报头，有关于调制或者字段长度的重要信息，还包含一个CRC用于报头数据的校验，随后就是DATA，在之后有一个4比特的CRC作为FCS，Frame Check Sequence，用于DATA的校验。
你会发现，这里用的WIFI协议是802.11b，这其实是一个已经淘汰的WIFI协议，他甚至没有用OFDM，为什么，后面说。
系统设计
所有的真正有价值的WIFI操作，都需要双向通信。因此，作者分成了两个方向，两个章节，这里也按照这两个章节来写。此外，因为WIFI是半双工的工作模式，因此FSK芯片必须能够在发射和接收两种状态下做好适当的切换，单独作为物理层的一节来写。
WIFI to FSK
一句很重要的insight：通过适当的频移，传统的FM/FSK接收器可以作为DSSS + DBPSK解调器工作。
此外，使用FM/FSK接收器，而不是设计复杂相位同步的PSK接收器，本身就简单很多，还不用额外增加DSSS要求的解调器，因为DSSS要求更高的速率（比如11Mhz），而在FLEW中，使用FSK接收器就可以在1MHz运行。
也就是说，所谓的解调DSSS WIFI信号，只是将DSSS扩频之后的11个频段中的某一个频段进行解调。。
而如果巴克码仅在除了0频段的位置均为非零，因此所有频段放置的都是原始信号的副本，接收一个频段的信号就等于接收了原始信号。
而相位和频率具有一个Δφ = 2πfΔt 的关系，因此可以说频率就是相位差。在FSK中，相位差根据时间升高或者减少；而在DBPSK中，相位差随着每个比特突变。而低通滤波可以平滑相位，因此我们可以直接使用FSK芯片来接收这种DBPSK的信号，并通过FSK中的filter，将其中突变的地方变得平滑，从而直接可以从频域查看解调出来的信号，应该是能够区分0和1的。当然，这里还需要一个频率偏移，因为DBPSK得到的频谱看的是比特之间相位的相对值，要么为1，要么为0，所以δφ要么为0要么为π，也就是说频率要么为0要么为非0.然而FSK调制的频率要求往往是正负的区分，因此可以将解调后的DBPSK信号下移，从而使得得到的信号变成正负值。这个非常简单，只需要改变一下FSK接收器的中心频率就可以做到了。
横轴是啥我也不太理解，猜着是采样时间？？
最后，拿到了WIFI信号，就是对信号进行解扰，这只涉及简单的位运算操作，因此可以很方便地实现。
Ok，说完位级别的问题，我们来说包级别的问题。
作者使用了多个商用WIFI芯片来做实验。
其寻找WIFI数据包的方式就是找到SFD字段，来检测WIFI数据包。这里作者提到了一嘴，其检测的是打乱之后的SFD，即扰频完成之后的SFD，而不是在代码中直接匹配，这样可以直接在底层芯片做，效率很高。
然后这篇文章在做实验的时候还声称发现了Realtek的一个巨大漏洞：SYNC字段比要求的短了2位(126位1而不是128位1)。这明显偏离了802.11标准。
但是无妨，在解扰之后，FLEW检查WiFi SYNC字段的最后一个字节，该字段应该是0xFF，正如标准中指定的那样。相反，如果是0x3F，这表明SYNC字段缩短了2位，并且SFD的2位被转移到这个字节(因为WiFi首先传输最低有效位)。如果检测到错误，我们只需对所有子序列字节应用2位的移位。
FSK to WIFI
首先，如何调制一个PSK信号？
其实非常简单，PSK调制之后的信号，其实就是一组载波，比特流编码到载波里面，只是将很多小段的载波信号的相位进行了翻转，换句话说，发射的PSK信号，正常的载波信号部分代表1bit，而相位被反转的部分代表0bit，就像图1所示的那样。
但是传统的BPSK使用的相位是（-1,0）和（1,0），这样需要编码三个电压，即+-1和0，为了简单起见，将相位整体旋转二分之π，这样做就可以仅仅使用两个电压，即+-1去调制载波了，实现起来就更简单。
在DSSS之前，我们每1µs向混频器注入1或-1。在DSSS之后，我们每1µs注入10110111000或01001000111，这意味着芯片速率为11MChip/s。
注入+-1实际上是指在DSSS调制中，将原始数据流和扩频码序列进行相乘，实现了数据流的扩展和DSSS调制的过程。
而DSSS解调器对信号的速率往往有一定要求，比如达到11Mbps，这个可以通过SSP这种串行接口实现，这是几乎所有芯片都有做的功能。
FSM and MAC Layer
因为WIFI是半双工模式，即使用CSMA/CA 协议，因此也要对FSK进行半双工的设计。
WIFI的数据包处理往往都是在驱动程序或者软件层面使用的，除了在硬件处理的ACK RTS和CTS，因为他们受到严重的时间限制。在802.11中，接收端收到一个FCS检查的报文之后，应该在一个SIFS内（常常是10us）发送ACK帧，一个数据包和它对应的ACK数据包之间的时间间隔小于30us是比较理想的。在测试中，FSK芯片Rx to Tx状态切换时间是30-40us，虽然大于这个要求，但是实际使用中发送的ACK包能够被绝大部分现有的芯片检测，无需做更多修改。
但是也有对ACK时间很敏感的芯片，比如Intel的，它对ACK的检测时间要求在了10us左右，
为了赶上ACK的deadline，他们修改了WIFI数据包，即用来校验数据的FCS部分一共有四个字节的数据，他们现在只传输1字节，从而为芯片切换预留出更多时间。1字节的FCS仍然用来检验报文完整性，如果完整就发送ACK。错误检验就交给了高层的检查，比如TCP UDP的校验和。这样子可以实现 FSK芯片到WIFI AP的传输；
方向反过来呢，FLEW发送一个正常的数据包，AP就应该返回一个ACK数据包，届时FLEW已经转换成了接受模式，一旦收到有效地ACK则释放发送缓冲区并从上层复制更多的数据，否则就重新发送。
另外，RTS-CTS机制在绝大部分AP是默认开启的，而且这个对WIFI AP很重要，因为如果一个AP想要传输数据，发送了一个RTS之后没有收到CTS，那么AP就会不停的重发RTS，而不会发送数据。因此这个机制在FLEW也要实现，实现方案和ACK机制是类似的。
最后把所有必要的组件放在一起，就做成了一个有限状态机。
我们大概看一下，首先就是假设一个空闲状态的FLEW，会根据txnext的值立即进入Tx或者Rx状态。
进入Rx状态后，并不代表检测到了WIFI 数据包，当检测到WIFI数据包之后会进入Rx Packet状态，随后根据需要，在接收导数据后去传输CTS或者ACK，随后再次进入Idel状态重新启动这个进程。除此之外，还有一个重传机制，来实现咱们之前说的那些内容。
系统实现
使用Ubertooth作为底层硬件。在其核心，Ubertooth使用TI的CC2400，这是一个标准的FSK芯片设计用于低功耗，低压应用。其MCU使用的是LPC1756.
WIFI 的模拟使用的是linux内核自带的mac80211，这是一个Linux自带的WLAN协议栈，他们自己写了一个驱动，方便FSK去调用已经写好的WLAN函数。
这样写好的驱动可以直接调用mac08211这个WLAN协议栈，也可以直接与上层一起工作，WIFI的各种操作，比如MLME（实体子层）的网络连接、帧传输、发送、接收、认证、加密等操作，都是在mac08211实现的，IP/ICMP TCP/UDP也都在Linux内核实现，也就是说，只要是写了这样一个驱动程序，Internet就是开箱即用了，不用做其他任何修改。
系统评价
这篇文章有将近一半的篇幅用来评估自己的系统。主要分两部分，物理层和系统层。
他用了以下WIFI 芯片去评价自己的FLEW：
Atheros和Boradcom被认为是这个行业中最优秀的两家厂商，预计FLEW应该在这些厂商的芯片上发挥出一个当前最好的效果。 Ralink/Mediatek一般用于低成本的Ap，也常被用于高低端的安卓手机和平板，这是为了证明FLEW可以保证与大多数智能手机的兼容性；原作者声称已经证明了在iPhone的热点下，FLEW可以工作；Marvell 主要用于小众市场，比如高端的特别是企业用的Ap，它们的芯片很多缺乏Linux驱动程序， 因此在物理层不对这个芯片做出评价；Intel 和 Realtek一般不用于AP，只用于客户端，但是为了尽可能证明FLEW的兼容性，也对这些芯片做了测试。
首先是PER的结果:
让发送端向接收端发送一个1508字节的packet，算上4字节的FCS一共1512字节，接收并比较FCS的四字节，如果发现帧错误，就丢弃，一般情况下错误包不会有正确的FCS（小概率事件）。在WIFI芯片使用的天线是相同的。
可以看到，Atheros表现出了非常优秀的性能，特别是FSK to WIFI方向上，Atheros在20m的长度还能将误码率保持在0.1%以下！Broadcom和Ralink性能是差不多的，而二者均有一个现象就是距离变近可能PER还会升高，这可能是因为离得近了之后信号会比最佳距离下的信号更强。而Realtek在FSK to WIFI这个方向上的表现可以看到是最差的，作者认为，Realtek的那个数据包bug可能是这个结果的影响因素之一。
而在系统级评估中，使用未修改过的WIFI Ap测量传输层的吞吐量，iperf3是一个常用的网络测量工具。
首先是上行链路，可以看到，前四大厂商都表现得非常优秀，其中Atheros仍然是明显最优秀的一家。Intel其实也不错，但是远距离下的表现稍差一些，而Realtek仍然是明显的最差的一个，可能归咎于其很差的接收性能，以至于ACK丢的比较多，当然也可能是之前那个bug引起的其他错误。
UDP总是会比TCP的吞吐量要大一些，因为TCP要传输一个额外的ACK包。
一般来说，上行链路要比下行链路的吞吐量低，因为FSK在传输之间，复制数据所使用的时间比较少，所以在每次要切换到发射状态时，如果要发射的数据还没准备好，就不会直接切换到发射状态，这种设计简单好实现，但也牺牲了一些吞吐量。
但是不同芯片厂商的下行链路，相比于上行链路来说，表现出了更大的差异，但是Atheros依旧是最优秀的。
另外，他们还测了RTT（往返时间）：
在局域网，直接连通FSK芯片到AP，直接ping，对于广域网，将AP连接到互连网，去ping Google的DNS服务器，即8.8.4.4
对于每一个厂商的芯片，执行10组ping，距离均为20m，因为
看到结果，Atheros、Broadcom和Marvell的rtt通常是最低的。Intel 和 Ralink滞后，但是二者的rtt还算稳定，只有Realtek的结果最差，到处乱跳，这一定程度上归因于它的芯片无线性能不理想，以及前面提到的那个bug。第三次cue到。
而广域网和局域网之间没有明显差别，只是广域网会有一个在互联网上的传输延迟，大概6毫秒。
后面是他们的共存能力：
首先，如果和其他WIFI设备同时与某个AP通信：
首先可以看到，随着WIFI设备的增加，UDP的上行链路是没有明显变化的，因为UDP不要求ACK，这可以证明FLEW的Mac层的功能是正常的；
而UDP的下行链路下降很大，是因为我们再用一个AP向多个节点发送信号会产生延迟。
而对于TCP来说，因为是可靠通信，只要加入一个客户机，就是以牺牲其他客户机吞吐量为代价的。可以看到，加入哪怕一个WIFI设备，TCP的吞吐量也会急剧下降。
另外，我们看一下第五组实验，可以看到TCP的吞吐量分配非常不平衡，这仅仅是不同厂商的COTS设备带来的区别。
当然还有一个更重要的，在测试TCP的时候，使用最大速率注入数据使得信道饱和，但是即使是饱和的信道仍然会给FLEW分配一些吞吐量，而且这个吞吐量可以满足大部分IOT设备，且网络达到饱和的几率很小，而且就算偶尔饱和时吞吐量不能满足要求，往往也可以利用信道空余时间去传输数据，这也足以满足IoT设备的需求，可以说FLEW是完全满足IoT设备需求的。
当然也可以通过速率限制或者Ap的负载均衡去更公平地实现吞吐量分配，但是这不是这篇文章的重点，作者作为日后工作留给了他们组的师弟师妹们。
与WIFI共存，当然也要与FLEW本身共存：
相对于不同厂商的WIFI芯片，可以看到，FLEW因为设计是一致的，在吞吐量分配上是比较好的，基本达到了1:1.
与蓝牙设备共存：（background Bluetooth traffic）
其实就是在环境中放了两个蓝牙设备，然后用蓝牙设备连接AP播放音乐。可以看到，这根本不影响FLEW的工作。这可能是由于蓝牙本身的跳频设计和比较优秀的自适应跳频机制。因为蓝牙一直在跳频，我之前看过一篇文章就是讲用蓝牙跳频做加密去对标WIFI阻塞时段的密钥生成速率的文章，蓝牙好像是有0-79个可选频段可以跳，因此它不太可能跳到FLEW使用的频段，而且蓝牙的自适应跳频机制本身会自动避免WIFI信道内的蓝牙信道，且蓝牙一般都是低功率运行的，所以即使发生碰撞，也能减轻对WIFI的影响。另外，FLEW是“完全模拟WIFI”，采用的波形和Mac设计与WIFI没有什么区别，所以也可以认为是这个原因导致了WIFI与蓝牙共存的结果和抗干扰机制能够直接适用于FLEW与蓝牙身上。
移动环境中的吞吐量：（在距离AP 0-15m范围内狂奔）
可以发现，移动本身对UDP有些细微影响，但是影响不大，而对TCP几乎没有影响。
而在室外环境下：
这是使用前面实验中最优秀的WIFI芯片Atheros的结果，可以看到，上行链路在150m内能够始终保持一个良好的性能，下行链路在100m内也是如此。更长的范围将逐渐降低，可能是误码率很高的结果。但是不管如何，在150m内，他的吞吐量已经是Zigbee最大吞吐量的两倍了。
最后就是评估一下安全性，之前都是打开了WIFI的WPA2-PSK，
WPA2-PSK代表Wi-Fi Protected Access 2 Pre-Shared Key，是一种Wi-Fi网络的安全协议。WPA2-PSK提供了对Wi-Fi网络的数据传输的加密和身份验证，以确保无线通信的安全性。
在WPA2-PSK中，"PSK"代表预共享密钥（Pre-Shared Key）。这意味着网络中的所有设备都使用相同的预先共享的密钥进行身份验证和数据加密。只有知道该密钥的设备才能成功连接到网络并进行通信。
WPA2-PSK使用高级加密标准（Advanced Encryption Standard，AES）来加密数据传输，提供了较高的安全级别。它是目前被广泛采用的Wi-Fi安全协议之一，常用于家庭网络和小型办公室网络等场景中。
因此需要测一下使用WIFI自带的这个安全协议到底有多大开销：
然后发现，可以说基本没有开销，在误差范围内。毕竟本身这个协议传送的数据包只有16字节，而常规的WIFI数据包大约是1.5k字节，也就占了1%。
在应用层面测试一下FLEW的性能：
证明：FLEW可以完完全全被当做一个WIFI芯片使用，可以直接无视其FSK芯片这一事实，网络应用程序可以直接使用FLEW访问互连网，正常的网页浏览没有任何问题，还支持高质量的Spotify音频流以及480p的YouTube视频，当背景的干扰很小的时候，甚至可以播放720p的YouTube视频！
（作者没放图，我觉得作者可能会在主页或者哪里传一下使用时拍摄的画面，但是，没有找到，就是单纯在论文口述的……）
能耗：
在这个表里可以发现，idle的电流，FLEW其实是比较高的；但是Tx的电流明显小于其他WIFI板子，而Rx排中等。
Rx-Idle这个：If we adjust the Rx current with the idle current, FLEW also has the lowest power consumption in Rx mode.
大概意思就是统筹考虑空闲和接收，发现FLEW也是最低的，这个我有点疑惑啊，因为作者没有说它是怎么算的，只是说同时考虑两个状态耗能，但是我寻思，一个电流最大，一个电流排名中等，我不理解，它能怎么统筹出一个最小值？反正原文就给了一句话而已。
讨论
这篇文章是必须有讨论的，因为它根本没在最新的WIFI协议上做，甚至没有用OFDM，因此也是一个玩具。
那看看作者是怎么狡辩的：
1、802.11协议一直强调向后兼容，这使得FLEW能够适用最新的设备，尽管最新的设备可能使用了OFDM。其狡辩的依据只有一个：802.11协议向后兼容。也就是说，OFDM可以用我捏（假的）。
2、相比于OFDM，物联网设备更适合DSSS调制，因为在物联网设备中，设备复杂性、功耗和成本比吞吐量重要，且DSSS调制的波形比OFDM要健壮。也就是说，现在广泛分布的OFDM并不适合做IoT连接，不如我们用DSSS吧！而且，从实用角度来看，现有设备已经广泛使用了FSK，蓝牙，或者ble,那么FLEW的吞吐量其实是足够的，因此OFDM带来的好处其实没有必要，那为何不用DSSS呢？（这其实和第一点比较，就有点打脸，且对这篇文章的motivation有一些不利，即这篇文章的目的在于要使用已经被大面积覆盖的WIFI，但是现在又吐槽这种WIFI不适合IoT设备直接连接。）
3、推翻第一点，FSK芯片的解调器和分组处理电路不太可能和OFDM一起工作，处理OFDM波形需要更复杂更耗电的电路，而构建OFDM基本的模块也不存在与FSK芯片上。因此，现有的大面积覆盖的WIFI信号应该是没办法使用的。
4、往回拉一把：802.11g/802.11n/802.11ac/802.11ax这些使用了OFDM的WIFI协议，在传输管理帧和信标的时候，使用的协议仍然是802.11b波形，因此，即使未来找到一种可以把FSK芯片应用于OFDM的WIFI场景下的方法，也得确保FSK芯片能够支持802.11b协议，特别是当我们无法修改AP的时候，因此可以说，这篇文章确实推动了这个领域的研究。（我觉得这是discussion最重要的一句话，因为前三点其实都是扯淡，没有这句话，我认为这篇文章就基本没有意义，虽然它有意思）
相关工作
之前的人们已经尝试改进WIFI设备，使得WIFI设备直接与ZigBee通信，即修改WIFI端，而ZigBee不能像传统WIFI设备那样工作。
对于蓝牙也是如此，比如自己的BlueFi，通过修改WIFI端，让其与Bluetooth通信。
这些的缺陷：
1、只允许WIFI到蓝牙的单向通信；
2、对广泛部署的WIFI设备进行修改；
之前确实有同时修改WIFI设备和蓝牙设备从而实现双向通信的工作，但是它同时修改了两个设备，且仅仅实现了SDR仿真，并没有直接像这篇文章一样在商用设备上做实验。
Zhijun Li and Yongrui Chen. Bluefi: Physical-layer cross-technology communication from bluetooth to wifi. In 2020 IEEE 40th International Conference on Distributed Computing Systems (ICDCS), pages 399–409, 2020
注意哦，这个不是原作者的Bluefi，二者系统名字重叠而已，原作者的BlueFi是：
Hsun-Wei Cho and Kang G. Shin. Bluefi: Bluetooth over wifi. In Proceedings of the 2021 ACM SIGCOMM 2021 Conference, SIGCOMM ’21, page 475–487, New York, NY, USA, 2021. Association for Computing Machinery.
走，我们看一眼这个工作做了啥：
这是一个B类的会议，ICDCS，其实就是通过修改WIFI和BLE设备，使得其能够通信。然而其没有在商用设备上做修改，而是单纯的用USRP做的模拟。
问题在于，两台USRP本身就很容易通信，所以双方互相模拟WIFI和BLE实现通信之后就想声称自己做了一个BLE和WIFI能够通信的东西，我觉得不是很有说服力，另外，即修改WIFI，又修改BLE，你的意义何在？你不就是重新做了一套通信系统吗？这个意义很不好写。
封底
