Forum

I searched but found no results so I posted this in WLAN Design, QoS, Protocol & Spectrum Analysis, wVoIP but got no answer. I apologize if this question has been asked and answered before.

Why is it that an 802.11 ACK frame has no source address?

TIA,
Brad

I???¡é?¡é?????¡é???¡éve asked myself this very question a few times before. I???¡é?¡é?????¡é???¡éve not heard a definite answer anywhere, so I???¡é?¡é?????¡é???¡éve made this up. If it???¡é?¡é?????¡é???¡és wrong or anyone wants to add to it, please do so.

Here goes???¡é?¡é???????|???¡é?¡é???????|.

Firstly, 802.11 relies on what is called ???¡é?¡é?????¡­?¡°positive acknowledgement???¡é?¡é????????. This means that whenever an 802.11 data frame, management frame, control frame etc is sent, the sender expects to see an ACK frame in order to know whether the receiver got the frame or not. The wireless medium [ the air and objects around us ] is much more unreliable than good old copper Ethernet. Interference, multipath, people moving around the office etc, ???¡é?¡é?????¡­?¡°conspire???¡é?¡é???????? to make those frames ???¡é?¡é?????¡­?¡°disappear???¡é?¡é???????? or become corrupted. Detecting a collision with Ethernet is electrically not too difficult [ and is done every day all over the world in working systems ]. Detecting collisions in a wireless medium is technically very difficult indeed and very expensive [ sometimes impossible ]. To get around this, 802.11 says that in order for the sender to positively, 100% know that the receiver got the frame in good condition, the receiver must acknowledge this by sending an ACK frame. The sender must receive that ACK correctly. When the sender sends it???¡é?¡é?????¡é???¡és [ say ] data frame, it makes an estimate of how long it will take to transmit that data, wait a little bit for a safety gap [ called an Inter-Frame Space, such as an SIFS ] and to receive an ACK frame back. When it has taken control of the wireless medium , it sends that time data in the 802.11 MAC header in what is called the duration/ID frame. All other stations are listening to the medium. They hear the transmitted frame and extract that time data from the frame. They use that to set a timer called the NAV [ or Network Allocation Vector ] timer. This thing basically says; ???¡é?¡é?????¡­?¡°Hey, someone is transmitting and expecting an ACK. I need you to wait until the end of that time???¡é?¡é????????. Nobody is allowed to transmit before the end of that period. This means that by default only the transmit and receive stations can be involved. Nobody else. The transmitting station [ Tx ] includes it???¡é?¡é?????¡é???¡és MAC address in the 802.11 MAC header. It also includes the receiver MAC address [ I won???¡é?¡é?????¡é???¡ét go into the whole Address 1 -4 thing here ]. So, the receiver now knows the Transmitter???¡é?¡é?????¡é???¡és address. Just before it sends the ACK back, it says to itself ???¡é?¡é?????¡­?¡°Hey, there???¡é?¡é?????¡é???¡és only the TX station and me allowed on the air during this period [ the NAV period ], and everybody else knows that. He knows he???¡é?¡é?????¡é???¡és sent me a frame, and I know what his address is. Why should I take up valuable air time sending a copy of my MAC address when he already knows that if he receives an ACK, it HAS to be me ? So, I???¡é?¡é?????¡é???¡ém going to just take his MAC address from his MAC header and put it into my ACK frame and send it off to him. I don???¡é?¡é?????¡é???¡ét need to send him my address, hence saving some ???¡é?¡é?????¡­?¡°air time???¡é?¡é????????.

Now, 802.11 tries to be as efficient as possible as regards ???¡é?¡é?????¡­?¡°air time???¡é?¡é????????. In other words, time is very valuable. Say what you have to say and then that???¡é?¡é?????¡é???¡és it. Say no more than is absolutely necessary. Save ???¡é?¡é?????¡­?¡°air time???¡é?¡é???????? whenever you can. We have seen this in a recent posting about TIM???¡é?¡é?????¡é???¡és where we saw that instead of sending 251 bytes of data each time in a TIM to show who has data buffered for up to 2007 AID???¡é?¡é?????¡é???¡és we can ???¡é?¡é?????¡­?¡°compress???¡é?¡é???????? a bunch of zeroes for STA???¡é?¡é?????¡é???¡és who do not have data buffered. We then send a PARTIAL bit map instead of a FULL bit map.

Anyways, that???¡é?¡é?????¡é???¡és about it. If I am wrong, I shall go away and be one with my shame???¡é?¡é???????|.

8-O


Dave

Sounds very reasonable. I thought I had come up with a counter-example for your explanantion but as I was typing it up in the post it caused me to think about the process more deeply and what you were saying started to click. Thanks Dave.

It's pretty tough for anyone to add to Dave's articles or responses, but I'll try. :)

Dave's example of the Duration value and NAV timer was in relation to the ACK, but keep in mind that the duration value is used whenever a Wi-Fi STA (AP or STA) wants to clear the medium for some reason, not just for an ACK response.

As far as why ACK's don't have a source address, it comes down to a few rules. First, if more than one device could ACK, then there won't be one. For example, when the receiver address is a broadcast or multicast, there won't be an ACK response.

So that leaves us with this; when an ACK is sent, who else, except the receiver of the last frame, could the ACK be from?

Something else to note though. Packet capture software such as OmniPeek tends to confuse us a bit. I was just chatting with Neil Mac and he was showing me some frame captures that shows a source address with an ACK. Well, OmniPeek puts it in there because it is making the same assumption as we are regarding the source. However, if you look at the actual decode, you will see that it only contains the receiver. I'm not sure that I like that "guessing" feature in OmniPeek.

Great question from the OP and a great response. I love it that people are looking this deep into Wi-Fi protocol!

GT