Re: Wireless Protocol Question

On Thu, 4 Oct 2007 10:23:00 -0400, muppet <muppet.2xxo04@no-mx.wirelessforums.org> 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 <Aaron@Cisco.COM> 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 jeffl@cruzio.com
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 <jeffl@cruzio.com>
wrote:

>Aaron Leonard <Aaron@Cisco.COM> 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 jeffl@comix.santa-cruz.ca.us
# http://802.11junk.com jeffl@cruzio.com
# 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 <Aaron@Cisco.COM> 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 jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558