[Ns-developers] spectrum modeling [was: ns-3.5 planning]
Mathieu Lacage
mathieu.lacage at sophia.inria.fr
Wed Apr 22 02:06:45 PDT 2009
Hi nicola,
I looked carefully at your code but, what is really missing is a picture
of how this would be used in real devices so, I can't really comment on
the overall direction.
On Fri, 2009-04-17 at 11:41 +0200, Nicola Baldo wrote:
> 1) a class (ValuesVsFreq) providing the representation of
> frequency-dependent things (such as spectral power density, propagation
> loss, tx/rx mask...);
a) If you intend to use code in src/devices/spectrum as shared, I think
you can move it to src/common instead. The initial idea beyond
src/devices was that each subdirectory would contain a single NetDevice
class. Maybe someone has a better idea.
b) Multiple inheritance !! What happened to you to become evil
overnight ? Instead, please, make std::vector<double> a member of
SetOfFreqs. Make it a public member if you must (or use a struct).
class SetOfFreqs : public RefCountBase, public std::vector<double>
{
};
c) It's really a bad idea to make arithmetic operators member methods
(they should be friend functions) because that makes them asymetric (A+B
becomes different from B+A): you should consider reading "more effective
c++", items 6, 7, 21, 22. Also:
http://www.parashift.com/c++-faq-lite/operator-overloading.html#faq-13.9
Now, given the complexity of getting this kind of C++ operator
overloading magic right, I would like to suggest that you don't do it at
all. Yes, I know that we do this in src/simulator/nstime.h but I think I
can comment about this code to say that doing it once taught me to not
do it ever again. I don't claim I never make any mistake but I can claim
that I _try_ to not do the same mistake more than once (ok, maybe,
sometimes, hubris makes me do the same mistake twice, or more).
Ok, what could you do to avoid this ? I have to confess that I don't
know: I am still missing the big picture of your code.
> 2) interfaces definitions for the spectrum-aware channel, phy and
> propagation loss model (delay model is the same as wifi);
d) How do you envision that SpectrumPhy::StartRx would be used ?
> 3) a basic but usable implementation of the channel and the
> spectrum-aware version of the Friis propagation model;
>
> 4) two sample PHY layer implementations (WaveformGenerator and
> SpectrumAnalyzer) and a couple of test scripts to test everything and
> show how it works.
>
>
> What is still missing are PHY layers to be used within a NetDevice
> context, and in particular something that can work with the current wifi
> code -- either some code which can interact with the existing
> YansWifiPhy, or a brand new WifiPhy implementation. I plan to be working
> on this issue the near future.
>
> You can find the code here:
> http://code.nsnam.org/nbaldo/ns-3-dev-spectrum/
>
> Any feedback would be very much appreciated, as well as any intent to
> cooperate in this development. I would be happy to have all this code
> included in ns-3-dev at some point, but I am not sure of whether this
> can happen for ns-3.5. The point in favor of this is that the new
> features do not mess up with existing code, so including it does no
> harm. The point against is that at the moment there is still nothing
> which can be really useful for practical purposes; more modules need to
> be developed for this.
I think that we need some real code using this before it can be
included.
Mathieu
More information about the Ns-developers
mailing list