Cisco Cisco Aironet 1850e Access Points Libro blanco
IEEE 802.11ac Wave 2 AP’s: Cisco, Aruba, Ruckus
12
DR151120D
Copyright © Miercom 2015
5 February 2016
A panoramic view of the test facility is shown above. The AP being tested was mounted below
the drop ceiling, as indicated above.
In order to maximize throughput the APs were all set to 80-MHz channels. The client devices
were all positioned from 10 to 45 feet from the AP under test. A 70/30 mix of clients operating at
5 GHz (70 percent) and 2.4 GHz band (30 percent) was maintained throughout the testing.
Downlink TCP throughput
The Ixia IxChariot test system was configured to deliver TCP traffic over GE (1-Gbps Ethernet)
links to the Access Point under test, and through the AP to each active client device. Each AP
supported two RJ-45/copper GE links.
Multiple tests were first run on 10 client devices, as listed in the above client table. Then, when
testing that group was done, 10 more active clients were then incrementally added to each set of
tests, up to the point that all 100 client devices were tested.
The IxChariot measured individual-client and aggregate downlink TCP throughput for each test.
The results from three IxChariot test runs were then averaged for each client load level.
Failed clients and APs
During the tests we had to deal with two types of failures that impacted results: 1) client failures
and 2) AP failures.
In some test runs, one or more clients would lose network connectivity (due for example to a
DHCP failure). These clients cannot then be ping’ed, during or after the test run. Such “client
failure” cases would cause aggregate overall throughput to be lower than expected. In such
cases the wireless connection to the absent client(s) would be re-established and the test re-run.
In other cases, one or more clients could still be ping’ed, but would fail to send any data packets
through the AP during the test. Such AP failures in almost all cases are due to the APs not
sharing bandwidth across all clients. These are real situations that do occur in WiFi networks,
especially in high-client-density environments. The incidence of such no-bandwidth clients were
recorded, where the clients did not send or receive data. (TCP, the type of traffic sent in these
tests, assures that both ends of a communications session are active and able to send and receive
before any data is transferred. Because of this the IxChariot test system could readily identify
clients that did not send or receive data during the test.)
the drop ceiling, as indicated above.
In order to maximize throughput the APs were all set to 80-MHz channels. The client devices
were all positioned from 10 to 45 feet from the AP under test. A 70/30 mix of clients operating at
5 GHz (70 percent) and 2.4 GHz band (30 percent) was maintained throughout the testing.
Downlink TCP throughput
The Ixia IxChariot test system was configured to deliver TCP traffic over GE (1-Gbps Ethernet)
links to the Access Point under test, and through the AP to each active client device. Each AP
supported two RJ-45/copper GE links.
Multiple tests were first run on 10 client devices, as listed in the above client table. Then, when
testing that group was done, 10 more active clients were then incrementally added to each set of
tests, up to the point that all 100 client devices were tested.
The IxChariot measured individual-client and aggregate downlink TCP throughput for each test.
The results from three IxChariot test runs were then averaged for each client load level.
Failed clients and APs
During the tests we had to deal with two types of failures that impacted results: 1) client failures
and 2) AP failures.
In some test runs, one or more clients would lose network connectivity (due for example to a
DHCP failure). These clients cannot then be ping’ed, during or after the test run. Such “client
failure” cases would cause aggregate overall throughput to be lower than expected. In such
cases the wireless connection to the absent client(s) would be re-established and the test re-run.
In other cases, one or more clients could still be ping’ed, but would fail to send any data packets
through the AP during the test. Such AP failures in almost all cases are due to the APs not
sharing bandwidth across all clients. These are real situations that do occur in WiFi networks,
especially in high-client-density environments. The incidence of such no-bandwidth clients were
recorded, where the clients did not send or receive data. (TCP, the type of traffic sent in these
tests, assures that both ends of a communications session are active and able to send and receive
before any data is transferred. Because of this the IxChariot test system could readily identify
clients that did not send or receive data during the test.)