Long Distance 802.11b Timing Issues

coderman | 09/21/2003 - 14:22 |
The 802.11b MAC layer is extremely sensitive to transmission delays that can exceed the tight timing tolerances defined in the IEEE specifications. Some people reading the spec "by the book" have come to the conclusion that this makes any long distance links greater than a few miles an impossibility for the 11Mbps rate. The truth is a bit more complicated.

The core of the timing problem is the 10 microsecond Short Inter-Frame Spacing interval. This delay of 10 millionths of a second is all the 802.11b specification allows for certain high priority packets to begin to be received in response to other packets (like data). I say "begin to be received" because the receive time for an 802.11b ACK packet is a good bit longer than 10uSec.

If you do the calculations you end up with roughly the following:
Speed of Light (and RF): 299 792 458 m/s or 299.8 m/uSec
 x 10uSec for the SIFS
 2,998 meters or 9,836 feet or 1.86 miles.
Obviously that isn't very far, and the fact that people have been able to maintain 11Mbps connections over much longer distances implies something is being miscalculated.

It turns out that the 802.11b spec is implemented in a much more lenient manner in almost every MAC. The 802.11b spec requires other peers to wait at least as long as the Distributed Point Coordination Function Inter-Frame Space (DIFS for short, sheesh) before attempting to transmit. Any seemingly lost frames are also delayed at least the DIFS plus some "contention window" time which is an exponential backoff.

If we plug the math back in, and allow for a loose MAC timing with at least 2xSIFS + DIFS the results look more forgiving:
Speed of Light: 299.8 m/uSec
 x (10 + 10 + 50) 
 20,986 meters or 68,852 feet or 13 miles.
Now if you consider a final optimistic case, where the contention window is honored at 640uSec (every other collision) the distance starts to reach some of the long range links observed in the Real World (tm). Throughput definitely takes a hit, no question, however, the 802.11b MAC does not melt down irrevocably:
Speed of Light: 299.8 m/uSec
 x (10 + 50 + 640) 
 209,860 meters or 130 miles.
Links in excess of 64 miles have been maintained using 24dB grid parabolic antennas with 200mW radios and also consumer cards with 0.5W amplifiers. Slight tweaks to 802.11b MAC parameters make even longer links possible. (NOTE: most of the 40+ mile links are using a lower rate, which relaxes timing issues even more. This is another discussion for a later time :-)

Note that the last two cases assume a dedicated point-to-point link between two clients. The moment you try and do point-to-multipoint over this kind of distance with many clients, you end up with extremely high amounts of contention and collisions due to the delays in critical control packets.

There is one more trick to mention when talking about long distance links: Lucent/Orinoco "demo" ad-hoc mode. This was implemented by Lucent before the IEEE had standardized the IBSS peer-to-peer mode of operation. This special mode does not send ACK's and is thus very handy for long range links or even point-to-multipoint configurations.

You can still access this mode via any prism or hermes chipset under linux with the right wireless tools commands. Below is a table of useful wireless configuration commands that can be used to tune a card for long distance, high latency links. (You will need a good antenna and card for this to work at 11Mbps at a decent distance. My ad-hoc long shot tests always utilize a 16dB yagi and 1W amplifier to ensure strong signal)

# Put card in ad-hoc mode
iwconfig $dev mode ad-hoc

# Disable RTS as this is a point-to-point link - probably not needed
iwconfig $dev rts off

# Place a fragmentation threshold - more loss on precarious p-t-p links
# If you are using point-to-multipoint setting this lower would be a
# good idea
iwconfig $dev frag 1024

# Fix the rate at 11Mbps - remember what I said about good 
# antennas / cards / amps for this distance and rate ...
iwconfig $dev rate 11M

# Turn on the old ad-hoc "demo" mode for peer to peer
iwpriv $dev set_port3 1

# You can verify that you are using the ad-hoc mode if the
# AccessPoint BSSID/MAC in iwconfig is reported as all zero's. 
# If it is your MAC or the peer's MAC, you are using IBSS ad-hoc mode.