Bug 689 - default energy detection threshold is not useful
: default energy detection threshold is not useful
Status: RESOLVED FIXED
: ns-3
wifi
: pre-release
: All All
: P3 minor
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2009-09-27 02:43 EDT by
Modified: 2009-11-10 06:43 EDT (History)


Attachments


Note

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


Description From 2009-09-27 02:43:54 EDT
there are many questions on our users mailing-lists related to this: we need to
come up with better defaults. I marked this as P1 to outline that it's an
important user-visible problem and that the fix is technically easy. We just
need to make sure that the new default is agreed upon.

We have 3 proposals for now:
    wifiPhy.Set ("EnergyDetectionThreshold", DoubleValue (-100.0) );
    wifiPhy.Set ("CcaMode1Threshold", DoubleValue (-90.0) );

     wifiPhy.Set ("EnergyDetectionThreshold", DoubleValue (-99.0) );
     wifiPhy.Set ("CcaMode1Threshold", DoubleValue (-94.0) );

     wifiPhy.Set ("EnergyDetectionThreshold", DoubleValue (-96.0) );
     wifiPhy.Set ("CcaMode1Threshold", DoubleValue (-90.0) );
------- Comment #1 From 2009-09-27 11:18:52 EDT -------
Could you provide some references to the sources of the numbers above? Also I
wonder why CCA threshold is larger than the energy detection one. Does that
mean that CCA range can be smaller than TX range using slowest rate?

Considering numbers we find -95/-95 dBm satisfactory until we can measure this
for sure.
------- Comment #3 From 2009-09-28 04:16:31 EDT -------
(In reply to comment #2)
> http://groups.google.com/group/ns-3-users/browse_thread/thread/1397aea914eab983#
> 

 Hmmm, link above looks strange. (The answer to _that_ question is
udp-socket-impl.cc:360 : "If dest is set to the limited broadcast address (all
ones), convert it to send a copy of the packet out of every interface as a
subnet-directed broadcast.") But I guess you just paste wrong link here.
------- Comment #4 From 2009-09-28 05:13:33 EDT -------
ok, that was the one: 

http://groups.google.com/group/ns-3-users/browse_thread/thread/b6c5e8d2863d4ebf
------- Comment #5 From 2009-09-28 11:41:12 EDT -------
  Ok. now I prove that CS and RX (aka energy detection) thresholds are
definitely mixed up in bug description above. Cited paper "Broadcast Reception
Rates and Effects of Priority Access ..." uses CS Threshold = -96dBm and RX
Threshold =  -90dBm (p.13 Tab.3). 

 Personally I find -90 dBm RX threshold too strict and propose to agree on
"world average":

     wifiPhy.Set ("EnergyDetectionThreshold", DoubleValue (-94.0) );
     wifiPhy.Set ("CcaMode1Threshold", DoubleValue (-96.0) );

(In reply to comment #4)
> ok, that was the one: 
> 
> http://groups.google.com/group/ns-3-users/browse_thread/thread/b6c5e8d2863d4ebf
> 
------- Comment #6 From 2009-09-28 21:31:27 EDT -------
I guess the real question is what numbers are closest to real hardware
behavior.  In real hardware, does the packet reception probability decrease
sharply or gradually?  With the EnergyDetection=-99, CcaMode1=-94, the packet
recepetion decreases gradually.  Reverse the numbers, and the reception drops
sharply.  See below, each node is 10 meters from the previous node, node 0 is
the broadcaster (node 20 is 200 meters from the transmitter).  The reception is
the same at 230 meters, but then stops in the second case (ED=-94, Cca=-99). 
Is that the way real hardware works?  The numbers below also had
TxGain=RxGain=4, and RxNoiseFigure=5.

ED=-99, Cca=-94
Number Rx Node 20 = 1911
Number Rx Node 21 = 1911
Number Rx Node 22 = 1911
Number Rx Node 23 = 1909
Number Rx Node 24 = 1906
Number Rx Node 25 = 1889
Number Rx Node 26 = 1795
Number Rx Node 27 = 1544
Number Rx Node 28 = 1014
Number Rx Node 29 = 356
Number Rx Node 30 = 39
Number Rx Node 31 = 0
Number Rx Node 32 = 0

ED=-94, Cca=-99
Number Rx Node 20 = 1911
Number Rx Node 21 = 1911
Number Rx Node 22 = 1911
Number Rx Node 23 = 1909
Number Rx Node 24 = 0
Number Rx Node 25 = 0
Number Rx Node 26 = 0



Which threshold (EnergyDetection or CcaMode1) triggers the CCA_BUSY state? 
Once the PHY enters CCA_BUSY state, which triggers the SYNC state?  Or are
these attributes used interchangeably?  The RxNoiseFigure has a large impact on
the packet reception also, that is probably another attribute that needs to be
considered for "tuning."

(In reply to comment #5)
>   Ok. now I prove that CS and RX (aka energy detection) thresholds are
> definitely mixed up in bug description above. Cited paper "Broadcast Reception
> Rates and Effects of Priority Access ..." uses CS Threshold = -96dBm and RX
> Threshold =  -90dBm (p.13 Tab.3). 
>  Personally I find -90 dBm RX threshold too strict and propose to agree on
> "world average":
>      wifiPhy.Set ("EnergyDetectionThreshold", DoubleValue (-94.0) );
>      wifiPhy.Set ("CcaMode1Threshold", DoubleValue (-96.0) );
> (In reply to comment #4)
> > ok, that was the one: 
> > 
> > http://groups.google.com/group/ns-3-users/browse_thread/thread/b6c5e8d2863d4ebf
> > 
------- Comment #7 From 2009-09-29 10:14:11 EDT -------
(In reply to comment #6)
> I guess the real question is what numbers are closest to real hardware
> behavior.  In real hardware, does the packet reception probability decrease
> sharply or gradually?  

  Packet error probability (PER) is a gradual function of SNR for short enough
packets, you can see experimental figures here:
http://www.nsnam.org/~pei/80211b.pdf Also you can try to find more experimental
results in this papers: http://www.cs.cmu.edu/~emulator/papers.html 

> With the EnergyDetection=-99, CcaMode1=-94, the packet
> recepetion decreases gradually.  Reverse the numbers, and the reception drops
> sharply.  

  That's not because you _reverse_ the thresholds, only EnergyDetection one
affects 2-station scenario. I agree that it should be tuned not to limit
gradual PER(distance) curve in clear channel and -99 dBm works better for this.

> Which threshold (EnergyDetection or CcaMode1) triggers the CCA_BUSY state? 

  Cca... one

> Once the PHY enters CCA_BUSY state, which triggers the SYNC state? 

  PHY goes from CCA_BUSY -> IDLE when transmission ends and IDLE -> SYNC when
new transmission starts and receiving signal > EnergyDetectionThreshold.
Mathieu, please correct me if I am wrong here.  

> Or are these attributes used interchangeably?  The RxNoiseFigure has a large impact on
> the packet reception also, that is probably another attribute that needs to be
> considered for "tuning."

  That's because you experiment with 2 stations without any external
interference (in "clear channel") and thermal noise + RxNoiseFigure are the
only sources of noise. I guess that things will change in presence of other
active stations. I don't know values of receiver noise figure for wifi cards,
first link by google cites 5 dBm
(http://www.openbasestation.org/Newsletters/June2007/Teleasic.htm). 
------- Comment #8 From 2009-10-08 02:42:48 EDT -------
It seems no resolution forthcoming for ns-3.6
------- Comment #9 From 2009-11-06 15:42:21 EDT -------
(In reply to comment #8)
> It seems no resolution forthcoming for ns-3.6

I've been doing a few more experiments, as well as re-reading the references
above.  The following numbers seem to "work well":

    wifiPhy.Set ("EnergyDetectionThreshold", DoubleValue (-96.0) );
    wifiPhy.Set ("CcaMode1Threshold", DoubleValue (-99.0) );

I think it would be to have something in for 3.7.

  Michael
------- Comment #10 From 2009-11-06 15:58:28 EDT -------
Sorry -- I should have also included this additional source.

http://digbib.ubka.uni-karlsruhe.de/volltexte/documents/3253

Schmidt-Eisenlohr, F., M. Torrent-Moreno, et al. (2006). Cumulative Noise and
5.9 GHz DSRC Extensions for ns-2.28, Universitat Karlsruhe (TH).

This is not specifically for generic Wifi, but I think maybe it is closer than
the current -140, -140 default values.

  Michael
------- Comment #11 From 2009-11-10 06:43:35 EDT -------
(In reply to comment #10)
> Sorry -- I should have also included this additional source.
> 
> http://digbib.ubka.uni-karlsruhe.de/volltexte/documents/3253
> 
> Schmidt-Eisenlohr, F., M. Torrent-Moreno, et al. (2006). Cumulative Noise and
> 5.9 GHz DSRC Extensions for ns-2.28, Universitat Karlsruhe (TH).
> 
> This is not specifically for generic Wifi, but I think maybe it is closer than
> the current -140, -140 default values.
> 
>   Michael
> 

  Michael,

  I have pushed default threshold values of -96 and -99 dBm. Thank you for
working on this point.