Showing Posts From

Wifi

双频WiFi+BT的通信复用与并发技术总结

在WiFi产品的演进过程中，2.4GHz和5GHz的双频（Dual Band）是一个非常常见和常用的术语。在通信的过程中，两个频段的通信究竟是通过分时等方式复用/切换还是能够直接实现双频并发通信，就形成了两套完全不同的工作逻辑。本文尝试从RF链路的复用和并发处理的逻辑上来解释这个问题。 典型的RF通信链路 要理解双频WiFi以及蓝牙模块在通信过程中的RF链路的复用与并发的问题，首先需要对基本的RF通信连接的组成结构有一个总体的理解。 从一个尽量简化的角度上，一个典型的RF通信链路的连接图如下所示： !RF_Transceiver_Link_Diagram_%281%29.png 如上图所示，这个简化的RF通信链路包含RFIC（也可以称为Transceiver）、射频前端FEM以及匹配电路与天线这几个部分。 在具体的通信过程中（以发送为例）： - 数字电路部分（也就是所谓的数字基带部分）要通过射频发送的字节流0/1信号首先通过QAM、OFDM等调制处理变成模拟低频基带信号，这个过程也就是一个数字到模拟信号（DAC）的转换过程。 - 然后通过上图中的 TX LPF（低通滤波器）滤除 DAC 转换时所产生的高频数字噪声，以确保模拟基带信号平滑、纯净。 - 上图中的PLL/VCO（本振）负责产生RF通信中的高频载波频率，例如2.4GHz和5GHz。Up-Mixer（上变频器）则负责把模拟低频基带信号搬运到高频载波信号的频段，所以，经过这个环节处理以后，低频基带信号的频谱被平移到了高频载波频段，这个环节输出的 RF 射频信号就是包含了低频基带信号信息的高频载波射频信号。 - 以上RFIC环节输出的高频RF信号的功率一般比较小，所以还在在FEM的PA中进行信号功率放大，然后再通过射频开发+带通滤波电路+匹配网络的处理后，耦合到天线上发射出去。 那么，以上的整个RF链路中的各个环节，对于2.4GHz WiFi、5GHz WiFi、2.4GHz BT而言，哪些是可以在通信中是可以复用的？ 主要的原则如下： 1. 首先一点，对于 2.4GHz 和 5GHz 频段的无线通信而言，上图中的 FEM 及其无源匹配电路等，由于物理学上的频率谐振和阻抗匹配特性，是不肯能跨频段复用的。这是因为，PA 和 LNA 内部的晶体管匹配电路极其依赖频率，2.4GHz（波长约12.5cm）和5GHz（波长约6cm）的阻抗特性相差极大；而匹配网络是由电感（L）和电容（C）组成的，其电抗 直接受角频率 影响，不同频段的匹配网络参数需要独立调试。因此针对 2.4GHz和5GHz 的射频通信，在芯片外（或内部封装）必须要有独立的 2.4G 和 5G FEM及其外围匹配电路。 2. 至于上图中的 RFIC 部分是否可以复用，则需要视情况来确定： 1. 2.4GHz WiFI和BT之间，尽管都是2.4GHz频段，但因为两者的基带信号调制方式和协议特性的巨大差别，所以在目前主流的 WiFi/BT Combo 芯片中，RFIC 内部的各个模块（DAC、ADC、基带滤波器、混频器等）在硅片上几乎都是两套独立的物理电路，否则很难在各项物理指标上达到比较好的权衡。 2. 而2.4GHz和5GHz WiFi两者是否可以共享RFIC，则要看设备通信的要求是双频分时通信还是双频并发通信。对于分时通信的情况，两者可以复用RFIC，此时芯片内部只有一个宽带 PLL/VCO，在切换频段时，通过改变分频比，让 PLL 从锁定 2.4GHz 跳变到锁定 5GHz，当然代价是需要几毫秒的切换锁相时间；而对于并发通信的情况，RFIC不可复用，此时必须在硅片上蚀刻两套完全独立的 PLL，一套死死锁住 2.4G，另一套死死锁住 5G，两者互不干扰。 3. 天线部分是完全可以复用的。虽然2.4GHz和5GHz两个频段的电磁波频率不同，但在天线设计上可以使用双频谐振天线（例如包含两个不同长度振子的 PCB 倒 F 天线 PIFA），可以在 2.4G 和 5G 都呈现出良好的 50 欧姆阻抗。具体的工程实践中，可以在上图中的匹配网络之后、天线之前，插入一个 Diplexer。这个器件内部包含一个低通滤波器 (LPF, 允许 2.4G 通过)和一个高通滤波器 (HPF, 允许 5G 通过)。 2.4GHz WiFi与BT Combo的RF复用设计 基于以上总结的RF链路的复用设计原则，下图是一个2.4GHz WiFi与BT Combo的典型RF设计链路： !Combo_RF_Architecture.png - 如前所述，WiFI与蓝牙之间对于基带信号的调制规范差异极大、蓝牙的跳频通信与WIFI的OFDM对于PLL的要求差异也极大，所以在RFIC层面上，Combo需要针对蓝牙和WiFi有一套各自完整独立的实现。 - 而在 FEM 方面，2.4GHz WiFi和BT都在2.4GHz频段工作，但因为两者通信中调制方式、参数和功率的巨大差不，并不能直接复用完整的FEM模块： - LNA (低噪声放大器部分)：由于进入天线的都是 2.4GHz 的微弱信号，系统通常会共用同一个 LNA来放大接收到的空口信号，经过LNA放大后通过模拟开关一分为二，分别送给 WiFi 的 Down-Mixer 和 BT 的 Down-Mixer。 - PA (功率放大器）：通常不复用，物理分离。如果让蓝牙直接使用 WiFi 的 PA 发射，会导致蓝牙功耗成倍飙升。因此，通常会在 FEM中包含一个极其小巧、省电的蓝牙专属小 PA。 - FEM内部在WiFi和BT通信过程中共享通信链路（LNA）和天线时，就不能同时进行 WiFi 发射和蓝牙接收，此时就需要使用PTA机制来对蓝牙和WiFi的使用时隙进行调度管理。 - RF末端的天线、匹配网络、BPF 这几个部分，则可以100% 完全复用。这是因为频段相同，阻抗特性一模一样，蓝牙完全可以直接使用 2.4GHz WiFi 调校好的 50 欧姆完美匹配网络。 2.4GHz/5GHz WiFi的RF复用设计（分时复用） 对于大部分低成本 IoT 设备、低端手机或单天线网卡而言，这类产品中的 WiFi 芯片普遍采用的是双频可选或者分时双频的机制来实现对两个频段的支持，其核心特征是：一芯双频，但同一时刻只能二选一。一旦 WIFi 芯片及其RF链路工作在 2.4 GHz，其5 GHz 链路就处于物理断电或休眠状态，反之亦然。 在硬件层面的设计师，这类双频复用的芯片为了极致削减成本，在硅片上只保留了一套 MAC、一套基带（PHY）和一套频率综合器（Synthesizer/PLL），但因为频段不同，所以FEM部分肯定是要独立分开的。 !TDM_DualBand_WiFi_Architecture_Fixed.png 在上图所展示的双频 WiFi 分时复用的架构图中： - 因为无论是2.4GHz还是5GHz的WiFi通信，其基带信号的调整规范都是相同的，所以可以彻底共享基带，也就是说ADC/DAC 和基带滤波器只有一套。 - 可以复用高频信号的 PLL，只保留一颗 PLL，然后需要在两个频段之间切换通信的时候，通过切换锁相频率分别为 2.4G 和 5G 混频器来提供本振信号。当然如上所述，这个切换的代价是每次切换都需要几个毫秒来达到本振信号的稳定，所以切换的频率不能太高，但是对于同一时刻在2.4GHz和5GHz二选一的WiFi通信应用而言足够了。 - 需要两个频段独立的射频前端 FEM，在模拟高频段，2.4G 和 5G 必须拥有完全独立的 PA、LNA 和 T/R 开关。 - 最终通过Diplexer 把两个频段的RF信号合路处理，RF信号耦合到到同一根双频天线上发射出去。 2.4GHz/5GHz WiFi的RF复用设计（DBDC） 接下来的双频并发（Dual Frequency Dual Concurrent）模式的2.4GHz和5GHz的wifi RF链路相对就比较简单了，整个RF链路能够复用的环节最少，成本最高： !DBDC_DualBand_WiFi_Architecture.png - 因为要双频并发，那么两个频段就无法复用PLL，因此RFIC部分就是完整的两套独立实现。 - 而因为2.4GHz和5GHz频段的巨大差异性，因为整个FEM及其相关的BPF以及匹配电路也需要是完全独立的实现。 - 最终两路并发的RF信号通过合路器Diplexer合并到一起，通过一条天线发射出去。当然也可以各自使用自己的独立天线发射出去。

WiFi漫游协议详解-IEEE 802.11 kvr

本文对WiFi通信无线漫游的概念和传统的漫游流程进行了解释，并对支持WiFi无线漫游过程的三大协议IEEE 802.11K/V/R进行了详细总结，阐述各自解决的问题。 为了能够支持WiFi设备在不同AP之间快速高效的实现无缝漫游，IEEE 802.11组织专门定义了三个协议：802.11K，802.11V，802.11R协议，简称802.11 KVR协议。这三个协议完整的解决了在WiFi无线漫游过程中“什么时候启动漫游切换”，“漫游到哪个AP”和“怎样快速漫游”的问题。 什么是无线漫游？ 既然IEEE 802.11KVR协议主要解决的就是WiFi的无线漫游的问题，那么就需要首先定义什么是无线漫游，以及对于一个wifi STA而言，在无线漫游的整个流程中，这个wifi STA与各个AP之间是如何交互的。 WiFi漫游，是指移动设备（如手机、笔记本电脑等）在不同WiFi接入点（也就是AP）之间自动切换，以保持其连接的无线网络通信业务的连续性，同时要求在这个切换的过程中尽量减少网络中断时间的过程，避免对通信业务造成明显的影响。简单地说，这就好比你在家里拿着手机从客厅走到卧室，客厅的WiFi信号变弱，此时手机就会自动连接到卧室里面WiFi信号更强的路由器上，让你的WiFi网络尽量保持连接在信号最强的WiFi接入点上，同时能在这个过程中持续不中断地、顺畅地使用网络。 众所周知，因为WiFi通信的无线特性，无线信号在空间中传输的衰减非常快，所以一个AP的覆盖范围非常有限，大部分情况下只有几十米。那么对于一个要在较大空间范围内移动的STA而言，要想能够在整个空间中保持与AP的连接，就需要不同的位置部署多个AP，当无线终端STA在移动到两个AP覆盖范围的临界区域时，STA与新的AP进行关联，并且与原有AP断开关联，在整个过程中保持不间断的网络连接。这就是无线漫游的大致执行过程。 !image.png 传统的无线漫游工作流程 传统的无线漫游的完整过程如下：当无线终端逐渐远离当前正在关联的AP时，终端会通过RSSI感知到信号强度逐渐下降，此时终端可通过探测当前环境中多信道的广播报文感知周边AP的存在，并开始与之进行交互。当无线终端的信号达到漫游切换AP的门限值之后，无线终端触发漫游，与新的AP进行关联、并与原有AP断开连接，从而完成AP的切换。 从以上过程中可以看到，传统模式下无线终端的漫游行为完全是由无线终端自己来进行控制的，由终端自己根据漫游切换的门限值，以及自主探测周围环境中所有WiFi热点的信号强度等参数来决定漫游触发机制和漫游判断逻辑。 传统无线漫游模式存在的问题 - 预切换流程中丢包严重。在无线终端测量并且决策进行无线漫游切换的过程中，需要在多信道之间频繁切换监听广播报文、并且同时与多个其他AP进行交互，整个过程从通信的角度看耗时很长，当前连接中所维持的正常业务数据通信中的丢包无法避免。 - 漫游触发不及时。传统无线漫游的触发条件就是其当前连接AP信号的门限值，当信号强度低于门限值，才会进行切换。但是如果尚未达到门限值时，当前环境中有其他通信质量更好的AP时，不会触发切换，这样就会导致终端仍然连接在信号已经较差的AP上继续使用，用户通信的使用体验不佳。 - 无线漫游选择的AP可能不是最佳的AP。按照以上无线漫游工作流程的描述，对于终端而言，选择新AP的比较条件就是其信号强度，但是实际上当前空间中存在的多个AP的工作负荷是不同的，因此选择新AP的时候还应该综合考虑这个AP的当前负荷情况，尽可能选择负荷较少的那个，而不是仅仅依赖于信号强度。 - 关联新AP的时间过长。这一点在AP开启较为复杂的安全认证模式例如802.1x的时候尤其如此。因为无线通信安全协议和流程方面的需求，对STA和AP之间进行完整的重新关联过程需要较长的时间，也就不可避免的导致在这段时间里面应用层的通信无法正常进行，劣化了用户体验。 IEEE针对无线漫游功能，所推出的802.11KVR快速漫游三协议，就是用来解决以上问题的。而能够支持802.11 K/V/R协议的新漫游模式与传统漫游模式的区别，就在于K/V/R漫游的完整流程和执行逻辑是由AC、AP和无线终端一起决定的。 802.11K 802.11K协议的全称是，无线局域网频谱资源测量协议(Radio Resource Measurement of Wireless LANs，简称为 RRM)。 802.11K协议的主要工作目标，就是要通过在AP和STA之间的相互通信，尝试收集并且共享当前无线环境中AP相关的所有信息（信号强度、信道负载、负荷状况、邻居AP列表等），辅助STA找到下次进行无线漫游的最优AP。 802.11K协议的工作流程如下： - 终端主动向AP请求邻居报告信息。当终端STA检测到当前所连接的AP信号质量下降（最典型的就是RSSI低于其预设门限阈值）时，STA向AP发送邻居报告请求（Neighbor Report Request）报文。 - 当AP收到以上请求后，生成邻居报告（Neighbor Report）并发回给终端。这个邻居报告中包含的信息如下：由AP自身所实时维护的邻近AP的静态信息（如SSID、BSSID、信道等），以及动态信息（各个AP的当前负载、信号强度（RSSI）、信道干扰等）。 - 由终端决策与切换。终端收到以上的邻居报告信息以后，根据邻居报告中的综合指标（如信号强度、负载、干扰等）进行评估，选择其中最优的AP作为漫游目标。 从802.11K的以上工作流程可以看到，802.11K协议重点解决的是在漫游过程中尽可能缩短STA的信道扫描时间，由STA当前所连接的AP来提供候选AP列表及其信道方面的信息，最终仍然是由STA为主来决定漫游的切换逻辑。 802.11V 802.11V协议的全称是，无线网络管理协议(Wireless Network Management，简称为WNM)。与802.11K协议类似，802.11V协议也是用于解决传统漫游流程中漫游目标选择不合理的问题，但是两者的区别主要是AP在整个决策机制的被动报告和主动引导上。 在802.11V协议的支持上，AP可以根据网络动态变化状况，主动向终端推荐最优漫游AP，而非仅依赖终端自主选择，通过这种AP主动调整的方式，可以避免网络中的单一AP过载，从而提升网络整体吞吐量。 在具体的工作机制上： - AP在通过802.11K协议获取邻居AP列表信息以后，可进一步利用802.11V的BTM（BSS Transition Management）机制，向终端发送包含各个候选AP的负载、干扰等参数的建议切换列表，以此来引导终端选择最佳AP。 - 此外，在正常的运行中，当AP检测到自身的通信负载过高时，可以通过定向漫游请求（如发送BSS Transition Query帧）将部分终端迁移至低负载的AP。 因此，与802.11K协议相比，802.11V协议在无线漫游流程中的决策主体变成了AP建议或主导，最终的目标是希望能够实现网络中各个AP的负载均衡，优化网络的整体性能。 802.11R 802.11R协议的主要功能是快速BSS切换（FT，Fast Basic Service Set Transition），其核心目标是不降低安全性能的情况下，通过尽量简化AP关联过程中的认证流程，并优化密钥管理机制，实现毫秒级的无缝漫游切换体验。因此，802.11R协议重点解决的问题是传统漫游中，因为STA与AP之间的安全认证流程冗长而导致的业务中断问题。 在支持WPA2/WPA3加密或802.1X认证的网络中，传统的漫游方式需重新执行完整的四次握手（4-Way Handshake）和密钥协商，因此这个完整的关联过程耗时可达数百毫秒甚至秒级。我在另外一篇笔记中详细的整理了WPA/WPA2的完整包交互流程:WiFi WPA/WPA2四步握手认证机制详解 | pavelhan.tech。 而802.11R协议则通过预认证和密钥缓存等机制，可以将漫游过程中STA与AP之间的重新关联切换时间压缩至50毫秒以内，这样就可以满足语音通话（VoWiFi）、AR/VR教学等实时业务需求。 在具体的实现上，802.11R实现快速关联切换时间的核心机制在于快速基本服务集转换（FT）： - 预认证机制：STA终端在切换前通过当前AP与目标AP建立安全隧道，提前完成身份验证和密钥协商，这样就可以避免在切换时的重复认证流程。 - 密钥分层管理：802.11R协议引入PMK-R0（主密钥）和PMK-R1（派生密钥）两级密钥架构。PMK-R0由AC统一分发至AP群组，PMK-R1由各个AP基于PMK-R0来动态生成，从而实现跨AP的密钥共享。 - 四步交互优化：将传统漫游流程的8-10次报文交互简化为4次（Reassociation Request/Response + FT Action帧交换），减少了50%以上的信令开销。 总结 IEEE 802.11K，802.11V，802.11R三个协议一起针对WiFi设备在不同AP之间，如何实现快速高效的无缝漫游提供了较为完整的解决方案。其中： - 802.11K侧重于在AP上持续的收集当前无线环境下的静态信息，STA在需要切换AP时向当前正在连接的AP读取这些静态信息，然后决定应该切换到哪个新的AP上。在整个过程中，尽管AP要向STA提供一些漫游切换的相关环境信息，但总体而言，整个过程中仍然是由STA主导，AP处于被动的角色之中。 - 802.11V则更侧重于整体网络的动态负载均衡的管理，更多的是由AP主动发起或者引导STA切换到符合更小的新AP上，实现整体网络负载均衡的情况下，同时优化了整体网络的通信性能。在这个过程中，AP则从网络整体性能和规划的角度上，处于相对更加主动的角色中。 - 802.11R则在无线漫游切换AP过程中，对AP和STA之间的关联时间及其响应的密钥管理和认证机制进行优化，尽可能在保证安全认证的前提下，缩短STA切换到新AP上的关联时间，避免因为频繁切换导致影响用户层面上的通信体验。 参考资料 - 802.11K/V/R协议介绍 - 802.11k/v/r - lsgxeva - 博客园

WiFi6的Bss Coloring特性详解

在802.11ax也就是WiFi6中引入了一种BSS Coloring特性，这种特性用于优化和解决在高密度环境中多个基本服务集（BSS）之间的无线干扰问题。 在传统的Wi-Fi网络中，如果两个相邻的BSS网络使用相同的信道，它们之间在通信的过程中所发送的信号会相互干扰，导致两个网络的通信性能均明显下降。因为，一旦发生同信道的无限冲突，对于每一个通信节点，都需要增加重传尝试来把数据包放到通信的对端，这样才能避免潜在的数据丢失，无线冲突和重传太多，严重劣化了网络的通信性能。而WiFi6中所推出的BSS Coloring机制可以减少这种不必要的干扰，提高了网络性能和信道利用率。 要理解BSS Coloring的工作原理，首先需要理解WiFi通信节点在信道监听中所采用的CCA（Clear Channel Assessment，信道空闲评估）机制的工作流程。 CCA信道空闲评估流程 在wifi通信中，每个通信节点在发出数据之前，都首先要监听当前的信道是否是空闲的（即同一信道下是否有另外一个节点正在发送数据）。每个通信节点只有在确认当前信道空闲的情况下，才能向外发送数据，这就是物理载波监听的机制。而对于每个通信节点而言，如何评估当前的通信信道是空闲的，就是CCA机制，即信道空闲评估。 在CCA机制的具体实现上（此处只关注物理层载波监听，不关心虚拟载波监听NAV），其核心机制可分为 能量检测（Energy Detection, ED） 和 载波侦听（Carrier Sense, CS） 两个方面。 载波侦听（CS） 物理层载波侦听的核心运行逻辑为：只要物理层能够有效的检测和解调出来Wi-Fi前导码（如802.11协议定义的OFDM符号或DSSS头），那么无论当前信号能量是否超过阈值，均判定当前的通信信道为繁忙。 具体的实现细节是，CS通过解码前导码中的 SFD（Start Frame Delimiter）字段或 PLCP头（Physical Layer Convergence Protocol）来识别合法的Wi-Fi信号，因此这一机制主要用于区分当前信道中所存在的无线信号是Wi-Fi信号还是其他的非协议干扰（如蓝牙、微波炉等）信号。如果是WiFi信号的话（也就是说能够检测到WiFi前导码），当然就判定当前信道是繁忙的；而如果无法解出正确的WiFi前导码的话，就依赖于下一步的能量检测ED阶段来判断信道是否繁忙。 简单总结：CS只要检测到当前信道中有WiFi信号，就认为当前信道繁忙。 能量检测（ED） 物理层能量检测的核心运行逻辑则是，当信道单位时间内积分上的总能量超过ED阈值时，无论信号是否为Wi-Fi协议帧，均判定信道为繁忙。ED检测的主要应用场景是判断信道是否被其他设备（无论是否遵循Wi-Fi协议）占用，当信道上的总能量（包括Wi-Fi信号、非Wi-Fi干扰、噪声等）超过ED阈值时，设备判定信道为繁忙，从而推迟发送数据。 - 不同协议标准阈值不同（如802.11b为-76 dBm，802.11a/g/n/ac更高） 简单总结，当ED检测到当前信道单位时间内的积分能量超过指定的阈值，无论这些信号是否是WiFi信号，都认为当前信道繁忙。 在实际的工作过程中，一般是CS和ED这两个检测之中，只要有一个判断结果是信道繁忙，系统就会认为当前信道为占用状态，推迟发送数据。 BSS Coloring的工作原理 在WiFi6（802.11ax）所引入的BSS Coloring工作机制中，每个AP（接入点）被分配了一个6bit的BSS颜色标识（因此其取值范围0~63），该标识嵌入在PHY层的HE-SIG-A1字段中（位于PPDU帧头），因此每个WiFi6节点所发出数据包的包头都包含有这个6bit的Coloring ID，每个BSS的Coloring ID都不同（理论上，如果检测到Coloring ID冲突可动态调整）。因此对于每个WiFi6节点而言，都可以通过载波侦听（即前面所说的SD环节）监听当前信道WiFi信号的包头前导码来判断这个数据包是自己BSS（MYBSS）的数据包还是使用相同信道的其他BSS（OSS）的数据包。 - AP会在自己的Beacon Frame中广播自己的Coloring ID，这样的话，每个BSS内的STA都可以很清楚的知道自己BSS的Coloring ID是多少。 !image.png 除了以上在包头信息中增加Coloring ID以外，BSS Coloring机制还在CCA的流程中引入了一个差异化及动态调整能量检测阈值的机制。所谓的差异化信道检测门限是指： - MYBSS：如果接收到信号的BSS Coloring ID与自己的AP一致（也就是同一个BSS内部的STA发出的信号），采用一个较低的ED检测阈值（CCA-SD，Signal Detect）来判断信道是否繁忙。例如，当信号功率超过CCA-SD（如-82 dBm）时判定信道繁忙。CCA-CD这个阈值的设置比较低，确保对同BSS信号的敏感检测，避免在相同BSS的其他STA正在传输信号的时候发出数据。 - OBSS：如果接收到WiFi包头前导码序列中的Coloring ID不一致，表示这个数据包来自于其他的BSS。此时在CCA的能量检测环节采用更高的门限值（CCA-ED，Energy Detect）来判断信道是否繁忙。例如，当信号功率超过CCA-ED（如-62 dBm）时才判定信道繁忙。在这种情况下ED检测阈值较高，就允许设备忽略弱干扰信号（如相邻AP的同频信号），减少不必要的退避等待，可有效提升信道的利用效率。 此外，CCA-ED门限还可根据网络负载动态调整。例如当检测到来自OBSS的干扰较强时，可适当提高CCA-ED门限，这样就可以进一步容忍干扰并提升空间复用率。 在下图中，左侧的WiFi4对于所有的BSS，都采用相同的CCA-SD和CCA-ED阈值，这样在有OBSS存在的情况下，很容易就会被判断为当前信道繁忙，不得不等待退避一段时间后再发送数据；而右侧的WiFi6针对MYBSS和OBSS对CCA的判断阈值进行了区分并且可以动态调整，这样的话如果检测到当前是OBSS的节点正在发送数据的话，可以采用更高的CCA-ED判断阈值，只要来自OBSS的信号强度不至于影响当前BSS的信号解调，两个BSS的无线信号就可以同时发送，这样就可以有效的提升频谱的空间利用率。 !image.png BSS Coloring机制理解的相关问题 增加BSS Coloring ID可以解决通信的无线冲突吗？ 当然不可以。在wifi6包头增加的BSS Coloring ID只是用于分辨这个包是否来自自己所在BSS的设备，根据这个ID可以判断出来当前无线环境正在发送的包是否是自己所在BSS的包，然后再根据这个信息来决定CCA信道繁忙状态判断的阈值。包头上增加BSS Coloring ID本身并不能解决冲突问题。 所以，如果两个wifi节点在相同的信道上同时间发出数据，而且对于接收节点而言干扰功率足够大的话，肯定还是会影响接收信号的正确解调。但是，如果两者的距离比较远，两个不同BSS的数据包被认为是弱信号，那就不会影响各自的正确解调，从而可以有效的提升频谱的空间利用效率。 在WiFi6和WiFi4的混合环境中是否还可以支持BSS Coloring？ 在WiFi4和WiFi6的混合环境中，BSS Coloring特性仍然是可以工作的。在这种情况下，Wi-Fi 6设备能够按照其标准流程识别和处理BSS Color字段，而Wi-Fi 4设备由于不支持这一特性，它们不会识别这个字段。但是这并不妨碍Wi-Fi 6设备利用BSS Coloring来减少与其他Wi-Fi 6网络的干扰。因此在实际工作中，Wi-Fi 6设备会忽略来自Wi-Fi 4设备的信号，这样Wi-Fi 6设备就可以更有效地利用信道，而Wi-Fi 4设备则继续按照它们原有的方式工作，不会受到BSS Coloring的影响。 总结 BSS Coloring的具体实现，就是： - 在WiFi6节点所发出的数据包的包头上额外增加一个BSS Coloring ID标识，理论上每个无线环境中的BSS ID表示都是不同的，那么在同一个无线环境中，通过接收和解调出来的包头信息，就可以判断当前正在传送的这个包是哪个BSS的包。 - 基于以上的BSS Coloring ID标识，判断当前收到的数据包来自于相同的MYBSS，还是不同的OBSS。针对MYBSS设置较低的冲突检测阈值CCA-SD，也就是只要检测到相同BSS的数据包正在发送，就要退避等待发送机会；而对于OBSS设置较高的冲突检测阈值CCA-ED，也就是即使检测到有另外一个同信道BSS的数据包正在发送，只要其能量不是很大（使用CCA-ED进行过滤），就认为当前信道可以正常发送数据，这样就可以提升频谱的空间利用率。 因此，按照以上工作流程，通过在WiFi6的包头序列码中增加BSS Coloring ID标识以及针对MYBSS和OBSS设置不同的冲突能量检测阈值并可支持进行动态调整阈值的方式，BSS Coloring确实是可以从一定程度上优化同频段干扰并提升整个频谱使用的空间利用率。 但需要注意的是，BSS Coloring机制并不能从根本上解决同信道无线通信中存在的冲突问题（这个问题实际上是无解的），只不过它通过对BSS的区分，使得不同BSS的数据包在相互之间干扰功率不是很大的情况下可以同时发送，以提升整个网络的通信效率。 参考资料 - 802.11协议精读22：CCA (Clear Channel Assessment) - 知乎 - Wi-Fi 6(802.11ax)解析7：BSS Coloring技术 - 知乎

WiFi6的OFDMA特性详解

OFDMA：全称是Orthogonal Frequency Division Multiple Access，即正交频分多址。 OFDM vs OFDMA 在WiFi6之前的WiFi4/WiFi5，甚至更早的802.11a协议中，已经导入了OFDM机制，即把整个通信信道的频宽划分为多个相互重叠但是正交的子载波，以尽可能提升数据传输速率以及频谱利用率，并且克服无线传输中存在的多径干扰问题。 但是单独OFDM的使用，WiFi AP和STA之间的每次通信都是针对单用户的，也就是说每次发送数据的时候，不管这个用户数据量的大小，与这个用户的通信每次都要占用全部的子载波进行通信。如果把整个信道全部的子载波整体看成一辆送货的小车，当用户要通信的数据量很小的时候，例如即时消息，浏览网页等，这些通信的数据量根本用不了全部的子载波，因此这个小车是装不满的，但根据OFDM的工作机制和流程，这个装不满的小车里面也只能装这个用户的数据，小车里多余的空间（即剩下闲置的子载波）就被白白浪费了。 !image.png 在WiFi6中引入的OFDMA机制则可以有效的改善以上情况。在WiFi6协议中，把整个信道带宽所包含的所有子载波划分为多个相互独立的资源单元RU（Resource Unit），在发送数据的时候，经过AP的统一协商和管理，不同用户的数据只会占用其中的某个RU而不是整个信道，这样的情况下，因为整个信道包含多个RU，那么就可以实现在同一时间使用不同的RU向多个用户同时发送数据的应用场景。如果仍然拿小车来举例的话，OFDMA相当于是在小车中划出专门的隔间，通过调度确定下来每个隔间用户放置不同用户的货物，这样小车跑一次就可以同时为多个接收方送货，当然是大大提升了运输效率（通信效率）。 !image.png 以下是传统的OFDM与OFDMA之间的对比： !image.png RU（Resource Unit）的概念 如上所述，在WiFi6的OFDMA机制的运行过程中，RU是OFDMA的最小资源分配单位。RU由一组连续的子载波（Tone）组成。在WiFi6的OFDMA机制中，RU最小可包含26-tone（也就是26个子载波），其他类型的RU还包括52-tone、106-tone、242-tone等。RU中tone的数量与其所占频宽的对应关系是：（WiFi6的子载波间隔是78.125KHz，很好计算） - 26-tone RU ≈ 2 MHz - 52-tone RU ≈ 4 MHz - 106-tone RU ≈ 8 MHz - 242-tone RU ≈ 20 MHz（对于20MHz频宽而言，相当于是覆盖整个信道） 以2.4GHz频段20MHz频宽为例： - WiFi6导入了更小的子载波间隔（78.125kHz），相比Wi-Fi4/5（312.5kHz）缩小了4倍。因此WiFi6在相同带宽下，可用的子载波数量大幅增加。 - 对于20MHz的信道频宽而言，整个信道的20MHz会被分割为256个子载波，其中234个用于数据传输，其余为保护子载波（11个）、空子载波（4个）和直流子载波（7个）。 - 在20MHz的信道中，最多可支持9个26-tone RU，即同时服务9个用户。 !image.png 在具体的执行中，完整的20 MHz信道可以被灵活的动态分配为不同的RU组合，例如可以分为1个106-tone RU + 5个26-tone RU来同时支持6个用户；也可以分为4个52-tone RU同时支持4个用户。另外，AP在运行的过程中，还会周期性的探测当前连接的多个终端设备的数据流量类型（如视频、语音）和缓冲区状态等，在各个设备之间动态分配RU，进一步优化带宽利用效率。 > 但是需要注意，WiFi6的OFDMA对于RU的划分，只能够支持在同一时间周期内给一个STA分配一个RU，因此无论AP如何灵活的给其连接的STA分配RU资源，每个STA都只能使用其中的一个RU。 触发帧(Trigger Frame)结构 如上所述，在WiFi6 OFDMA机制的运行过程中，AP可以根据其连接的各个节点的通信需求在多节点之间动态的分配RU，那么这个动态分配RU的执行流程是什么呢？答案是： - AP要依赖于触发帧（Trigger Frame）和管理帧交互机制来动态通知各个终端（STA）RU的分配结果。 - 而对于AP与STA之间的下行通信，如果不依赖于MU-RTS机制的话，各个STA的下行通信RU信息就直接包含在AP发出数据PPDU的HE-SIG-B字段中，这样对于下行OFDMA通信而言，就不需要依赖触发帧来分配RU资源了。但上行OFDMA通信（即多个STA利用各自的RU同时向AP发出数据）必须要依赖于触发帧进行RU的协商和同步。 触发帧是在802.11ax规范中引入的一种控制帧结构（Type=1，SubType=2）。有关触发帧的详细信息可以参考[[WiFi6的触发帧（Trigger Frame）帧结构详解]]。 上行和下行OFDMA的运行流程 WiFi6的OFDMA在具体的应用上可以分为上行OFDMA和下行OFDMA两种应用场景和流程： - 下行OFDMA(Downlink OFDMA)，是指AP可以同时使用多个RU向多个不同的STA传输数据，因此可以提高单位时间内的有效数据吞吐率，提升频谱的利用效率。 - 上行OFDMA(Uplink OFDMA)，是指多个STA可以通过利用自己分配的RU向AP传输数据，因此各个STA之间不再需要通过传统的竞争信道的方式来竞争无线传输媒介，减少了STA上传数据由于信道竞争而产生的时延和冲突次数。 以下总结下行OFDMA的通信流程：（AP同时向多个STA发送数据） - AP发出一个MU-RTS Frame类型的触发帧。相比于传统的RTS(Request To Send) Frame，这个MU-RTS Frame中包含了多个目的STA的Association ID以及各个STA在本次会话通信中使用的RU等信息。在这个AP的BSS中，所有的STA都可以接收并解析这个MU-RTS Frame，从而了解到本次会话中AP是否有数据发送给自己，自己是否需要给AP发回CTS应答以及自己的数据在哪个RU。 - STA（MU-RTS中指定的那些STA）发回CTS Frame，确认信道可用于接收数据。因为在MU-RTS中指定了本次会话通信中各个STA的Association ID以及其占用的RU，所以这些STA收到MU_RTS Frame以后，就通过给自己分配的RU向AP发回CTS Frame进行应答。因此，多个STA占用的RU相互独立，可以同时向AP发回这个应答。 - AP同时向多个STA发出数据。这个阶段就是AP使用不同的RU向多个STA同时发出数据，各个STA也只需要接收自己的RU中所传输的数据。 - AP轮流向每个STA发出BAR(Block ACK Request)帧。数据发送完成后等待SIFS的时间，AP轮流向每个接收数据的STA发出一个BAR Frame用于请求各个其数据接收应答帧，以确认数据是否被正确接收。（此处为什么不采用MU-BAR帧，主要是考虑兼容性方面的问题，确保不支持OFDMA和触发帧的其他STA也能够正常收到BAR帧并答复。） - 多个STA同时使用自己的RU向AP回复Block ACK帧。对于本次OFDMA下行通信过程中每个接收数据的STA，使用上行OFDMA机制在自己的RU中同时向AP返回Block ACK Frame，表示前面的数据已经被正常接收并解析。 !image.png 当然以上的MU-RTS和CTS环节是可选的流程，推荐在高密度部署或者敏感数据传输的应用场合中使用。在一般优化吞吐量的应用场景中，可跳过MU-RTS和CTS环节以降低控制开销，在这种情况下，本次下行传输中对各个STA的RU分配信息包含在下行数据PPDU前导码中，前导码中所包含的HE-SIG-A和HE-SIG-B字段描述了RU的分配信息，STA接收到前导码以后对其中的HE-SIG-B字段进行解析来判断自己数据所在的RU。 对于上行OFDMA流程而言，相比下行通信要稍微复杂一点。在上行的流程中，AP需要先轮询各个STA的数据缓冲状态（是否有上行通信的需求），然后再根据各个STA的信息来分配RU资源。因此，在上行流程中，AP先发送BSRP触发帧，STA回复BSR（缓冲状态报告），然后AP再根据这些信息发送基本触发帧来调度资源。 以下总结上行OFDMA的通信流程：（多个STA同时向AP发送数据） - 首先由AP发起下行OFDMA通信流程，AP向所有的STA发出BSRP(Buffer Status Report Poll)触发帧，通过这个触发帧来查询各个STA是否有数据要发送给自己。 - 每个STA通过自己分配的RU，向AP返回一个Qos Null Frame，其中包含有BSR信息(Buffer Status Report) ，告知AP自己是否有数据要发送。 - AP再向所有的STA发出MU-RTS Frame，用于确认各个STA是否已经准备好上传数据，以及各个STA的RU分配信息。 - 多个STA通过自己的RU同时向AP应答一个CTS Frame，表示自己已经准备好发送数据。 - AP再向所有的STA发出一个基本触发帧，通过这个基本触发帧来触发多个STA向其上传数据。各个STA收到这个基本触发帧以后，同时通过自己的RU向AP发出自己的数据。 - 最后AP再向所有的STA发出应答包Multi-STA Block ACK，表示自己已经成功的接收并解析上行数据。 !image.png 同样的道理，以上的上行OFDMA流程中的MU-RTS和CTS部分也是可选的。 参考资料 - Wi-Fi 6(802.11ax)解析2：OFDMA资源块 - RU - 知乎 - Wi-Fi技术简介（九）-- WIFI6高性能之OFDMA - 【WLAN从入门到精通-Wi-Fi 6】第2期——物善其用 OFDMA-云社区-华为云 - Wi-Fi 6(802.11ax)解析13-15：触发帧（Trigger Frames）和MAC接入机制、下行OFDMA接入机制（DL-OFDMA）、上行OFDMA接入机制（UL-OFDMA）_dl ofdma 80211-CSDN博客 - Wi-Fi6协议Triggle Frame在OFDMA中应用_wifi 6 ofdma-CSDN博客

WiFi6的触发帧（Trigger Frame）帧结构详解

WiFi6（802.11ax）中OFDMA（正交频分多址接入）的实现依赖于触发帧（Trigger Frame, TF） 这一关键机制。本文从技术角度深入剖析其触发帧的详细细节。 触发帧整体结构 整体而言，触发帧是802.11ax所引入的一种控制帧类型（Type：Control，Subtype：2）。下图是802.11ax规范中定义的Trigger Frame的整体帧结构。 !image.png 从以上触发帧的整体帧结构上可以看到，Trigger Frame的整体帧结构可以分为四个部分： - MAC Header：包含Frame Control，Duration，RA，TA四个部分。其中触发帧的帧类型在Frame Control中指定。 - Common Info：紧随MAC Header之后的是一个Common Info部分，在其中定义了这个帧的全局参数配置信息。 - 连续多个User Info结构：每个User Info结构针对一个用户（也就是STA）的独立配置字段信息，在其中指定给这个STA分配的RU资源。 - Padding和FCS：最后是整个包结构的占位字段和校验字段。 对于触发帧而言，又可以按照Common Info中的Trigger Type指定，分为多种不同的子帧类型。 !image.png - Basic：用于常规上行OFDMA MU-MIMO传输，AP通过RU分配指定各STA的时频资源，启动各个STA向其上传数据。 - BSRP：在UL OFDMA通信中，AP使用BSRP帧请求STA上报缓冲区状态（有多少数据等待上传），以便于AP动态分配资源。 - MU-RTS：类似于RTS帧，但用于OFDMA通信中，用于协调多用户同时发送RTS帧，以减少信道竞争冲突。 - MU-BAR：用于上行OFDMA通信中，AP向所有的STA请求Block ACK应答消息。 > 另外需要注意的是，在Wi-Fi6协议中，所有的触发帧（Trigger Frame）及其子帧都是AP专属的控制帧，只有AP有可能会发出触发帧，STA无法主动发送触发帧或其子类型。STA仅在收到AP的触发帧后，按照RU分配和时间同步的要求进行响应（如发送数据或ACK），但STA无权主动发起触发帧。这种设计确保了信道资源的集中调度和冲突避免。 > 需要说明的是，对于各个子帧类型不同的触发帧，其中所包含Common Info和User Info的信息可能会有较大的差异。例如MU-RTS类型的触发帧中，Common Info和User Info里面的大部分字段都是不存在的。 Common Info 以下对Common Info部分的重要字段进行解释： - Trigger Type：这个4bit额字段用于说明这个触发帧具体对应的子帧类型，Basic，MU-RTS，BSPR等（可参考上面的表格理解）。 - UL Length：本次上行传输的总时长（也就是STA本次上行传输包含的符号数）。 - More TF：大部分情况下设置为0，主要用于TWT等低功耗模式。 - UL Bandwidth：此处指定上行传输的带宽（20/40/80/160MHz），AP在此带宽内分配给各个STA所使用的上行RU资源 - GI and LTF Type：指定保护间隔（GI）的时间长度 - RU Allocation：定义了每个RU在信道中的频域位置（例如26-tone、52-tone RU）。 - AP Tx Power：此处的AP Tx Power字段是建议所有STA使用的统一发射功率基准，此外User Info部分允许为每个STA指定个性化功率参数。 - HE-SIG-A Info：携带HE PHY头的参数（如是否使用LDPC、STBC等）。 !image.png User Info 在触发帧的帧结构中，针对OFDMA进行RU分配的每个STA都有一个User Info数据结构。这个User Info中就包含了针对对应STA的独立配置信息。 以下对User Info部分的重要字段进行解释： - AID（Association ID）：对应于目标STA的Association ID。 - RU Allocation Index：对这个STA分配的具体RU索引（根据标准预定义映射表）。 - UL MCS（Modulation and Coding Scheme）：指定上行数据传输的调制编码策略。 - UL DCM（Dual Carrier Modulation）：是否采用双载波调制方式来传输上行数据。 - SS Allocation：空间流数（仅适用于UL MU-MIMO）。 - UL Target RSSI：AP要求STA在上行发送数据过程中的发射功率（基于接收信号强度的反馈）。 !image.png 参考资料 - The 802.11ax Trigger Frame – SemFio Networks - Trigger Frames in 802.11ax | Hitch Hiker's Guide to Learning

WiFi不同制式下最大速率的计算

以下对各种OFDM调制模式下的WiFi标准能够支持的最大通信速率理论值进行计算和整理。 WiFi速率的计算公式 !image.png - T(DFT)是OFDM子载波调制的一个symbol的时长。T(GI)是连续Symbol之间增加的保护间隔，用于保护连续symbol之间造成相互干扰。因此T(DFT)+T(GI)是各个子载波上所实际发送的symbol的周期。 - N(SS)是空间波数据，简单地说就是通信中能够支持同时用几根天线发送不同的数据。与MIMO的支持有关。 - N(SD, U)是指OFDM调制的子载波数量，仅包含用于进行数据传输的子载波数量，不包含各种信道保护子载波。与各个不同wifi制式定义的子载波间隔以及能够支持的信道频宽（20/40/80/160MHz）有关。 - N(BPSCS, U)是指每个symbol能够传输的位数，例如QAM16一个symbol可传输4bit数据，QAM256一个symbol可以传输8bit数据。 - R是指编码率，也就是通过信道发出的有效数据和实际数据（其中还包含了一些纠错码等）的比例。例如编码率3/4表示每发送4bit数据，其中有3bit是实际的有效数据，1bit是纠错数据。 802.11a/g 802.11g采用OFDM。在802.11g模式下只支持2.4GHz的20MHz频宽的信道，其OFDM共包含52个子载波信道，其中48个被用于进行数据传输。 802.11g制式下T(DFT)也就是symbol长度是3.2us，symbol保护间隔T(GI)是0.8us。 802.11g能够支持的速率类型包括： !image.png 那么以802.11g最高的QAM64调制模式为例来进行计算，每个symbol能够包含的数据位数是6bit，编码率是3/4，天线数量1根，其能够支持的最高速率就是(48个子载波 6bit 3/4 * 1根天线)/(3.2us+0.8us)=54Mbps. 802.11n 802.11n采用OFDM，开始支持MIMO，最高可以支持4T4R（4个空间流），即可以支持4根天线向外发出数据。 除了默认的一个信道20MHz频宽以外，802.11n也开始支持40MHz的频宽，并且在20MHz和40MHz频宽的情况下均可支持0.8us和0.4us保护间隔。 - 20MHz频宽下，子载波数量由之前的52个提升到56个，其中52个子载波信道可用于传输数据。 - 40MHz频宽下，共包含114个子载波信道，其中108个子载波信道可用于传输数据。 !1735114283629.png 在单根天线（1x1单空间流）的情况下，采用MCS7，调制模式采用QAM64，每个OFDM Symbol可以携带6bit数据，传输编码率为5/6： - 20MHz频宽+保护间隔为0.8us的最大速率：（52个子载波6bit5/6*1根天线）/(3.2us+0.8us)=65Mbps - 20MHz频宽+保护间隔为0.4us的最大速率：（52个子载波6bit5/6*1根天线）/(3.2us+0.4us)=72.2Mbps - 40MHz频宽+保护间隔为0.8us的最大速率：（108个子载波6bit5/6*1根天线）/(3.2us+0.8us)=135Mbps - 40MHz频宽+保护间隔为0.4us的最大速率：（108个子载波6bit5/6*1根天线）/(3.2us+0.4us)=150Mbps 因此单条流的情况下，802.11n最高可以达到的数据传输速率是150Mbps。 !1735114937730.png 以802.11n所能支持最大的4T4R（即MCS31）情况下，调制模式为QAM64，一个OFDM Symbol可传输6bit数据，传输编码率为5/6， - 40MHz频宽+保护间隔为0.4us可达到的最大速率：（108个子载波6bit5/6*4根天线）/(3.2us+0.4us)=600Mbps. 因此在802.11n所能支持的最大四个空间流的情况下，802.11n能达到的最大数据传输速率是600Mbps。 802.11ac 802.11ac也就是WiFi5，相比于WiFi4也就是802.11n而言最大的变化是： - MIMO方面从WiFi4的4T4R提升到最高8T8R。 - 调试方式从WiFi4的最大QAM64提升到QAM256，每个OFDM Symbol可以传输8bit数据。 - 信道频宽从WiFi4支持的20/40MHz提升到20/40/80/160MHz频宽，最高可以在5G频段支持单信道160MHz的频宽。 - 20MHz频宽的情况下，子载波数量56个，其中52个可用于传输数据。 - 40MHz频宽的情况下，子载波数据114个，其中108个可用于传输数据。 - 80MHz频宽的情况下，子载波数据242个，其中234个可用于传输数据。 - 160MHz频宽的情况下，子载波数据484个，其中468个可用于传输数据。 !1735115611007.png 单条流的情况下，最高支持QAM256调制方式，一个symbol可容纳8bit数据，在160MHz信道频宽+保护间隔400us的情况下可达到的最大传输速率是：（468个子载波8bit5/6*1根天线）/(3.2us+0.4us)=866Mbps。 !image.png 类似的，计算802.11ac所能支持的最大8个空间流的情况下，所能达到的最大传输速率为：（468个子载波8bit5/6*8根天线）/(3.2us+0.4us)=6928Mbps。 802.11ax 802.11ax也就是所谓的WiFi6。 802.11ax的OFDM Symbol的周期与前面几代有了很大的差异： - 从802.11g一直到802.11ac，其OFDM的symbol周期都是3.2us，保护间隔是0.4/0.8us，子载波间隔是312.5KHz。 - 但是到了802.11ax，OFDM的symbol周期变成了12.8us，保护间隔是0.8/1.6/3.2us，子载波间隔是78.125KHz。 因为子载波间隔发生了变化，也就影响了不同信道频宽模式下的子载波数量： - HT20模式下有234个子载波可被实际用于传输数据。 - HT40模式下有468个子载波可被实际用于传输数据。 - HT80模式下有980个子载波可被实际用于传输数据。 - HT160模式下有1960个子载波可被实际用于传输数据。 此外，802.11ax能够支持的最大调制模式也从QAM256提升到了QAM1024，一个symbol可以容纳10bit数据。 !1735120986990.png MCS11在一条空间流的情况下，采用QAM1024调制方式，一个symbol最高带10bit数据，编码率5/6，在160MHz频宽，以及采用0.8us的情况下可以达到的最大单路流的传输速率是：（1960个子载波10bit5/6*1根天线）/(12.8us+0.8us)=1200.98Mbps。 !1735121257522.png 同样的道理，在802.11ax能够支持的最大8条空间流的情况下，计算其能够支持的最大数据传输速率就是：（1960个子载波10bit5/6*8根天线）/(12.8us+0.8us)=9607.843Mbps 参考资料 - 802.11gnacax理论速度计算 - 百度文库 - 802.11 WiFi 由浅入深系列文章[10]-理论速率 - 知乎 - 802.11a/b/g/n/ac速率表 - OpenWrt开发者之家 - 【Wi-Fi】802.11/802.11b/802.11g/802.11n/802.11a/802.11ac/802.11ax/802.11be_wifi速率对照表-CSDN博客

WiFi6的低功耗特性TWT简介

之前在另外笔记中（WiFi的低功耗策略实现机制总结， WiFi低功耗工作模式的完整工作流程总结），我整理了经典wifi规范针对低功耗应用所支持的power saving工作流程。这种在STA端基于周期性监听DTIM消息来实现低功耗特性的功能，是目前各个wifi规范中针对低功耗尤其是电池供电的IoT WiFi产品所使用的标准处理方式。但是在WiFi 6（802.11ax）规范中，提供了一种新的更为激进的低功耗工作流程，这就是TWT。 TWT的简介 TWT，Target Wake Time。TWT实际上是首次在802.11ah规范中提出，在802.11ax也就是WiFi6协议规范中正式确定下来，其初衷主要是针对IoT设备，尤其是低通信业务量的设备（例如智能电表等）设计的一套节能机制，可以使得IoT设备能够尽可能长时间地处于休眠状态，从而实现降低功耗的目的。总的来说，TWT是一种与传统的基于周期性唤醒监听DTIM Beacon Frame来实现低功耗特性的完全不同的低功耗技术。 TWT特点是能够让AP和STA之间更加灵活以及个性化的协商双方的唤醒工作时间，其最终的结果不仅仅是能够有效的改善电池产品的待机时间，也可以改善同一无线网络环境下多个设备之间同时通信所造成的无线信号相互冲突的问题。 在WiFi的经典Power Saving Mode中，AP以100ms或者200ms为周期定期发出Beacon Frame，在Beacon Frame中包含有是否缓冲STA数据的标记；STA以Beacon Frame Time为周期定期唤醒监听Beacon Frame，查询AP上是否有自己的缓冲数据，没有的情况下继续休眠，有自己的缓冲数据的情况下进入Normal状态从AP上获取自己的数据。在这个低功耗工作流程中，基本上是以STA为中心的，STA决定自己进入low power以及normal Mode的时机，以及由STA自行决定定时唤醒去监听Beacon Frame的时间周期，AP只是根据STA所处的模式来决定是直接把单播数据发给STA（Normal Mode）还是暂时缓存在buffer中等待STA唤醒后从AP上读取（Low Power Mode）。 而TWT Power Saving Mode下，STA就不需要再机械的定时唤醒去监听Beacon Frame了，而是和AP共同协商自己低功耗模式休眠时机、休眠时长、唤醒工作时长等参数，在这种情况下，STA就不需要数百ms周期性醒来去监听beacon frame，而是按照自己之前与AP协商好的休眠唤醒周期，在唤醒时机到来时唤醒工作，完成后重新进入休眠状态，这个休眠时间可以长达数秒，乃至数分钟和数小时（理论上，这个休眠周期的时长甚至可以达到23小时59分钟！），经典Power Saving Mode的数百ms休眠唤醒周期与TWT模式下的数分钟乃至数小时的休眠唤醒周期相比，TWT自然就可以更长时间关闭耗电的无线模块，从而达到更省电的设计目标；另外，TWT休眠模式，在各个设备的休眠唤醒时机等参数的协商方面，更多的要依赖于AP的整体调度和管理，这样AP清楚的了解和错开分配各个Low Power设备的工作时间段，同一时间段只有少量的设备参与无线通信，就可以尽可能避免同一无线网络下的通信冲突。 !1729238550165.png TWT的工作流程 总的来说，TWT可以分为单播TWT、广播TWT和Opportunistic PS。 单播TWT 单播TWT是STA与AP协商一个双方都可以接受的休眠和唤醒的周期，由STA向AP发出这个TWT工作模式的请求，AP收到后发回应答，双方就成功的建立了一个TWT的低功耗模式工作协议。此后，STA在休眠周期内关闭TX和RX，保持为休眠状态。唤醒周期到了以后，STA打开RX等待接收AP发出的触发包（该触发包是一个可选的选项），然后打开TX进入数据收发的状态，数据收发完成后重新进入休眠状态，进行下一轮的TWT休眠唤醒周期。 每个STA和AP之间都进行独立的TWT工作周期、休眠/唤醒时隙、休眠/唤醒阶段的时长等参数的协商，这样的话，每个STA的唤醒时间段就可以在AP的协商下错开，避免各个STA与AP通信时可能出现的无线冲突的问题，更有效地利用无限频谱。 如上所属，AP和STA之间的TWT协议参数是在双方开启TWT协议工作模式之前通过STA发出TWT请求和AP返回TWT应答来进行交换的，这个交换的重点内容就是TWT参数集。 对于TWT参数集的协商而言，STA有三种请求方式： - 请求TWT参数（Request TWT）。在这种模式下，STA不指定具体的TWT参数，而是由AP在应答消息中指定双方之间的TWT参数。 - 建议TWT参数（Suggest TWT）。在这种模式下，STA可以根据自身的情况发出一个建议的TWT参数，但是实际的TWT参数则由AP决定，AP可以在应答消息中根据自身网络状况修改TWT参数，返回给STA。 - 要求TWT参数（Demond TWT）。该模式下，STA提供一组自己要求的TWT参数，并且要求AP不能修改；那么对于AP而言，收到这种类型的参数以后，就只能返回接受或者拒绝的应答。 双方通过以上TWT参数集协商流程，成功的建立起TWT协议后，STA就开始进入休眠状态（TX和RX全部关闭，既不发送也不监听无线数据包），休眠TWT参数中指定的休眠周期后，再定时唤醒，无线功能进入活动状态开始进行数据的收发，完成后重新进入休眠状态，开启下一个TWT周期。 在AP和STA协商的TWT参数集中，还存在一个“AP是否需要在TWT唤醒阶段发送触发帧”的选项，当该选项使能以后，每次STA从休眠模式唤醒后，不会直接打开TX，而是首先打开RX等待接收AP的这个触发帧，收到以后再进入完整的活动状态。AP通过对触发帧的控制，尽可能避免STA唤醒后双向通信的数据包过多而导致的无线冲突问题。 下图是单播TWT在AP和STA之间收发数据包得了流程图，需要注意的就是，与传统的power saving mode不同的是，单播TWT下STA不需要再监听Beacon Frame了： !image.png 广播TWT 与单播TWT模式不同，广播TWT模式的情况下，AP和STA没有协商TWT参数集的工作流程。 在广播TWT模式下，首先是由AP在其Beacon Frame中携带一个或者多个TWT参数集的信息，多个TWT参数集使用TWT标识符来进行区分。STA在监听Beacon Frame时，可以从中解析出来目前AP所维护的TWT运行周期。当STA有意愿参与AP在Beacon Frame中所广播的某个TWT周期协议时，向AP发出请求加入某个TWT协议（通过TWT标识符指定要加入的TWT周期协议）的请求消息，完成这个加入TWT协议组的申请。完成后，STA即按照AP所指定的这个TWT协议组的TWT参数集来定期休眠和唤醒。 下图是广播TWT模式下AP和STA的工作数据包流程图，注意加入同一TWT协议组的多个STA会在同一时间休眠和唤醒，因此存在多个STA同时进行无线通信的冲突。 !image.png Opportunistic PS Opportunistic PS实际上与广播TWT非常类似，也是不需要AP和STA之间独立的协商TWT参数集，而是直接在Beacon Frame公布出来TWT参数集。而Opportunistic PS相比广播TWT更简单，STA要加入TWT的情况下，也不需要再给AP发出请求加入某个TWT协议组的消息。STA可以自行根据AP Beacon Frame中所提供的TWT参数自行决定是否加入TWT协议组，加入后开始进入休眠状态，到了TWT的wakeup时间段，AP发出TWT唤醒触发消息，然后多个被唤醒的STA基于OFDMA同步与AP进行数据包的交互，交互通信完成后进入休眠状态，等待下一个TWT唤醒周期的到来。 !image.png TWT低功耗模式的应用思考 总结起来，WiFi6中所提供的TWT低功耗模式的工作流程，与传统的WiFi low power saving mode的工作流程差异还是很大的。因为TWT模式下，STA与AP之间可以自由灵活的协商（尤其是单播TWT）TWT参数集，即TWT的休眠和唤醒的时间周期，对于参与wifi通信不多、大多数情况下处于待机状态下的WiFi低功耗设备而言，确实是可以减少耗电比较多的TX和RX打开的时间，从而有效的降低wifi部分工作的功耗，同时各个设备的TWT周期可以在与AP进行TWT周期协商的过程中错开工作，也可以有效的降低多个设备同时与AP通信时，不可避免的无线冲突的问题。 但是需要清楚的认识到一点，就是TWT模式对于STA设备本身在低功耗模式下的工作状态要求是很高的： - 这个STA设备绝大多数情况下并没有被动通信（即从AP到STA的下行主动通信）的需求。 - 这个STA设备对于来自外部的远程唤醒功能没有太大的实时性要求。 试想一下，如果一个设备在TWT协议参数所定义的较长的休眠时间段（例如超过几分钟）里面休眠的时候，此时外部网络向这个STA下发了比较多的数据，这些数据就需要暂时缓存在路由器里面，自然会对路由器的缓存造成比较大的压力；或者在这个设备处于休眠的状态下，外部网络下发了一个唤醒或者请求数据的操作，就需要等到下次这个设备进入TWT唤醒周期后才能给出应答，实时性肯定会非常差。 因此，这种TWT的协议对于抄表这类下行流量和实时性要求不高的应用是合适的，但是如果通信过程中这种随机性的下行流量和通信响应的实时性要求比较高的话，肯定是不适用的。 参考资料： - WIFI6 TWT机制介绍-CSDN博客 - The Low-Power Advantage of Wi-Fi 6/6E: TWT Explained | Renesas 瑞萨电子 - 《企业WLAN架构和技术》2.4 802.11ax标准介绍

WiFi WPA/WPA2四步握手认证机制详解

STA与AP之间建立连接的过程 !Untitled.png 在AP设置为WPA-PSK或者WPA2-PSK加密模式的情况下，STA与AP之间建立连接的流程，主要可以分为以下四个部分： - 阶段1：STA扫描到AP的Beacon Frame或者通过Probe Request找到AP - 被动模式：AP周期性的（一般为102.4ms）对外广播Beacon Frame，STA打开WiFi后尝试在各个信道监听周围环境的Beacon Frame，扫描到要连接的AP在哪个信道。通过对Beacon Frame的数据解析了解到这个AP使用的是哪种加密认证方式。 - 主动模式：除了监听Beacon Frame以外，STA也可以在各个信道主动发出包含有想要连接的AP信息的Probe Request Frame，AP收到后会发回Probe Response frame。这种扫描的方式不需要被动等待Beacon frame，连接速度可以更快。 - 阶段2：STA以Open Authentication的方式连接AP - 这个环节包含Open Authentication和Association两步，每一步都涉及到STA发出请求包和AP发回应答包的收发过程，总共两次交互四个包。 - WPA和WPA2的这一步是Open Authentication，所以没有密码或者密码输错的STA在这一步也可以认证成功并与AP建立连接。但通过了这一步认证，STA只是与AP建立了连接，还无法访问网络。真正的安全性认证通过后才能访问网络。 - Open Authentication：STA向AP发出一个Authentication Request Frame，AP返回一个Authentication Response Frame。 - Association：STA向AP发出一个Association Request Frame，AP返回一个Association Response Frame。 - 以上环节确保STA与AP建立了连接，但还尚未进行安全性认证的内容。 - 阶段3：WPA/WPA2的四次握手完成安全性认证并交换通信密钥 - 由AP发起，AP与STA之间基于EAPOL协议进行四次交互通信，在对预共享密钥PSK认证通过的情况下，完成单播和多播通信密钥的交换。 - 所以这个环节包含两个部分的功能：安全性认证，交换单播和多播密钥。 - 阶段4：加密通信阶段 - 以上WPA/WPA2的四步握手认证通信完成后，STA就与AP之间通过了安全认证并且交换了通信密钥，此后的通信内容使用密钥进行加密保护。 WPA认证加密中的Key解析 - 对于这些加密通信中的Key是如何生成的，因为我自己并非从事安全行业，只需要了解大致的工作流程即可，因此没有太大必要弄得非常清楚。 先说结论，经过WPA 4-Handshake的安全认证以及密钥交换环节后，实际上在AP和STA之间交换了两个密钥PTK和GTK： - PTK用于对后续AP和STA之间的所有单播一对一通信进行加密保护。PTK仅在AP和某个STA之间共享，所有STA的PTK都是不一样的。 - GTK则用于对AP和STA之间的所有广播和多播也就是一对多的通信进行加密保护。GTK则在这个AP的整个局域网内部的所有STA之间共享，GTK由AP维护，在四步握手的第三步由AP加密传输给STA。 - 因为GTK在整个局域网内共享，为了进一步保证GTK的安全性，在AP维护GTK时会定期刷新GTK并通知给各个STA，同时在某个STA断开连接后，AP也会刷新GTK避免过期的GTK被重复使用。 WPA通信中所使用到的各个Key的简单解释如下： - MSK (Master Session Key)：在我们常用的WPA-PSK/WPA2-PSK预共享密钥验证方式中实际上没有用到，仅用于802.1x认证体系，AP与Radius Server之间生成的第一个加密Key。 - PMK (Pairwise Master Key)：在我们常用的WPA-PSK/WPA2-PSK预共享密钥验证方式中，可以认为等同于在AP和STA两端设置的预共享密钥，也就是wifi密码；在802.1x认证体系中，是由AP与Radius Server协商到的AAAkey。 - GMK (Group Master Key)：由AP生成的随机数，用于进一步生成GTK。 - PTK (Pairwise Transient Key)：在4 handshake过程中基于PMK、ANounce、SNounce、双方MAC地址、SSID等生成，用于对AP和STA的单播流量进行加密。 - GTK (Group Temporal Key)：由AP定期生成刷新并加密发给各个STA，在整个AP的局域网内共享相同的GTK，用于对多播和广播流量进行加密。 - ANonce：AP所产生的随机数 - SNonce：STA所产生的随机数 - MIC：AP和STA的MAC地址。 以下附图是WPA加密通信Key的架构图。 !Untitled.png 对上图的简单总结起来就是： - PTK是依赖于PMK生成的，PMK又依赖于AP和STA之间设置的预共享密钥，以及802.1x体系下AP与Radius Server协商的AAA密钥。 - GTK则是依赖于GMK生成的，而GMK本质上则来源于AP定时刷新生成的随机数。 那么接下来就是详细看PTK和GTK究竟是如何生成的。 首先看GTK。 - 如上所述，GTK是由AP独立生成和维护的，不需要在AP和STA之间交换随机数，只需要在与STA建立连接的时候，把这个GTK加密后传递给STA即可，以及定时或者在有STA离开网络时及时更新GTK。 - GTK的生成依赖于GMK。而GMK实际上就是一个由AP定期生成和刷新的伪随机数。GMK并不会被直接发给各个STA，而是由GMK进一步生成的GTK才会被用于发给STA进行多播和广播流量的加密。 - AP有了GMK以后，就会使用PRF算法生成GTK，并且把GTK加密后发给各个STA。 其次是我们常用的预共享密钥WPA-PSK/WPA2-PSK模式下如何生成PTK。 - PTK的生成公式是：PTK = PRF (PMK + Anonce + SNonce + Mac (AA)+ Mac (SA))。也就是说，PTK依赖于PMK、AP端生成的随机数Anounce，STA端生成的随机数SNounce，STA和AP的MAC地址。其中STA和AP的MAC地址肯定是在双方进行第一次通信的时候就能知道的，Anounce和Snounce则分别在4-way handshake的第一个和第二个message分别由AP发给STA以及由STA发给AP。所以要生成PTK，就剩下一个PMK是未知的。 - 而本质上，对于WPA/WPA2的PSK认证模式而言，PMK实际上就是对AP和STA两端分别设置的wifi预共享密钥（也就是所谓的WiFi密码）进行PBKDF2算法运算后生成的256bit密钥。因为这个预共享密钥AP和STA都是知道的，所以它们就可以分别独立的计算出来相同的PMK。 - 至此，对于PTK而言，只要在AP和STA之间成功的交换了SNonce和ANounce，就可以分别生成PTK，用于后续的单播流量的加密。 再次简单总结起来： - 对于多播流量加密所需要的GTK而言，由AP生成和维护，只需要在4-way handshake过程中把GTK加密发送个要接入网络的STA即可。 - 而对于单播流量加密所需要的PTK而言，需要在AP和STA两端分别各自生成。因为预共享密钥已经提前在AP和STA两端分别设置，所以PMK不是问题；AP和STA的MAC地址也不是问题；重点就是ANounce和SNonce应该如何安全的交换。 - 此外就是，在4-way handshake的过程中，AP是如何验证STA是一个合法的接入设备呢？这一点当然归根结底是要验证两者设置的预共享密钥是否一致了。 关于WPA以及WPA2各个Key的生成，有一篇非常好的参考文档可以进一步深入学习：networklessons.com... 。我自己在这里只是把简单的逻辑流程整理清楚。 WPA四步握手的流程 按照以上对于WPA Key框架的分析，下一步在4way-handshake阶段要解决的问题就是： - 如果安全的交换SNounce和ANounce，在AP和STA之间分别生成相同的PTK，用于对后续两者之间的单播流量进行加密。 - 如果把AP端的GTK加密发送给STA，用于对后续的多播和广播流量进行加密。 - AP端如何能够验证STA接入设备的合法性。 WPA 4-way handshake的流程共包含AP和STA之间的4个消息，由AP发起，如下图所示。 !Untitled.png Message 1: Message 1是由AP发送给STA，主要的作用就是向STA发送自己的随机数ANounce。 注意： - 因为在这个阶段，AP和STA之间还没有交换其他密钥（AP和STA上分别设置的wifi密钥也就是预共享密钥PSK会在Message 2上使用），所以此时的ANounce是以明文形式由AP发给STA的。 - Message 1中发送的ANounce也是没有MIC校验的。 !Untitled.jpeg 简单总结：Message 1就是AP向STA以明文方式发出自己所产生的随机数ANounce。 Message 2： STA在Message 1中收到AP的ANounce以后，就可以按照以下公式计算出来PTK：PTK = PRF (PMK + Anonce + SNonce + Mac (AA)+ Mac (SA))。 - PMK在WPA-PSK/WPA2-PSK中是由用户输入的wifi连接密码字符串生成的。 - ANounce是Message 1由AP发过来的，SNounce是自己产生的。 - Mac(AA)和Mac(SA)分别是STA和AP的密码，这个在AP和STA上都可以解析到。 STA计算出来自己的PTK以后，就需要在Message 2里面把自己产生的SNounce随机数发给AP。 - 因为这个时候AP需要收到SNounce以后才能计算出来自己的PTK，所以Message 2里面的SNounce当然也是以明文的方式发送给AP的。 但是与Message 1不同的是，Message 2消息里面除了SNonce明文以外，还包含了这个SNounce随机数的MIC。所以在这个报文的Key Information中设置了Key MIC flag。 这个MIC是如何计算的呢？ - Now WPA2 PSK uses HMAC-SHA1 to generate the MIC and it uses the KCK as a secret to generate the MIC. 也就是说，Message 2的MIC值会使用HMAC-SHA1算法计算，MIC计算的密钥是KCK。 那么KCK是什么呢？KCK就是签名STA已经计算出来的PTK的前16个字节，后续通信中专门用于计算MIC。下图是PTK的结构，KCK就是PTK的前128bit。 !Untitled.png 当AP收到Message 2以后，首先取出其中包含的SNounce明文，结合自己之前产生的ANounce明文，以及双方MAC地址，AP中设置的预共享密钥等信息，计算出来自己的PTK。然后拿出这个PTK的前16个自己，也就是KCK，作为密钥调用HMAC-SHA1算法对Message 2中的SNounce明文进行MIC计算，并且与Message 2中的MIC值进行比较。如果一致就表示双方PTK的交换成功，至此双方有了相同的PTK，可以使用这个PTK对后续的单播流量进行加密了。 - 因此Message 2中的这个MIC隐藏了两个作用，一个是验证Message 2中传递的SNounce的完整性以及是否被人修改，另外一方面也是通过计算MIC所使用的KCK（KCK来源于PTK，而PTK则与PMK也就是预共享密钥相关）验证了AP和STA双方设置的预共享密钥是否一致。 !Untitled.png 简单总结：Message 2就是STA向AP发出自己的SNounce，双方计算出自己的PTK，并通过MIC的匹配计算判断PTK乃至预共享密钥是否一致。 至此，AP和STA已经完成了预共享密钥认证，并且已经交换了双方后续单播通信的密钥PTK。后续的Message 3和4主要就是用于交换对广播和组播流量进行加密的GTK了。 Message 3: 因为前面的Message 1和Message 2阶段已经交换了PTK，所以后续的Message 3和Message 4的通信都使用PTK来进行保护。 Message 3的主要作用就是由AP向STA发出自己的GTK。GTK是由AP独立维护，并且在AP的整个局域网内共享，所以AP只需要把GTK使用前面已经协商好的PTK加密传输给STA即可。 Message 3报文中最重要的就是GTK的加密密文以及消息验证码MIC。 !Untitled.png - 上图中Key MIC Flag设置，表示这个消息同样包含了GTK的消息验证码MIC，使用PTK的前16个字节KCK进行MIC计算。 - 上图中的Secure Set flag设置，表示这个消息说加密消息，需要使用PTK进行解密。 - WPA Key data：就是GTK的加密密文。 - WPA Key MIC：就是GTK的消息验证码MIC。 STA收到以上报文后，使用自己的PTK对密文进行解密得到GTK，同时使用自己的KCK进行消息验证码的计算匹配，验证通过后表示GTK合法。后续STA就有了对广播和组播流量进行加密的GTK密钥。 Message 4: Message 4就比较简单了，它的作用实际上就只是通知AP自己已经正确的收到了GTK并安装到系统中。 !Untitled.png 至此，WPA的4 way handshake流程结束，后续AP和STA之间的通信均使用PTK和GTK进行加密保护。 参考资料 - 4-Way Handshake - WiFi (wifi-professionals.com) - WiFi 四次握手分析 | Think && Act (gitbook.io) - 4-Way Hand shake , Keys generation and MIC Verification-WPA2 – Praneeth's Blog (praneethwifi.in) - 4-Way Handshake - WiFi (wifi-professionals.com) - 4-Way Hand shake , Keys generation and MIC Verification-WPA2 – Praneeth's Blog (praneethwifi.in)

WiFi低功耗工作模式的完整工作流程总结

STA的两种不同的功耗工作模式 总的来说，STA包含有两种不同的功耗工作模式： - Active Mode：在这种状态下，WiFi的无线信号接收电路RX始终处于打开状态，因此可以在任何时间接收AP发过来的数据帧。 - 因为STA的RX要保持打开状态，这种模式下自然功耗较大； - PS（Power Saving） Mode：这种状态下，STA的RX大多数时间保存关闭状态，只需要定时同步打开RX并监听AP发出的Beacon Frame，以此达到尽可能节约能耗的目的； 注意：只有STA才有低功耗模式，对于AP而言因为要实时的对所连接的STA设备进行状态管理和包转发，因此一定是处于Active Mode下； 连接在同一个AP上的STA既可以处于active mode下，也可以处于PS mode下，AP需要对每一个STA是在Active mode还是PS mode有清晰的管理，这样才知道是否需要为某个特定的STA缓存数据（PS mode）还是直接发送出去（Active Mode）； STA处于Active Mode： - 当STA处于Active Mode的情况下，STA的RX会始终保持打开状态，此时AP可以随时把需要发给这个STA的数据包直接发送给STA； - 当STA处于Active Mode的情况下，STA向AP发送的所有数据包的MAC Header Frame Control中的Power Management bit应保持为0； STA进入PS低功耗模式： - 当STA需要进入低功耗运行模式的时候，STA通过设置MAC Header Frame Control中的Power Management bit为1，来通知AP自己将要进入低功耗待机模式； - 当STA处于低功耗模式运行时，其发出的所有包的Power Management bit均应该保持设置为1； - 当AP接收到STA发出的数据包的MAC Header Frame Control中的Power Management bit为1，表示这个STA将会进入低功耗运行模式，此后AP在收到发给这个STA的数据包时，就会把这个数据包暂时缓存起来； STA低功耗模式的运行逻辑 - AP会以固定的Beacon Interval周期（一般为100ms或者200ms）向外发出自己的Beacon Frame，在这个Beacon Frame中包含有TIM Field，这个Tim Field以bitmap（即连接到AP的每个STA对应于其中的一个bit）的形式包含有AP是否为这个STA缓存数据的标记； - 当AP有为某个处于PS mode的STA缓存数据的情况下，bitmap中与该STA对应的bit会被设置为1；否则为0； - 当某个STA进入低功耗模式以后，在AP收到其他（外部）设备发给这个STA的包后，就会暂时为这个STA缓存这个数据，然后通过Beacon Frame的TIM信息中的bitmap来通知STA有缓冲数据； - 当STA处于低功耗模式运行时，STA的RX绝大多数时间处于关闭状态，以Listen Interval（每个STA可以单独设置自己的listen interval，以beacon interval为单位）为周期唤醒，等待接收来自AP发出的Beacon Frame； - Listen Interval越大，STA越省电，但是STA接收到外部数据的延迟越大； - Listen Interval越小，STA接收到外部数据的延迟越小，但是因为要频繁醒来监听Beacon Frame，因此更耗电； - 当STA处于低功耗模式运行时，STA按照预先设定的Listen interval周期性唤醒接收到Beacon Frame，对其中的TIM信息进行解析，了解到AP中有自己的缓存数据； - 如果AP中没有自己的缓存数据，STA关闭RX继续休眠，等待Listen Interval后重新唤醒检查，反复执行以上运行逻辑； - 如果AP中有自己的缓存数据，STA会主动通过以下PS-Poll的机制来获取这个数据； - STA向AP发出一个PS-Poll Frame，请求AP发回自己的缓存数据包； - AP收到PS-Poll Frame以后，会把这个STA缓存的一个数据帧发给STA； - 如果AP上有针对这个STA的多个数据帧，那么会把返回的数据帧的MAC Header中的more data bit设置为1，这样STA就知道AP上还有它的缓冲帧；然后STA回继续以上过程，重复向AP发出PS-Poll Frame，直到把所有的数据帧全部接收完毕； STA退出PS低功耗模式 - 当STA需要退出低功耗运行模式的时候，STA通过设置MAC Header Frame Control中的Power Management bit为0，来通知AP自己将要退出低功耗待机模式，进入Active mode； - 当STA处于Active模式运行时，其发出的所有包的Power Management bit均应该保持设置为0； - 当AP接收到STA发出的数据包的MAC Header Frame Control中的Power Management bit为0，表示这个STA退出低功耗运行模式进入Active mode，此后AP在收到发给这个STA的数据包时，就会把这个数据包直接转发给STA； - 当某个STA退出PS mode时，AP会检查自己当前是否有为这个STA缓存数据包，如果有的话就立即把这些缓存的数据全部发给这个STA； 参考资料 - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, 2007；

Wireshark抓包环境的工作原理与使用技巧总结

Wireshark基本介绍 - Wireshark是全球使用最广泛的开源抓包软件（其前身为Ethereal），是一个通用的网络数据嗅探器和协议分析工具。1998年开始以GPL开源许可证发布。 - 主要功能： - 分析网络底层协议； - 解决网络故障问题； - 找寻网络安全问题； - 跨平台支持很好，可以在Windows、MACOS、Linux/Unix系统上运行； - 官方网站：www.wireshark.org； - 与Wireshark相关/类似的其他软件： - Sniffer - Omnipeek - Fiddler，HTTPWatch，这两个工具主要用来抓包分析HTTP协议； - 科来网络分析系统 - Wireshark中的抓包数据可以支持保存为很多种其他类型的抓包文件，这样这些抓包数据保存后就可以在其他的抓包工具软件中打开并分析。此外还可以使用wireshark提供的导出功能，对抓包序列/文件中的数据进行过滤以后，导出到一个新的抓包文件中； 有线网卡的混杂工作模式 - 有线网卡包含两种工作模式：正常工作模式，混杂模式。 - 在设备网卡正常的工作模式下，当网卡收到的数据包中所包含的MAC地址与自己的MAC地址不一致的话（除了广播包，广播包的MAC地址是固定的FF:FF:FF:FF:FF:FF），就会选择把这个数据包丢弃掉，这样对于网卡的驱动以及驱动更上层的操作系统内核、应用程序而言，根本就看不到不属于自己的网络数据包；因此对于网卡的正常工作模式，网卡只会把属于自己的网络包以及网卡收到的广播包向上提交，把其他的网络包直接丢弃； - 这样的处理可以显著的提升设备系统和应用的处理性能，试想如果网卡收到大量不属于自己的网络包，全部提交给系统内核和应用程序来处理的话，大量的CPU计算周期会浪费在这些没有意义的事情上，严重影响系统本身处理正常工作的性能； - 在这种工作模式下，使用wireshark对网卡收到的数据包进行抓包的话，自然也就只会抓到发给自己的包和当前网络下收到的广播包； - 如果希望能够在wireshark上抓到网络上其他设备的数据包，就需要能够让网卡进入混杂模式。 - 并非所有的网卡都能够支持混杂模式。 - Windows系统中提供了libpcap和winPcap驱动，能够通过这个驱动很方便的在wireshark的软件界面上把网卡的工作模式切换为混杂模式。 - 在网卡的混杂工作模式下，网卡能够捕获到达其网络端口的所有数据流量。无论这些流量是否发给自己的（即无论这些流量的目的地址是什么），都不会丢弃，而是直接发给系统内核和应用层来做进一步的处理，这样运行在系统应用层的wireshark上就可以抓取并显示出来不属于自己的网络包。 - 因此结论就是：如果想要wireshark上抓取到不属于自己的网络包，就必须要有一个能够支持混杂模式的网卡。 无线网卡的监听工作模式 - 无线网卡有四种工作模式： - Master Mode：主要用于无线接入点AP对外提供无线接入以及路由管理的功能服务，可以简单地理解为我们的无线路由器就工作在Master模式下。 - Managed Mode：当无线客户端与无线接入点AP之间连接的时候，无线客户端就工作在Manged mode下。 - Ad Hoc Mode：用于两台无线设备之间建立P2P直连的情况。 - Monitor Mode：用于监控无线网络的流量。在这种工作模式下，无线客户端自身停止收发数据，专心监听在空气中某个信道上正常传输的数据包。 - 如果想要使用Wireshark来监听空气中传输的无线数据包时，就必须要使自己的无线网卡工作在这种模式下。当然并非所有的无线网卡都能够支持Monitor Mode。 - 也称为RFMON Mode。 - 如上所述，如果要通过wireshark来监听空气中传输的WiFi无线包，必须要有一个能够支持Monitor Mode的无线网卡，然后设置该网卡为Monitor Mode，并指定要监听的wifi信道，无线网卡将会开始专心的监听该信道中正在传输的所有数据包，解析后推送给wireshark显示出来。 - 无线网卡的Monitor模式与有线网卡的混杂模式比较： - 有线网卡设置为混杂模式后，只能监听到自己所加入的网络中传输的数据包； - 而无线网卡的Monitor模式，根本就不需要无线网卡加入网络就能够进行监听，而且可以监听到指定信道所有网络中正在传输的无线包，因此无线网络相比有线网络，要不安全的多； - 无线网卡的混杂模式？理论上无线网卡在加入某个AP以后，也应该可以监听到这个AP网络中的所有流量，但是实际上无线网卡根本就没有必要加入AP，就能够监听到这个信道中所有网络的流量，权限要大得多，所以无线网卡的混杂模式就没有太大意义了。 抓包环境分类及其工作原理 - 有线网络下的抓包环境分类 - 本机环境：即对发给本机网卡的所有网络流量或者本机网卡发出的所有流量进行抓包分析； - 即只对自己的流量进行抓包分析，这是最基本最简单的一种流量监控和分析的方式； - 集线器环境：同一冲突域，可以对所有连接到同一集线器上的所有设备的进出流量进行抓包； - 流经集线器的所有网络包都会被发送到集线器上的每一个端口上，因此这种情况下对网络流量进行嗅探实施起来最方便，只需要把网络嗅探器连接到集线器上的任意一个空闲端口上即可； - 但因为集线器的半双工通信模式，连接到集线器的设备只能有一个设备在发送数据，传输效率比较低，现在已经很少见使用集线器的网络环境了；所以这种环境现在基本上只存在于理论分析中； - 交换机环境 - 交换机是当前网络环境中应用最常见的连接设备类型。 - 交换机工作在物理链路层，因此可以通过MAC地址来唯一的标识连接到其上的设备节点，交换机内部维护有一个MAC地址寻址表CAM（其中保存在MAC地址和端口的映射信息），交换机在收到一个数据包以后，通过读取这个数据包的头部信息中包含的MAC地址，然后查CAM来决定把这个包发到哪个连接端口上。 - 因此当把网络嗅探器连接到交换机上的某个端口，将会只能收到发给自己的数据包和广播类型的数据包。 - 那么对于在一个交换机环境中如果要对这个网络中的流量进行嗅探的话，主要有以下几种方法： - 端口镜像 - 前提条件： - 交换机能够支持端口镜像设置； - 有权限设置交换机的端口镜像功能； - 交换机上有空闲的端口接入网络嗅探器； - 在交换机上设置端口镜像后，交换机在转发流量的时候就会把这个流量拷贝一份同时转发给网络嗅探器所在的端口； - 各个交换机的端口镜像支持以及设置方式均不同； - 集线器接出 - 使用网络分流器 - ARP欺骗攻击 - 不需要特殊的交换机设置的权限； - ARP攻击软件：Cain&Abel； - 通过在嗅探机上安装ARP欺骗/攻击工具， 通过发送ARP应答伪装自己为流量接收机器的MAC地址，这样原本发给目标机的流量就会被发给嗅探机，借此接收到本不属于自己的流量。 - MAC泛洪 - 不需要特殊的交换机设置的权限； - 在嗅探机上发送包含有大量MAC地址的包出去，交换机接收到以后会把新的MAC地址填写到CAM表中，但是CAM表的长度是有限的，如果MAC地址太多的话就会把原先正常的MAC表项冲掉。这样这些机器的流量因为在CAM标志找不到对应的对应项，就会被转发到所有的端口上，从而到达监听流量的目的。 Wireshark使用的一些技巧总结 - 可使用工具栏上的放大镜按钮对抓包窗口显示内容进行放大缩小的控制。 - 增加/修改列： - 给抓包窗口增加列：在具体要增加的信息项上点击右键，选择“应用为列”，就可以把这个选型增加到新的列上； - 修改列的信息：在抓包列表窗口对应列的Header上点击右键，选择Edit Column，就可以修改指定列的信息，例如列的名称； - Packet Time相关设置 - 修改抓包创建的时间显示格式：视图---时间显示格式； - 修改抓包窗口中的time base，即在抓包的序列中，选择一个包作为起始包，其他包的时间都以这个包的时间作为参考：在需要设置作为参考的包上点击右键--设置/取消设置时间参考； - 在同一个抓包序列中可以设置多个时间参考； - 名字解析的功能 - wireshark在MAC、IP地址、端口的各个层次都提供了名字解析的功能，名字解析的功能开启后，显示在抓包窗口中的地址就不再是简单的MAC或者IP地址，以及端口号，而是可以直接自动识别为对应的厂商字符串（MAC地址）、公网服务器名称（IP地址）和传输层协议名称（端口号），这样查看抓包列表就会更方便简洁一些； - 名字解析功能默认情况下只打开了MAC层的解析，如果需要开启IP地址和传输层协议名称的解析，可以在捕获---选项---选项---Name Resolution或者编辑---首选项--Name Resolution中开启IP地址和传输层名称的解析； - 数据包的标记 - 为方便对数据包进行分析，可以使用mark/unmark的功能对选择的数据包进行高亮显示和取消高亮显示； - 还可以通过对话着色功能对不同类型的协议使用不同的颜色来自动标记； - 多个数据包文件的合并操作 - 如果多次抓包得到多个抓包文件，可以使用wireshark的文件---合并功能把多个抓包文件做合并处理，显示在一起进行分析； - wireshark的抓包自动保存设置 - 可以通过设置捕获---选项---output来设置抓包数据自动保存到文件的设置，这样在wireshark中捕获到的抓包数据就会自动的写入参数指定的文件中；并且可以支持按照固定抓包文件大小、抓包时间长度、抓包数量等设置来自动创建新的抓包文件； - 过滤器 - wireshark有两种过滤器设置，两种过滤器的语法还不一样： - 抓包过滤器：在捕获---选项---Capture Filter中进行设置；这种情况下设置的过滤器会自动把不符合过滤器的包直接丢弃； - 抓包过滤器使用的是基于libpcap/wincap库的BPF（Berkley Packet Filter）语法； - 类型Type：host，net，port； - 方向Dir：src，dst； - 协议Proto：ether，ip，tcp，udp，http，ftp - 逻辑运算符：&&，||，!，==； - 显示过滤器：也就是在抓包列表显示窗口上方的过滤器设置；这种情况下设置的过滤器不会针对丢弃掉不符合过滤规则的包，而只是会隐藏显示； - 比较操作符：==,!=,>,=,

基于Wireshark+Acrylic WiFi Sniffer的WiFi空口抓包环境

前提条件： - 安装好wireshark和Acrylic WiFi Sniffer软件； - 一个能够支持Monitor工作模式的无线网卡； - 提前知道要抓包的AP信道； - （如果需要对数据链路层以上的数据进行解密的话，需要）提前知道要抓包的AP SSID和密码； 安装Wireshark和Acrylic WiFi Sniffer - 在www.wireshark.org上下载wireshark的最新版本并安装即可； - Acrylic WiFi sniffer - 下载地址：https://www.acrylicwifi.com/en/downloads-free-license-wifi-wireless-network-software-tools/download-acrylic-wi-fi-sniffer/#； - 免License的Acrylic WiFi Sniffer软件在进行抓包的时候，每次执行抓包只能抓1min的包，并且抓包5min后才能执行第二次抓包。如果要去掉以上限制，就需要购买License：1年期的软件使用授权费用是100美元，永久授权是220美元； - 安装后打开软件，Acrylic WiFi Sniffer软件就开始扫描连接到电脑上的无线网卡，并检测是否能够Monitor工作模式，并把能够支持Monitor模式的无线网卡列表罗列出来： !Untitled.png - 如果以上Compatible WiFi Devices中显示的结果是No WiFi devices found，就需要另外找一个能够支持Monitor工作模式的无线网卡； Acrylic WiFi Sniffer支持的无线网卡 - Acrylic WiFi Sniffer软件对无线网卡的支持情况在以下链接中查看：https://www.acrylicwifi.com/en/wlan-wifi-wireless-network-software-tools/sniffer-wifi-for-windows/acrylic-wi-fi-sniffer-requirements-and-compatibility/； - 实际上以上连接中只是罗列出来一部分，例如可以确定磊科的NW392 USB无线网卡可以支持； 抓包前提前扫描AP所在的信道 可以提前在手机上安装AP扫描软件对周围的AP状况进行扫描，例如Android平台的《WiFi分析助手》： !Untitled.jpeg 使用Wireshark进行WiFi空口包的抓包 打开Wireshark后，在Wireshark捕获设备列表中选择Acrylic WiFi Sniffer软件找到的无线网卡： !Untitled.png 点击前面的齿轮按钮选择正确的wifi信道，确认开始后即启动WiFi空口包抓包： !Untitled.png - 在Channel位置选择使用WiFi信道扫描工具扫描到的AP信道； WiFi空口包的解密 - 默认情况下，通过以上WiFi空口包抓包环境抓取的数据包的Protocol都是802.11，因此只能看到数据链路层包头部分的內容，之前的部分都以QoS Data的形式进行加密。这样我们在进行抓包分析的时候就没法知道其上层协议、端口等信息的具体內容。 - 这是因为在空中传输的WiFi packet都是经过加密的，密钥在AP与STA进行Association操作的时候进行协商，此后的通信过程中，会使用协商的密钥对数据链路层以上的数据进行加密，只有这个packet的接收方才有正确的密钥来进行解密。 - 如果要实现对WiFi空口包抓包数据的解密操作，即能够看到802.11数据链路层以上的协议、数据、端口等內容，需要： - 提前知道抓包AP的SSID和Key，并在wireshark中设置：Edit -> Preferences -> Protocols -> IEEE802.11 -> Edit，设置选择wps-pwd，key填：KEY:SSID；例如SSID是R8000，Key是88888888： !Untitled.png - 能够抓取到一次完整的STA到AP的Association过程，这样才能够获取到这次STA与AP连接过程协商的加密密钥： !Untitled.png - 最重要的就是能够拿到以上完整密钥协商过程的四个key，只有四个key都监听到的情况下，后续这个STA与AP之间的通信包才能得到正确的解密。 - 从以上完整的Association过程的抓包过程来看，如果要能够对后续的通信包正确解密成功，需要在wireshark中抓包到以下序列： - STA向AP发出Authentication，并接收到应答Acknowledge； - AP向STA发出Authentication，并接收到应答Acknowledge； - STA向AP发出Association Request，接收到应答Acknowledge； - AP向STA发出Association Response，接收到应答Acknowledge； - AP向STA发出Key Message 1，接收到应答Acknowledge； - STA向AP发出Key Message 2，接收到应答Acknowledge； - AP向STA发出Key Message 3，接收到应答Acknowledge； - STA向AP发出Key Message 4，接收到应答Acknowledge； - 而实际的抓包测试中，可能会漏掉其中的某个key message，这样就会导致无法解密成功； - 在遇到无法解密成功的情况下，需要检查一下： - 是否在802.11包解密设置中填写正确了SSID和Key信息； - 是否监听到一次完整的Association过程，即能够在抓包数据中看到完整的Key1-Key4的完整过程； - 如果仍然无法解密成功，尝试修改802.11包解密设置中的Assume Packets have FCS和Ignore the protection bit设置选项；

WiFi中的Beacon、TIM与DTIM概念总结

Beacon Frame - AP默认每102.4ms向外广播一个Beacon Frame，每个Beacon Frame中都包含有一个TIM Field，其中描述了AP为哪些STA缓存了数据； - Beacon Frame的发送周期以及DTIM间隔可以在路由器的设置选项中进行设置（路由器支持设置的情况下）； - 注意：Beacon Frame在发送的时候也需要参与到信号竞争机制中，只有当AP竞争到发送Beacon Frame的发送时隙后，才会把Beacon Frame发送出去。因此理想情况下Beacon Frame会以Beacon Interval的设置为周期精准的发出，但是当信道比较繁忙的时候，这个发送时隙可能会与理论值稍有偏差； - AP发出的Beacon Frame中包含一个固定8字节的TimeStamp field，其中包含了AP自己以us为单位的计数器的计数值，STA通过监听Beacon Frame的这个timestamp，可以实现两者通信的定期精准时间同步； - 当STA接收到AP的beacon帧后，提取Timestamp字段的时间戳，并且添加一下本地估算出来的延迟（从天线端口接收到最后处理的本地延迟），从而完成节点与AP时间同步的功能。 - 在802.11协议中，Beacon在发送的时候始终使用的是AP能够支持的最低速率，因为： - Beacon帧是一个广播帧，没有ACK反馈，也就无法设置重传机制； - Beacon的目标是希望广播AP上的基本信息，所以希望所有的节点（包括兼容那些比较老的设备）都能够收到这个信息，发送beacon的时候采用最低的传输速率能够支持那些比较老的无线设备接入； - 此外，速率越高，在无线信号解调的时候需要信号越好（即最低灵敏度越高），降低传输速率可以降低信号解调的要求，确保信号较差的设备也能够接收到这个信息； Beacon Frame中TIM Field的作用 Beacon Frame中的TIM Field主要用于配合实现802.11定义的低功耗运行逻辑。 在STA的低功耗运行模式下，STA会处于休眠状态，为了能够保持基本实时的网络连接，STA需要定时唤醒并打开RX监听AP的Beacon Frame，在这个Beacon的TIM Field中就包含有为哪些STA缓冲了单播帧的信息；STA收到后解析并判断AP中是否有自己的单播帧； - 如果有的话通过向AP发出PS-POLL frame来申请自己的缓存单播帧； - 如果没有的话就可以继续休眠。 通过以上基本的运行逻辑来保证低功耗和网络通信实时性的平衡。 Beacon Frame中的TIM Field详解 !Untitled.png - Element ID：固定一个字节，元素识别码，用于表示Beacon Frame中包含的不同字段，对于TIM类型的字段而言这个ID是5； - Length：固定一个字节，用来表示这个Field中所包含的数据的长度，以字节为单位； - 具体而言，Length表示的是以上DTIM Count、DTIM Period、Bitmap Control、Partial Virtual Bitmap这四个子域的长度，因此Length最小为4，最大为254； - DTIM Count：固定一个字节，距离下一个DTIM还有几个Beacon Frame； - DTIM Count=0表示当前TIM为DTIM； - DTIM Period：固定一个字节，每隔几个Beacon Frame发出一个DTIM信息，这个值由AP设置； - 如果DTIM Period设置为1，表示所有的TIM都是DTIM；0为保留值，不可设置； - Bitmap Control：固定一个字节； - Bit0：为1表示AP中缓存有组播/广播帧，会在DTIM对应的Beacon Frame后发出来；为0表示AP中没有缓冲的组播/广播帧； - Partial Virtual Bitmap：变长，长度在1-251个字节； - Bitmap Control的bit1-bit7以及完整的Partial Virtual Bitmap数据用于表示这个AP中为哪些进入低功耗的STA缓存有单播帧；STA收到这个信息以后解析，查询自己的AID对应的那个Bit是否为1，如果为1的话表示AP中有自己的缓存帧，此后STA就需要使用PS-POLL的机制来获取自己的缓存帧；如果为0的话表示没有自己的缓存帧，STA可以继续休眠； - 实际上每个连接到AP上的STA在Partial Virtual Bitmap中都有对应的一个bit，这个bit为1，表示AP上有为这个STA缓存的数据，为0表示没有；Partial Virtual Bitmap最大为251个字节，也就是最多可以包含2008个bit，刚好与一个AP能够连接的STA的数量一致； - 如何通过Bitmap Control的bit1-bit7以及Partial Virtual Bitmap数据来解析AP上是否有为某个STA缓存数据，在802.11协议中有一个Annex O：An example of encoding a TIM virtual bit map可供参考。 - 既然Partial Virtual Bitmap中的每一个bit代表一个STA，直接就可以使用包含251个字节的Partial Virtual Bitmap来标识AP中的缓存数据情况，为什么要搞这么一份负责的算法呢？这是因为如果每个Beacon Frame都包含完整的251字节Partial Virtual Bitmap，那么这个Beacon Frame的长度就太长了，而Beacon Frame是使用最低速率发送的，发送频率又比较高，这样的话导致光是Beacon Frame的发送就占去了不少无线信道时隙。因此引入了Bitmap Control机制来达到既可以在TIM中包含所有的缓存信息数据又尽量减少Beacon包的大小的效果。 下图是一个TIM类型的Beacon TIM Field抓包数据： !Untitled.png 下图是一个DTIM类型的Beacon TIM Field抓包数据： !Untitled.png TIM与DTIM的区别究竟是什么？ - 其实TIM与DTIM的差异非常小，最重要的区别只是： - DTIM类型的Beacon Frame后面会紧跟着发出AP上缓存的所有组播/广播帧，当然前提条件是AP中有缓存的组播/广播帧（即Bitmap Control=1）； - 当AP中不包含有缓存的组播/广播帧（即Bitmap Control=0）的话，TIM实际上与DTIM一样，只不过DTM Beacon Frame中的DTIM Count=0而已。 - 因此在Beacon Frame内部，DTIM与TIM类型的数据结构基本上是完全相同的： - TIM的DTIM Count不等于0，DTIM的DTIM Count等于0； - TIM与DTIM的DTIM Period相同； - TIM与DTIM的Bitmap Control的Bit0都用于表示AP中是否有广播/组播缓冲帧； - TIM与DTIM的Bitmap Control的Bit1-Bit7以及Partial Virtual Bitmap都用于表示AP中为哪些STA缓存了单播帧； 参考资料 - 802.11 ------ Beacon帧、Beacon Interval、TBTT、Listen Interval、TIM、DTIM - 802.11协议精读10：节能模式（PSM） - 802.11 – TIM and DTIM Information Elements

WiFi的低功耗策略实现机制总结

WiFi的低功耗工作模式 低功耗工作模式禁止：STA在大部分时间保持RF接收器打开等待和监听是否有自己的无线数据包，在需要发送数据的时候切换为RF发射状态。 - 在这种情况下，AP会直接把所有发给这个STA的frame直接发给这个STA，不会为其缓存frame。 - 这种情况下STA的RF电路的大部分都需要保持开启状态，非常耗电； 低功耗工作模式使能：STA通知AP自己即将进入低功耗模式，AP就会为这个STA缓存数据帧；STA周期性的醒来，通过Beacon Frame中的TIM Field了解到AP上是否有自己的缓存数据，有的话就发出PS-Poll frame获取这些缓存帧；完成后重新进入低功耗状态； - STA处于低功耗状态下，AP收到发给这个STA的数据后，不会直接发给这个STA，而是先为其缓存，等待其发出PS-Poll来获取或者等待这个STA重新进入唤醒模式（Power management bit设置为1）； - 在低功耗模式下，STA的RF电路大部分的时间只有时钟部分在工作，只有定期醒来需要进行数据交互的时候才需要接收器或者发射器工作，因此非常省电； - 对于应用层而言，一般通过WiFi原厂提供的接口来设置STA进入低功耗模式； 低功耗模式的整体工作流程 STA要进入低功耗工作模式的时候，就会把发给AP的frame的Power Managerment bit设置为1，表示其将进入低功耗模式； AP收到后就会为这个STA缓存所有要发送给它的单播数据帧，并且在它发出的周期性Beacon Frame的TIM Field设置标志，标记这个STA在AP中有缓存帧； STA周期性醒来，等待接收来自AP的beacon frame；通过beacon frame中的TIM信息了解到是否有自己的缓存帧； - 如果没有自己的缓存帧，STA就会重新进入休眠状态； - 如果有自己的缓存帧的话，STA就会向AP发出一个PS-Poll frame请求获取自己的缓存帧，AP收到后就会把缓存的Frame发给STA； STA把缓存在AP上的所有frame都读取到本地处理之后，就可以重新进入休眠状态； More Data 以上所描述的低功耗模式的工作流程里，有一个问题：如果在STA休眠期间，AP为STA缓存了多个帧，而不是一个帧的话，应该如何处理？这就是More Data标志的用武之地了。 !Untitled.png More Data是MAC Frame Header的Frame Control Field中的一个标志。 STA向AP发出一个PS-Poll Frame，AP就会给它回一个Data Frame，并根据情况设置这个Data Frame的More Data标志： - 当AP中还有更多缓存帧的话，设置为1，这样STA就需要继续发出PS-Poll Frame，并等待读取下一个缓存的Data Frame，并继续检查More Data标志，直到所有缓存的Data Frame读完，那么最后一个Data Frame的More data标志就会设置为0； - 如果AP中没有更多缓存帧，那么这个More Data标志就是0，同时AP发出的Beacon Frame的TIM中也不会再设置这个STA中有缓存帧的标志；STA在收到这个Data Frame就会了解到AP中没有为自己缓存的帧；这个时候它就可以重新进入休眠状态了； DTIM TIM：Traffic Indication Map； DTIM：Delivery Traffic Indication Map； 每一个Beacon Frame中都包含有TIM信息，但是并非每个beacon帧中都包含DTIM信息。 TIM信息结构体中描述的是AP中为每个STA缓存的单播帧信息，处于休眠状态的STA可以通过TIM信息了解到AP是否有为自己缓存的单播帧； DTIM信息结构体中描述的则是AP中所缓存的组播/广播帧； - 当AP下连接的所有STA都始终处于Wakeup状态，即没有一个STA处于低功耗状态的时候，AP会把所有的广播/组播帧直接向外发送，不会在AP中进行缓存； - 只要AP下连接的一个STA进入低功耗模式，那么AP会先把所有的广播/组播帧缓存起来，等到包含有DTIM信息的Beacon frame发出去后，再把这些缓存的广播/组播帧向整个网络广播出去；广播完成后会继续把新的广播/组播帧缓存起来，等到下一个DTIM周期到来后再发出去； - 如下图所示，AP如果有缓存的广播和组播帧的话，会在每个DTIM Beacon frame发出之后，把这些缓存的广播和组播帧一起发出去，因此如果STA的应用对广播和组播帧的内容感兴趣的话就需要在DTIM Beacon Frame保持唤醒状态等待接收这些广播帧； - !Untitled.png TIM与DTIM信息结构体的组织结构是一样的： !Untitled.png - DTIM Count：表示当前的这个Beacon Frame后面还有几个Beacon Frame里面才包含有DTIM信息；如果这个值为0的话，表示当前的这个Beacon Frame就包含有DTIM信息，否则这个Beacon中包含的是TIM信息； - 是一个倒计时计数值，从DTIM Period开始倒计时为0，周而复始； - DTIM Period：表示每隔几个Beacon Frame有一个包含有DTIM信息，是一个固定数字，可以在AP的设置界面进行设置； - Bitmap Control：1个字节 - bit0：如果是TIM信息，则这个bit为0；如果是DTIM信息，并且AP有缓存的广播/组播帧，则这个bit为1，否则仍然为0； - Bit7-1：与Partial Virtual Bitmap合并在一起表示AP为哪些STA缓存了单播帧； - Partial Virtual Bitmap：2个字节 - 与Bitmap Control的高7bit合并在一起表示AP为哪些STA缓存了单播帧； - 具体的算法可以参考《802.11-2012》Annex O； 另外一种低功耗模式的实现策略 以上所描述的在Beacon的TIM中包含帧缓存标志+PS-Poll获取缓存帧的方式并非是802.11规范提供的唯一一种低功耗实现策略。 一些厂商还提供了另外一种不使用PS-Poll的低功耗实现策略，具体的实现流程如下： - STA在要进入低功耗模式的时候，向AP发出一个空Data frame，把其Power Management bit设置为1，表示这个STA要进入低功耗模式； - 此后AP就会为这个STA缓存要发给这个STA的帧，并在Beacon的TIM域中广播； - STA周期性的唤醒后，不需要等待和关注Beacon Frame中的TIM标志的内容，直接向AP重新发一个空Data frame，把其Power Management bit设置为0，表示它退出低功耗模式； - AP在收到这个空Data Frame以后就会停止为这个STA缓存帧，并立即把之前为这个STA缓存的所有帧发给这个STA； - 如果之前AP没有收到这个STA的缓存帧，就不需要做任何事情； - STA在收到所有的缓存帧以后，就会重新发一个Power Management bit设置为1的空Data frame，重新进入低功耗模式。 参考资料： - 《CWAP WLAN ANALYSIS》第四章； - How to: Get the Most from 802.11 Multicasting - 802.11 – TIM and DTIM Information Elements