Bugzilla – Bug 689
default energy detection threshold is not useful
Last modified: 2009-11-10 06:43:35 EST
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) );
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.
http://groups.google.com/group/ns-3-users/browse_thread/thread/1397aea914eab983#
(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.
ok, that was the one: http://groups.google.com/group/ns-3-users/browse_thread/thread/b6c5e8d2863d4ebf
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 >
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 > >
(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).
It seems no resolution forthcoming for ns-3.6
(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
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
(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.