Is there any way of measuring wifi SNR? Problems with co-channel interference.

593 views
Skip to first unread message

Marek Ciesla

unread,
Aug 15, 2017, 11:00:02 AM8/15/17
to ns-3-users
Hi,

I'll try to explain the problem that im getting with my code step by step.

First of all, i took as example the MonitorSniffRx from wifi-spectrum-per-interference to measure this parameter. I made the next test to compare with my program:

I printed the mac address headers from the packets that triggers MonitorSniffRx, the 4 MAC addresses viewing the generated pcap file are:


So having this is mind the output of the triggered packets is:


      Config::ConnectWithoutContext ("/NodeList/0/DeviceList/*/Phy/MonitorSnifferRx", MakeCallback (&MonitorSniffRx));
The path thats its passed to the callback is the first node, thats the STA, which mac is 00:::::01



I made a new scenario to measure the co-channel interference. I just created 2 AP and 2 STA which are on a different channel of the 802.11n 2.4 GHz standard.
From my code im measuring the SNR of the APA which mac is 00:::::02 and i get more packets than its expected. This test is made using udp, the same as the wifi-spectrum-inteference example and as you can see i get a lot of different addresses.



So the next thing that i made is filter packets by the receiver address, and i got all the packets that are expected, but i doesnt seem that something the other ap and sta are interfering. The value of the SNR in a scenario with 1 AP and 1 STA is 23.3027dB, which is the same as i get now:





How is MonitorSniffRx triggered? I read the doxygen but i couldnt figure out how it works. Is there any way of measuring the interference? I read about The snr tag but it doesnt seem that is what i need here.
Is there any wat of measuring the interference or see that it works?

Regards, Marek.

wifi-spectrum-per-interference.cc
alpha03.cc
Auto Generated Inline Image 1
Auto Generated Inline Image 2
Auto Generated Inline Image 3
Auto Generated Inline Image 4
Auto Generated Inline Image 5
Auto Generated Inline Image 6

Rediet

unread,
Aug 18, 2017, 9:35:07 AM8/18/17
to ns-3-users
Hello Marek,

If you search for NotifyMonitorSniffRx method which triggers the trace source within WifiPhy (in ns-3-dev branch) you'll see that it's called only upon successful reception of the PPDU. This is indeed the normal procedure since you can only sniff correctly decoded packets (at least from a PHY perspective).
If your stations are within range they'll end up seeing each other, so will avoid collisions, unless in some cases, where there'll be a collision, but in that case the trace source is not fired at all.
By the way, did you put your BSSs on different channels or on the same? It wasn't clear from your explanation.
Just note that a perfect transmit mask is considered for the time being (no leakage at all on adjacent bands).

Rediet

Marek Ciesla

unread,
Aug 19, 2017, 1:07:25 PM8/19/17
to ns-3-users
I made several test with different channel numers to compare:

Channel 1-2


Channel 1-1


Channel 1-11 (no interference)

As you can see this is the only one that gets the 1000 sent packets.

This test were made without packet filtering. The next one are made with packet filtering( I only have in consideration packets that are received by the node with his receiver mac):

This is the filter:
 if(packet->PeekHeader(hdr))
  {
     
    if (  addrmp == hdr.GetAddr1())
    ...

Channel 1-2


Channel 1-1



Channel 1-11




These tests were made with udp, as you can see its not calculating any interference.

The next test were made with tcp with packet filtering, without packet filtering the results are similar to udp:

Channel 1-2



Channel 1-1



Channel 1-11



So here we can see that it seems that the interference is "working". The problem i see is the throughput that is very low, should be near 4Mbps.
Does the wifi interference really work? From these test I cant say 100% that it works and, why it works with tcp and not with udp?

This is the description of MonitorSniffRx: "sniffing all received frames" . What are the other frames that are triggering the monitor?

regards and thank you for your help.
Auto Generated Inline Image 1
Auto Generated Inline Image 2
Auto Generated Inline Image 3
Auto Generated Inline Image 4
Auto Generated Inline Image 5
Auto Generated Inline Image 6
Auto Generated Inline Image 7
Auto Generated Inline Image 8
Auto Generated Inline Image 9

Rediet

unread,
Aug 31, 2017, 8:58:20 AM8/31/17
to ns-3-users
Hello Marek,

I really took some time to dig into your script and managed to make things work by enabling beacon generation jitter for both APs (at least one should do the trick).
Indeed this is what was happening; AP_A sent its beacon first (from a scheduling perspective, since it was installed first) and virtually at the same time came AP_B's beacon. The latter was dropped by both STAs (and AP_A) so only STA_A could associate to AP_A immediately. STA_B had to wait longer. Following beacons also collided. Adding a jitter made the two BSSs independent (which is the case normally).
With this modification everything seems to work fine.
One more thing though; your callback was not correctly configured to compute SNR. You are setting up DL traffic and sniffing for Rx frames at AP. So you'll only be getting UL frames, and especially ACKs/BAs once data gets generated. Considering that ACKs/BAs are protected by NAV and preempt channel within SIFS, you're almost sure not to get disturbed. Try changing traffic direction and then you'll be able to see the impact of interference (which should work fine by the way :-)).

Rediet

Marek Ciesla

unread,
Sep 4, 2017, 6:19:10 AM9/4/17
to ns-3-users
Hi, thanks for your touble.

But from what said Sebvastien Deronne, co-channel interference isnt implemented:
But ill try what u said.

Marek Ciesla

unread,
Sep 4, 2017, 7:35:34 AM9/4/17
to ns-3-users
Could you tell how did you found the problem?

Rediet

unread,
Sep 5, 2017, 2:16:10 AM9/5/17
to ns-3-users
Hello Marek,

I don't know if you've noticed but I was also telling you that the Wi-Fi module currently uses perfect transmit masks in my first reply... In the case channel 1 and 2 that you've been simulating, even with perfect transmit masks (i.e. rectangular) you'll still manage to model a certain level of interference (since channels 1 and 2 are overlapping) through the use of the Spectrum model.
As for how I managed to identify the problem, just activated logs progressively (while displaying all prefixes so as to catch the context), namely SpectrumWifiPhy and WifiPhy at info level, since the trace source wasn't enough.

Rediet

Sebastien Deronne

unread,
Sep 11, 2017, 3:57:00 PM9/11/17
to ns-3-users
Rediet correctly explained what the current status is.
If you want to see the effects, you can check the RX and TX PSD by enabling relevant wifi and spectrum traces.
Message has been deleted
Message has been deleted
Message has been deleted

IZYDOR SOKOLER

unread,
Sep 14, 2017, 3:03:32 AM9/14/17
to ns-3-users
Hi 
I think the following issue has relevant to this ongoing discussion:
I was looking at the  wifi-spectrum-per-example.cc  example. 

I tried to change the noisefigure with the YansWifiPhyHelper / SpectrumWifiPhyHelper  , but couldn't understand why I didn't see any change in the output snr reported by the MonitorSniffRx  module.
 
After some digging into the ns3 src code, I found that there is a mistake in the way the snr is calculated in the yans-wifi-phy.cc and sprectrum-wify-phy.cc  modules.

The line:
signalNoise.noise = RatioToDb (event->GetRxPowerW () / snrPer.snr) - GetRxNoiseFigure () + 30;
 
should be changes to: 

signalNoise.noise = RatioToDb (event->GetRxPowerW () / snrPer.snr) + 30;

That solves the problem and will give the right results.  (matching also manual calculations with the same parameters)

Regards Izydor

Rediet

unread,
Sep 20, 2017, 8:50:24 AM9/20/17
to ns-3-users
Hi Izydor,

Thanks for the info, Tom has submitted a bug so that it can be analyzed further.

Rediet

Ansil Shajil

unread,
Feb 7, 2018, 12:13:31 AM2/7/18
to ns-3-users
The uploaded wifi-spectrum-per-interference file is giving a lot of compiling errors. Is it the same code's output you ve put as screenshots or did you modify ?
Message has been deleted

Ansil Shajil

unread,
Feb 8, 2018, 1:13:31 AM2/8/18
to ns-3-users
Is he saying co channel interference is present because the number of packets is less than 1000 ? Can someone clarify this . If that is the case then Channel 1 & 2 has Adjacent Channel Interference ?
Also i want to know how collision is being modeled . It should be based on Co Channel Interference right ?

Rediet

unread,
Feb 8, 2018, 5:14:03 AM2/8/18
to ns-3-users
Hello,

Please do rephrase your questions. It would also be much clearer if you specify to which comment you are referring to (4 people in this thread).

Rediet

Ansil Shajil

unread,
Feb 9, 2018, 12:04:39 AM2/9/18
to ns-3-users
As per Marek Ciesla first/second mail , the wifi-spectrum-interference-per.cc file gives compilation errors.

As per the second mail dated 8/19/17 all cases except case2 - channel 1 1, AP and station are deployed on 2 different channels. only in case channel 1 11, both clients receive equal number (1000) packets. All other cases, client 2 receives less packets.

 Is he saying co channel interference is present because the number of packets is less than 1000 ? Can someone clarify this . 
If that is the case then Channel 1 & 2 has Adjacent Channel Interference  since both Aps are deployed on different channels.

I also want to know how collision is being modelled in ns3. Is it based on co-channel interference ? 
Reply all
Reply to author
Forward
0 new messages