[Ns-developers] Adding Wifi Phy models

[Timo Bingmann]

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.

> 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.

> Currently, there is a YansWifiPhy, which aligns with 802.11a PHY. It
> works together with interference-helper, yans-error-rate-model and
> yans-wifi-channel.
> 
> It seems to me that Yans model is generic and can be used as the bases
> for the other PHY models.
> 
> How about the following approach for adding additional PHY model?
> 
> (1) generalize interference-helper based on PHY standard type: 

As you have already figured out, the YansWifiPhy does a BER/PER calculation based on the SINR value. The SINR contains cumulative interference as expected from a AWGN model. The cumulation is calculated by the interference helper.
 
Then after SINR calculation, the InterferenceHelper uses ErrorRateModel to calculate the BER/PER for each packet chuck with time-invariant SINR.

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

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.

For my part i believe there should be two classes: WifiMode and WifiModulation
WifiMode encompasses all parameters of a transmission schema.
Including: header modulation(s),  payload modulation, preamble length, bandwidth, maybe even frequency (that's a separate discussion). 

WifiModulation is only about calculating the BER for one chunk. Hence it is not used by upper layers.

> Instead of assuming 802.11a parameter, add a member variable "enum
> WifiPhyStandard m_80211_standard". In
> InterferenceHelper::CalculateTxDuration(), the TxDuration is calculated
> based on m_80211_standard. For each standard type x, there should be a
> "Configure80211xParameters" function.

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.

> (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.

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 :)

> (3) Add Chunk success rate functions in yans-error-rate-model based on
> new modes added in WifiPhy.

Ah :)

> (4) In YansWifiPhy, the only thing need is to add Configure80211x() to
> support YansWifiPhy::SetStandard for new 802.11x mode added.
> 
> Is this approach acceptable? The pros of this approach is that new modes
> can leverage Yans model heavily. As you can see only minor changes
> needed for YansWifiPhy class. The cons of this approach may be that it
> is not modular since it directly add new PHY models on top of Yans
> model. 
> 
> Another approach is that each additional PHY mode is standalone module,
> which has its own error-rate-model, interference-helper etc. But I see a
> lot of overlapping codes for this approach. What are your thoughts for
> this type of approach?
> 
> Since Yans model seems to align with 802.11a well, what is the reason
> not to call it 802.11a and set default parameters such as receiver
> sensitivity more closely to the standard? What is your vision and plan
> for adding other 802.11 PHY models within your current framework.
> 
> Thanks,
> 
> Gary

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!)

Greetings
Timo