Forum

Greetings:

I used to be fond of the phrase “atomic event” when speaking of 802.11 frame exchange sequences such as Data-ACK, and RTS-CTS-Data-ACK. But when I tried to define the term precisely I found that it does not apply well to 802.11 concepts.

The IEEE 802.11 standard does not use the word “atomic”. Elsewhere the IEEE says: “The execution of an atomic procedure completes before the next sequential procedure starts to execute.” The atomic essence is indivisibility of execution.

When the word atomic is used by the 802.11 community we are speaking informally of frame transmissions separated by nothing but a SIFS, and we are speaking of the several transmissions taken together as a single hopefully uninterrupted event that succeeds or fails altogether.

But all 802.11 frame exchange sequences are interruptible by definition. And take for example the fragmentation frame exchange sequence Frag1-ACK-Frag2-ACK-Frag3-ACK-...-FragN-ACK. If this sequence is interrupted midway, something that should not happen with a purely atomic procedure, the retransmission picks up with the last fragment transmitted. In other words, the sequence is both interruptible and when interrupted does not fail altogether -- hardly atomic. Bummer.

I conclude that IEEE 802.11 analysts would do well to use the words found frequently in the IEEE 802.11 standards, “frame exchange” and “frame exchange sequence”, instead of the words “atomic event”.

For example, the rest of this text is an improved version of a recent comment of mine on this forum:

We do well to analyze the end to end communication of a data frame between two client stations through an access point (AP) station, as two frame exchange sequences rather than one.

In other words, in the absence of fragmentation, the data frame payload, or MAC Service Data Unit (MSDU), is "relayed" by the AP but the data frame itself is unique to each of two frame exchanges. The two data frames have different values in many header fields including unique tuples of RA TA DA SA addresses.

Each data frame exchange may be acknowledged, or not. Each data frame exchange may be preceded by RTS/CTS, or not. Each data frame exchange may fail and be followed by one or more retransmission attempts, or not.

One data frame may be transmitted immediately and the other may be buffered while the receiver dozes. In the extreme case one data frame exchange may be controlled by DCF while the other is controlled by PCF (if anyone ever ships a PCF equipped access point).

In the presence of fragmentation even the data frame MSDU is not “relayed” in the sense of a single data frame payload appearing twice in the air. Each MSDU may be fragmented and reassembled, or not, and each fragmentation may be at its own size threshold, producing two very different frame exchange sequences.

Have a great day. /criss

Greetings:

I note that the IEEE 802.11 Handbook uses the phrase "atomic unit" in reference to the "frame exchange protocol". I find neither phrase in the IEEE 802.11 standards.

We read on page 20 of the Handbook: "The minimal MAC frame exchange protocol consists of two frames, a frame sent from the source to the destination and an acknowledgment from the destination that the frame was received correctly. The frame and its acknowledgment are an atomic unit of the MAC protocol. As such, they cannot be interrupted by the transmission (sic) from any other station." And on page 22 referring to RTS/CTS: "The four frames in this exchange are also an atomic unit of the MAC protocol. They cannot be interrupted by the transmissions of other stations."

According to the IEEE 802.11 Section 7.2 a “frame exchange sequence” involves >>one<< or more frames and when more than one they are separated by a SIFS. They are summarized in tables 21 and 22. Throughout the standards “frame exchange” is almost always followed by the word “sequence”.

Furthermore, receiver and transmitter addresses are the relevant addresses, not source and destination addresses. And every frame exchange sequence may be interrupted; it is silly to say otherwise.

Most of us, myself included, owe much of our early learning about the IEEE 802.11 standards to the Handbook. Nonetheless inventions and imprecisions such as these help create and perpetuate profound misunderstandings of IEEE 802.11 LAN's.

As stated on page iii of the Handbook: "IEEE PRESS/Standards Information Network (SIN) publications are not consensus documents." And, "... all parties must rely upon their own skill and judgement when making use of it."

Thanks. /criss

PS-Poll. (I was dozing, sorry, what was that again?)
:-)

I have to agree, but to be honest, most people don't read far enough into things to ever argue over words like "atomic", "relaying", "Address1, Address2...", etc. It would be great if we all had an extra 2 hours a day to devote to reading the Bible and the 802.11 Standard, but it's hard to make the time to dig endlessly, hour after hour over such minute details.