Wifi Enhancements for ns-3

Multiple issues are contained in the patch:
Ns2ExtWifiPhy and lots of small changes to the wifi code. We'll need to review
that in detail.
TrafficApplication and NakagamiPropagationLossModel are independent.

[Nicola Baldo]

Hi Timo,

a few comments on some your proposed wifi enhancements. Mainly, I am commenting
about functionality. I am sure others will be happier  and more competent than
me to comment on the implementation.

Regards, 

Nicola

http://codereview.appspot.com/65051/diff/1/45
File src/devices/wifi/wifi-phy.h (right):

http://codereview.appspot.com/65051/diff/1/45#newcode104
Line 104: * and information.
I like the concept of having a WifiPhyTag! 
+1

http://codereview.appspot.com/65051/diff/1/45#newcode125
Line 125: void  SetTxParameters(WifiPreamble wifiPreamble, WifiMode wifiMode,
Time duration, uint8_t txPowerId, double txPowerDbm);
Can we add channel information here? For example the center frequency in MHz

http://codereview.appspot.com/65051/diff/1/54
File src/devices/wifi/yans-wifi-phy.h (right):

http://codereview.appspot.com/65051/diff/1/54#newcode80
Line 80: bool GetUseConstantNoiseFloor () const;
I don't really see the need for this new ConstantNoiseFloor.
While in theory it is true that the former method determines the noise power as
a function of the bandwidth, in practice the bandwidth is always 20MHz, so the
noise is already costant!  The only misleading thing is that it is expressed as
the Noise Figure, i.e., the difference in dB with respect to -130.97 dBm, which
is the power of thermal noise at room temperature in a 20MHz channel. 

To summarize, the only difference between the pre-existing Noise Figure and your
newly proposed ConstantNoiseFloor is an offset of 130.97 in the value. We might
discuss on which of the two is more intuitive to use. But I think we should keep
only one of them.

[timo.bingmann]

Some quick explanations.
The 10 MHz channel problem is still open. I don't think we'll manage a simple
one-switch configuration option.

Some time ago I've drawn a scratch patch to make WifiMode contain more broad
configuration options:
https://idlebox.net/2008/ns-3-wifi/code/ns-3-wifimode/rev/46be5539eee1
But it also has drawbacks.

Greetings
Timo

http://codereview.appspot.com/65051/diff/1/45
File src/devices/wifi/wifi-phy.h (right):

http://codereview.appspot.com/65051/diff/1/45#newcode104
Line 104: * and information.
On 2009/05/15 09:57:54, Nicola Baldo wrote:
> I like the concept of having a WifiPhyTag! 
> +1 

Yes, I like it too. It stabilizes TraceCallback signatures and is useful for Dbm
and W conversions.
However, the multi-inheritance is evil; but I think that could be fixed with
another class.
The big question is whether this should be a Tag or not (just an Info structure
for callbacks).

http://codereview.appspot.com/65051/diff/1/45#newcode125
Line 125: void  SetTxParameters(WifiPreamble wifiPreamble, WifiMode wifiMode,
Time duration, uint8_t txPowerId, double txPowerDbm);
On 2009/05/15 09:57:54, Nicola Baldo wrote:
> Can we add channel information here? For example the center frequency in MHz

I was going to write some more info about the 10 MHz channel problem. The real
issue is that it requires configuration of both MAC and PHY layer models.

http://codereview.appspot.com/65051/diff/1/54
File src/devices/wifi/yans-wifi-phy.h (right):

http://codereview.appspot.com/65051/diff/1/54#newcode80
Line 80: bool GetUseConstantNoiseFloor () const;
I need the constant noise level for compatibility with ns-2.
By setting it to say -100 dBm, calculation of the reception power with 5 dB SINR
threshold is -95 dBm and not some decimal ;).