|
Distance Limits for 802.11
G'Day
WOW....
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
with...
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.
From http://www.isi.edu/nsnam/archive/ns-users/webarch/2000/msg04162.html
/*
* 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.
Darryl
>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 -
http://www.amazon.com/exec/obidos/ASIN/0596001835/radioactivene-20)
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
____
Welcome to our Techical Site. If you are interested in an overview, then visit our
Marketing Site
Copyright © 1994-2005
Radioactive Networks ,
darryl@radio-active.net.au
This page was last updated 2005-08-31 15:01:58
This page was last compiled 2005-11-15 19:03:13
Question or Comment? Click
here
|
