NS-3源码学习（五）手搓一个multi-Link的WiFi7系统

目的

   <--Channel - 0-- 
AP                  STA
   <--Channel - 1-

创建一个一AP，一STA的系统，这两个结点通过同一载波频率。同一信道宽度但不同的中心频率的两个不同信道号的信道相连，观察数据传输的过程。

就结果来看，虽然是muti-Link了，但是在运用上是交替的使用这两个Link，数据传输速率并没有提升。

杂记

src/propagation/model/propagation-loss-model.h
- 这里存放了一些信号损失模型，在Channel中添加这些损耗模型有助于使仿真更加真实
- 本人思考：重要的是，可以利用这些损失模型来人为的制造一些干扰、信号错误，来观察WiFi7的应对策略
- 向Channel中添加模型：
```
Ptr<MultiModelSpectrumChannel> spectrumChannel = CreateObject<MultiModelSpectrumChannel>();
Ptr<LogDistancePropagationLossModel> lossModel = CreateObject<LogDistancePropagationLossModel>();
spectrumChannel->AddPropagationLossModel(lossModel);
```
- 尚未学习：
1. 当前ns-3中已经有了哪些模型？他们的作用是什么
2. 如何正确的去设置这些模型的参数
3. 如果想要自建一个模型，应该怎么去做？重写哪些函数？返回怎样的数据？
两个信道和多个信道的实验：

我先写了一个含有两个信道的物理层，两个信道分别为：
```
std::string channelLink0 =
        "{36, 20, BAND_5GHZ, 0}"; // {channel number, channel width (MHz), PHY band, primary20
                                // index} from wifi-phy.cc
std::string channelLink1 =
    "{40, 20, BAND_5GHZ, 0}"; // {channel number, channel width (MHz), PHY band, primary20
                            // index} from wifi-phy.cc
```
然后又使用了一个信道和其做对比，一个信道的参数为：
```
std::string channelLink0 =
        "{36, 20, BAND_5GHZ, 0}"; // {channel number, channel width (MHz), PHY band, primary20
                                // index} from wifi-phy.cc
// std::string channelLink1 =
//     "{40, 20, BAND_5GHZ, 0}"; // {channel number, channel width (MHz), PHY band, primary20
//                               // index} from wifi-phy.cc
```
经过测试，发现双信道会输出2*2个pcap文件，第一个2代表ap和sta，第二个2通过阅读pcap文件发现，代表了两个信道，而且这两个文件的大小非常接近，几乎都是90，000kB左右。

而单信道仅输出了1*2个pcap文件，该文件大小约为174，000kB，大约是上述两个pcap文件的和

阅读双信道输出，可以得到如下结果：
- 我在双信道仿真代码中添加了如下信息：
```
std::cout << "Number of apDevice " << apDevice.GetN() << std::endl; 
std::cout << "Number of staDevices " << staDevices.GetN() << std::endl;
```
```
Server IP address: 192.168.1.1
Server MAC address: 03-06-00:00:00:00:00:01
Client IP address: 192.168.1.2
Client MAC address: 03-06-00:00:00:00:00:04
Number of apDevice 1
Number of staDevices 1
MCS value               Channel width           GI                      Throughput
13                      20 MHz                  3200 ns                 123.287 Mbit/s
```
- 出现的mac地址有：
  - 01
  - 02
  - 03
  - 04
  - 05
  - 06
- 广播信标帧的mac地址有：
  - 06：使用40Channel
  - 05：使用36Channel
- 使用36Channel的有：
  - 05：发送信标帧
  - 02：向05请求连接，Association request
  - 04：这个含有04的数据帧中，地址字段如下：该数据帧为ARP广播数据帧，来源是04，经过05进行转发广播
```
IEEE 802.11 QoS Data, Flags: ......F.C
    Type/Subtype: QoS Data (0x0028)
    Frame Control Field: 0x8802
    .000 0000 0000 0000 = Duration: 0 microseconds
    Receiver address: Broadcast (ff:ff:ff:ff:ff:ff)
    Transmitter address: Xerox_00:00:05 (00:00:00:00:00:05)
    Destination address: Broadcast (ff:ff:ff:ff:ff:ff)
    Source address: Xerox_00:00:04 (00:00:00:00:00:04)
    BSS Id: Xerox_00:00:05 (00:00:00:00:00:05)
    STA address: Broadcast (ff:ff:ff:ff:ff:ff)
    .... .... .... 0000 = Fragment number: 0
    0000 0001 0101 .... = Sequence number: 21
    Frame check sequence: 0x00000000 [unverified]
    [FCS Status: Unverified]
    [WLAN Flags: ......F.C]
    Qos Control: 0x0020
```
- 使用40Channel的有：
  - 06：发送信标帧
  - 03：
    - 向06发送了Null function帧，而后06回复了ack
    - 回复ARP协议的请求，信息中显示要寻找的ip地址在01这个mac地址
  - 04：
    - 在40号信道上，使用04的帧有以下三种：
    - ARP广播帧，源是04，但经过了06的转发
    - ARP回复帧，源是03，目的是04，但接收者是06，该回复帧出现了两次，两次的不同在于：
      1. 字段radiotap.ampdu.flags.last，后一个指示该帧为A-MPDU最后一个帧
        
        .... .... .... 0... = This is the last subframe of this A-MPDU: False .... .... .... 1... = This is the last subframe of this A-MPDU: True
      2. 数据帧的序列号wlan.seq
- 经过上述实验，可以看到ns-3对于单设备多信道的仿真结构如下图所示：
  - 其中，对于WiFi的认证和回复（Association request和Association response）仅在channel 36的两个mac上进行
  - 对于信标帧的广播，ap在两个channel上的mac（05和06）都会进行广播
  - 然后开始UDP通信，本次通信过程中可以看到miss了一些包
  - 但并不懂为何会miss，除了添加了新的channel之外，其他部分都是照抄的example文件，example文件仿真的结果中并没有miss
  - 被miss的包在block ack后被重新发送，而且在重新发送的时间段中还发送了新的数据帧
  - 这里有一个问题，本次udp通信的长度并没有达到块确认请求中请求的缓冲区大小，即被提前块确认了
    - 猜测应该有一个字段指示要求立刻进行确认，但是我还没有找到这个字段
    - 也有可能接收端的等待时间达到阈值，自动触发了block ack
  - 在UDP通信中可以看到两个信道交替发送数据，而不是同时发送数据
    - 可能是因为我仅建立了一个UDP连接，下次尝试建立多个UDP连接，看看能不能同时发数据
  - 在UDP通信中，无论是在36号信道上，还是在40号信道上，源mac地址是一致的，但目的mac地址有所不同
    - Source address均为04
    - 在36信道上，目的mac地址是02，经过了05的转发
    - 在40信道上，目的mac地址是03，经过了06的转发
    - 这两个信道上的目的mac地址都不是01，而根据arp数据包的内容来看，目的ip地址对应的mac地址是01。这个在40信道上还好解释，因为是03回复的arp广播，因此建立mac表的时候将目的ip映射到03上很合理，但36信道上为何会发给02就很意外，并没有帧告知02和01相关联
    - 下次尝试在同一个信道中接入多台设备，观察UDP数据包的目的mac地址会发生什么变化