[Ns-developers] Adding Wifi Phy models

[Nicola Baldo]

Hi all,


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

I think it is interesting to see how things are in real devices. I have 
some familiarity with the old intersil HFA3863 chipset, which implements 
the baseband part of the 802.11b PHY. You can find the datasheet here:
http://www.datasheetcatalog.org/datasheets2/31/312321_1.pdf

The way the MAC and the PHY interact with each other for TX is 
summarized on page 10, right column, where the Configuration Register 
involved in the TX phase are described. Basically, the MAC is required 
to have some prior knowledge of the PHY modes which are available, and 
of the duration of the transmission for each mode. I think that this 
type of shared knowledge between MAC and PHY would be better modeled if 
CalcTxDuration() were a member of 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.
> 

I absolutely agree and strongly support this approach.



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

Such a hardware is for instance Calradio:
http://calradio.calit2.net/calradio1a.htm

For those who are not familiar with it, Calradio is an experimental 
platform with a 802.11b PHY and a fully customizable MAC layer written 
in C code which runs on a DSP. The PHY in particular is based on two 
components: the baseband module (the Intersil HFA3863 chipset I 
mentioned earlier) and the RF module (based on the Maxim MAX2820 chipset).

In Calradio, the setting of the PHY mode belongs to the baseband module, 
whereas the setting of the frequency to be used belongs to the RF 
module. Both these settings are performed by writing to appropriate 
configuration registers when desired. As a consequence, per-packet 
frequency selection can be implemented by setting a new frequency just 
prior to transmission.

I would like to point out that in this case the baseband module, which 
is responsible for handling the PHY mode (i.e., preamble, modulation and 
coding) is completely unaware of the frequency that will be used for 
transmission. I think that for ns3 too we should keep these two issues 
separate. In other words, I do not agree that adding a frequency 
attribute to WifiMode is a good idea. WifiMode is used to calculate TX 
duration, and for error modeling purposes. The frequency setting does 
not play any role into these issues.

Regards,

Nicola