MeshHelper issues with HtSupported and MinstrelWifiManager

[Federico Tramarin]

Dear all,

I am experiencing issues with the MeshHelper class.

Specifically, I modified the mesh example in order to enable support for 802.11n 5GHz standard.

Quite simple.

mesh.SetStandard(WIFI_PHY_STANDARD_80211n_5GHZ);

however, setting a line such as

mesh.SetRemoteStationManager ("ns3::MinstrelWifiManager");

or better 

mesh.SetRemoteStationManager ("ns3::MinstrelHtWifiManager");

produces an error

assert failed. cond="duration >= MicroSeconds (0)", msg="Please provide test case to maintainers if this assert is hit.", file=../src/wifi/model/mac-low.cc, line=2376

libc++abi.dylib: terminating

The same happens if I set the HtSupported attribute of the mac type in the mesh helper

mesh.SetMacType ("RandomStart", TimeValue (Seconds (m_randomStart)),

                   "HtSupported", BooleanValue (true) );

I actually already looked at other discussion in this forum, and looked at the classes.

The APIs said that HtSupported parameter is inherited by MeshHelper, and as such I do not understand the error.

Moreover, I think that both errors (Ht and Minstrel) are actually related.

Can you help me with this issue, please?

I am using the latest stable release (3.25) built from scratch.

Thank you for your help

Cheers

Federico

[Tommaso Pecorella]

Hi,

please try with ns-3-dev. Moreover, check if there is already an open bug on our bugzilla.

Thanks,

T.

[Federico Tramarin]

First of all.

A clarification: setting wifi standard to 80211n alone seems to work. The issue arises if I forcibly set HtSupported or if I request Minstrel as a RA scheme (which is indeed what I need!)

Inline answers...

Il giorno lunedì 26 settembre 2016 17:41:11 UTC+2, Tommaso Pecorella ha scritto:

Hi,

please try with ns-3-dev.

Tried. Same identical file (attached, not polished, forgive me ;) )

ns-3.25 -> run without errors

ns-3-dev -> not running -> error:

msg="Information element 0 is not implemented", file=../src/wifi/model/wifi-information-element-vector.cc, line=100

libc++abi.dylib: terminating

 

Moreover, check if there is already an open bug on our bugzilla.

No much relevant opened bugs on bugzilla.

Yes, there is a bug relevant to missing support for 802.11n/ac with mesh. However, the strange point is that if you run my file you are able to get "static" rates from 802.11n in a 2x2 configuration (e.g. 65Mbit/s, etc...)

But you are not able to change the wifimanager...

And hence, summing up, one remains wondering if 802.11n is actually simulated or if there are any subtle bugs around.

 

Thanks,

T.

If I can be of any help...

Thank you Tommaso

Federico

[Tommaso Pecorella]

Hi,

I guess we need the Wi-Fi maintainer...

Cheers,

T.

[Tom Henderson]

On 09/27/2016 05:23 PM, Tommaso Pecorella wrote:
> Hi,
>
> I guess we need the Wi-Fi maintainer...

The ns-3 mesh module is not currently compatible with 802.11n/ac
configuration.

- Tom

[Federico Tramarin]

Thanks.
I actually saw your bug filed on bugzilla.

Nonetheless, please allow me for a couple questions:

a) If I set the wifi standard to 80211n_5GHz && a constant bitrate of, lets say, Mcs7, the network actually run at the correct data rate. So, why?
b) If I print the whole set of simulator parameters (via ConfigStore) I can see the following
          /$ns3::NodeListPriv/NodeList/0/$ns3::Node/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::MeshWifiInterfaceMac/HtSupported "true"
      but also
          default ns3::RegularWifiMac::HtSupported "false"
c) The issue arise when I try to use Minstrel (indeed the example provided uses Arf, and that works!)

Lastly, I tried to follow the path of function calls, but I surely missed some point...

Please let me know

Cheers

Federico

[Tom Henderson]

On 09/28/2016 02:41 AM, Federico Tramarin wrote:
> Thanks.
> I actually saw your bug filed on bugzilla.
>
> Nonetheless, please allow me for a couple questions:
>
> a) If I set the wifi standard to 80211n_5GHz && a constant bitrate of,
> lets say, Mcs7, the network actually run at the correct data rate. So, why?

I think that you may be able to make some things work; I haven't tested
it extensively. Mesh functionality actually sits on top of Wifi
functionality, which is why you see some of those aspects in the
ConfigStore output, but it was written mainly assuming 802.11a and, for
instance, doesn't include 11n supported rates in the beacons (which is
why the HT rate controls do not work). There may be other things too...

If you or anyone would like to work with us to fix this limitation for
the next release, please let me know.

- Tom

[Federico Tramarin]

I made some step forward, but anything working will right now....

1) Minstrel works with the 2.4GHz versione of 802.11n. More on this later...

2) the issue 

assert failed. cond="duration >= MicroSeconds (0)"

happens only if 802.11n 5GHz is selected (not the 2.4 GHz) with Minstrel

The problem is with sifs and ack tx time. Duration reach 48 us value, than mac-low subtract 44 us for the ack duration and then 16 us for the sifs, hence negative value. Why this happens is a mystery to me!

3) Mistrel works, but falling back internally to the non HT version.

This is driving me mad!! 

because created mesh stations set the htsupported flag correctly, Minstrel recognize it in the docreatestation method,

but when enter the checkinit method to create its internal table of peer stations, it says that the other stations are non-HT.

Example log output:

MinstrelHtWifiManager:IsLowLatency(0x7fe5eb55d480)

MinstrelHtWifiManager:DoCreateStation(0x7fe5eb55d480)

here 1

MinstrelHtWifiManager:IsLowLatency(0x7fe5eb5613c0)

MinstrelHtWifiManager:IsLowLatency(0x7fe5eb565850)

MinstrelHtWifiManager:IsLowLatency(0x7fe5eb5613c0)

MinstrelHtWifiManager:DoCreateStation(0x7fe5eb5613c0)

here 1

MinstrelHtWifiManager:DoGetDataTxVector(0x7fe5eb5613c0, 0x7fe5ed802e00)

MinstrelHtWifiManager:CheckInit(0x7fe5eb5613c0, 0x7fe5ed802e00)

Non-HT station 0x7fe5ed802e00

messages "here 1" are my debug strings inserted in the docreatestation method to verify the output of HasHtSupported.

For completeness, I use this initialization in the mesh nodes creation

mesh.SetMacType ("RandomStart", TimeValue (Seconds (m_randomStart)),

"HtSupported", BooleanValue (true) );

explicitly setting the HtSupported flag.

I have no other time in these days. but my feeling is that the issue is actually very "stupid", maybe some odd parameters set up in the initialization stage.

I hope these information are useful.

Federico

[Yiannis]

Hi Federico,

I used to get a similar error for VHT-MCS7 (802.11ac - constant rate), but I didn't have time to
dig more into it. That was a couple of months before the ns3.26 release.

"InitialDuration: +44000.0ns duration: -16000.0ns phyRate: 65000000 mode: VhtMcs7
ackTxVector: format: 1mode: OfdmRate6Mbps txpwrlvl: 0 retries: 0 channel width: 20 Short GI: 0 Nss: 1 Ness: 0 MPDU aggregation: 0 STBC: 0

assert failed. cond="duration >= MicroSeconds (0)", msg="Please provide test case to maintainers if this assert is hit.", file=../src/wifi/model/mac-

low.cc"

Ioannis