Wireless Protocol Question

Hello,

I have a question about the 802.11g protocol.

If you have 10 users connected to an AP, 9 of them are close and can
get speeds of up to 54Mb/s, 1 of them is right on the range point and
can only connect at 1Mb/s, is it true everyone will be limited to
1Mb/s?

i.e. Is it true that all users are dragged down to same speed as the
slowest connected user?

I've been told today that this is the case, however I don't believe
what I'm being told, but I've had a hard time trying to find something
specific in plain english that answers this.

If you know the answer to this, I'd also love a link to a technical
document if you have one. If I go back and say to the person "It's not
true, according to an Internet forum post" I'm not really going to have
a leg to stand on, however if I say that -and- have some hard
documentation, I will!

Many thanks,

muppet


------------------------------------------------------------------------
View this thread: http://www.wirelessforums.org/showthread.php?t=29857
http://www.wirelessforums.org

muppet <(E-Mail Removed)> hath wroth:

>I have a question about the 802.11g protocol.
>
>If you have 10 users connected to an AP, 9 of them are close and can
>get speeds of up to 54Mb/s, 1 of them is right on the range point and
>can only connect at 1Mb/s, is it true everyone will be limited to
>1Mb/s?
>
>i.e. Is it true that all users are dragged down to same speed as the
>slowest connected user?
>
>I've been told today that this is the case, however I don't believe
>what I'm being told, but I've had a hard time trying to find something
>specific in plain english that answers this.
>
>If you know the answer to this, I'd also love a link to a technical
>document if you have one. If I go back and say to the person "It's not
>true, according to an Internet forum post" I'm not really going to have
>a leg to stand on, however if I say that -and- have some hard
>documentation, I will!

See:
<http://standards.ieee.org/getieee802/802.11.html>
You'll need:
IEEE-802.11-1999
IEEE-802.11b-1999
IEEE-802.11b/COR1-2001
IEEE-802.11g-2003
Warning: Reading these have been known to turn one's brain to mush.

The question is a bit muddled because two things are happening at the
same time. Most packets run at individual connection speeds, but not
in all modes or with all types of packets. The details:

Only one user can move traffic to/from an access point at a time. The
system is essentially simplex, where the AP and clients can only
transmit or receive, one at a time.

802.11g access points usually have at least two modes. The AP can be
in 802.11g mode, where the speed it 6-54Mbits/sec and the modulation
is OFDM, or it can be in the 802.11b compatibility mode, where the
speeds are 1-11Mbits/sec using various modulation schemes. There also
modes not specified which are used to obtain speeds greater than
54Mbits/sec. The problem is that when the AP is in one mode, it
cannot decode transmissions sent in the other modes.

Depending upon the algorithms used, switching between 802.11g,
802.11b, and Turbo-Whatever modes can be quite sluggish. This is what
I believe your sources were discussing. In the dim and disgusting
past, when a single 802.11b packet was heard, other traffic thruput
would slow down drastically because the AP was multiplexing between
802.11b mode and 802.11g mode. Typical was about 25-50% of the time
went to 802.11b. During this time, no 802.11g traffic could move.
802.11b also takes much more air time than the same amount of data
using 802.11g, so it can really impact the speed of the system.
There's a speed table, which uses this scheme, in the FAQ at:
<http://wireless.wikia.com/wiki/Wi-Fi#Performance_and_Speed>

More modern chipsets and algorithms have eliminated the fixed time
slicing and replaced it with a more efficient algorithm. I'm too lazy
to dig out the patents, but basically it prevents the 802.11b mode
from hogging too much AP time. The same is true for the faster
speeds, which can also do the same thing. To maintain high airtime
efficiency, it's fairly common for capacity limited systems (such as
WISP systems) to just disable 802.11b compatibility and to not support
turbo modes.

The other part of the question is whether each 802.11g client can
connect at its own favorite speed or whether the access point give
everyone the same speed as the slowest connection (assuming 802.11b
compatibility mode is disabled). It would be really dumb to run the
system at speed of the slowest client. Each connection speed is
independent. The proof is somewhere in the IEEE 802.11 specs. If you
can't find the reference, I'll dig for it when I have time.

Also, there's the not so minor problem of communicating 802.11
management and control packets (such as beacon, probe, auth, assoc,
flow control, etc). In 802.11b, they are all transmitted at the
slowest speed of 1Mbit/sec. I think it's the same with 802.11g at
6Mbits/sec, but I'm not sure and need to read the specs.

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Thu, 4 Oct 2007 10:23:00 -0400, muppet <(E-Mail Removed)> wrote:

~
~ Hello,
~
~ I have a question about the 802.11g protocol.
~
~ If you have 10 users connected to an AP, 9 of them are close and can
~ get speeds of up to 54Mb/s, 1 of them is right on the range point and
~ can only connect at 1Mb/s, is it true everyone will be limited to
~ 1Mb/s?
~
~ i.e. Is it true that all users are dragged down to same speed as the
~ slowest connected user?
~
~ I've been told today that this is the case, however I don't believe
~ what I'm being told, but I've had a hard time trying to find something
~ specific in plain english that answers this.

Here's the way I like to think of this.

A bit encoded at 1Mbps is 54 times "fatter" (longer duration) than a bit
encoded at 54Mbps.

So, the data sent/received by your 1Mbps client hogs the channel because
its bits are so fat.

Does the 1Mbps client limit everyone else to 1Mbps? Not really, because,
if the 1Mbps client isn't sending or receiving data, then the channel is
free for your 54Mbps clients to send/receive their skinny bits.

Now: it's not QUITE as simple as this. There are a couple of ways that
your 1Mbps client might slow everyone down even when it's not active:

1) with 1Mbps client, beacons and other stuff will have to go out at 1Mbps,
so that's more overhead on the channel. If you limit yourself to only
support the 54 rate, then ALL bits (even the beacons) are skinny.

2) if the 1Mbps client is an 802.11b-only client, then its presence in
the BSSID is going to force the 11g devices to use RTS/CTS or CTS-to-self
protection. This will slow them all down due to greater MAC layer overhead.

The question you have to ask yourself is: how big a coverage area do you
want your AP to provide? Then, figure out the highest bit rate that will
reliably cover that coverage area. Then, disable bit rates lower than
that. This will optimize your 802.11 performance given your cell's radius.

Aaron

Aaron Leonard <(E-Mail Removed)> hath wroth:

>2) if the 1Mbps client is an 802.11b-only client, then its presence in
>the BSSID is going to force the 11g devices to use RTS/CTS or CTS-to-self
>protection. This will slow them all down due to greater MAC layer overhead.

I'm not 100% sure (which has never stopped me from posting wrong info)
but methinks that this is not exactly correct. If you fix the
wireless rate of your access point at 54Mbits/sec, methinks the
beacons still go out at the slowest OFDM rate of 6Mbit/sec, not at
54Mbits/sec. That's so stations that have not yet associated can
monitor with a common protocol for 802.11g.

It's the same with 802.11b, where all management junk, including
beacons, gets belched at 1Mbit/sec, the slowest speed.

I'll see if I can determine if my guess(tm) is correct. I'm not quite
sure how as none of my utilities will display the speed of the
management packets, just the data rates. I guess I'll just have to
read the IEEE specs, something I'm not looking forward to doing.

Bingo. I just found an easy way to test. Using DD-WRT, I got the
following (edited) report:

# site_survey
[ 0] SSID[ NETGEAR] BSSID[00:1B:2F:4F:60:AC] channel[11]
rssi[-88] noise[-93] beacon[100] cap[421] dtim[0] rate[12] enc[Open]

Methinks rate[12] is 24Mbits/sec. There's no way that my probe
request is scanning 11 channels *AND* 15 speeds. The response for the
8 or so access points I can see is just too quick for 165 probe
requests and responses). If this Netgear router were only operating
at 54Mbits/sec (including beacons), then the AP scanner would never
hear it. However, it it's doing all the management junk at
6Mbits/sec, and my client was only scanning at 6Mbit/sec, then it
should work as shown.

I'm still not 100.0% sure, am willing to be proven wrong, will read
IEEE-802.11g-2003, and will report what I excavate when my brain
recovers.

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Thu, 04 Oct 2007 13:11:48 -0700, Jeff Liebermann <(E-Mail Removed)>
wrote:

>Aaron Leonard <(E-Mail Removed)> hath wroth:
>
>>2) if the 1Mbps client is an 802.11b-only client, then its presence in
>>the BSSID is going to force the 11g devices to use RTS/CTS or CTS-to-self
>>protection. This will slow them all down due to greater MAC layer overhead.

>I'm not 100% sure (which has never stopped me from posting wrong info)
>but methinks that this is not exactly correct. If you fix the
>wireless rate of your access point at 54Mbits/sec, methinks the
>beacons still go out at the slowest OFDM rate of 6Mbit/sec, not at
>54Mbits/sec. That's so stations that have not yet associated can
>monitor with a common protocol for 802.11g.
>
>It's the same with 802.11b, where all management junk, including
>beacons, gets belched at 1Mbit/sec, the slowest speed.
>
>I'll see if I can determine if my guess(tm) is correct. I'm not quite
>sure how as none of my utilities will display the speed of the
>management packets, just the data rates. I guess I'll just have to
>read the IEEE specs, something I'm not looking forward to doing.

My guess(tm) was correct. Buried deep inside the IEEE 802.11a-1999
specification and camouflaged with acronyms and legalese:

17.3.7 PLCP data modulation and modulation rate change

The PLCP preamble shall be transmitted using an OFDM modulated fixed
waveform. The IEEE 802.11 SIGNAL field, BPSK-OFDM modulated at
6 Mbit/s, shall indicate the modulation and coding rate that shall
be used to transmit the MPDU. The transmitter (receiver) shall
initiate the modulation (demodulation) constellation and the coding
rate according to the RATE indicated in the SIGNAL field. The MPDU
transmission rate shall be set by the DATARATE parameter in the
TXVECTOR, issued with the PHYTXSTART.request primitive described
in 17.2.2.

Translation: The transmitter belches a PLCP (physical layer
convergence procedure) broadcast packet at 6Mbit/sec. In this packet
is the speed at which subsequent data packets are going to be spent.
The receiver then switches from 6Mbit/sec to whatever speed is
specified.

It took me about 30 minutes to find that. It may take all night to
recover from the resultant brain mush. Maybe some wine will help.
Please don't ask any intelligent questions for a while. Thanks.


--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 (E-Mail Removed)
# http://802.11junk.com (E-Mail Removed)
# http://www.LearnByDestroying.com AE6KS

~ >>2) if the 1Mbps client is an 802.11b-only client, then its presence in
~ >>the BSSID is going to force the 11g devices to use RTS/CTS or CTS-to-self
~ >>protection. This will slow them all down due to greater MAC layer overhead.
~
~ >I'm not 100% sure (which has never stopped me from posting wrong info)
~ >but methinks that this is not exactly correct. If you fix the
~ >wireless rate of your access point at 54Mbits/sec, methinks the
~ >beacons still go out at the slowest OFDM rate of 6Mbit/sec, not at
~ >54Mbits/sec. That's so stations that have not yet associated can
~ >monitor with a common protocol for 802.11g.
~ >
~ >It's the same with 802.11b, where all management junk, including
~ >beacons, gets belched at 1Mbit/sec, the slowest speed.

~ My guess(tm) was correct. Buried deep inside the IEEE 802.11a-1999
~ specification and camouflaged with acronyms and legalese:
~
~ 17.3.7 PLCP data modulation and modulation rate change
~
~ The PLCP preamble shall be transmitted using an OFDM modulated fixed
~ waveform. The IEEE 802.11 SIGNAL field, BPSK-OFDM modulated at
~ 6 Mbit/s, shall indicate the modulation and coding rate that shall
~ be used to transmit the MPDU. The transmitter (receiver) shall
~ initiate the modulation (demodulation) constellation and the coding
~ rate according to the RATE indicated in the SIGNAL field. The MPDU
~ transmission rate shall be set by the DATARATE parameter in the
~ TXVECTOR, issued with the PHYTXSTART.request primitive described
~ in 17.2.2.
~
~ Translation: The transmitter belches a PLCP (physical layer
~ convergence procedure) broadcast packet at 6Mbit/sec. In this packet
~ is the speed at which subsequent data packets are going to be spent.
~ The receiver then switches from 6Mbit/sec to whatever speed is
~ specified.
~
~ It took me about 30 minutes to find that. It may take all night to
~ recover from the resultant brain mush. Maybe some wine will help.
~ Please don't ask any intelligent questions for a while. Thanks.

I keep my brain nice and rock-solid by assiduous avoidance of IEEE
specs at almost all costs. Thus you can count on the following point
being uncorrupted by any actual reading of the standards:

* 802.11 frames are actually transmitted with different parts encoded
at different bit rates! The front of the frame has to be encoded in the
lowest bit rate that is valid for that band (1Mbps for 2.4GHz, 6Mbps
for 5GHz), so that all devices on that channel know how long to stay
silent in order to avoid stepping on the rest of the frame. (Collision
Avoidance.) However, the rest of the frame can then be encoded
in a higher bit rate (so the payload may be unintelligible to some devices.) *

So, MOST of each beacon frame (where "most" is by % of bits if not duration)
may indeed be transmitted at 54Mbps or whatever.

(This is why I did some handwaving in my earlier post.)

Aaron

P.S. Sorry Jeff about the bad BEFW11S4 V4 1.52.06 code. I finally got
around to trying it myself a little while ago and also found that the
file was corrupt. My BEFW11S4 V4 code connection has dried up on me,
so I'm afraid that I've pretty much given up hope on rehabilitating this
sorry little sucker.

Aaron Leonard <(E-Mail Removed)> hath wroth:

>I keep my brain nice and rock-solid by assiduous avoidance of IEEE
>specs at almost all costs. Thus you can count on the following point
>being uncorrupted by any actual reading of the standards:

It's been a while since I've dived into the 802.11 specification briar
patch. It seems that the original 802.11 and 802.11b specifications
were written by academics and engineers. 802.11a seemed to be written
by academics trying to write like lawyers. 802.11g is pure legalese
tangle and was certainly written by an army of lawyers.

>* 802.11 frames are actually transmitted with different parts encoded
>at different bit rates! The front of the frame has to be encoded in the
>lowest bit rate that is valid for that band (1Mbps for 2.4GHz, 6Mbps
>for 5GHz), so that all devices on that channel know how long to stay
>silent in order to avoid stepping on the rest of the frame. (Collision
>Avoidance.) However, the rest of the frame can then be encoded
>in a higher bit rate (so the payload may be unintelligible to some devices.) *

Yep. Each management frame includes the speed (and duration) of the
following data frames.

>So, MOST of each beacon frame (where "most" is by % of bits if not duration)
>may indeed be transmitted at 54Mbps or whatever.

I beg to differ (again). All packets are proceeded by a PLCP frame,
that sets the speed of the following packets. I think it's handled
differently for beacons and broadcasts. It makes no sense to send a
beacon to all clients, where some of them may be so far away that they
can't decode 54Mbits/sec. Unless the beacon is transmitted
individually to each connected client, then it would need to be
transmitted at a speed that all clients can hear. It would also need
to be tranmitted multiple times, once for each AP at their favorite
connected speed. Methinks this makes no sense and that it would be
more logical to transmit beacons and management frames once and at the
slowest speed.

It's a bit dangerous assuming that the IEEE specs were logically
contrived, but it's possible.

I'll dig some more after I recover from the effects of reading the
IEEE specs and the wine. I'm taking the day off to do some loafing.

>(This is why I did some handwaving in my earlier post.)

Trust, but verify.
Hmm... that should probably be "Trust, but Google anyway".

>Aaron
>
>P.S. Sorry Jeff about the bad BEFW11S4 V4 1.52.06 code. I finally got
>around to trying it myself a little while ago and also found that the
>file was corrupt. My BEFW11S4 V4 code connection has dried up on me,
>so I'm afraid that I've pretty much given up hope on rehabilitating this
>sorry little sucker.

My apologies for waiting 6 months before even trying to load it. I'm
fairly sure that it does a line by line checksum during transfer. I
think that can be fixed. The file size is identical to 1.52.02 so
nothing seems to be lost. However, I'm far to busy to do that now.
I'll probably sacrifice these routers on the hibachi as an offering to
the radio gods.


--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558