Forum

If the PLCP preamble and header are always sent at 1Mb/s and the MPDU can be sent at 2Mb/s, then is the PPDU as a whole 1 or 2 Mb/s? So, does how does the PMD modulate this? Perhaps this is not terribly important but bear with me here, I'm relearning Wi-Fi.

Interesting, I wasnt planning on drilling into the packet level just yet however does this mean that even if we disable thelower data rates the preamble still sends the plcp at 1Mbps?

Hello Jon

When 802.11 first began, there were only two data rates specified: 1.0 Mbit/s and 2.0 Mbit/s.

A PPDU [ PLCP PDU ] is onpassed from the PLCP layer [ Physical Layer Convergence Procedure Layer ] to the PMD layer [ Physical Medium Dependent Layer ].

The PLCP adds on the header and trailer [ if present, e.g. in 802.11g and 802.11a ] components to the PSDU [ PLCP Service Data Unit ].

With an 802.11 PPDU, a preamble and header are added to the beginning of the PSDU.
The preamble comprises of two components:
A Sync sequence and an SFD [ Start of Frame Delimiter ].

The header comprises a Signal field, a Service field, a Length Field and an HEC [ Header Error Correction field ].

Be aware that although the preamble and header are two different entities, many whitepapers and texts simply refer to the preamble/header combination as ?the preamble? or ?the header?. Not correct, but widely used.

For 802.11 [ the original standard ], the preamble/header combination is always transmitted at 1.0 Mbit/s using DBPSK.

However, the PSDU may be transmitted at either 1.0 Mbit/s using DBPSK or 2.0 Mbit/s using DQPSK.

How does the modulator know when to change it?s operational mode when the data rate becomes 2.0 Mbit/s ? Via information contained in the Signal field of the PLCP header.

Thanks to rapid acting electronic circuitry, the modulator is capable of achieving this result.

When 802.11b was introduced, two modes were present: long preamble and short preamble. Long preamble mode was essentially ? a copy ? of the 802.11 PLCP preamble and header construction [ with some changes in the header field contents for example ]. Long preamble mode utilized 1.0 Mbit/s DBPSK for the preamble and header. The actual payload [ PSDU ] could be sent at 1.0 Mbit/s using DBPSK, 2 Mbit/s DQPSK or 5.5 Mbit/s CCK [ Complementary Code Keying ] or 11.0 Mbit/s using CCK.

Short preamble mode utilized 1.0 Mbit/s DBPSK for the preamble and 2.0 Mbit/s DQPSK for the header. The actual payload [ PSDU ] could be sent at 2 Mbit/s DQPSK or 5.5 Mbit/s CCK [ Complementary Code Keying ] or 11.0 Mbit/s using CCK.

When 802.11g [ 802.11a came prior to this, but I will use 802.11g here as an example ] was introduced, a more complex scenario took place. Three frame structures were included:

DSSS Long preamble
HR/DSSS Short preamble
Native ERP preamble

The first two have the same type of structures as mentioned previously. The latter is more complex.
In the Native ERP preamble scenario, we have a preamble transmission period of 16 microseconds and a header transmission period of 4 microseconds.

The header contains one OFDM symbol of 24 bits. However, it is transmitted at 6 Mbit/s [ the lowest mandatory rate of .11a and .11g ?6, 12, 24 ] using BPSK with rate 1/2 coding.

The actual ?preamble? structure is totally different from the previous .11, .11b and .11g structures. I won?t go into details here, as it involves a course on it?s own. Suffice to say that in Native mode, it does not run at 1.0 or 2.0 Mbit/s. 802.11n involves similar levels of complexity.

The PSDU may be transmitted at rates ranging from 6.0 to 54 Mbit/s.
The electronics involved do some pretty nifty ?moving about?: OFDM, BPSK, OFDM

In a nutshell, not all preambles and headers are transmitted at 1 and 2 Mbit/s. The modulator can switch very quickly from preamble/header rates to PSDU rates.

Hope this helped.

Dave

DAve

Brilliant answer

If we ahve 802.11b eneabled it still uses these legacy rates?

If we just use 802.11g can we select the data rate, similarly with 802.11a or is it always at the lowest data rate?

What dta rates are selectable for the plcp in 802.11n again is it the lowest supported rate?

For 802.11b, we can have either long preamble or short preamble. For long, both the preamble and header run at 1.0 Mbit/s [ DBPSK ]. For short, the preamble runs at 1.0 Mbit/s [ DBPSK ] and the header runs at 2.0 Mbit/s [ DQPSK ].

For 802.11g and 802.11a, we can select whichever data [ non preamble/non header ] rates are supported.

There are certain terminologies used by the standard and certain ones used by manufacturers. For example, on most AP?s you have a selection of basic, and what are sometimes called ?supported? rates. Basically everyone who wants to be in the BSS has to be capable of transmitting and receiving the basic rates. The beacon should go out at the lowest of the basic rates. Supported rates are the ?extras?. Then in some documentation, you will see 802.11b having Basic Rate [ 1 Mbps DBPSK ], Extended Rate [ 2 Mbps DQPSK ] and Enhanced Rates [ 5.5 Mbps and 11 Mbps CCK]. In the Supported and Extended IE?s you will sometimes see ?In Basic Rate Set? and ?Not in Basic Rate Set?, but referring to the basic rates of the AP. There are only supposed to be 8 entries in the Supported Rates IE, with the ?excess? coming in under the Extended Rates IE. Some implementations have more than 8 in the Supported Rates IE, which can lead to even more confusion.

Confusion also comes in when OFDM is referred to as a modulation technique, which it is not. Unfortunately popular writings continually refer to it as such, and sometimes you ?have to? refer to it as such in order not to allow a thread or conversation to come to an abrupt halt.

Now with .11n it becomes even more complex. Now we have to take into consideration the three different PHY layer types [ HT-Legacy, HT-Mixed, HT-Greenfield ]. Each has a different preamble/header combination. Tables are produced in the 802.11n spec containing detailed information on timing for [ e.g. ] LTF and STF fields.

There are no ?user facilities? available to alter the standard preamble and header values [ this could lead to chaos ]. Only the actual data rates themselves can be altered. .11n uses the terminology of MCS values.

Dave

Ok this is getting interesting.

I can understand that ofdm isnt a modulation technique but for the purists what is is? How would you define it.

OK maybe I missed something, What are IEs.?

Do you have any references where I can read mire?

OFDM is a multiplexing technique and IE's are Information Elements.

I'd put more down but am working on some projects just now.

That stuff was "floating around in my head". I'll need to see if I can dig up some documents on all this.

Dave

Ok, that is what I was thinking in regards to the preamble and header being transmitted at different rates with the the short preamble. So, I guess the rate is technically 2 Mb/s with the header at one but you for all intensive purposes the packet is considered 2 Mb/s. Indeed, all the more reason to think about disabling 802.11b. I was just curious about this interaction, as the modulation would change mid frame if the Sync field indicated to do so. Fascinating, Dave123 you are a wireless guru. I'm glad I asked the question now, since this carries over to 802.11n in principle.

As a further issue, when 802.11g came out, legacy compatability was big on the minds of the IEEE. Two modes: ERP-DSSS and ERP-CCK were supported. The ?biggie? mode was ERP-OFDM [ based on the ground work done on the 802.11a system??well ahead of it?s time and not a great commericial success ]. Protection mechanisms amongst .11, .11b and .11g were provided, such as RTS/CTS [ along with the attendant overall s..l?o?w?i..n?g down of TOTAL throughput, NOT .11g STA?s ?changing? to .11b speeds ].

The IEEE came up with what they thought was a rather nice idea [ which never really caught on ]. Why not have the preamble/header in a DSSS readable format, and the payload in OFDM format ? Inlcuded in the header package was data that indicated the frame length. So, pre .11g folks could read that header and say ?Hey, I can read this little bit of header , and it is telling me that the next ?stuff? that occurs right after this readable header will last for x amount of time, even though it is in OFDM format?. It fell by the wayside due to a bunch of issues [ not the least of which was the fact that the duration/ID field which provides info on how long the transmission SEQUENCE lasts is part of the MAC header [ Frame Control, Duration/ID etc ?.] , and that MAC header is ?after? the PLCP header and of course is in OFDM format, which the STA?s [ legacy ] can?t read anyway.

You may see it mentioned in some obscure questions along with the dear departed PBCC of .11b and g ?fame?.

These guys are tucked away in the depths of the .11 spec and rarely see the light of day. Have woken them up for a minute so that they can get a breath of fresh air:

"ERP-PBCC (Optional)
1) This is a single carrier modulation scheme that encodes the payload using a 256-state packet
binary convolutional code. These are extensions to the PBCC modulation in Clause 18.
ERP-PBCC modes with payload data rates of 22 Mb/s and 33 Mb/s are defined in 19.6.
d) DSSS-OFDM (Optional)
1) This is a hybrid modulation combining a DSSS preamble and header with an OFDM payload
transmission. DSSS-OFDM modes with payload data rates of 6, 9, 12, 18, 24, 36, 48, and
54 Mb/s are defined in 19.7.
2) If the optional DSSS-OFDM mode is used, the supported rates in that mode are the same as the
ERP-OFDM supported rates"

On top of all that, we have the ?joys? of half and quarter clocked OFDM systems which have probably been put to the rest in the great 802.11a cemetery in the sky.

On the positive side think of all the new modes and abbreviations we'll have when 802.11ac gets going !!........well.......on second thoughts........maybe not..........

Dave

Oh my, I didn't expect to drag things like PBCC out. One of those things you read about but never actually see. Speaking of things you never see, the first AP I ever deployed was a token ring 802.11(FHSS) AP for a warehouse. Pretty funny in hindsight since I had no ideas that I was working with something 99% wireless engineers would never get a chance to see.