[Ns-developers] Adding Wifi Phy models

[Mathieu Lacage]

On Fri, 2009-03-20 at 15:14 -0700, Pei, Guangyu wrote:
> Mathieu,
> 
> I have some questions about adding additional PHY models (such as
> 802.11b/g) in ns-3.
> 
> 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: 
> 
> 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.
> 
> (2) add new PHY modes in wifi-phy (e.g., Get1mbb for 802.11b 1Mbps etc)
> 
> (3) Add Chunk success rate functions in yans-error-rate-model based on
> new modes added in WifiPhy.
> 
> (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

I think that this looks great.

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

It's ok in this case I think.

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

I think that if all you want to do is add new models of the SNIR <-> PER
calculation, either extending YansErrorRateModel or creating new
subclasses of ErrorRateModel is fine. I originally envisioned that some
people might want _very_ different models for a PHY model which do not
require the use of an SNIR so, for these people, it would have made
sense to derive from WifiPhy directly and re-implement everything.

Mathieu