XCC - wondering about ac-WiFi asymmetric client speed

[M_Nees]

I got this XCC WLAN client report shown:

(XCC 5.36.02 - report truncated - AP310i)

XCC-V5.36.02# show clients apserial XXXXX-XXXXXX00000

Protocol   Radio  SSID       Aut./Priv.    OS         RSS(dBm)  Avg.Rate
                                                                (Mbps)
                                                              Sent/Recvd 

5.0ac|L|S  2      XX-MDE     None/WPA-PSK  Apple iOS  -55       360/6                      
5.0ac|L|S  2      XX-MDE     None/WPA-PSK  Apple iOS  -55       300/6                      
5.0ac|L|S  2      XX-MEDIEN  None/-        Apple iOS  -63       400/6                      
2.4n       1      XX-Mobile  None/WPA-PSK  Apple iOS  -96       0/0                        

XCC-V5.36.02#

i wondering about the asymmetric speed of this apple clients (while RSS is good).

It seems to be a general behaviour of smartphones (means android also). Windows clients seem to have symmetric speeds.

Is  anybody able to explain this behavior ?

Also seeing some rates as a point number e.g. “102.3 Mbps”. Does XCC Controller calculates some averages ? If yes within which timerange ? (maybe during whole session or within a fix amount of time?)

How can i understand the displayed direction in this report - View of Controller/AP or View of client?

Given above example does this apple phone send or receive only with 6 Mbps ?

BR,

Matthias

[M_Nees · Accepted solution]

Hi Gareth,

today i take the time an do some testings.

Getting wireshark traces within XCC GUI in now much more easier compare to legacy identify.

Analysing the wireshark traces (radio 2) show me the needed background information:

• if the client does not communicate much, than the AP/Controller see mostly 802.11 radio overhead packtes which are send at min. basic rate (here 6Mbps)
  (for example a smartphone which is automatic connected to SSID, but no need to communicate)
   
• if the client communicate later more real traffic, it will be send with best possible speed - depends on RSS, wifi technology, available channels and channel bonding etc.
  (Windows clients mostly having communication with someone)
   
• confirm every data packet also having a 802.11 data rate (if tcpdump is done on a radio interface) - and this rate changes/adapts 
   
• IEEE 802.11ac-2013 wikipedia article (https://en.wikipedia.org/wiki/IEEE_802.11ac-2013) give me a good overview about the possible data rates - and to my surprise there a lot of possibles rates - also the seen point number rates.
   
• Averages are done by 30 secs steps - TxRate and Rxrate are always defined in APs view

BR,

Matthias

[Gareth_Mitchell]

Hi Matthias

It’s more that the volume of data is low rather than only using slow 802.11 data-rates, this would cause the average to be lower

To be sure, you can take a wireless trace and see the volume of data being used by the device, and in the radiotap header you can see the data-rates used.  I normally have a column in wireshark to show the rate for each frame.

You are right about lower data-rates consuming more airtime than higher, however this is the 802.11 data-rate, not the average throughput data-rate seen on the controller sample above.

I hope this makes sense?

-Gareth

[M_Nees]

Hi,

thanks for reply.

one point causes some headache … what’s the benefit/reason that smartphones request only small datarates /eg 6Mbps)?

In legacy wifi networks (pre ac/ax) small datareate means (in my opinion) wasting limited and worthful airtime? 

Is there some technique in ac / ax networks that solve that opposite needs?

BR,

Matthias

[Gareth_Mitchell]

Hi Matthias

Typically phones pull data down from the internet (downlink) rather than pushing it to the internet (uplink.)  This is most likely what you are seeing, the average speed for the small amounts of data sent by the device is 6Mbps.

It’s also worth mentioning that the data rate used in wireless is variable, it can change frame by frame, depending on the RF environment.

The stats are averaged by the AP over 30 seconds and then reported to the controller.

The view of the controller/AP is what you are seeing there.

-Gareth