Bug 1848 – yans-wifi-phy can receive frames sent using unsupported mode

Bug 1848 - yans-wifi-phy can receive frames sent using unsupported mode


Summary:	yans-wifi-phy can receive frames sent using unsupported mode

Status:	RESOLVED FIXED

Product:	ns-3
Classification:	Unclassified
Component:	wifi
Version:	ns-3.19
Hardware:	All All

Importance:	P5 enhancement
Assigned To:	Daniel L.

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2014-01-31 11:45 EST by Daniel L.
Modified:	2015-05-27 10:40 EDT (History)
CC List:	3 users (show)

See Also:

Attachments
Check mode before switching to RX (2.75 KB, patch) 2014-01-31 11:52 EST, Daniel L.	Details \| Diff
Sample scenario (8.43 KB, text/plain) 2014-01-31 12:06 EST, Daniel L.	Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Daniel L. 2014-01-31 11:45:18 EST

The current yans-wifi-phy implementation simply checks if the signal power is higher than the threshold and start receiving the frame if the signal exceeds the threshold even though the mode is not supported by the receiving phy.

For example, consider the following scenario (all nodes are within range of each other):

           802.11g AP

802.11g STA          802.11b STA

Communication between the two STAs will have to go through the AP but 802.11b STA is still able to "overhear" all frames sent between 802.11g STA/AP. (The frames will be ignored anyway since they are not addressed to 802.11b STA.)

This scenario is not a problem for adhoc since we assumed that all nodes support the same rate in adhoc mode.

I marked this as "enhancement" since I think mixing between b/g is not common in the simulation(?)

Comment 1 Daniel L. 2014-01-31 11:52:17 EST

Created attachment 1776 [details]
Check mode before switching to RX

Check mode before switching to RX

Comment 2 sebastien.deronne 2014-01-31 12:01:35 EST

Hi Daniel,

I noticed this bug, which is still true for 802.11n.

I think it is even worse with 802.11n because of greenfield mode which should not be understood by non-HT stations. I have not tested all that, but I wonder also how the simulator behaves when a 40MHz transmission occur in presence of non-HT stations.
Have you looked yet at such 802.11n mixed scenarios?

I will try to test your patch as quickly as possible.

Comment 3 Daniel L. 2014-01-31 12:02:40 EST

10600:48c3c6b355a1

Comment 4 Daniel L. 2014-01-31 12:04:10 EST

Hi Ghada,

Sorry, I just pushed the patch. If you can test it more, that would be great. I have not tested with 802.11n yet.

We can roll it back if needed.

Comment 5 Daniel L. 2014-01-31 12:06:35 EST

Created attachment 1777 [details]
Sample scenario

Here's the sample scenario.

Comment 6 Tommaso Pecorella 2014-01-31 14:30:28 EST

Please make a test and update the Python bindings (you added a new function) :P

Comment 7 sebastien.deronne 2014-02-01 16:53:22 EST

I rapidly tested your patch, and it resolves perfectly troubles when b and g stations are involved.

When I consider HT, b and g stations, I get a strange behaviour (the same one with or without the patch). So, we should now investigate how to support 802.11n mixed mode with b/g stations. I do not think it is hard to do, I will try to work on that when I have some time for it.

Comment 8 sebastien.deronne 2015-05-27 10:40:25 EDT

Closing this bug since patch has been committed a while ago and no issues have popped up.