[Ns-developers] Update on ns-3 802.11n

[Nicola Baldo]

On 08/31/2010 03:06 PM, Mathieu Lacage wrote:
> On Tue, 2010-08-31 at 14:30 +0200, Nicola Baldo wrote:
>> I already spent some time coming up with API proposals for the
>> case
>
> Those proposals were in the bug report, I presume ?

Yes.


Mathieu Lacage wrote:
> What I would have expected is merely a delegate to the
> WifiRemoteStationManager with a default stupid implementation (say,
> use the constant you want to put in the PHY) that can be overriden
> entirely by subclasses should they want to. Something like the
> maximum retry threshold. For tx power, it should be sufficient.

I had started with this idea and came out with this patch:
http://www.nsnam.org/bugzilla/attachment.cgi?id=946

the patch is largely incomplete because I didn't like what was coming
out. In particular, I was concerned with the difficulting of
implementing joint power and rate adaptation with such an API.

I had tried to summarize the pros and cons of this approach in this comment:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=917#c13

feedback would be very much appreciated.


Jens Mittag wrote:
> I would keep the possibility to set the TX power on a per packet
> base, since this is also the way how a real chipset implements it.
> Afaik, the TXpower parameters is also part of the transmission
> request interface in 802.11 PHY.

You mean the TXVECTOR defined in the standard, right?
This is what I tried to introduce with this other patch:
http://www.nsnam.org/bugzilla/attachment.cgi?id=947

pros and cons were discussed in this comment:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=917#c14

again, feedback would be very much appreciated.


Mathieu Lacage wrote:
> For the preamble thing, it's more tricky because the preamble type
> should be chosen depending also on the capabilities of the remote
> station. The short preamble is allowed only when the remote side
> explicitely supports it so you need to keep track of the supported
> preambles for each remote.
>

I don't think this is mandated by the standard. See IEEE Std.
802.11-2007, Section 18.2.1:

"The optional short preamble and header is intended for applications
where maximum throughput is desired and interoperability with legacy and
nonshort-preamble-capable equipment is not a consideration. That is, it
is expected to be used only in networks of like equipment, which can all
handle the optional mode".


Jens Mittag wrote:
> For preamble format, I agree to follow your proposal. An adaptation mechanism can still adapt these parameters through the attribute system if it wants to.

It might make sense to do what you propose, i.e., leave TX power in 
WifiPhy::SendPacket, but take the preamble out. In fact, according to 
the standard, the preamble is not part of the TXVECTOR.

It would be also to know what is done in drivers such as madwifi and ath5k.



Nicola