NS-3源码学习（三）Pcap文件分析
Pcap文件生成
NS-3生成.pcap文件
相关函数有EnablePcap()和EnalePcapAll(),
-
支持第一个函数的类有ns3::YansWifiPhyHelper PointToPoint EmuHelper CsmaHelper
-
支持第二个函数的类有ns3::YansWifiPhyHelper PointToPoint InternetStackHelper EmuHelper CsmaHelper
用法：PointToPointHelper::EnablePcapAll("p2p") 或者
PointToPointHelper phy;
phy.EnablePcap("p2p",p2pDevice.Get(0));
可以对节点生成，也可以是netDevice等
wifi 7
使用examples/wireless/wifi-eht-network.cc该文件进行对wifi 7通信的仿真。该文件会循环进行不同MCS值，不同channelWidth以及不同gi的仿真。为缩短仿真时间，修改掉循环，让其每次仅对特定的mcs，channelWidth和gi进行仿真
在仿真开始之前添加Pcap输出语句：
std::string pcapFileName = "wifi-eht-network-mcscwgi" + std::to_string(mcs) + "MCS" +
std::to_string(channelWidth) + "MHz" +
std::to_string(gi) + "ns";
phy.EnablePcap(pcapFileName,staDevices,true);
Simulator::Stop(Seconds(simulationTime + 1));
Simulator::Run();
运行仿真，可以得到相应的Pcap文件
WiFi 6
由于在WiFi 6的仿真文件中中，phy的选择有两个，添加了一次判断去选择是"Spectrum"还是YansWifiPhyHelper，因此将Pcap允许语句添加至条件体之中：
apDevice = wifi.Install(phy, mac, wifiApNode);
phy.EnablePcap(pcapFilename,staDevices, true);
···
apDevice = wifi.Install(phy, mac, wifiApNode);
phy.EnablePcap(pcapFilename,staDevices, true);
这样就能得到相应的Pcap文件，并于WiFi 7的Pcap文件进行对比
Pcap文件分析
WiFi6还是WiFi7
可能是由于wireshark版本的问题，对于WiFi6的数据帧可以正确的识别其版本为802.11be，但WiFi 7却被识别为802.11a，而且无法正确识别OFDMA，仅会显示OFDM。
判断：
对于802.11ax帧来说，在radiotap字段中含有一个特殊的字段：HE information，wireshark通过这个字段的填充情况就能区分出该帧是WiFi 6和不是WiFi 6，然而WiFi 7中并不含有特殊的字段，因此无法进行协议版本的判断。
但是，对于AP来说，需要广播自己支持的协议，这样才能让请求连接的STA知道自己是否能够接入这个网络，因此通过分析AP广播的帧，就能判断出出这确实是一个WiFi 7的仿真结果：
AP广播的帧：
IEEE 802.11 Wireless Management
Fixed parameters (12 bytes)
Tagged parameters (188 bytes)
Tag: SSID parameter set: "ns3-80211be"
Tag: Supported Rates 6(B), 9, 12(B), 18, 24(B), 36, 48, 54, [Mbit/sec]
Tag: Extended Supported Rates Unknown Rate, [Mbit/sec]
Tag: EDCA Parameter Set
Tag: HT Capabilities (802.11n D1.10)
Tag: HT Information (802.11n D1.10)
Tag: Extended Capabilities (8 octets)
Tag: VHT Capabilities
Tag: VHT Operation
Ext Tag: HE Capabilities
Ext Tag: HE Operation
Ext Tag: EHT Capabilities (802.11be D3.0)
Ext Tag: EHT Operation (802.11be D3.0)
STA请求建立链接时的帧：
IEEE 802.11 Wireless Management
Fixed parameters (4 bytes)
Tagged parameters (120 bytes)
Tag: SSID parameter set: "ns3-80211be"
Tag: Supported Rates 6, 9, 12, 18, 24, 36, 48, 54, [Mbit/sec]
Tag: Extended Supported Rates Unknown Rate, [Mbit/sec]
Tag: HT Capabilities (802.11n D1.10)
Tag: Extended Capabilities (8 octets)
Tag: VHT Capabilities
Ext Tag: HE Capabilities
Ext Tag: EHT Capabilities (802.11be D3.0)
Ext Tag length: 15 (Tag len: 16)
Ext Tag Number: EHT Capabilities (802.11be D3.0) (108)
EHT MAC Capabilities Information: 0x0000, Maximum MPDU Length: 3 895, EHT Link Adaptation Support: No feedback
EHT PHY Capabilities Information
Supported EHT-MCS and NSS Set
EHT-MCS Map (BW <= 80MHz): 0x111111
.... .... .... .... .... 0001 = Rx Max Nss That Supports EHT-MCS 0-9: 1
.... .... .... .... 0001 .... = Tx Max Nss That Supports EHT-MCS 0-9: 1
.... .... .... 0001 .... .... = Rx Max Nss That Supports EHT-MCS 10-11: 1
.... .... 0001 .... .... .... = Tx Max Nss That Supports EHT-MCS 10-11: 1
.... 0001 .... .... .... .... = Rx Max Nss That Supports EHT-MCS 12-13: 1
0001 .... .... .... .... .... = Tx Max Nss That Supports EHT-MCS 12-13: 1
但是这里有一个问题，我暂时还没有分析出来二者是如何进行信道选择的沟通的。因为NS-3仿真中对于Channel的选择是在仿真之前就配置好的，并非是仿真开始后STA与AP进行协商的结果。
不过好像市面上的路由器也是用户手动的选择信道：TP-Link：如何正确设置路由器无线信号的信道？
WiFi连接的建立
可以通过对Pcap文件的分析，得到WiFi系统建立连接的过程：
-
广播Beacon Frame，Beacon帧是Wi-Fi网络中的重要管理帧，通过周期性地广播这些帧，接入点能够告知附近的设备有关网络的基本信息，从而支持设备的连接和通信。
-
展开该数据帧，可以看到下述信息：
IEEE 802.11 Wireless Management Fixed parameters (12 bytes) Timestamp: 0 Beacon Interval: 0.102400 [Seconds] Capabilities Information: 0x0001 Tagged parameters (188 bytes) Tag: SSID parameter set: "ns3-80211be" Tag: Supported Rates 6(B), 9, 12(B), 18, 24(B), 36, 48, 54, [Mbit/sec] Tag: Extended Supported Rates Unknown Rate, [Mbit/sec] Tag: EDCA Parameter Set Tag: HT Capabilities (802.11n D1.10) Tag: HT Information (802.11n D1.10) Tag: Extended Capabilities (8 octets) Tag: VHT Capabilities Tag: VHT Operation Ext Tag: HE Capabilities Ext Tag: HE Operation Ext Tag: EHT Capabilities (802.11be D3.0) Ext Tag: EHT Operation (802.11be D3.0)上述描述信息中可以看到该AP支持802.11be D3.0版本的接入
-
STA发送Association Request帧请求与AP建立连接 - AP回复ACK
-
STA广播CF-End帧通知其他设备释放信道资源
-
AP发送Association Response帧通知STA建立连接 - STA回复ACK
-
AP广播CF-End通知其他设备释放信道资源
-
ARP协议过程：
在本仿真中，AP作为UDP数据发送端，STA作为UDP数据的接收端，因此ARP询问的广播由AP发起，STA响应
-
发送端和接收端协商为block ack准备的缓冲区大小
通过对Pcap的分析可以发现，该缓冲区的大小是由数据的接收方指定的，也就是数据接收方通知发送方：
Block Ack Parameters: 0x1003, A-MSDUs, Block Ack Policy .... .... .... ...1 = A-MSDUs: Permitted in QoS Data MPDUs .... .... .... ..1. = Block Ack Policy: Immediate Block Ack .... .... ..00 00.. = Traffic Identifier: 0x0 0001 0000 00.. .... = Number of Buffers (1 Buffer = 2304 Bytes): 64 -
数据发送端发送数据
在最后的一帧数据中指定要求数据接收端立即回复块确认：
这是非最后一帧数据：
Radiotap Header v0, Length 32 Header revision: 0 Header pad: 0 Header length: 32 Present flags MAC timestamp: 1007551 Flags: 0x10 Data Rate: 18.0 Mb/s Channel frequency: 5180 [A 36] Channel flags: 0x0140, Orthogonal Frequency-Division Multiplexing (OFDM), 5 GHz spectrum Antenna signal: -31 dBm Antenna noise: -94 dBm A-MPDU status A-MPDU reference number: 1 A-MPDU flags: 0x0004 .... .... .... ...0 = Driver reports 0-length subframes in this A-MPDU: False .... .... .... ..0. = This is a 0-length subframe: False .... .... .... .1.. = Last subframe of this A-MPDU is known: True .... .... .... 0... = This is the last subframe of this A-MPDU: False .... .... ...0 .... = Delimiter CRC error on this subframe: False .... .... .0.. .... = EOF on this subframe: False .... .... 0... .... = EOF of this A-MPDU is known: False这是最后一帧数据：
Radiotap Header v0, Length 32 Header revision: 0 Header pad: 0 Header length: 32 Present flags MAC timestamp: 1007551 Flags: 0x10 Data Rate: 18.0 Mb/s Channel frequency: 5180 [A 36] Channel flags: 0x0140, Orthogonal Frequency-Division Multiplexing (OFDM), 5 GHz spectrum Antenna signal: -31 dBm Antenna noise: -94 dBm A-MPDU status A-MPDU reference number: 1 A-MPDU flags: 0x000c .... .... .... ...0 = Driver reports 0-length subframes in this A-MPDU: False .... .... .... ..0. = This is a 0-length subframe: False .... .... .... .1.. = Last subframe of this A-MPDU is known: True .... .... .... 1... = This is the last subframe of this A-MPDU: True .... .... ...0 .... = Delimiter CRC error on this subframe: False .... .... .0.. .... = EOF on this subframe: False .... .... 0... .... = EOF of this A-MPDU is known: False -
块确认：通过一张bit图对之前发送过的数据进行确认，bit图的大小为块缓冲区的大小，对于每一个bit，取1代表正确收到，取0代表丢失（或错误）
IEEE 802.11 802.11 Block Ack, Flags: ........C Type/Subtype: 802.11 Block Ack (0x0019) Frame Control Field: 0x9400 .000 0000 0000 0000 = Duration: 0 microseconds Receiver address: Xerox_00:00:02 (00:00:00:00:00:02) Transmitter address: Xerox_00:00:01 (00:00:00:00:00:01) Compressed BlockAck Response Block Ack Control: 0x0004 Block Ack Starting Sequence Control (SSC): 0x0000 Block Ack Bitmap: ffffffffffff3f00 Missing frame: 54 Missing frame: 55 Missing frame: 56 Missing frame: 57 Missing frame: 58 Missing frame: 59 Missing frame: 60 Missing frame: 61 Missing frame: 62 Missing frame: 63 Frame check sequence: 0x00000000 [unverified] [FCS Status: Unverified] [WLAN Flags: ........C]