Forum

Hii Everybody..

I have some doubt regarding DSSS-OFDM.How the use of DSSS-OFDM helps in b/g mixed mode without use of any protection mechanism.

Acc. to what i understand (correct me if m wrong)

in DSSS-OFDM Upto PLCP header we transmit using DSSS and rest part including MAC header is transmitted using OFDM.

If this the case is ,then Duration value is also transmitted using OFDM then how a B client will update its NAV as it can decode OFDM coded Duration value and in that case other B clients can start transmission when DSSS-OFDM is transmitting its OFDM part.

Plz help me out in understanding this.

Vinay Saini
Wireless# , CWNA
India

Good question. I actually always assumed that it was because in the DSSS header it has the signal field (speed) and the length field (frame size). With those two values, the DSSS device could determine a duration value. Anyone else?

GThill,
Thanks for replying Vinay's question.

Can Devin/Criss Hyde/Joel give a insight on Vinay's Question.

I have one more question.


Refer Fig 5.3 of CWAP study guide. (Page No :135)
-------------------------------------------------

Figure 5.3 says MPDUMaxlength=4095(or 8191)

May i know why the MAX length of MPDU is so high.
MSDUMax is 2304[more on encrption]and the other fields contribute 32 bytes.

Hi Vinay and others:

The original IEEE 802.11 MAC design has a receiving station read the physical header length field (PLCP Header Length field) and defer transmission for that amount of time regardless of whether reception proceeds to a successful conclusion, breaks off abruptly, or trails off into noise.

Clause 19.7 ERP DSSS-OFDM modulations theoretically (I know of no one who has encountered ERP DSSS-OFDM in the field) build on this by wrapping otherwise ordinary clause 19 ERP-OFDM frames with otherwise ordinary clause 18 HR/DSSS physical headers.

The result is that a nonERP (HR/DSSS or DSSS) receiver sees a good physical header followed immediately by what appears to it to be no more than RF noise for the balance of the time indicated in the physical header.

A significant limitation of this design is that it only "protects" the immediate frame; it does not protect a frame exchange sequence consisting of more than the immediate frame.

ERP vendors have instead relied on CTS frames to precede their ERP-OFDM frames and protect the frames that may follow in the current frame exchange sequence. In this case the receiver, if it correctly receives the entire CTS frame, reads the duration field in the MAC header and defers for the data frame to follow plus a SIFS and an ACK.

I hope this helps. Thanks. /criss

Hi Wizard of Chennai:

Each of the several IEEE 802.11 PHYs has its own Physical Service Data Unit (PSDU) minimum and maximum length.

Clause 14 FSSS: 1-4095 octets
Clause 15 DSSS: 4-8191 octets
Clause 16 IR: 4-65535 octets
Clause 17 OFDM: 1-4095 octets
Clause 18 HR/DSSS: 14-4095 octets
Clause 19 ERP: 14-4095 octets (except for ERP-OFDM: 1-4095)

The maximum 802.11 PHY Protocol Data Unit (PPDU) is the number above plus PHY headers including preamble.

All these 802.11 PHYs share a common 802.11 MAC description. The absolute maximum 802.11 MAC Service Data Unit (MSDU) is 2304 octets (remember this number). The maximum 802.11 MAC Protocol Data Unit (MPDU) is 2304 plus MAC headers including encryption overhead.

I do not know why each PSDU range is precisely what it is. However considerable room is left for innovations to the MAC layer that could seriously fatten up a 2304 octet MSDU.

I hope this helps. Thanks. /criss

Thanx a lot friends , I think ur explanation has helped me a lot in understanding the things.

I got one another doubt , On page 242 of CWAP guide

last 2 lines says "AP always forward mesages in broadcast and multicast"

i cant understand this message forwarding, r they talking bout wireless interface or to wired.

Also last paragraph of the same topic says "Analyzer will not see broadcast/multicast frames which will originate from wired side" what they mean by this?

R they talking bout only bout wired side or wired broadcasts on wireless interface.

This is quite confusing for me . I think u people can help me making the better understanding of the topic as u did last time.

Thanx in advance

Vinay

Hi:

I'll reply to this last post later.

Meanwhile, a correction to my last post above.

Clause 14 is FHSS, not FSSS. Sorry, I need to work more from notes and less from unassisted brain cells.

I urge students to learn the 802.11 PHYs by clause number, by name, and by acronym. The common practice is to refer to them only by the amendment that introduced them, i.e. A, B, G. Using these letters makes marketing products easier, but understanding the technology harder.

I hope this helps. Thanks. /criss

Hi Vinay:

Regarding CWAP page 242, "Message Forwarding":

IEEE 802.11 defines access points as having an optional "portal" service, or a way to move frames between the access point's BSS and any other data-link besides that one.

While the standard does not define the 802.11 portal to operate exactly as an IEEE 802.1 translational bridge between an 802.11 data-link and an 802.3 Ethernet data-link, that is the way that many 802.11 access points are implemented. (A popular alternative routes between WLAN and Ethernet instead of bridges. Virtually all access points use one or both of these two methods.)

This section of the CWAP study guide describes the implications of bridging between what is often a relatively high bandwidth Ethernet and a relatively low bandwidth WLAN. In brief, known unicasts are forwarded but only where needed. Unknown unicasts and all broadcasts and multicasts are forwarded, unless blocked by some deliberate configuration in the access point. That policy may be motivated by precious WLAN bandwidth being consumed by multicasts originating on the Ethernet side that serve little or no purpose on the WLAN side.

Because the translation between data-links changes the frame headers, one should remember that what a WLAN protocol analyzer sees on the WLAN side is not the same frame as seen by an Ethernet protocol analyzer on the Ethernet side even for a single frame that is "forwarded". Instead what one sees is a translation of the original frame or, if blocked by policy, no frame at all.

I hope this helps. Thanks. /criss

Thanx a lot Criss

U r really gud at explaning the thingso one more doubt is here for you and all..

On page 74 of CWAP book point 3 says that WEP encrypts the plain text and ICV while page 75 last line says ICV is not encrypted (easily read by analyzer)..

Can u plz explain me this..

with Thanx
Vinay

Hi Vinay:

The last sentence on page 75 is incorrect. It should read "Notice in the graphic that the IV and Key ID are both in clear text..."

The first sentence on page 76 is correct.

I hope this helps. Thanks. /criss