Filed under: Uncategorized
I presented at two events last week (totally separate topics) and the same two questions came up at both – how many users can I put on 1 AP and does 11ac change this?
If you have ever attended one of my presentation you will have head this – ‘It Depends’.
This is always true and will continue to be so no matter if you are doing 11a, 11n, 11ac, or whatever comes next. My normal answer to this question is to turn it around and get feedback from the audience on what number they think is correct, I get a wide variety of answers and then explain they are all correct, because it really does depend. It depends on the client devices, it depends on the applications and most importantly it depends on the expected and/or required user experience demanded by the users.
As noted, I work for Xirrus, on our products we can support 120 or 240 associations per radio and as a result this means up to almost 4000 association can be supported on our largest products. Would you ever design a solution based on those numbers? No, this is because that what you can do is not always what you should do. In example – I can probably transport 20 students in the back of a pickup, but not really something you would do
It all comes down to what is the expected or designed user experience and I like to use K-12 schools to demonstrate as they make a great example. If I need to provide Wi-Fi for elearning in the classroom, I will design for about 20 users per radio to provide a reliable ‘wired-like’ experience. Now if coverage was also desired in the cafeteria I would design for 20-40 per radio as normally the level of service is not are stringent. And finally for the sports stadium I might design with even higher densities, once again it depends on the level of service I want to provide to the end user.
Bottom line there is no magic number, different devices with different capabilities, connected at different data rates and requiring access to different applications will have a greater impact on network performance, see graphic below and you will start to appreciate the impact of the client types.
As an example, if I have a clients connected at 300 Mbps and on the same radio I have other clients connected as low as 6Mbps the overall performance is degraded because even though both get their max data rate ‘when they have the air’, it will take the slower client 50x as long to send the same packet and the other clients will have to wait their turn. And in most environments clients will not be connected at the max date rates available.
Filed under: Uncategorized
Discussions about 802.11ac are all the rage now so over the next month I am going to focus on this topic and hopefully impart some info you can actually use. I am going to bypass most of the bits and bytes as most of us are trying to build networks, not chip-sets, apologizes to the ASIC engineers.
We all know the potential value of 11ac is a tremendous increase in wireless performance, I say potential because upgrading just one side of the link (the APs) is not enough by itself. The type and quality of the client connections will always be the primary factor in your overall network performance. So it is key to understand client capabilities and then engineer your network to optimize the available bandwidth.
Just like mixing 11b, 11g and 11n on a single radio was a bad idea (it degraded overall performance), so will mixing 11a, 11n and 11ac on a single radio reduce expected performance. Some quick background, in any production network (not a testbed) you will have a variety of clients types, all connected at different data rates depending on technologies (11a/b/g/n/ac), different capabilities (SISO, MIMO [2×2, 3×3, 4×4], bonding, …) and varied signal strengths (RSSI). As a result you could have one client associated at 300Mbps and at the same time another client, sharing the same radio, connected at only 6Mbps. Although each will be able to operate at their max performance when they get access to the air, it takes the 6Mbps client 50x as long to send the same date as the 300Mbps clients. Since the vast majority of ‘existing’ clients today are consumer grade tablets and smartphones, we will tend to see far more clients associated at the lower half of the scale vs. the higher end. This disparity in client capabilities will only increase with 11ac, and just adding 11ac infrastructure components alone will not offer the performance improvements many are expecting.
Bottom-line, take all the 11ac performance numbers with a grain of salt, these numbers are all valid, but are typically measured in very controlled environments, not something you see in your production network. The best analogy I can come up with is car millage, those miles per gallon are all validated but once you hit the road with other cars, stop lights, stop signs, traffic, hills, bikes, … all bets are off. Your mileage/performance will vary, accept it.
My way of thinking, we started with 11a/g, 11n doubled, tripled and quadrupled these speeds, and 11ac will do it again. Enough said
For more info:
Solution and best practices coming.
Filed under: Uncategorized
Sorry for the long delay in posting, unavoidable, but I am now back.
I recently attended a CIO Summit where the Keynote speaker (Doug Caddell) made the following statement (or thereabouts)
“Technology today is increasing in complexity, however at the same time is becoming much easier to use, this lends itself to a false sense of confidence when deploying” Although he wasn’t talking specifically about Wi-Fi, it fits very nicely.
The following week I was at another show where the combined use of Wi-Fi by the hotel, the event staff and the individual exhibitors consumed every 2.4 channel from 1 thru 11, and many times each, while the 5GHz band was hardly used. This is the result of lack of knowledge, indiscriminate assignment and the habit of some ‘mifi’ devices to randomly select a ‘channel not in use’. Remember folks, the channel your AP radio is operating on is actually the center frequency and the bandwidth extends at least 10 MHz to either side of it. That means a device on channel 6 is actually ‘’consuming channels 4 – 8 (that’s why we say 1, 6 & 11). Now you RF engineers out there please excuse my intentional simplification of this issue.
Bottom-line, Wi-Fi is so easy to deploy today for home use (almost plug and play); and many try the same approach in enterprise deployments. Plan your Wi-Fi usage correctly, understand the limitations of the 2.4 GHz band and deploy accordingly. Focus on the 5GHz band where there are more channels today, additional channels proposed for the future, where 11ac will live and where almost all devices do not allow channel selection to cause additional interference (I.e. 36, 40, 44…).
Remember it takes far less time to design correctly at the start then to spend 10x the time and resources fixing interference issues.
Filed under: Uncategorized | Tags: 802.11h, DFS, extended UNII, UNII, WiFi Radar
Dynamic Frequency Selection (DFS) When additional channels were added to the available 5GHz spectrum there was much concern on how Wi-Fi’s use of these channels may impact devices already operating in these ranges. To address this the 802.11h spec, commonly referred to as Dynamic Frequency Selection (DFS) was created to define a set of procedures to detect and avoid interference with Radar systems operating in the 5 GHz range (UNII channels – 52-64 & 100-140). Note that many people believe that DFS is only required for the extended UNII band, when in fact it also includes the upper 4 channels in UNII (52-64). There are several parts of the specification, however the one that is most visible to users is the ability of an AP to detect and move from a channel that interferes with radar systems. Basically AP’s supporting the standard will designate a ‘Quiet’ period using information in the Beacon frame. This information will tell the stations to set their Network Allocation Vector (NAV) to allow for a quiet period when the AP can listen for transmitting Radar. If radar is detected the AP must alter the channel it is operating on and most have the ability to tell associated stations what channel they will be moving to. This allows stations to re-associate with minimum interruption. APs that do not support DFS are not allowed to operate on the channels where interference occurs; this significantly limits the number of channels available in the 5GHZ spectrum.
Thanks for visiting, The Prof
Filed under: Uncategorized | Tags: 802.11e, AIFS, CWmax, CWmin, EDCF, TXOP, VoWiFi, WiFi Qos
Ok, we all know that real-time, delay sensitive applications such as voice and video require a higher level of service than traditional data communications. Data traffic can take forever to arrive, it may annoy you but it doesn’t impact the communication. Voice and data however are different; if real-time traffic of this type is significantly delayed your communication could become unusable.
On the wired side we use the 802.1p standard to provide traffic prioritization at the media access control (MAC) layer. It defines eight priority levels for network traffic and provides classification and tagging of the packets.
In Wi-Fi we have 802.11e, it provides four provides called Access Categories. These include: Background (AC_BK), Best Effort (AC_BE), Video (AC_VI) and Voice (AC_VO), the standard provided a method to map the 8 wired priorities to the 4 Wi-Fi access categories.
Wireless QoS Prioritization (802.11e and WMM)
WMM (Wi-Fi Multimedia) is a subset of the 802.11e standard and provides far more granular QoS mechanisms to prioritize access to the media (air).
Using these QoS mechanisms APs (or Xirrus Arrays) is able to contend for access to the shared spectrum based on the priority of the traffic to be sent. Note that this contention is performed on a packet by packet basis.
A text book might say something like ‘the AC determines the priority of access and length of access based on the assigned AIFS, contention window and TXOP. But most of us don’t think that way, so to you I say the priority level of the traffic will determine how long you typically must wait to transmit wireless data.
Here is the process:
First you listen to see if anyone else is ‘talking’, Wi-Fi is designed to be courteous of other devices. If another device is communicating you wait for the channel to become clear.
Once the channel becomes clear you must wait a short period to allow priority traffic, like the ACK from the last transmission to be transmitted.
Next comes the contention window, this is where the real QoS happens. As the name implies, this is a period of time where different stations ‘contend’ for access to the air. Contention is considered fair, but not even, with higher priority traffic, like voice having a distinct advantage over lower priority traffic like data.
This is all based on slot times; these are just a period of time that will vary between the different Wi-Fi technologies. When a station wants to send data it randomly selects a number of slot times to wait before attempting to transmit. The key to Wi-Fi QoS is that high priority traffic typically gets to pick a lower number and gains access to the air quicker.
There are standard slot time values for the different traffic classes; however vendor may alter these values. Using the following example you can see how the Wi-Fi QoS process will work.
In this case we have 3 devices wanting access to the wireless network: a phone, a set-top box, and a laptop with web application.
They all want to send information at the same time
- First there is a wait period called Arbitration Interframe Space (AIFS), the length of this is based on traffic category priority. For traffic categories with higher priority, the wait period is shorter than for those with lower priority. The voice traffic will win this, however there also may be other devices wishing to transmit voice traffic so additional methods are required
- Next comes the contention window, the device with voice traffic will random select a number of slot times to delay before transmitting (between 0 & 3).After waiting the time required the station can now transmit its packets, assuming no other station picked a lower number and started transmitting first.
- Typically voice will use 0-3, video 0-7 and data 0-15 as the slot times they will select from. As you can see the higher priority traffic has the advantage. If a ‘collision’ of communications were to occur due to 2 stations selecting the same delay period this would be detected by both stations not receiving an ACK to their message. In that case the contention window is doubled (from 0-7 to 0-15) and the process repeats. Doubling will continue to occur until the contention window exceeds 0-1023 or the station gives up for another reason.
- This process continues as long as there is traffic to send.
QoS for Voice Communications (Voice over Wi-Fi)
In addition to the previously described standard QoS methods, some vendors have developed their own proprietary QoS extensions; mostly this is done to provide a higher level of services for voice than is currently available with existing standards. My next post will discuss specific QoS requirements of voice traffic (VoWiFi)
Thanks for visiting,
Filed under: Uncategorized | Tags: 802.11 antennas, 802.11e, DFS, EIRP, site Surveys, Wi-Fi, WiFi roaming, wifi tutorial, WMM
Well all my additional activities associated with Interop have come and gone and now it’s time to get back to posting, however there will be some changes.
I know I started this with the idea of focusing on Wi-Fi tools, however in many discussions at Interop, I learned there are lots of Wi-Fi topics that many are unfamiliar with. This includes the operation of QoS, Antenna options, power settings, site surveys, DFS, roaming, etc. To that end, I am going to start including short tutorials on these topics to my postings.
As with previous posts, my tutorials will be at a common sense and user level, not designed to a level required to build the chipsets themselves.
The one topic most asked about is how the quality of service can be applied in a Wi-Fi shared environment. That’s a great place to start and will be my next post.
Filed under: Uncategorized | Tags: 802.11abgn, 802.11n, Interference, iperf, search for Wi-Fi networks, troubleshooting RF, Wi-Fi Array, wi-fi performance, wifi testing, Wifi tools
Continuing with the discussions of free Wi-Fi tools, we come to iPerf. Important note, iPerf is not specific to wireless and can be used in any IP environment; however increased interest in its use in Wi-Fi is the result of more administrators deploying 802.11n networks.
iPerf is an easy to use and very popular tool designed to measure communication channel characteristics, I strongly recommend every IT professional have a copy and be comfortable with its use. iPerf operates in a client server manner, generating traffic between two devices and measuring key network criteria. It provides feedback in easy to understand tables and graphs, showing throughput, packet loss, jitter etc. between the client and server. Using this information you are able to tweak (tune) TCP and UDP data settings to optimize connection. iPerf can be run from a command line or a GUI interface (called jPerf).
As mentioned, a primary purpose of iPerf is to allow you to ‘tune’ connections. I am not going to spend time going into depth on the variables of TCP or UDP but there are some basics worth mentioning.
When tweaking a TCP connection the place to start is the TCP window size, the window size determines the amount of traffic a client can transit at any one time. If too much traffic is sent buffers can be exceeded, too little and the connection is not optimized. iPerf can be used to test transfer rates across a link while varying the window size. Based on this testing the optimum window size can be determined and the network optimized. A good tutorial for more information on window size is available at http://www.rhyshaden.com/tcp.htm.
UDP traffic does not offer the guarantees of TCP, error or flow control. It is a connectionless protocol and often used for streaming information such as voice or data with no concern (at this layer) for loss. When tweaking a UDP connection the adjustment here is the packet size. UDP testing is useful in determining bandwidth, jitter and packet loss.
As I mentioned iPerf can be used in any IP environment, however of late there is increased interest in it for testing Wi-Fi links. As most are aware, RSSI values identified by many Wi-Fi clients only estimate what physical layer data rates you could expect. They typically do not take into consideration SNR (Signal to Noise Ratio), packet loss, management overhead and other conditions that influence the rating algorithms and define your actual layer 3 throughput numbers. As more and more users are moving to 11n for the increased bandwidth it offers, many want to see what the actual improvements are over legacy 11a/g throughputs.
The below graphic (using the GUI interface) is an example of a Wi-Fi throughput test between an iPerf client (wireless laptop) and an iPerf server (Xirrus Array), as you can see the throughput averaged in the 180Mbps range. This is actual TCP throughput, not link rate.
To simplify testing and as a value add for their customers, many vendors (including Xirrus) have integrated iPerf in their products.
Iperf is copyrighted by the University of Illinois, except for the gnu_getopt.c, gnu_getopt_long.c, gnu_getopt.h files, and inet_aton.c, which are under the GNU General Public License.
Iperf 2.0.2 installer for Windows – Provided by Ted Fines (firstname.lastname@example.org) at Macalester College, St. Paul, MN.
To download iPerf, click here: kperf_setup.exe
Thanks for visiting, in a following post I will discuss some of the other ‘dials’ you can tweak and test with iPerf