802.11n model documentation and refinements

[Federico Tramarin]

Dear developers,

I am using the 802.11 model contained in INET in my simulations.

I am now switching to the "n" mode, but its usage in INET is little (practically, not) documented.

Therefore, my first question is if there is any plan to update the documentation in this regards?

Actually, I am also quite confused about some implementation details, and I think that some bugs may hide in the code.

For example, if I set this

[Config testN]

**.wlan*.opMode = "n(mixed-2.4Ghz)"

**.bitrate = -1bps

**.wlan*.mac.dataBitrate = ${13,26,39,52,78,104,117,130}Mbps

**.numAntennas = 2

**.errorModelType = ""

simply the datarates 78,104,117 fail to load!

Digging into the code reveals that the method getMode() made a search within the available rates in the "n" modeset, but it searches within all the available rates, even if they are relevant to a different number of spatial streams.

For example, if a set the number of antennas to 2, and search for 13 Mbps, it finds immediately the rate but we have no insurance that that 13 Mbps is relevant to 2 spatial streams, since it may happen that it is relevant to 1 SS.

This is more evident setting some particular rates (or better MCS in the n language).

If you try to set 78Mbps, simply the simulation doesn't start, because the rate is not found.

The same for 104 and 117 Mbps.

However, these rates are relevant to the MCS 12, 13 and 14 (please see http://mcsindex.com)

This is, in my opinion, because the code performs an "exact" calculation, without the proper roundings, as it appears evident printing on debug the full set of rates.

I think that this should be fixed somehow. Nonetheless, before trying to modify things in my sources, I would like to have some confirmations by the developers, since it is clearly possible that I am embarrassingly wrong :(

Clearly, in every case, this issue is exacerbated by the fact that practically no documentation is found with respect to the "n" mode, even if it is included in inet by almost 2-3 years now. Even some simple examples, but provided by the developers that know exactly the details of the code, maybe sufficient.

Concluding, please do not consider this my request as a bunch of not useful complaints about a piece of software. I am a long time user of Omnet++/Inet, and what I would like to highlight is only a minor deficiency that in my opinion could be fixed quite easily.

So, please, let me know your opinion about this, and provide me some details about the bugs that I highlighted above.

With much regards

Federico

 

[Levente Mészáros]

Dear Federico,

Unfortunately even in the latest INET version, 802.11n modes are only partially supported mostly due to lack of time. Your analysis regarding the search for the selected MAC mode is correct. Please note that when you configure the number of antennas in your example, you only specify the maximum number of spatial streams that is how many physical antennas there are in the radio. Right now there are no parameters in the MAC to actually select a mode with the desired number of spatial streams. Moreover, 802.11n modes which utilize multiple spatial streams are not currently supported by the 802.11 error models.

In general, we would be happy to receive enhancements to the 802.11 model in the form of pull requests.

Best regards,

Levente Mészáros

--
You received this message because you are subscribed to the Google Groups "OMNeT++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/omnetpp.
For more options, visit https://groups.google.com/d/optout.