Changes between Version 8 and Version 9 of 802.11/Usage/BestPractices

Timestamp:

Dec 19, 2014, 4:14:36 PM (9 years ago)

Author:

chunter

Comment:

--

802.11/Usage/BestPractices

@@ -20 +20 @@
 To provide a concrete example of where this function can be useful, consider the [wiki:802.11/wlan_exp/app_notes/dcf_with_multiple_flows DCF with Multiple Flows Application Note]. This experiment was to show the interaction of DCF behaviors on a few nodes in a very small tabletop topology. In this experiment, the Tx power was intentionally lowered to a minimum value (-10dBm), resulting in received powers between [https://warpproject.org/trac/raw-attachment/wiki/802.11/wlan_exp/app_notes/dcf_with_multiple_flows/figs/v1_0_cs_pow_vs_time.png -75 dBm and -70 dBm] for the duration of the experiment. At the same time, in the active scan figure above, we can see that there are other Wi-Fi channels near the scanner that packets as low as -90 dBm. If we set the minimum detection power to, say, -80dBm, we can keep the PHY from being "distracted" by the low-level interference and yet still be able to detect our -75 dBm to -70 dBm traffic with high probability. If we hadn't lowered the Tx power so much, we could potentially raise this threshold much more.
 
-'''Pitfalls:''' The usage of this feature is highly situational. In the multi-flow appnote, it would have fit pretty seamlessly. Care should be taken when trying to use this feature in other applications. Here are some example applications where it may not be appropriate:
+'''Pitfalls:''' The usage of this feature is highly situational. In the multi-flow appnote, it would have fit pretty seamlessly. Care should be taken when trying to use this feature in other applications. Here are some examples where it may not be appropriate:
  * The multi-flow application note had direct line-of-sight links and zero mobility. This had the effect of creating remarkable static channels for the duration of the experiment. You can see this in the plot of receive power, where each line varies minimally. In the presence of non-line-of-sight fading channels like Rayleigh, the receive power of your signal can fluctuate immensely. These fluctuations can potentially drop below the minimum packet detection and cause the design to ignore packets you care about. At a bare minimum, considerably more headroom on this parameter must be allocated when you know that channels will fluctuate significantly.
  * The act of ignoring weak but otherwise-decodable packets has subtle implications on random access protocols that should be considered. For example, ignoring a valid reception because it is weak will prevent clear channel assessment (CCA) from registering and deferring to that packet. If your signal is dramatically more powerful, this may not be an issue since you can likely overpower it and still have the receiver be able to decode your packet. If, however, your packet is just a little bit over the minimum packet detection power threshold and another interfering packet is just below the minimum packet detection power threshold, you could actually wind up causing a collision that might have been avoided if you didn't make your receiver so deaf.