[Ns-developers] Adding Wifi Phy models

[Mathieu Lacage]

On Sat, 2009-03-21 at 12:10 +0100, Timo Bingmann wrote:
> On Friday 20 March 2009 23:14:28 Pei, Guangyu wrote:
> > Mathieu,
> 
> Hi there, I'm currently writing my diploma thesis and it will contain
> a ton of info on the PHY layers in ns-3. In my private repo I cloned
> YansWifiPhy to create Ns2ExtWifiPhy for ns-2-similar or equal
> reception.

Oh, this is cool. It would be nice to see this code to try to see if we
can merge it at some point.

> > I have some questions about adding additional PHY models (such as
> > 802.11b/g) in ns-3.
> 
> I believe you are wanting to add new WifiModes, not actually a new PHY
> model.

yes, I think so.

> I guess this is the place to add BER formulas to add b/g modes. See
> YansErrorRateModel::GetChunkSuccessRate().

yes.

> 
> The rest below is about organization of the WifiMode class and what it
> is for. I did some work on that, but never finished as more important
> things intervened. Here the idea on that work:
> 
> My perception is that WifiMode is used for two separate purposes: once
> by MAC layer to tell the PHY which transmission schema it should use.
> And once to indicate the PHY modulation mode.
> 
> These are not identical as even the simpler 802.11a OFDM modes show:
> the preamble and header are differently modulated than the payload.
> Currently this is modeled by setting
> InterferenceHelper::m_longPlcpHeaderMode and using it at the right
> places.

I was expecting that the MAC layer would pass two different mode
arguments to set this on a per-transmission basis if it was needed. 

> For my part: all these methods don't belong into an interference
> helper.
> 
> However if CalcTxDuration is a method of a WifiMode or of a WifiPhy is
> an open issue. This depends on how tightly a WifiMode is bound to a
> specific WifiPhy, in my opinion very tightly. In that case TxDuration
> is fully defined by the WifiMode.

There are naming issues here but, what matters is that the MAC layer can
specify tx parameters in a way which is as abstracted as possible from
the PHY layer because the goal is to be able to replace the PHY layer.

> > (2) add new PHY modes in wifi-phy (e.g., Get1mbb for 802.11b 1Mbps
> etc)
> 
> Definitely. Interesting issue is how many to actually list. Especially
> with 10 MHz bandwidth and whether to include the frequency in the
> WifiMode. That would yield lots of modes. I mean of course only one
> frequency per band.

Yes, this is a good question.

> The main advantage of also listing frequencies is for answering user
> questions like "does ns-3 support 802.11p in 5.9GHz ?". Nothing
> changes, only the frequency. But listing them as extra modes
> forestalls user questions :)

Yes, we need a way for users to specify the frequency band but I thought
that WifiPhy::SetFrequency would be enough because I can't imagine any
hardware which is able to change the frequency band on a per-packet
basis. If there is such hardware around or if the goal is to modelize
such hypothetical hardware, then, you need to add an extra parameter to
WifiPhy::StartTransmission and, if you want to encapsulate all of the tx
parameters in a single object, that would be fine with me, but you need
to pick a good name for this object/structure.

> I did some test coding some time ago:
> https://idlebox.net/2008/ns-3-wifi/code/ns-3-wifimode/
> 
> And created WifiModulation and changed all code accordingly. It all
> works ok.
> However more important things stalled that branch.
> I manged to remove WifiPreamble from all higher MAC layers (Yay!)

I will try to review this at some point: sorry for not getting to this
in time.

Mathieu