Forum

Greetings.

This is a popular assertion about IEEE 802.11 frames:

"Unicast data frames are acknowledged; broadcast and multicast data frames are not acknowledged"

As a test, use an 802.11 client to ping 255.255.255.255 and a protocol analyzer to observe the frames carrying the "broadcast" ping request. The Destination Address (DA) of the resulting data frames is the well known broadcast address ff:ff:ff:ff:ff:ff but the access point (AP) acknowledges them anyway. Hmmm.

The answer to this conundrum is that the 802.11 standard is referring not to the DA but to the Receiver Address (RA), always stored in the Address1 field of every 802.11 frame, to distinguish unicast frames from multicast frames!

With this new understanding we realize, in IEEE speak, that the above ping request was carried in a unicast frame, also known as a directed frame, to the AP and in a multicast frame away from the AP!

This becomes easier to see after we display Address1, Address2, and Address3 columns in our analyzers instead of DA and SA columns.

Have a great day. /criss

Chris,
Thanks for the info.
It is important to distinguish between the source address and transmitter address, the destination address and the reciever address. I know this is how mobility is acheived through the indirection introduced by these concepts, but sometimes it boggles my mind when thinking about it.
Your example gives emperical evidence of indirection in action. A broadcast is first sent to the AP(Reciever Address)as a unicast then on to the Destination Address as a multicast. The RA sends an acknowledgement but the DA does not. So IEEE rule that unicasts are acknowledged but multicasts are not is technically followed, but you have to distinguish TA, SA, RA, DA to understand how it works. This is cool stuff !!!!
This is just like being in class. Keep the tips coming!

Red:

I suggest that you separate your analysis of the end to end communication of two client stations through an access point (AP) station into two atomic frame exchange events, each involving its own data frame and each data frame with its own theoretical tuple of RA TA DA SA addresses.

In other words, the data frame payload is "relayed" by the AP but the data frame itself is unique to each of two frame exchange transmission events. The two data frames have different values in many header fields. Each data frame may be acknowledged, or not. Each data frame may be fragmented and reassembled, or not. Each data frame may be preceded by RTS/CTS, or not. Each atomic frame exchange may fail and be followed by one or more retransmission attempts, or not. One data frame may be transmitted immediately while the other is buffered while the receiver dozes. In the extreme case one transmission may be controlled by DCF while the other is controlled by PCF.

Thanks. /criss

Chris,

I think it was Yogi Berra who said “The problem isn’t what you don’t know, it’s what you do know that just ain’t so” I think I may fall into the later category.

I think I understand what you said about the AP just relaying the payload but the data frame gets rebuilt each step of the way with it’s own headers, up to 4 addresses etc. I guess each communication over the unreliable media would have to be an atomic unit unto itself for purposes of recovering after an unsuccessful transmission.

Like I said it boggles my mind, but I keep at it and sometimes I have an epiphany and sometimes I don’t. More research required. This gives me a good point to start getting a deeper understanding.

Thanks for the reply,

Criss is right. The MSDU (the MAC frame payload) is the only thing "relayed" through the AP. Each conversation (data-link) is atomic and should be considered a complete exchange. It takes 2 frame exchanges to move an MSDU between two wireless clients in the same BSS.

Devinator

Guys,

Thanks for the input, it makes it much easier to understand this process.
I can see the reasons for the atomic unit and why it has to be that way.
My study guide the IEEE 802.11 Handbook is long on information but short on explanations. These conversations are a tremendous help.

Red:

Thank you for your compliments. Please suspend your belief in explanations, especially free ones such as mine found here, until you have matched them to both the technical standards and the vendors' products. Some of the most satisfying explanations are simply wrong.

Have a great day. /criss