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

目的

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

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

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

杂记

1. 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. 如果想要自建一个模型，应该怎么去做？重写哪些函数？返回怎样的数据？

2. 两个信道和多个信道的实验：

   我先写了一个含有两个信道的物理层，两个信道分别为：

   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地址会发生什么变化

代码

https://gitee.com/zgBCQ/ns-3_scratch/blob/master/StaApLinkLink.cc