WiFi基础学习到实战(六:Beacon帧字段解析)

欢迎大家一起学习探讨通信之WLAN。上节我们基于Android设备分析了WiFi扫描的代码实现，具体执行WiFi网络扫描由WiFi模块实现。WLAN协议定义扫描方式有“被动扫描”和“主动扫描”。本节继续分析“被动扫描”依赖Beacon帧中的字段。

好。我们先来看Android11 WiFi扫描代码部分的一个小细节，与将分析Beacon Body部分时间戳字段有关，它可能造成扫描结果无法在列表上显示。上节分享WiFi扫描流程中，框架处理WiFi扫描命令时，会调用到startSingleScan()方法。

在该方法中，通过mClock.getElapsedSinceBootMillis()->SystemClock.elapsedRealtime()方法获取系统时间，并赋值给mLastScanSettings.startTime成员。

public boolean startSingleScan(WifiNative.ScanSettings settings,
        WifiNative.ScanEventHandler eventHandler) {
            ......
            mLastScanSettings = new LastScanSettings(
            mClock.getElapsedSinceBootMillis(),
            reportFullResults, allFreqs, eventHandler);
            ......
        }
}

在扫描完成后，框架处理WiFi扫描结束事件时，将调用pollLatestScanData()方法获取扫描结果。将通过getScanResult()获取扫描到的每一个WiFi网络实例。

这里很重要的一个点是“将用获取到WiFi网络实例中的时间戳(timestamp_ms)和startTime进行比较”。

如果其大于startTime则将WiFi网络加入到扫描结果列表中；若其小于则忽略该网络，将导致WiFi网络无法被正常扫描识别。

private void pollLatestScanData() {
            ......
            mNativeScanResults = mWifiNative.getScanResults(getIfaceName());
            List<ScanResult> singleScanResults = new ArrayList<>();
            int numFilteredScanResults = 0;
            for (int i = 0; i < mNativeScanResults.size(); ++i) {
                ScanResult result = mNativeScanResults.get(i).getScanResult();
                long timestamp_ms = result.timestamp / 1000; // convert us -> ms
                if (timestamp_ms > mLastScanSettings.startTime) {
                    if (mLastScanSettings.singleScanFreqs.containsChannel(
                                    result.frequency)) {
                        singleScanResults.add(result);
                    }
                } else {
                    numFilteredScanResults++;
                }
            }
            if (numFilteredScanResults != 0) {
                Log.d(TAG, "Filtering out " + numFilteredScanResults + " scan results.");
            }
}

在什么情况下会出现以上所述WiFi网络被忽略的情况呢？

回到这个问题，要追踪到扫描网络实例的时间戳。该时间戳来自每个WiFi网络的Beacon帧和probe respons帧的时间戳，与路由器有很大关系，如路由器断电重启，其值就会变化。

因此，如WiFi模块直接将扫描Beacon帧的内容上报，在Android上就会存在网络被忽略的情况。

解决方法：

在linux或WiFi框架将扫描网络实例时间戳重新赋值为自系统起来后的时间。对应到linux中的时间类型为CLOCK_BOOTTIME，可通过ktime_get_boottime()方法获取。

好。接下来继续分析Beacon帧的内容，如下图Beacon抓包实例。Beacon帧Body分为两种类型：字段(Fields)和元素(Elements)。

Beacon帧中的Field字段，如下图所示。

(1)时间戳字段(Timestamp field)

表示发送该帧的源设备时间同步功能，其值单位为us，占用8个字节。该字段有以下特点：

一般该值代表路由器时间戳值，表明自网络工作以来经过的微秒数。
时间戳值达到最大值后，其值将从0重新开始。因其占8个字节，需要经过580000年才可能发生。
WiFi网络中设备通过该时间戳调整网络设备时间钟。在TWT，设备PS功能等都会用到。

(2)Beacon间隔字段(Beacon Interval field)

表示Beacon传输间隔时间，其值单位为TUs，占用2个字节。一般默认值为100。

如 a DMG 设备发送的Beacon间隔字段值为0时，表明下一个TBTT的TBI是未知的。

注：协议规范【原文】

A 0 in the Beacon Interval field transmitted by a DMG STA indicates that the TBTT of the next BTI isunknown.

(3)网络能力信息字段(Capability Information field)

表示当前WiFi网络的能力信息，占用2个字节。较其他字段比较复杂，协议定义Bit位含义如下图所示。

以上表示的feature大部分可选实现。

ESS(B0)：表示Beacon是否来自AP。
IBSS(B1)：表示Beacon是否来自一个IBSS设备。
Privacy(B4)：表示WiFi网络中是否所有数据帧都需要加密。

Slot Time和SIFS用于帧间隔时间值。802.11和802.11b协议定义标准的slot time为 20u。802.11g协议定义slot time为9us，即为short slot time，同时也表示WiFi网络是否支持802.11g。

关于该标志位有以下特定：

有一个不支持short slot time的设备加入网络，则整个WiFi网络应表示不支持short slot time。
IBSS网络不支持short slot times，short slot time应被设置为0。

接下来分析Beacon帧中的Elements元素。

[1]SSID element：

协议定义格式如下图。element ID为0。SSID最大长度32个字符。当长度为0时，指SSID通配符。

[2]Rates Element：

协议定义格式如下图。element ID为1。最大长度为8，即最多可表示支持8种速率，每个速率对应1个字节

WLAN协议将速率分为基本速率和传输速率。基本速率对应字节的Bit(7)为1，其值乘500kb/s，即为对应的速率。

下图为Beacon帧中速率实例，如82：1000 0010，bit7=1，基本速率；bit0-bit6值为2, 2 * 500kb/s = 1Mb/s。

任何一个加入WiFi网络的设备，都需要全部支持该网络的基本速率。因基本速率是协议定义默认的一些调制方式，该网络中的设备都要可以解析，保证设备间的通信顺畅。

[3]DSSS Parameter Set element：

协议定义格式和实例如下图，element ID为3。包含当前网络工作的信道，让设备识别当前网络信道。

[4]Traffic Indication Map(TIM) element：

协议定义格式如下图所示，element ID为5。其他字段解析如下。

DTIM Count：表示下一个DTIM出现，需要经过几个Beacon帧(包括当前Beacon)。其值为0，表示当前TIM是DTIM。
DTIM Period：表示连续DTIM的间隔Beacon帧数。该间隔与AP的配置有关。其值为1，表示TIM都为DTIM。
Bitmap Control：表示路由器侧有无缓存的广播或组播包。
Partial Virtual Bitmap：表示路由器侧是否缓存有对应WiFi设备的数据包。

路由器利用Beacon帧中，DTIM字段通知整个网络当前缓存广播或组播帧状态。在发送每个DTIM的Beacon帧时，要求WiFi网络内的设备处于唤醒接收状态。

DTIM包含在TIM字段内，通常将TIM也叫做DTIM。关于Partial Virtual Bitmap字段，后面我们专用一节对其计算生成方法进行分享。下图是实例DTIM字段，指示当前路由器有缓存广播或组播包，且为AID为0x09的设备缓存有数据包。

注：协议规定【原文】

1.The DTIM Count field indicates how many Beacon frames (including the current frame) appear before thenext DTIM. A DTIM count of 0 indicates that the current TIM is a DTIM.

2.The Bitmap Control field is a single octet. Bit 0 of the field contains the Traffic Indicator bit associated withAID 0. This bit is set to 1 in TIM elements with a value of 0 in the DTIM Count field when one or more group addressed MSDUs/MMPDUs are buffered at the AP or the mesh STA. The remaining 7 bits of thefield form the Bitmap Offset.

[5]Country element

协议定义格式如下图所示，element ID为7。该元素可从实例字面意思理解。关于Environment字段重点分析下。

有些国家对WLAN网络室内和室外的信道、功率等有不同的要求。因此利用该字段识别当前环境。关于信道介绍可参考【第七节：通信之WLAN(信道)】。

“O”：室外环境。
“I”：室内环境。
“ ”：不对环境区分。

注：协议规范【原文】

country code as described in document ISO/IEC 3166-1. The third octet shall be one of the following:

1. an ASCII space character, if the regulations under which the station is operating encompass all environments in the country,

2. an ASCII 'O' character, if the regulations under which the station is operating are for an Outdoor environment only.

3. an ASCII 'I' character, if the regulations under which the station is operating are for an Indoor environment only.

4. an ASCII 'X' character, if the station is operating under a non-country entity. The first two octets of the non-country entity shall be two ASCII 'XX' characters."

[6]Power Constraint element

协议定义格式如下图所示，element ID为32。该元素与802.11h相关，有些地区国家要求发送功率最大值，因此，用其通知网络内设备可在该信道使用的最大发送功率。

[7]TPC Report element

协议定义格式如下图所示，element ID为35。该元素与802.11h相关。其元素解析见下：

Transmit Power：表明当前发送该帧的实际传送功率。
Link Margin：表明链路余量情况，根据接收包含TPC Request element帧的时间和接收速率计算所得。其在Beacon帧中做为保留位。

注：协议规范【原文】

The Link Margin field is reserved when a TPC Reportelement is included in a Beacon frame or Probe Response frame.

[8]AP Channel Report element

协议定义格式如下图所示，element ID为51。指明WiFi网络内在哪些信道可能发现该AP。仅会表明一个Operation class对应的多个信道。

抓包实例如下图所示。

[9]ERP element

协议定义格式如下图所示，element ID为42。ERP参数占1个字节，每个bit位指明含义如下解释。由于802.11b协议和早期802.11协议版本，不能与802.11g定义的ERP-OFDM 数据速率通信。

因此，需要WiFi网络表明其是否要用保护机制，改善WiFi网络的性能，是否可以使用长前导序列或短前导序列。

NonERP_Present(B0)：表明WiFi网络中是否有仅支持802.11b协议或早期802.11的设备。有存在，则设置为1。
Use_Protection(B1)：表明WiFi网络是否启用保护机制。
Barker_Preamble_Mode(B2):表明WiFi网络是否可以使用短前导序列。如有一个802.11b的设备，则设置为1。

关于ERP的基本服务集中，有以下几种场景都会触发保护机制：

一个802.11b的设备连接到WiFi网络，将触发保护机制。
一个ERP的AP听到附近的Beacon只支持802.11b或早期802.11 DSSS速率时，将触发网络内的保护机制。
一个ERP的AP听到附近的管理帧其只支持802.11b或802.11 DSSS速率时，将触发网络内的保护机制。

从上可知，802.11b的设备会对附近802.11g的网络造成影响，网络内的保护机制触发后，影响网络整体吞吐速率。

[10]Extended Supported Rates element

协议定义格式如下图所示，element ID为50。该元素字段表明设备支持的速率不能完全携带在支持速率的元素中。信息元素1-255个字节，每个字节可描述支持一个速率。

前7bit(0-6)数值以500Kbps为单位，表示速率大小，最高位表示是否为基本速率。该字段仅当支持的速率大于8个时，才会被使用。

[11]Overlapping BSS Scan Parameters element

协议定义格式如下图所示，element ID为72。该元素参数基于Android代码有详细的分析，见【第二十节：通信之WLAN(OBSS)】。此处不做分析，抓包元素实例如下。

本节基于扫描网络实例的时间戳，分享了可能存在WiFi列表上无法显示正常WiFi网络的情况，并对Beacon帧中的Field字段和Element字段进行了详细解读，大家应该发现Beacon帧中还有HT和HE等Element，其内容比较多，为了专栏课节间的连续性，后续单独对其详细解读。WiFi基础学习到实战(六)探讨就到此，后续期待共同继续探讨学习。

注：

对以上所述专业知识有修正意见或建议，可随时留言反馈。如感兴趣更多通信知识，可关注“通信之WLAN” for WeChat 公众号。

谢谢大家支持~！