Wi-Fi Dynamic Rate Selection?

Question

I have two related questions about how dynamic rate selection works in wireless (802.11a/b/g/n) networks:

1. On what time scale does this rate scaling take place? I imagine it actually occurs much more frequently than the changes are reported to the user by e.g. Windows' wireless utility, on the order of milliseconds.

2. If I'm correct that rate selection actually takes place on a millisecond time scale, how do wireless utilities (e.g. the Windows built-in one) decide what speed to report? Do they typically report the minimum over the past few seconds, the maximum, the median, etc.?

Answer 1

Any time a packet has to be retransmitted at the 802.11 layer (because no 802.11-layer Ack was received within the Ack window at the end of the packet transmission), the transmitting device may choose to send the retransmission at a lower (more robust) rate. So rates can change instantly from one packet to the next, so yes, on a millisecond time scale if not faster. Also note that rates are not necessarily symmetric. So the client may be using one rate for its transmissions to the AP, but the AP may be using a different rate for its transmissions to that particular client. If your GUI only reports one "speed" for the connection, is it reporting the rate this device is transmitting at, or rate the other device is transmitting to this device at?

There is no standard for whether software that reports the rate to the user should report the instantaneous rate of the last packet sent or received, or if it should apply some sort of averaging or hysteresis. I've seen quite a bit of variance here depending on the tool/OS/driver combination. And even if it reports the rate of, say, the last transmitted packet at the time the "GetRate()" (so to speak) API was called, how often does the user-level tool call that API? Once ever 10 seconds? Once a second? Many times a second?

I doubt anyone has enough data to say what is "typically" done. If you walk your way through the code for your favorite open source tool/OS/driver, then you could say how that combination behaves. Good luck finding out how closed-source tools/OSes/drivers behave in this respect.

I've definitely seen tool/OS/driver combinations that report the most recent receive rate, because it would often show a low number (which corresponded to the multicast rate) when the connection was basically idle. So when there was no real unicast traffic being sent or received, the software would be seeing all the multicast background chatter going by at the lower multicast rate, and report that as the speed of the connection. In that case, if you really wanted to see what speed the connection was capable of, you needed to be sending a lot of unicast traffic back and forth across the connection, so that you'd see the typically much higher unicast data rates get reported.

Answer 2

1. I doubt it takes place on the order of milliseconds. In all probablility, if there are enough dropped packets, it automatically downgrades to connection until the percentage of dropped packets is tolerable.

2. Windows reports whatever it is right now.

The reason that the scaling takes place, is because if the router were to try and maintain the same speed, there would be too much data loss.

The factors that effect data loss are:

• Distance
• Radio interference
• Physical objects that hinder the transmission of the signal
• Power of the transmitter

Since these things do not change quickly, and there are a very limited number of speeds that the router can scale to (4 for wireless b, 8 for wireless g) there is no reason to check every millisecond, or to expect the scaling rate to change rapidly.