Quality of Service - A Simple Explanation

When dealing with voice or video conferencing over Wi-Fi, one can use "quality of service" (QoS) mechanisms to provide differentiated services and prioritize the traffic.  Voice traffic is fairly low bandwidth but, being real-time, is very sensitive to latency (i.e. the delay time between when the message is sent vs. when it is received) and jitter (i.e. variation in latency).   Real-time video such as a two-way video conference is also sensitive to latency and jitter, as well as being high bandwidth. 

Conversely, one way video, such as a stream from a security camera or a Netflix streaming movie, is typically buffered at the receiving end to smooth out jitter effects, which allows variation in how the traffic is received to not impact playback, so long as the buffer is not empty. This buffering can lead to several seconds of delay between the source of the stream and its destination - while such a delay is obviously disastrous in two way communication, it is generally acceptable in one-way communications such as a surveillance camera feed.

The following table shows quality of service requirements for typical applications:

In order for QoS to be effective, it needs to be enabled end-to-end.  If it is enabled on some equipment but not others, you only get QoS on the enabled segments.  There is no QoS over the Internet, but many enterprise voice and video applications are contained within the network itself (e.g. two employees talking with each other over VoIP badges), and thus need not go through the Internet.   Note that QoS is important both for your wired switch devices as well as wireless APs.  If there is not provision for handling QoS on the AP, then the AP itself will not prioritize any traffic. On a network with a relatively light load, this isn't a big deal, but it could be problematic under heavy wireless loads.

There are two basic ways of setting up QoS.  The older, and simpler, method is to dedicate one VLAN as a "voice VLAN", connect all of your voice clients to that VLAN, and then prioritize that VLAN traffic through all of the equipment on the network.  Note that all traffic on the VLAN is prioritized, so if there is a mix of high priority voice traffic and low priority data traffic on the same VLAN (e.g. from a smartphone connected to the voice SSID), there is no distinguishing the traffic.  Accordingly, this approach is best suited for dedicated voice appliances (e.g. wired VoIP phones and wireless VoIP handsets or badges).  The network should be architected such that only voice devices connect to the voice SSID / VLAN.  To minimize roaming issues, wireless security should be WPA2-PSK (i.e. not Enterprise, even with 802.11r support, as some older devices don’t support 802.11r).  The other drawback to this approach is that there is generally no prioritization of the VLAN in the access points, only on the wired network.

The other major approach is QoS tagging and prioritization queues.  This is the 802.11e standard method which divides wireless traffic into four four QoS categories (i.e. in order of decreasing priority: voice, video, best effort, background), with “best effort” being the default priority on any non-QoS traffic.  QoS traffic entering the network via Wi-Fi is put into the appropriate queue and then handed off through the network.  The corresponding prioritization on the wired network actually has 8 categories in Layer 2 and 64 categories in DCSP at Layer 3, but there is a standard (and often configurable) mapping as follows:

With this method, QoS being configured "end-to-end" is extremely important.  If there is a link in the network chain that does not support QoS prioritization, the prioritization is lost and thus ineffective for the rest of the transmission.   Additionally,  the VoIP appliance or softphone application (e.g. on a laptop or smartphone, think Skype) must actually do the QoS tagging – this starts at the application layer and must be passed down within the appliance / application.  If the appliance / application does not do the tagging, then the AP will not know it is voice traffic and will classify it as best effort.   Many appliances / applications have been notoriously bad about actually doing this, making the QoS effort moot. One would hope that vendors who make products in this space are smart enough to be passing these parameters, but the only way to know for sure is to sniff and examine the contents of the actual packets.

These approaches are, fortunately, not incompatible, and if used in conjunction with each other can best assure QoS handling of voice traffic under a variety of circumstances.

Baby Got Backhaul

"Baby Got Backhaul" 

A Wi-Fi musical parody of "Baby Got Back" by Sir Mix-a-Lot

Written: September 2015 

Updated November 2021

Spoken Intro:

"Oh, my, God. Look at that WAP!
It is so big, it looks like <scoff>
One of those flying saucers.
But, ya know, who understands that Wi-Fi?
They only connect, because,
The SSIDs like totally open, 'kay?
I mean, the AP, is just so big!
I can't believe it's just so round, it's like out there
I mean <scoff> gross, look
It's just so, huge!"

Rap:

I like big WAPs and I cannot lie!
You CWNAs can't deny
That when you see an AP with an itty-bitty mount
And more antennas than you can count
You get sprung!

Want to pull out iPerf
'Cause you notice that bandwidth's stuffed
Deep into two LAG ports its sporting
I'm hooked and I can't stop hoarding

Oh baby, I want to connect with ya
And upload pictures
My homeboys tried to warn me
But that WAP you got makes... <me so bandwidth hungry>

Ooh, MU-MIMO
You say you want to give me over 1 Gig?
Well, sound me, beamform me
Cause you ain't that average A.P.

I've seen it linking
To hell with LEDs blinking
It's set and forget
Got it goin' like a hard wired net…

I'm tired of marketing
Saying ax is the thing
Take the average user and ask him that
Its gotta pack much backhaul

So, fellas (Yeah) Fellas (Yeah)
Has your network got the WAP? (Hell yeah)
Tell 'em to stream it (Stream it) Stream it (Stream it)
Surf that healthy WAP

Baby got backhaul! (A.P. fits with the spec, OMG!)
Baby got backhaul! (A.P. fits with the spec, OMG!)

I like 'em round, and big
And when I'm pulling over 1 gig
I just can't help myself, I'm actin' like an hacker
Now here's my factor:
I want to get you home
And <ugh> rack-em-up <ugh, ugh!>
I ain't talking bout mounts, boy
'Cause 1U racks are made for toys

I want 'em real thick and heavy
So find radios in double
@EmperorWiFi’s in trouble
Begging for that coverage bubble

So I'm looking at WAP videos
Network vendors pretending they know
You can have them vendors
I'll keep my APs with more radios

A word to the bonded channels, I want to make you bigger.
I won't interfere with ya.
But I gotta be straight when I say I want to <surf> 'til the break of dawn

AP's got it goin' on!
A lot of MSPs won't like this song
'Cause them punks like to hit it and quit it
And I'd rather stay and play
'Cause my antenna's long, and its strong, and I'm down to get the beacons on

So, Ladies (Yeah) Ladies (Yeah)
If you want to surf the net with no zzzzzz's (Yeah)
Then turn it on, crank it out
Even CWNE's got to shout

Baby got backhaul!
Baby got backhaul!

Yeah, baby, when it comes to APs
Marketing ain't got nothing
To do with my selection
36x36:36
Ha ha, only if it's Wi-Fi 6E

So your engineers roll "smart APs",
Giving you dashboard screens for large fees.
But those screens won't give you total control of that AP...
My cloud monitor don't want none unless you've got MIBs, hon'
You can do TACACS or CAPWAP
But please don't lose that SNMP

Some WISPs want to play that "hard" role
And say auto-channel is such gold
So they install it and forget it
And I pull up quick to reset it

So you're controller architecture’s "fat"...
Well I ain't down with that!
'Cause your overheads small and your GUI's kicking
And I'm thinking bout sticking
To the controller-less WAPs in the enterprise
You ain't winning no prize

Give me spectrum, I'll collect 'em
DFS channels ain't just pro tem

Some knucklehead tried to dis...
'Cause his APs are on my list
He had game but he chose to mesh 'em
And I pull up quick to connect 'em

So APs, if the uplink ain't down
And you want lots of clients around
Dial 1-900-SURFSALOT
And broadcast all those streams

Baby got backhaul!
Baby got backhaul!

(Signal in the middle and its got much backhaul)
(Signal in the middle and its got much backhaul)

 #babygotbackhaul

An Explanation of Channel and Transmit Power on Wi-Fi Networks

When designing and installing a Wi-Fi network consisting of multiple access points (APs), it is generally Best Practice to set up a static channel and static transmit power architecture for your access points.  This is often a confusing topic for both Wi-Fi novices and experts alike, as there are different frequency bands, different channel sizes, and different tradeoffs with using different transmission power settings.

This blog will go through the definitions of channel and power, and establishes the Best Practices of channel and transmit power planning for both 2.4 GHz and 5 GHz.

Defining Wi-Fi Channels

The Federal Communications Commission (FCC) and similar governmental agencies in other countries regulate the use of radio frequency spectrum.  Most spectrum is licensed, meaning that government agencies or commercial entities must purchase or lease a portion of spectrum, and then have exclusive rights to use that spectrum.  Some frequency bands are unlicensed, meaning that anyone can broadcast in that portion of the spectrum without getting a license to use that spectrum, so long as they meet certain maximum transmit power limitations.  This is the portion of the spectrum where Wi-Fi operates. 

Each Wi-Fi access point broadcasts a signal on a particular channel, which is specified as a particular center frequency and channel width.   With 802.11n and 802.11ac, there has been a push to use larger channel widths (40 MHz in 802.11n, and 80 MHz or 160 MHz with 802.11ac), as larger channel sizes enable more data to be sent within the same time window, increasing the throughput of the link.  However, since the size of the unlicensed bands used by Wi-Fi are fixed, larger channel sizes lead to fewer independent, non-overlapping channels.   In addition, larger channel sizes are subject to higher noise floors and more interference from neighbors, making the use of larger channels a tradeoff between potential throughput and achievable signal quality.

Wi-Fi signals interfere if their transmissions occur on the same or overlapping channels in the same space.  In reality, what happens is that the receiver (e.g. a wireless client) at a particular point in space hears transmissions from multiple sources simultaneously, and is incapable of distinguishing between the different sources.  The resultant data received is therefore a mashup of signals from the different sources.   A checksum of the received data indicates that the transmission is corrupted, which ultimately requires the original intended transmission source to retransmit the data.

Most enterprise access point vendors also provide a feature called band steering, which encourages dual band capable client devices to connect on the 5 GHz band to obtain higher speeds because of the use of larger channel sizes and fewer sources of external interference than the 2.4 GHz band.  This feature is also not part of the 802.11 standard, so implementation is vendor-specific, but it is a very good idea.  Especially with the emergence of new IoT network appliances that are not only 2.4 GHz but using new low-poer 802.11b chipsets, it is generally advisable that all clients that can operate on the 5 GHz band be directed to do so.

Defining Transmit Power

The transmit power of an access point radio is proportional to its effective range – the higher the transmit power, the more distance that a signal can travel, and/or the more physical materials that it can effectively penetrate and still have data successfully resolved at the receiver.  A stronger signal at a given distance generally results in a higher signal to noise ratio, which typically allows for more complex modulation and coding schemes (MCS) and thus faster data speeds.  

In early Wi-Fi deployments, which were primarily driven by the coverage requirements, it was common to turn up the power on the AP transmitter as high as allowed by FCC and IEEE regulations.  This approach worked when most clients had reasonably strong transmitters themselves, such as laptops.   With the emergence of smartphones, tablets, and network appliances, however, there is often a transmit power mismatch that leads to a range mismatch.   Most smartphone, tablet, and IoT appliances use relatively weak transmitters in order to preserve both space and battery life.  As a result, the client device can receive a relatively strong transmission from the access point, but the access point cannot receive the relatively weak transmissions of the client device in response.  Think of it this way:  the access point is shouting but the client device is whispering.   Accordingly, though non-intuitively, the effective coverage area is driven by the client devices, and the AP power levels must be set so as to minimize the mismatch between the range of the access point and the corresponding range of the client devices.  

Furthermore, in high density deployments where hundreds or even thousands of client devices can be operating within the coverage area of a single AP (e.g. college lecture halls, conference centers, stadiums, etc.), more access points are needed simply from a capacity standpoint.   This necessitates using lower transmit power levels, using directional antennas, and planning channels very carefully to prevent co-channel interference. 

Finally, as compared to 5 GHz, 2.4 GHz has less free space path loss and attenuation through standard building materials, giving it a larger effective range at a given transmit power level.  When using a dual band access point, one generally wants to have the coverage area equivalent for both bands.  For a typical SMB environment, one generally needs to set the 2.4 GHz transmit power level to be 6 dB lower than the 5 GHz transmit power to get a rough equivalency in coverage.  Even so, balancing coverage can be difficult.  It is not uncommon to design an AP layout for 5 GHz coverage, necessitating that some of the access points have their 2.4 GHz radios disabled (i.e. turned off) so as to not cause co-channel interference on the 2.4 GHz band.

Wi-Fi Channels on the 2.4 GHz band

On the 2.4 GHz band (802.11b/g/n) in North America, there are 11 channels of 20 MHz size allowed by the FCC.  Some or all of channels 12-14 are allowed in some other countries, such as Japan.  Unfortunately, the center frequencies of channels 1-13 are only 5 MHz apart, leading to only three non-overlapping channels, as shown in Figure 1. 

Figure 1:  20 MHz channels on the 2.4 GHz frequency band. [1]

While it is not generally known, Channels 12 and 13 (2467 MHz and 2472 MHz) are actually allowed by the FCC at low power levels.  While channels have a width of 20 MHz, there is some additional side-band leakage, typically at a level below -30 dB of the peak signal.  For Channels 12 - 13, there can be out-of-band emissions in the restricted frequency band 2483.5-2500 MHz (encompassing Channel 14) which is used by the mobile satellite service in the United States, hence Channels 12 and 13 are reserved essentially as a guard interval.  Channel 14 is only allowed in Japan, and then only for DSSS / CCK (802.11b), and not OFDM (802.11g/n). [4]

The 802.11n spec allows for the optional use of 40 MHz channels on the 2.4 GHz band, by bonding two neighboring channels together.  However, given that the entire usable band in 2.4 GHz is only 72 MHz wide (encompassing Channels 1 - 11), there are no two 40 MHz channel sizes that are independent, as shown in Figure 2. This makes the use of 40 MHz channels completely impractical in multi-AP deployments, though it is still unfortunately fairly common to see in practice as most vendors allow this channel width in their default settings.

Figure 2:  40 MHz channels on the 2.4 GHz frequency band. [1]

Given the restrictions on the number of independent channels and how that decreases as the channel width increases, poor channelization will create AP-to-AP interference and thus degrade both usage and coverage requirements.   On the 2.4 GHz band, only 20 MHz channel sizes should be used, and channels should be deployed across APs with an alternating static 1, 6, 11 scheme, both horizontally and vertically.

Wi-Fi Channels on the 5 GHz band

The 5 GHz band is much larger (over 555 MHz, semi-contiguous), and thus makes selecting independent channels and using larger channel widths via bonding neighboring channels much simpler.  802.11a allowed the use of 20 MHz channels.  802.11n allows the use of 40 MHz channels, and 802.11ac allows the use of up to 80 MHz or 160 MHz channels.   This is shown in Figure 3.

Figure 3:  Channels on the 5 GHz frequency band. [1, 2, 3]

The use of 40 MHz channels at 5 GHz with 802.11n is fairly common practice.  In most SMB deployments, unless the design calls for high client density (e.g. convention meeting space, large classrooms, etc.), or there is explicit issue to avoid the DFS channels (rarely a problem for indoor deployments, sometimes a concern for outdoor deployments), we can generally use 80 MHz channels with 802.11ac, and thus double the wireless throughput.  This is the primary advantage of deploying 802.11ac access points vs. 802.11n access points. 

The full list of 20 MHz channels available in North America is shown in Table 1.   Governmental regulatory agencies in other countries may restrict the use of one or more of these frequency bands and/or the maximum transmit power at those frequencies.  Most access points require that a country be selected in the configuration, which dictates what channels and maximum transmit powers are available.

Table 1: 20 MHz channels on the 5 GHz band.

Creating 40 MHz (and larger) channels involves bonding multiple neighboring channels together.  Each bonded channel has a primary 20 MHz channel that is used when an 802.11n or 802.11ac access point communicates with a legacy 802.11a client (or an 802.11n or 802.11ac client that is artificially limited to smaller channels).  The other bonded channels are “extension” channels, and can be either immediately above (upper) or below (lower) the primary channel.

Unfortunately, there are multiple “standards” of referring to bonded 5 GHz channels, which makes it very confusing for both Wi-Fi novices and experts, alike.   The three basic methods are to refer to their bonded channel range, their primary channel with extension (two variants for 40 MHz, four variants for 80 MHz), or their center channels (i.e. frequencies).   These are shown for 40 MHz channels in Table 2 for 40 MHz and for 80 MHz channels in Table 3.

Table 2: 40 MHz channels on the 5 GHz band.

Table 3: 80 MHz channels on the 5 GHz band.

The (*) is for channel 144.  This channel was opened up in March 2014 for use by Wi-Fi in the United States as part of the 802.11ac specification.  You will therefore generally not see it as a valid channel option on older 802.11n access points.  Furthermore, even on 802.11ac access points, many AP vendors still have firmware that complies with the older FCC specifications (i.e. pre March 2014), so do not recognize Channel 144 as being valid for use in the United States.  Accordingly, Channel 144 (20 MHz), Channel 140 (40 MHz), and Channel 132 (80 MHz) often cannot be used in static channel plans.

Note that the UNII-2 and UNII-2e bands (which cover 2/3 of the frequency space) are still in use by legacy military and commercial weather radar systems.  This leads to a requirement known as dynamic frequency selection (DFS), which requires Wi-Fi devices to periodically measure for the presence of such legacy radar systems and move off of the channel for a period of time if it is detected.  Currently, both the access point and client devices are each responsible for detecting DFS interference from radar devices and, if detected, move off the channel.   Prior to March 2014, only access points were required to make that detection and channel move, notifying their connected clients as to the channel change so as to encourage the clients to follow.  This was part of the original 802.11h amendment when UNII-2 and UNII-2e were opened up for Wi-Fi.   The older rules made more sense from a Wi-Fi operations perspective, as client devices associate with an access point and thus follow the access point’s channel.   Unfortunately, many legacy client devices didn’t know how to interpret the “I’m about to change from channel x to channel y” message from the AP and therefore didn’t move off the channel fast enough, which is probably what prompted the rule change.

The unintended consequence of this is that many consumer Wi-Fi device manufacturers decided it wasn’t worth investing in the code to do the DFS detection, and as a result just won’t operate at all on any of the UNII-2 (52-64) or UNII-2e (100-144) channels.   This is why many 802.11n consumer devices supported the UNII-2 and UNII-2e channels, but their newer 802.11ac counterparts do not. Ironically, this also tends to be a limitation of the consumer wireless router products from manufacturers that also make enterprise access point equipment that supports DFS detection. 

Fortunately, most phone and tablet manufacturers are not so shortsighted, so iPhones / iPads and most mainstream brands for Android phones / tablets with 802.11ac capability will work on the UNII-2 and UNII-2e bands.  Also fortunately, most consumer client devices these days are dual-band, so if they do roam to an AP with a 5 GHz channel they don’t recognize, they will still connect on the 2.4 GHz radio and be treated as a 2.4 GHz only client.  Where it can become problematic is using 5 GHz only consumer devices, such as USB dongles and 802.11ac wireless bridges.

Why not just let the AP figure it out on its own?

Many vendors provide features to do automated radio resource management (RRM), commonly also called auto-channel and auto-power. 

For each access point with auto-channel enabled, the AP senses the surrounding environment and then select the “best channel”, i.e. the channel that is presumably least in use by surrounding APs.  This is not officially part of the 802.11 standard, so each vendor implements this feature differently.  It is generally intended to make Wi-Fi deployments easier, and to react to changes in interference from the external environment by not requiring a static channel plan.  The problem with this approach is that these algorithms, while great for vendor marketing, tend not to work in actual practice, and in fact can make the network performance worse.   The standard implementation has each AP perform a periodic scan of all of the channels, typically on the order of 250 ms per channel, to give it enough time to hear at least two beacon frames from surrounding APs.  Once the access point has measured out all of the channels, it will then select the channel that is the least noisy.  This approach, however, is fundamentally flawed:  not only does the AP not get a true understanding of the channel usage over time, but it can be deceiving, especially on the 2.4 GHz band, where a channel can be seen as “clear”, even when there is a lot of traffic on overlapping channels.   On the 5 GHz band, there are many more channels to scan.  The number of channels also increases as you go to bonded 40 MHz, 80 MHz, and 160 MHz channels (though as of 802.11ac which introduced 80 MHz and 160 MHz bonded channels on the 5 GHz band, beacons are broadcast on all of the 20 MHz sub-channels).    Additionally, such algorithms tend to be convergent, meaning that neighboring APs have a tendency to settle on the same or overlapping channels, thereby increasing co-channel interference between APs. 

Auto-power is similar in form, function, and limitations as auto-channel.  As the name implies, auto power dynamically adjusts the transmit power levels used by each AP, with the intent of reacting to changes in interference from the external environment by adjusting the effective area of coverage from each AP to minimize co-channel interference.  

It should be noted that some vendors have proposed more sophisticated proprietary methods to automatically control channel and/or transmit power.  Generally, such alternatives tend to be divergent, i.e. change channels very frequently and not settle down.  It is therefore considered best practice to turn off auto channel and auto channel, and use static channel and transmit power plans for both the 2.4 GHz and 5 GHz bands.

References

1. Coleman, D. and Westcott, D.  CWNA Certified Wireless Network Administrator Official Study Guide: Exam PWO-105.  3^rd edition.  John Wiley & Sons, Inc., Indianapolis, IN.  ISBN 978-1-118-12779-7.   Copyright 2012.
2.  Jackman, S., Swartz, M., et al.  CWDP Certified Wireless Design Professional Official Study Guide: Exam PW0-250.  .  John Wiley & Sons, Inc., Indianapolis, IN.  ISBN  978-0-470-76904-1.  Copyright 2011.
3.  Hintersteiner, J. EnGenius Certified Operator.  EnGenius Technologies, Inc. certification program course.    Copyright 2014-2015.
4. COMMENTS OF THE NATIONAL TELECOMMUNICATIONS AND INFORMATION ADMINISTRATION, Copyright 2005. 
5.