WiFi interference: coordination note

View: New views
3 Messages — Rating Filter:   Alert me  

WiFi interference: coordination note

by Tom Henderson-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

A few of us are working on improving the modeling of WiFi interference.
I wanted to mention this for coordination with other people working on
similar topics.

We would like to improve the modeling in these areas:

1) Capture effect modeling

   Trevor has previously posted on this subject.  It seems that Timo's
Phy model forms a good basis for this.  It would be useful to merge this
Phy with YansWifiPhy so we only have to maintain one going forward.

2) Adjacent channel interference from same system

   It is possible in WiFi for frames on adjacent channels to interfere
with (and even be received on) the tuned channel.  We would like to be
able to model this, but presently there is no way for packets to "jump"
channels.  There is more to it than simply jumping channels; we need to
consider spectral masks of transmitter and receiver.

Here, I have read Nicola and Marco's recent paper:
http://www.dei.unipd.it/~baldo/mypapers/baldo2009spectrum.pdf
and the spectral modeling repo and previous Miracle work, so it seems
like we should harmonize with this work.

Nicola, what are your near-term plans for the spectral modeling repo?
One question I again have here is whether we can add this to existing
YansWifiPhy and channel rather than developing independent Spectrum*
model hierarchy.

3) Interference from other systems

   Bluetooth into wifi, or jamming signals into wifi, are of interest to
us.  This is somewhat related to the previous item but if there is a
desire for a foreign signal to be treated differently from an
interference perspective than a native wifi signal, then we may need to
think about how to model this at the receiver (what signal attributes
are important to convey across channels). Again, I realize Nicola and
others have worked on this.  I think it would be helpful to try to
sketch out a small roadmap of how this work can be added over time.

4) Receiver model profiles

In addition, we're working on experimentally deriving an 802.11g clear
channel BER model and will post that when it becomes available.  One
thing that has become apparent is that it would be nice to be able to
add "receiver profiles" to existing models (such as a suite of BER
curves that were empirically derived from a particular testbed) without
hacking on the device model.

5) subclassing YansWifiPhy

Would it be acceptable to make StartReceivePacket a virtual function so
that YansWifiChannel-compatible phys, with different reception behavior,
can be experimented with?

6) directional antennas with WiFi

Is anyone doing directional antenna modeling work?

- Tom


Re: WiFi interference: coordination note

by Nicola Baldo-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Tom and everybody,

Tom Henderson wrote:

> A few of us are working on improving the modeling of WiFi interference.
> I wanted to mention this for coordination with other people working on
> similar topics.
>
> We would like to improve the modeling in these areas:
>
> 1) Capture effect modeling
>
>   Trevor has previously posted on this subject.  It seems that Timo's
> Phy model forms a good basis for this.  It would be useful to merge this
> Phy with YansWifiPhy so we only have to maintain one going forward.

I agree that Capture effect should be included in YansWifiPhy, but I
have some doubts on the approach proposed by Trevor. I'll reply directly
to Trevor's email on the list so that we can keep on using that thread
for the detailed discussion.

>
> 2) Adjacent channel interference from same system
>
>   It is possible in WiFi for frames on adjacent channels to interfere
> with (and even be received on) the tuned channel.  We would like to be
> able to model this, but presently there is no way for packets to "jump"
> channels.  There is more to it than simply jumping channels; we need to
> consider spectral masks of transmitter and receiver.
>
> Here, I have read Nicola and Marco's recent paper:
> http://www.dei.unipd.it/~baldo/mypapers/baldo2009spectrum.pdf
> and the spectral modeling repo and previous Miracle work, so it seems
> like we should harmonize with this work.
>
> Nicola, what are your near-term plans for the spectral modeling repo?
> One question I again have here is whether we can add this to existing
> YansWifiPhy and channel rather than developing independent Spectrum*
> model hierarchy.

I had a private discussion with Faker about this issue a couple of weeks
(or so) ago. It is our intention to work for it to be merged in
ns-3-dev, however the current status of our code is that it still needs
a significant amount of work to be polished, so we though that this
was clearly out of reach for ns-3.7. We will try for 3.8.

As for merging the functionality of Spectrum into YansWifiPhy, I think
it is not at all straightforward, since the impact of the modifications
would be huge. Furthermore, it might not be desirable. If Spectrum is
merged into YansWifiPhy, and you want to implement say an LTE phy using
Spectrum functionalities, would then LtePhy inherit from YansWifiPhy?

>
> 3) Interference from other systems
>
>   Bluetooth into wifi, or jamming signals into wifi, are of interest to
> us.  This is somewhat related to the previous item but if there is a
> desire for a foreign signal to be treated differently from an
> interference perspective than a native wifi signal, then we may need to
> think about how to model this at the receiver (what signal attributes
> are important to convey across channels). Again, I realize Nicola and
> others have worked on this.  I think it would be helpful to try to
> sketch out a small roadmap of how this work can be added over time.

Yes our Spectrum framework supports this, though for now apart from wifi
we only support very simple jamming sources.
Of course if there are alternative proposals for how to address the same
problem we would be happy to start a discussion.

>
> 4) Receiver model profiles
>
> In addition, we're working on experimentally deriving an 802.11g clear
> channel BER model and will post that when it becomes available.  One
> thing that has become apparent is that it would be nice to be able to
> add "receiver profiles" to existing models (such as a suite of BER
> curves that were empirically derived from a particular testbed) without
> hacking on the device model.

I agree that would be a nice feature. If I remember correctly Federico
Maguolo had done something for this, and Mathieu was trying to recover
and merge his code, but I don't know how the thing ended up.


Regards,

Nicola





Re: WiFi interference: coordination note

by Mathieu Lacage :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Thu, 2009-11-12 at 17:40 +0100, Nicola Baldo wrote:

> > In addition, we're working on experimentally deriving an 802.11g clear
> > channel BER model and will post that when it becomes available.  One
> > thing that has become apparent is that it would be nice to be able to
> > add "receiver profiles" to existing models (such as a suite of BER
> > curves that were empirically derived from a particular testbed) without
> > hacking on the device model.
>
> I agree that would be a nice feature. If I remember correctly Federico
> Maguolo had done something for this, and Mathieu was trying to recover
> and merge his code, but I don't know how the thing ended up.

The interpolation code implemented by federico to interpolate the ber
surface between snr/number of bits points generated a discontinuous
interpolation surface full of singularities which made it generally
hopeless.

I discussed this matter (that is, what is the proper way to generate an
interpolated surface from an arbitrary number of arbitrarily positioned
discrete points) with a few co-workers: what came out of it is that the
proper way to do this is to generate a delaunay triangulation of the
supporting points, and then linearly interpolate on the edges of the
triangles. Although my co-workers helpfully pointed me to simple and
classic algorithms to generate this triangulation, I never found a way
to get enough time to do it. I would be happy to mentor anyone willing
to do this and I am sure nicola or myself can retrieve the proper
measurement data which federico originally used.

Mathieu