Distance Limits of 802.11
I will re-write the question… You have the Parkes radio-telescope (The Dish 🙂 and you plug your WAP-11 base station into it’s antenna… How far away can you use your laptop with 802.11 , given that you have more gain than you know what to do
The answer comes down to an issue of system timings. For instance GSM mobile phones this is an absolute 35 KM range. The timing breaks if you attempt to go further.
So when does 802.11b break?
The answer is not easy, because it depends on what you mean by break.
If you want to attempt to understand check out Wireless Lans by Geier (http://www.amazon.com/exec/obidos/ASIN/0672320584/radioactivene-20 ) or Wireless Communications and
Networks by Stallings (http://www.amazon.com/exec/obidos/ASIN/0130408646/radioactivene-20). I also have a few specific 802.11 books on
http://www.radio-active.net.au/web/books/ which might be of use.
Looking at the standards the area of interest is the ‘IEEE 802.11 MEDIUM ACCESS CONTROL’ or 802.11 MAC. This standard defines the way in which 802.11 equipment handles the retransmission of packets that are lost so that the ends do not need to worry
about it… Ethernet is good about working out when packets go missing from a cable (The CD in CSMA/CD), so they definied a way of working out when packets are missing on 802.11
The issue is for a long link. The longer the link the more time it takes packets to travel through it.
Light travels at 3E8 M/Sec. This equates to 300 KM/mSec; or 300M/uSec.
/* * IEEE 802.11 Spec, section 15.3.2 * - default values for the DSSS PHY MIB */ #define DSSS_CWMin 31 #define DSSS_CWMax 1023 #define DSSS_SlotTime 0.000020 // 20us #define DSSS_CCATime 0.000015 // 15us #define DSSS_RxTxTurnaroundTime 0.000005 // 5us #define DSSS_SIFSTime 0.000010 // 10us #define DSSS_PreambleLength 144 // 144 bits #define DSSS_PLCPHeaderLength 48 // 48 bits #define DSSS_MinimumBandwidth 1000000.0 // 1Mbit/sec
For a reliable multi-station network, each station must be able to hear a packet being transmitted within the timing of a single ‘SlotTime’. The default ‘SlotTime’ is 20 uSec.
But the standard says that stations must be able to contact the system within the SIFS (Shortest Inter Frame Sequence) for packets such as ACK or CTS. A station must have heard the end of a packet and transmit the packet within the SIFS period, and the
SIFS must not have ended for any station (importantly the first station. The SIFS default is 10 uSec. But since there is the forward and reverse propergation this value is halved to 5 uSec.
5 uSec becomes about 1.5 kM.
Anything over this range becomes unreliable with the default system values.
I have been dealing with these type of systems for over 10 years and I am out of my deapth here… So I might have missed something in my interpretation… In a two station link I would really not see getting over 30 kM…
Q: How can I increase range, if my transmit power is at it’s limit?
A: Add receive antennas. Some AP’s have diversity receive. You can set them to have separate antennas for transmit and receive… Use one for transmit and receive on the other. Have the transmit antenna being as big as legally allowable. For receive add
as many antennas in paralell as you like (There are limites with noise figures and the like but you get the idea)… Use a small whip antenna for transmit and a radio telescope for receive. By splitting the antennas you break the law of repricity.
>The state-owned Swedish Space Corporation (SSC) announced the >establishment of a broadband wireless Wi-Fi link over a distance of 310 >kilometers. This is VERY interesting, and I wonder how they did it. They are certainly bending the WiFi spec, if not breaking it. Lets have a look at a 310 km wireless link. I believe that they are unable to get a throughput on this link more than about 5 mbit bits/sec without overhead. And that is assuming that data rate of the link is fast. Let me explain. 1. We are talking about a data link here where EVERY frame must be acknowledged before the next one is sent. Hams have worked out that this may not be the best idea in the world. Think AX.25 with out another packet being sent before the present one is ackedged. 2. The path... 310KM. Lets assume it really is 300KM. Makes the maths easier. 300 km = 1 mSec ONE WAY. Therefore a two way path delay is 2 mSec. 3. The maximum size of a packet is 2304 bytes (Oreilly 802.11 Wireless Networks Page 42 - 4. The TX time assuming perfection is (2304 * 8/11000000) = 1.675 mSec. RX time will be the same 5. Assuming no retries, from the perspective of the Transmitter... It starts transmitting at T=0 and transmits for 1.675 mSec. 6. Thanks to the time delay (Damn Einstein) the packet starts to be received at T=1 mSec, and finishes receiving at T=2.675 7. The receiver sends back an OK, and it arrives back at T=3.675 mSec 8. This makes a maximum of 272 packets/second meaning 272 * 2304 * 8 = 5 mBit/sec Max throughput 9. But if we run TCP so that we are sure of getting the data off, that requires an ACK at IP level, with a lot of negotiation in order to change direction. I would guess that adding TCP ack would add a minimum 4-6 mSec, making the throughput much lower. 10. If it is 6 mSec, that would mean 9.675 mSec/packet or 103 packets/second or your 11 mBit link has just become a 2 mBit link. Point 9 is the interesting one... This link breaks all sorts of rules. The normal slottime is set at 20 uSec commonly, and the timer before sending a RETRY request is set at somewhere between 5 and 20 uSec as standard. For this link to work at maximum, the timers need to be hand configured. Conclusion. Are these guys completely nuts. There must be a better way to do this than a WIFI link. WiFi is not designed for this. You are looking at 10% useful bitrate used. Another Link Level protocol would work better. AX25 running with 2304 byte payloads and a 11 mbit/sec modem would work better... Darryl