[Ns-developers] Ideas about 802.11 enhancements in ns-3
Mathieu Lacage
mathieu.lacage at sophia.inria.fr
Sun Nov 23 21:20:14 PST 2008
hi timo,
On Fri, 2008-11-21 at 17:23 +0100, Timo Bingmann wrote:
> As first steps into ns-3, I have already ported Nakagami (+
> dependencies) to ns-3. To cross-check the results with ns-2, I
> disabled BER-calculation in WifiPhy and replaced it with a simple
> SINR-criterion. The results of some simple simulations were equal.
a patch to add the nakagami model to ns-3 would be great.
>
> Next step on the way will be to implement preamble and data capture.
> This is not an easy move, because it means changing the state machine
> of WifiPhy.
> First question is then: should I change the current ns-3-dev WifiPhy
> or take mathieu/ns-3-wifi and implement a derived WifiPhy class aiming
> at compatibility with ns-2 WirelessPhyExt?
If your goal is compatibility with the ns-2 WirelessPhyExt, then, yes,
it would make sense to implement your own WifiPhy subclass. However, if
the state machine changes make generally sense, then, adding them to
WifiPhyStateHelper would be ok too.
>
> >From reading dca-txop.cc and old yans code, I believe implementing
> QoS extensions is rather straight-forward. Mathieu advised me against
yes, it should.
> porting the old yans code. I will also have a long look at Casetti's
> 802.11e patch to ns-2.
> Another issue are the fixed 802.11a PHY parameters in ns-3. I
> understand this is needed for all the rate control to work. But
> somehow extending this to allow 802.11b/g parameters and future
> 802.11p for VANET is really necessary.
I do not believe that it is not needed for the rate control algorithms
to work. It merely makes the PHY implementation easier. The whole MAC
layer should be rather resilient to various PHY modes in the PHY layer.
regards,
Mathieu
More information about the Ns-developers
mailing list