Akin, why is the code in this branch at all if DSSS modulation is being used?

Thomas, I am not sure why you ask me this but I thought DSSS modulation was used in 802.11b for very low SINR values? In my case though, this ASSERT was hit for a STA using 802.11n or 802.11ac, I do not remember which standard exactly though.

Your fix is NOK, we can have DSSS even for 802.11n, in the 2.4 GHz bands.
The reason is backward compatibility. Whether or not using a DSSS rate when 2 802.11n stations are communicating is up to the rate manager.
We actually need to investigate why this assert pops up, I will try to have a look over the weekend.

Right, I had this problem at 802.11n at 2.4 GHz. The problem happens because the symbol duration is not taken care of for DSSS modes before the ASSERT:


----
  Time symbolDuration = Seconds (0);
  switch (payloadMode.GetModulationClass ())
    {
    case WIFI_MOD_CLASS_OFDM:
    case WIFI_MOD_CLASS_ERP_OFDM:
      {
        //(Section 18.3.2.4 "Timing related parameters" Table 18-5 "Timing-related parameters"; IEEE Std 802.11-2012
        //corresponds to T_{SYM} in the table)
        switch (txVector.GetChannelWidth ())
          {
          case 20:
          default:
            symbolDuration = MicroSeconds (4);
            break;
          case 10:
            symbolDuration = MicroSeconds (8);
            break;
          case 5:
            symbolDuration = MicroSeconds (16);
            break;
          }
        break;
      }
    case WIFI_MOD_CLASS_HT:
    case WIFI_MOD_CLASS_VHT:
      {
        //if short GI data rate is used then symbol duration is 3.6us else symbol duration is 4us
        //In the future has to create a stationmanager that only uses these data rates if sender and receiver support GI
        uint16_t gi = txVector.GetGuardInterval ();
        NS_ASSERT (gi == 400 || gi == 800);
        symbolDuration = NanoSeconds (3200 + gi);
      }
      break;
    case WIFI_MOD_CLASS_HE:
      {
        //if short GI data rate is used then symbol duration is 3.6us else symbol duration is 4us
        //In the future has to create a stationmanager that only uses these data rates if sender and receiver support GI
        uint16_t gi = txVector.GetGuardInterval ();
        NS_ASSERT (gi == 800 || gi == 1600 || gi == 3200);
        symbolDuration = NanoSeconds (12800 + gi);
      }
      break;
    default:
      break;
    }
-----

So symbolDuration says initialized at 0 seconds. After some calculations, this is what is causing the assert. However, skipping this calculation is perfectly OK for DSSS modes because DSSS mode does not use the outcome of calculation (numSymbols in this case) for returning the payload duration value, which just depends on the payloadMode.

----
    case WIFI_MOD_CLASS_DSSS:
    case WIFI_MOD_CLASS_HR_DSSS:
      return MicroSeconds (lrint (ceil ((size * 8.0) / (payloadMode.GetDataRate (22) / 1.0e6))));
----

My simulation ended without a problem after this fix, no functionality is lost but of course there might be an easier way. In summary, the following calculation should actually never be done for DSSS modes:

numSymbols = lrint (stbc * ceil ((16 + totalAmpduSize * 8.0 + 6 * Nes) / (stbc * numDataBitsPerSymbol)));

Can you provide a script to reproduce the issue? I want to work on a clean solution.

Akin, can you please provide me a way to reproduce the assert?

I will try to give you a clean script within this week. What it does in summary is this:

There is one 802.11ac STA close by and another 802.11n STA that is moving away from the AP at a speed of 1 m/s. The traffic is either bulk TCP or UDP.

I am not sure if I can reproduce it with the script but I will try.

I managed to reproduce the error again with the attached script. Command to run:

./waf --run 'scratch/test-script-wifi-phy --simulationTime=250 --ideal=1 --fading=0 --udp=0 --nWifiAp=2 --speed=1.0 --suppressAp2=1 --distance=63 --distance2=63 --nssAp=3 --nssSta1=3 --nssSta2=1'

And the backtrace I got from gdb:
assert failed. cond="m_totalAmpduNumSymbols <= numSymbols", file=../src/wifi/model/wifi-phy.cc, line=2224
terminate called without an active exception

Program received signal SIGABRT, Aborted.
0x00007fffeb81d428 in __GI_raise (sig=sig@entry=6)
    at ../sysdeps/unix/sysv/linux/raise.c:54
54	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007fffeb81d428 in __GI_raise (sig=sig@entry=6)
    at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007fffeb81f02a in __GI_abort () at abort.c:89
#2  0x00007fffec37d84d in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007fffec37b6b6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007fffec37b701 in std::terminate() ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff62ec5dd in ns3::WifiPhy::GetPayloadDuration (this=0x6e0000, 
    size=94, txVector=..., frequency=2437, 
    mpdutype=ns3::LAST_MPDU_IN_AGGREGATE, incFlag=0 '\000')
    at ../src/wifi/model/wifi-phy.cc:2224
#6  0x00007ffff62ed2e9 in ns3::WifiPhy::CalculateTxDuration (this=0x6e0000, 
    size=94, txVector=..., frequency=2437, 
    mpdutype=ns3::LAST_MPDU_IN_AGGREGATE, incFlag=0 '\000')
    at ../src/wifi/model/wifi-phy.cc:2313
#7  0x00007ffff6369f45 in ns3::MacLow::ForwardDown (this=0x6dbfb0, packet=..., 
    hdr=0x6dc128, txVector=...) at ../src/wifi/model/mac-low.cc:1602
#8  0x00007ffff636f4e0 in ns3::MacLow::SendDataPacket (this=0x6dbfb0)
    at ../src/wifi/model/mac-low.cc:1942
#9  0x00007ffff635f818 in ns3::MacLow::StartTransmission (this=0x6dbfb0, 
    packet=..., hdr=0x6dec88, params=..., dca=...)
    at ../src/wifi/model/mac-low.cc:748
---Type <return> to continue, or q <return> to quit---
#10 0x00007ffff64a849f in ns3::EdcaTxopN::NotifyAccessGranted (this=0x6dec10)
    at ../src/wifi/model/edca-txop-n.cc:353
#11 0x00007ffff63cf9ce in ns3::DcfState::NotifyAccessGranted (this=0x6de790)
    at ../src/wifi/model/dcf-state.cc:186
#12 0x00007ffff63c670c in ns3::DcfManager::DoGrantAccess (this=0x6dd130)
    at ../src/wifi/model/dcf-manager.cc:373
#13 0x00007ffff63c6a2d in ns3::DcfManager::AccessTimeout (this=0x6dd130)
    at ../src/wifi/model/dcf-manager.cc:390
#14 0x00007ffff63cd461 in ns3::EventImpl* ns3::MakeEvent<void (ns3::DcfManager::*)(), ns3::DcfManager*>(void (ns3::DcfManager::*)(), ns3::DcfManager*)::EventMemberImpl0::Notify() (this=0x6c91c0) at ./ns3/make-event.h:376
#15 0x00007fffef1dc84d in ns3::EventImpl::Invoke (this=0x6c91c0)
    at ../src/core/model/event-impl.cc:51
#16 0x00007fffef1e1cdd in ns3::DefaultSimulatorImpl::ProcessOneEvent (
    this=0x6bff70) at ../src/core/model/default-simulator-impl.cc:149
#17 0x00007fffef1e20f1 in ns3::DefaultSimulatorImpl::Run (this=0x6bff70)
    at ../src/core/model/default-simulator-impl.cc:202
#18 0x00007fffef1dda81 in ns3::Simulator::Run ()
    at ../src/core/model/simulator.cc:230
#19 0x000000000041b77c in main (argc=13, argv=0x7fffffffda28)
    at ../scratch/tri-band-evaluation-test1b-sebastien.cc:473

Created attachment 2915 [details]
test script

Which version did you use?
I get this error in ns-3-dev:
msg="Could not set default value for ns3::RegularWifiMac::VO_MaxAmpduSize", file=../src/core/model/config.cc, line=779
libc++abi.dylib: terminating

Created attachment 2916 [details]
Updated test script

I actually tested this against my checked out version of ns-3-dev but it seems there was an update. It should be working now.

Already fixed in ns-3-dev.