4

The data/link rate reported by my AP differs from that reported by my client PC. Does the transmitting device always determine link rate? Or can, for example, an AP dictate both the TX and RX link rate?

2
  • are you referring to the operating bitrate? i.e. 1, 5, 11, 54 mbps Nov 14, 2013 at 5:25
  • Yes, I'm referring to the bitrate.
    – elin05
    Nov 14, 2013 at 23:55

1 Answer 1

7

While this seems like a fairly straightforward question, the answer is by no means straightforward. This will get long, but the short answer is that both devices are adjusting the RX and TX rate all the time and these two data rates do not need to be the same.

In infrastructure mode, the access point determines the supported and base data rates in use for the wireless network. Clients need to support as least the lowest base data rate to connect to the network.

These are advertised in the beacons frames sent by the access point. See below for an example of a beacon frame I pulled from one of the captures I had stored:Beacon Frame

This Cisco access point is advertising the following data rates: 6, 9, 12, 18, 24, 36, 48, and 54 Mbps. All of them are marked as base data rates as well.

An 802.11b client, which only operates at 1, 2, 5.5 and 11 Mbps would not be able to connect to this network.

In operation, both the access point and the client device will use any or all of these data rates and are constantly adjusting them to account for changes in the environment. Typically, they will start by trying to use the fastest, but if they don't get acknowledgements at the higher data rate, they will retry the transmission at lower data rates. The access point and the client can be using two entirely different data rates and often do. Each ultimately makes the decision of what data rate to use at any given point in time.

The exact process of how the device selects/adjusts the data rate is a process determined by the programmers for the device. Some are very aggressive and will always start at the highest data rates and work their way down trying for the best performance, even if all the acknowledgements come in at very low data rates (resulting in many retries). Others will keep track of the recent successful acknowledgements and conservatively adjust the data rate upward, sacrificing high data rates for a lower number of retries.

There can also be "lopsided" capabilities in a wireless chipset. For instance, the Intel 5100 is a 1x2:2 device. It has only has one transmit radio chain but two receive radio chains, meaning it can only use one of it's spatial streams when transmitting. This results in a receive data rate (2.4GHz, 20 MHz channel width, long GI) of 130 Mbps, but it can only transmit at data rates up to 65 Mbps.

When it comes to reporting the data rates, different APs and clients also do this differently. I have seen some that report only the best possible data rate, some that report the TX rate, some that report the RX rate, and some that report both separately. They may update this value close to real time or they may only update it once per x seconds. They may use a median, mean or mode value for a data set; if they use the mean value then it may not even correspond to an actual data rate.

In any case, whatever value is given is not the single data rate in use. To illustrate this, here is the output from a Meru access point for a client device showing the RX and TX distribution of data frames (as well as the success/failure rate on TX - the AP won't have this for RX since it should only really be receiving one usable frame and then ack it):

***********************************************
  Rate --------------- Short Term -------------
  Kbps  #RX_frame(P)     Bytes
  6000       11(  0)      1455
 36000       15(  0)       420
 48000      214(  8)      6020
 54000     1069( 43)     31962
 81000      147(  5)     19426
108000      309( 12)     56322
121500      524( 21)     59948
135000      185(  7)     25439
***********************************************
***********************************************************************
   TX Rate Statistics for MAC address = xx:xx:xx:xx:xx:xx
                                BSSID = xx:xx:xx:xx:xx:xx 
***********************************************************************
  rate ------------------------- Short Term ---------------------------
  Kbps  #frame(P)  #suces(P)   #fail    byteSuc  byteFail (S/T) 
  6000     97(  4)     19(  1)     78       3938    10502 ( 19) 
 54000     59(  2)     58(  3)      1      17130      178 ( 98) 
 81000    312( 13)    272( 15)     40      56450    11380 ( 87) 
108000   1074( 46)    857( 50)    217     165724    42175 ( 79) 
121500    684( 29)    454( 26)    230      92321    47461 ( 66) 
135000     96(  4)     52(  3)     44      12815    11743 ( 54) 
************************************************************************
2
  • So regardless of the AP or client POV, it's always up to the transmitter to choose the data rate, correct? And is there a handshake process that is required to inform the receiver that the transmitter intends to change the data rate? A different, but related question, would be: are wireless chips able to receive any modulation/date rate at any time, or must it be informed first so it can configure its receiver to the correct modulation scheme?
    – elin05
    Nov 15, 2013 at 0:06
  • @elin05, yes the transmitter always chooses the data rate for transmission. This requires no handshake and no prior need to tell the receiver the data rate (other than the supported data rates established in the initial association process). The receiver will be listening for any RF in the air, and will be able to process any signal it can understand. This would be somewhat like someone giving you a list of languages they understand; no matter which you picked off the list to use, it will be understood.
    – YLearn
    Nov 15, 2013 at 3:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.