Interference among WiFi-transmission with Spectrum-WiFi-Phy and Nist

[Michael Rademacher]

Hi everybody,

I am working on interference with directional antennas in ns. I am facing a problem with a specific part of my results. At the moment I am unsure if it is a mistake, my misunderstanding, a bug or if I have reached the limits of the ns abstraction layer.

Here is what I have done so far:

• I extended the new Spectrum-WiFi-Phy module to use directional antennas.
  
• I implemented a small antenna-module to read antenna diagrams in the .ant v3 format which is provided by many vendors.

I have not used any existing antenna-module since I am specifically interested in the effects of side-lobes. I have verified this part of the implementation pretty excessive and if anybody is interested in the results or using it, let me know. I skip the details here now.

So my first experiment focuses on inter-flow interference. Here is the setting (Please also have look at the first attachment "inter_flow.png"):

Four nodes, forming two WiFi links between have been arranged in a rectangular two-dimensional grid. All nodes are equipped with directional-antennas aligned towards their corresponding partner. There are two important distances x and y; x is set fixed to 1000m and y is incremented for each new run of the simulation. I saturate the medium (Adhoc - MCS7) with UDP-Traffic and use the FlowMonitor to obtain the throughput on each link. In addition, I use the “WifiPhy/SignalArrival” callback to trace the signal-strength originating from specific nodes. Two signal-strengths are of interested, the parallel-interference (Par.) and the cross-interference (Cr.).

Please have a look at the second attachment which are the first results when the traffic is sent from 3→2 and 2→1 (case A). It shows the side-lobes (from the cross-interference) as expected in a wave-form. The parallel interference decreases according to the FSPL model. The other black line shows the EnergyDetectionThreshold, which is set to -95 dBm. I also added the throughput in red and blue.

Almost everything seems logical: In the first part, when both interference signals (parallel and cross) are above the EnergyDetectionThreshold the DCF does their job and both links receive an equal amount of throughput. When both signals are below the EnergyDetectionThreshold they are independent and both saturate the medium.

But. When just the cross-interference signal is above the threshold for example from 690-940m, I would expect a completely different throughput. Why do both stations receive almost the same amount of throughput like when the DCF is involved? Station 3 is unable to detect the transmission from Station 1 and the other way round. The DCF should not work here and I also disabled RTS/CTS. I would expect that both stations continuously sent their packets and that there is interference at the receiver node (node 2 and 0). In fact, I would even assume that the shape of both throughput lines and the cross-interference line are kind of similar. Since more cross-interference should increase the noise, reduce the SNR and therefore reduce the throughput.

When I look inside the debug logs I see that many packets are dropped at station 2 and 0:

“2.04895s 2 SpectrumWifiPhy:StartRx(): drop packet because already in Rx (power=1.07549e-08W)”

If a station is already in Rx or Tx, and another WiFi packet is arriving later, this should increase the noise? From my understanding, the NistErrorRateModel should do exactly this?

Thanks for reading. Any help, hints or discussion would really help me out.

I am currently working on the ns-3 Spectrum-WiFi-Phy branch located here.

With kind regards,

Michael

[Tom Henderson]

On 08/30/2016 08:23 AM, Michael Rademacher wrote:

Hi everybody,

I am working on interference with directional antennas in ns. I am facing a problem with a specific part of my results. At the moment I am unsure if it is a mistake, my misunderstanding, a bug or if I have reached the limits of the ns abstraction layer.

Hi Michael, thanks for a well written description.  Inline below.

Here is what I have done so far:

• I extended the new Spectrum-WiFi-Phy module to use directional antennas.
  
• I implemented a small antenna-module to read antenna diagrams in the .ant v3 format which is provided by many vendors.

I have not used any existing antenna-module since I am specifically interested in the effects of side-lobes. I have verified this part of the implementation pretty excessive and if anybody is interested in the results or using it, let me know. I skip the details here now.

I suspect that others will be interested in this module in the future, so please consider to contribute it someday; anyway, that is beside the point for this post.

So my first experiment focuses on inter-flow interference. Here is the setting (Please also have look at the first attachment "inter_flow.png"):

Four nodes, forming two WiFi links between have been arranged in a rectangular two-dimensional grid. All nodes are equipped with directional-antennas aligned towards their corresponding partner. There are two important distances x and y; x is set fixed to 1000m and y is incremented for each new run of the simulation. I saturate the medium (Adhoc - MCS7) with UDP-Traffic and use the FlowMonitor to obtain the throughput on each link. In addition, I use the “WifiPhy/SignalArrival” callback to trace the signal-strength originating from specific nodes. Two signal-strengths are of interested, the parallel-interference (Par.) and the cross-interference (Cr.).

Are you using Ideal or MinstrelHt rate control?

Please have a look at the second attachment which are the first results when the traffic is sent from 3→2 and 2→1 (case A). It shows the side-lobes (from the cross-interference) as expected in a wave-form. The parallel interference decreases according to the FSPL model. The other black line shows the EnergyDetectionThreshold, which is set to -95 dBm. I also added the throughput in red and blue.

Almost everything seems logical: In the first part, when both interference signals (parallel and cross) are above the EnergyDetectionThreshold the DCF does their job and both links receive an equal amount of throughput. When both signals are below the EnergyDetectionThreshold they are independent and both saturate the medium.

But. When just the cross-interference signal is above the threshold for example from 690-940m, I would expect a completely different throughput. Why do both stations receive almost the same amount of throughput like when the DCF is involved? Station 3 is unable to detect the transmission from Station 1 and the other way round. The DCF should not work here and I also disabled RTS/CTS. I would expect that both stations continuously sent their packets and that there is interference at the receiver node (node 2 and 0). In fact, I would even assume that the shape of both throughput lines and the cross-interference line are kind of similar. Since more cross-interference should increase the noise, reduce the SNR and therefore reduce the throughput.

I do not expect DCF to be involved since Par signal level is so low (they are hidden from one another).  I would expect instead that both transmitters would send as fast as they can and that there would be collisions at the receiver, and depending on the timing of frames, some may get through and most would collide.  I would probably expect the throughputs to be similar since the scenario is symmetric, but whether it should be this high (27 Mb/s) or not, I don't know.  Basically, this suggests to me that both nodes are able to squeeze enough frames through during the times in which the other node is not sending for some reason.

I suggest to look at the proportion of time (using the signal trace) that each sending node is active on the channel, and then see whether this is consistent with these nodes being able to get that much throughput through.

When I look inside the debug logs I see that many packets are dropped at station 2 and 0:

“2.04895s 2 SpectrumWifiPhy:StartRx(): drop packet because already in Rx (power=1.07549e-08W)”

If a station is already in Rx or Tx, and another WiFi packet is arriving later, this should increase the noise? From my understanding, the NistErrorRateModel should do exactly this?

It will increase the noise; at an earlier part of the code, the signal is passed to the InterferenceHelper (regardless of this drop).  This drop log is just saying that there is no way that the reception will be successful, but the frame is still accounted for as interference (noise).

Thanks for reading. Any help, hints or discussion would really help me out.

I am currently working on the ns-3 Spectrum-WiFi-Phy branch located here.

Please note that this branch has been merged to ns-3-dev, and no further work on it is planned, so please cut over to track ns-3-dev when you are ready.

- Tom

[Michael Rademacher]

Hi Tom, 

Thank for your very quick response. I spent the last day with some additional testing based on your suggestion and I made some progress. I stick with replying inline. 

On Tuesday, 30 August 2016 19:26:39 UTC+2, Tom Henderson wrote:

On 08/30/2016 08:23 AM, Michael Rademacher wrote:

Hi everybody,

I am working on interference with directional antennas in ns. I am facing a problem with a specific part of my results. At the moment I am unsure if it is a mistake, my misunderstanding, a bug or if I have reached the limits of the ns abstraction layer.

Hi Michael, thanks for a well written description.  Inline below.

Here is what I have done so far:

• I extended the new Spectrum-WiFi-Phy module to use directional antennas.
  
• I implemented a small antenna-module to read antenna diagrams in the .ant v3 format which is provided by many vendors.

I have not used any existing antenna-module since I am specifically interested in the effects of side-lobes. I have verified this part of the implementation pretty excessive and if anybody is interested in the results or using it, let me know. I skip the details here now.

I suspect that others will be interested in this module in the future, so please consider to contribute it someday; anyway, that is beside the point for this post.

So my first experiment focuses on inter-flow interference. Here is the setting (Please also have look at the first attachment "inter_flow.png"):

Four nodes, forming two WiFi links between have been arranged in a rectangular two-dimensional grid. All nodes are equipped with directional-antennas aligned towards their corresponding partner. There are two important distances x and y; x is set fixed to 1000m and y is incremented for each new run of the simulation. I saturate the medium (Adhoc - MCS7) with UDP-Traffic and use the FlowMonitor to obtain the throughput on each link. In addition, I use the “WifiPhy/SignalArrival” callback to trace the signal-strength originating from specific nodes. Two signal-strengths are of interested, the parallel-interference (Par.) and the cross-interference (Cr.).

Are you using Ideal or MinstrelHt rate control?

I am using the ConstantRateWifiManager. At the beginning, I want to avoid the additional complexity of any rate adaption. 

 

Please have a look at the second attachment which are the first results when the traffic is sent from 3→2 and 2→1 (case A). It shows the side-lobes (from the cross-interference) as expected in a wave-form. The parallel interference decreases according to the FSPL model. The other black line shows the EnergyDetectionThreshold, which is set to -95 dBm. I also added the throughput in red and blue.

Almost everything seems logical: In the first part, when both interference signals (parallel and cross) are above the EnergyDetectionThreshold the DCF does their job and both links receive an equal amount of throughput. When both signals are below the EnergyDetectionThreshold they are independent and both saturate the medium.

But. When just the cross-interference signal is above the threshold for example from 690-940m, I would expect a completely different throughput. Why do both stations receive almost the same amount of throughput like when the DCF is involved? Station 3 is unable to detect the transmission from Station 1 and the other way round. The DCF should not work here and I also disabled RTS/CTS. I would expect that both stations continuously sent their packets and that there is interference at the receiver node (node 2 and 0). In fact, I would even assume that the shape of both throughput lines and the cross-interference line are kind of similar. Since more cross-interference should increase the noise, reduce the SNR and therefore reduce the throughput.

I do not expect DCF to be involved since Par signal level is so low (they are hidden from one another).  I would expect instead that both transmitters would send as fast as they can and that there would be collisions at the receiver, and depending on the timing of frames, some may get through and most would collide.  I would probably expect the throughputs to be similar since the scenario is symmetric, but whether it should be this high (27 Mb/s) or not, I don't know.  Basically, this suggests to me that both nodes are able to squeeze enough frames through during the times in which the other node is not sending for some reason.

I suggest to look at the proportion of time (using the signal trace) that each sending node is active on the channel, and then see whether this is consistent with these nodes being able to get that much throughput through.

Your expectations were right, there are collisions at the receivers. I was unlucky that in my previous test, the DCF throughput and the throughput without the DCF involved (690-940m) are very similar using MCS7.  This pointed me to a false conclusion that the DCF is involved between  690-940m. 

To confirm your expectation I modified my experiment:

• I used MCS3 instead of MCS7,
• I significantly increased the gain of the side-lobe at one point,
• I traced the average CWmax value of the EdcaTxopN and added it to the plot (sorry for so many lines in the plot).

I attached the new results to this post. 

In the interesting part, from 690-940m, the throughput is now higher compared to the equal share at the beginning where the DCF handles the medium. The throughput is closer to the part where both transmissions are independent. From the CWmax line, it is possible to see that there are collisions. The average CWmax increases from its default 15 to an average of more than 200 between 690-940m. Therefore, a station can transmit one or even multiple complete A-MPDU while the other is in a large backoff. This explain the high throughput. 

The peak of the cross-interference with -50 dB shows the contemplated  significantly increased gain of the side-lobe at one point. Here the throughput drops significantly. From the debug log I learned, that when two Frames Collide at the receiver it reports significantly higher BER compared to a cross-interference signal of just -90 dB. This makes sense. I also learned about the very steep BER-SNR curves from the technical report about the NistErrorRateModel. So there will be no bowl-shape.  But why does the average CWmax decreases here? There should be even more collisions. Any ideas?

Another strange thing occurs for me in the debug log of the NistErrorRateModel:

5.56767s 0 NistErrorRateModel:Get16QamBer(): 16-Qam snr=134340 ber=0

5.56767s 2 NistErrorRateModel:Get16QamBer(): 16-Qam snr=80998.2 ber=0

5.56815s 0 NistErrorRateModel:Get16QamBer(): 16-Qam snr=134340 ber=0

5.56815s 2 NistErrorRateModel:Get16QamBer(): 16-Qam snr=80998.2 ber=0

 

These snr values seem to be very high and kind of arbitrary. Perhaps when there is no real-noise reported by the Spectrum-WiFi-Phy there is an init problem with the noise value?   

When I look inside the debug logs I see that many packets are dropped at station 2 and 0:

“2.04895s 2 SpectrumWifiPhy:StartRx(): drop packet because already in Rx (power=1.07549e-08W)”

If a station is already in Rx or Tx, and another WiFi packet is arriving later, this should increase the noise? From my understanding, the NistErrorRateModel should do exactly this?

It will increase the noise; at an earlier part of the code, the signal is passed to the InterferenceHelper (regardless of this drop).  This drop log is just saying that there is no way that the reception will be successful, but the frame is still accounted for as interference (noise).

Thanks for reading. Any help, hints or discussion would really help me out.

I am currently working on the ns-3 Spectrum-WiFi-Phy branch located here.

Please note that this branch has been merged to ns-3-dev, and no further work on it is planned, so please cut over to track ns-3-dev when you are ready.

I tried to merge my code  to ns-3-dev ( 12276:8156de57e4a6) at the beginning of the week but I ran into multiple issue. First, I need to apply your commit from github " wifi: copy Packet to allow multiple devices to modify ". It seems not to be merged into ns-3-dev yet? Second, I ran into bug 2477 . If you need some logs or additional information let me know.  I think I am waiting for ns-3.26 to be release before I conduct an additional merge attempt. 

Thank you,

Michael

 

- Tom

[Tom Henderson]

You mention 'average CWmax value' above, but the model puts out an instantaneous traced value of CW in the EdcaTxopN::CwTrace-- are you doing smoothing of those values?  Can you clarify what you mean by 'average CWmax'?

Another strange thing occurs for me in the debug log of the NistErrorRateModel:

5.56767s 0 NistErrorRateModel:Get16QamBer(): 16-Qam snr=134340 ber=0

5.56767s 2 NistErrorRateModel:Get16QamBer(): 16-Qam snr=80998.2 ber=0

5.56815s 0 NistErrorRateModel:Get16QamBer(): 16-Qam snr=134340 ber=0

5.56815s 2 NistErrorRateModel:Get16QamBer(): 16-Qam snr=80998.2 ber=0

 

These snr values seem to be very high and kind of arbitrary. Perhaps when there is no real-noise reported by the Spectrum-WiFi-Phy there is an init problem with the noise value? 

The method InterferenceHelper::CalculateSnr() is responsible for SNR, and in absence of interference, this will be the signal divided by the thermal noise.  If you enable debug logging of InterferenceHelper, you will see:

  NS_LOG_DEBUG ("bandwidth(MHz)=" << channelWidth << ", signal(W)= " << signal << ", noise(W)=" << noiseFloor << ", interference(W)=" << noiseInterference << ", snr(linear)=" << snr);

These values are linear (non-dB) scale.

When I look inside the debug logs I see that many packets are dropped at station 2 and 0:

“2.04895s 2 SpectrumWifiPhy:StartRx(): drop packet because already in Rx (power=1.07549e-08W)”

If a station is already in Rx or Tx, and another WiFi packet is arriving later, this should increase the noise? From my understanding, the NistErrorRateModel should do exactly this?

It will increase the noise; at an earlier part of the code, the signal is passed to the InterferenceHelper (regardless of this drop).  This drop log is just saying that there is no way that the reception will be successful, but the frame is still accounted for as interference (noise).

Thanks for reading. Any help, hints or discussion would really help me out.

I am currently working on the ns-3 Spectrum-WiFi-Phy branch located here.

Please note that this branch has been merged to ns-3-dev, and no further work on it is planned, so please cut over to track ns-3-dev when you are ready.

I tried to merge my code  to ns-3-dev ( 12276:8156de57e4a6) at the beginning of the week but I ran into multiple issue. First, I need to apply your commit from github " wifi: copy Packet to allow multiple devices to modify ". It seems not to be merged into ns-3-dev yet? Second, I ran into bug 2477 . If you need some logs or additional information let me know.  I think I am waiting for ns-3.26 to be release before I conduct an additional merge attempt.

Thanks for reminding me of the 'copy Packet' fix that I neglected to add to ns-3-dev; will add it now.

Bug 2477 needs investigation, I agree.

- Tom

[Michael Rademacher]

Again, you pointed me to the right direction. The EdcaTxopN::CwTrace was a bad decision in my experiment. I found that it only fires when the Cw values changes (lost Back, collision, successful transmission and a reset to 15). To calculate an average number of Backoff Slots using this trace is non-sense so my previous plot is wrong. 

The better choice is the EdcaTxopN::BackoffTrace. It fires even if the Backoff Slots stays constant/for every transmission. I used the ns3::average class to calculate the average and the standard deviation. 

I ran the simulations again and the result are pretty good. The average Backoff increases in conjunction with the parallel interference. I have attached it to this post if you are interested.

It seems like the Spectrum-WiFi-Phy is really powerful in modeling WiFi interference. Thanks again for your work. 

[Hadi Samani]

Hello Michael,

Could you please help me, How did you get the Interference and Noise value
And which propagationloss model did you use?

Best Regards
Hadi

[Michael Rademacher]

Hello Hadi, 

Sorry for the delayed reply but I was on vacation for two weeks.

I am using the SignalArrival callback function. Here is the line in the main function. 

WifiCallbacks n0callback;

Config::Connect ("/NodeList/0/DeviceList/*/$ns3::WifiNetDevice/Phy/$ns3::WifiPhy/SignalArrival", MakeCallback (&WifiCallbacks::SpectrumSignalArrival, &n0callback))

WiFiCallbacks is a helper class I wrote myself. In this class there is a function called SpectrumSignalArrival. 

void

WifiCallbacks::SpectrumSignalArrival (std::string context, bool signalType, uint32_t senderNodeId, double rxPower, Time duration)

{

// Evaluation of the callback

}

I hope this helps. 

With kind regards, 

Michael

[Chetan]

Hi Michael,

I would like to know more details on how you extended the new Spectrum-WiFi-Phy module to use directional antennas.

Did you have any patch for it? If not can you provide me any information on how to proceed.

Regards,

Chetan

[Michael Rademacher]

Dear Chetan, 

At the moment, I am in the process of publishing a paper about my results regarding interference with directional antennas. This process also involves a little bit of refactoring of the modules that I have written/extended.

I can try to provide you with a preliminary patch set for ns-3 3.26 if you want to test it right now. 

With kind regards, 

Michael