[Ns-developers] spectrum modeling and wifi device

[Nicola Baldo]

Mathieu Lacage wrote:
> ok, I see. You basically want to add a SrcSpectralMask and a
> DstSpectralMask. 

Kind of. Actually, after the experience with miracle, we realized that
we had over-standardized our general-purpose PHY framework (I seem to
recall that somebody had warned us about that...). In particular, we
tried to standardize 1) the way a transmission is perceived by the
receiver, and 2) the way interference is calculated. Eventually we
realized that these aspect are too technology-specific to be standardized.

What I am proposing here is the minimum level of standardization which
does the job. This means just having a uniform way of representing how a
transmission makes use of the spectrum. Compared with what we did with
miracle, it is like standardizing SrcSpectralMask only. All the other
features will be technology-specific.


> If you do this, please, don't make the classes
> virtual :)

I am always tempted to do this type of thing ;-) but I have to admit
that for the SpectralMask in miracle it ended up to be useless...



>>> I would be fine with this if it _really_ helps you but one thing that I
>>> would like to eventually support in this part of the code is
>>> omnidirectional antennas. My feeling is that, eventually, this will
>>> require us to push a bunch of extra pointers in YansWifiChannel::Add (a
>>> pointer to the tx and the rx antenna associated to a
>>> receiver/transmitter) and keep track of them in YansWifiChannel which
>>> seems really wasteful since all this information will be already stored
>>> in YansWifiPhy 
>> Can we use Packet Tags for this purpose?
> 
> Tags don't work very well for this kind of thing. They are great for
> end-to-end tagging.
> 

Why? Performance? I liked the idea of reducing the number of parameters
to be explicitly passed in function calls between objects of different
types.


> I suspect that the extra loss added by the spectrum model could be
> encapsulated in a single class and we could make this class virtual with
> a no-op version. i.e., 
> 
> class SpectrumLossModel
> {
> public:
>   virtual double CalcRxPower (double txPower, Spectrum txMask, Spectrum
> recvMask) = 0;
> };
> 
> It's not the most beautiful thing but, well, it should work.


That's like what we had in miracle. After that experience, I think that
it is not practical to define a generic SpectrumLossModel, because not
all types of interactions between txMask and recvMask can be summarized
with a loss in the (scalar) rx power. As an example, in OFDM it might be
easier to map this interaction directly onto an error model, rather than
on a scalar RX power loss first and an error model afterwards. This
aspect really depends on the particular PHY considered. Better to leave
it technology-specific.


Regards,

Nicola