The Limitations of Channel 144

Channel 144 (5.720 GHz) is a 20 MHz channel that is a part of the UNII-2e band.   It was added in March 2014 specifically as part of the official 802.11ac specification, so that the new Wi-Fi amendment would support an additional 80 MHz channel of 132-144 (see the figure above).   

While this additional 20 MHz channel is supported now in the 5 GHz band for Wi-Fi use, most legacy 802.11a and 802.11n clients don't actually support Channel 144 in their firmware.  These clients will support the 20 MHz channels 132, 136, 140 and (for 802.11n 5 GHz) the 40 MHz channel 132-136.   

Wi-Fi uses extended channels in order to be backwards-compatible to older generations.  One of the 20 MHz channels is defined as the primary.   The choices are upper and lower.   An upper extension uses the lowest channel in the primary and extends upwards to the neighboring channels.  Hence, for the 80 MHz channel 132-144, upper extension will use channel 132-136 for 40 MHz clients and channel 132 for 20 MHz clients.   By comparison, lower extension uses the highest channel as the primary and extends downwards, and thus would use 140-144 for 40 MHz clients and channel 144 for 20 MHz.   

For 80 MHz channels, technically the intermediate 20 MHz channels could be selected as the primary.  I have recommended to clients the following nomenclature (using Channel 132-144 as an example):

• Upper / Upper Extension:  Channel 132 (20 MHz), Channel 132-136 (40 MHz)
• Upper / Lower Extension:  Channel 136 (20 MHz), Channel 132-136 (40 MHz)
• Lower / Upper Extension:  Channel 140 (20 MHz), Channel 140-144 (40 MHz)
• Lower /Lower Extension:  Channel 144 (20 MHz), Channel 140-144 (40 MHz)

The terminology shall likely get even more confusing if we ever start using 160 MHz channels.

While there aren't a lot of legacy 802.11a clients, 802.11ac currently only has about 30% market penetration for 5 GHz client devices.  Hence, 40 MHz clients will be around for quite some time, and these clients will probably not support Channel 144.

  

What this means in practice is that you can ONLY use channel 144 as part of an 80 MHz channel, and must use the Upper Extension (or Upper / Upper or Upper / Lower), so that 40 MHz and 20 MHz legacy clients would avoid the use of Channel 144.

Wi-Fi Beacon Frames, Simplified

We talk about the Wi-Fi offerings on one AP, or across multiple APs in the same extended service set (ESS), as if it is all one unified network.  In reality, each AP has its own set of SSIDs, and each SSID is on its own VLAN.  We set up multple SSIDs purposely to make each of these different SSIDs an “independent” network.  (If you want further explanation of VLANs and why to use them, check out my earier blog post on this.)  

Similarly, the SSIDs on the 2.4 GHz band are “independent” from the SSIDs on the 5 GHz band, because different physical radios and antennas are used.  I’m using “independent” in quotations, as there are some coupling terms between the SSIDs on the same AP and between the same SSID offered on both the 2.4 GHz and 5 GHz bands.  Hence, while we can configure all of these SSIDs and networks independently, they do have interactions in the unbound RF medium, and thus we want to maintain certain relationships between them.

Every SSID on each band broadcasts its own unique beacon frame.  This is a periodic advertisement broadcast out to tell any listening devices that this SSID is available and has particular features / capabilities.  Client devices depend upon these beacon frames to discover what networks are available (passive scanning), and to ensure that the networks that they are associated with are actually still present and available.  A client also has the option to perform active scanning, where a client device sends a broadcast request to see what networks are available, and each SSID from each AP in range will send out a unicast probe response that has the same information as a beacon frame.  

Think of a beacon frame as a guy/gal standing out in front of a shop in a silly costume, advertising the shop to any and all passers-by.  In contrast, think of the probe request as a potential customer coming up to the guy/gal in the costume and asking “what do you offer?”  In the scenario where an AP offers multiple SSIDs (either within the same band and/or across bands), extend the analogy to a strip mall with multiple shops, where each shop has someone in a different silly costume making an advertisement to passers-by, but they have a mutual agreement than only one of them will talk at a time, so they do not talk over each other and confuse customers (i.e. “avoid collisions” in Wi-Fi parlance).   The probe request from the client can contain a specific SSID, analogous to a customer walking up to a specific costumed advertiser to ask “what do you offer?”, or a null SSID analogous to a customer asking the entire group of costumed advertisers at once “what do all of you offer?”, with then each costumed advertiser giving his/her unique response.

Each beacon frame (or probe response) contains a lot of information about the specific SSID being offered.  While not a complete list, the really important items are as follows: 

• SSID Name: 1-32 character name of the network
• BSSID:  Unique Layer 2 MAC address of the SSID
• Security capabilities:  e.g. open, WEP, WPA, WPA2, personal (passphrase) vs. enterprise (802.1x with RADIUS server)
• Channel: specific frequency that this SSID on this AP is operating on
• Channel width: e.g. 20, 40, 80, 160 Mbps
• Country: List of all supported channels and corresponding channel settings
• Beacon interval: How often the AP sends out this beacon frame
• TIM / DTIM:  Used for power management to allow devices that sleep to wake up at specific intervals to find out if there is unicast or broadcast data waiting for them

Quite importantly, beacon frames also advertise the connection speeds that the AP can use to connect to a client device.   These are broken up into a few different categories: 

• Basic rates: These are the 802.11a/b/g speeds that every connecting client device MUST support in order to maintain a connection
• Supported rates:  These are the 802.11a/b/g speeds that the AP will support and could use if the client device also supports those speeds
• 802.11n MCS rates:  These are the subset of the 78 total modulation and coding schemes (MCS) that are defined for 802.11n that the AP supports.  In reality, it gets dictated by the number of spatial streams that the AP supports (MCS 0 -7 for single stream, MCS 8-15 for dual stream, MCS 16 – 23 for three streams, and MCS 24 – 31 for four streams).   MCS32 – MCS77 are defined as combinations of asymmetric rates across different streams, which sounds like a neat idea but is utterly impractical in practice. 
• 802.11ac MCS rates / streams:  This is simplified compared to 802.11n, as there are no asymmetric rates, and the particular modulation and coding stream combination use the same index no matter how many streams.  256 QAM is added, providing two additional modes per stream, so these are simply MCS 0-9.  The beacon indicates whether the AP supports MCS 0-9 on one stream, on two streams, on three streams, etc. up to eight streams.  While the beacon is architected such that it could exclude particular modes, e.g. “I don’t support MCS 5 on three streams”, the spec dictates that an AP must support all 802.11ac MCS modes across all of the streams it has available.

Beacons are always sent at the lowest basic rate (and primary channel when using extended channels in 802.11n/ac).  This is done to ensure that every possible client in range of the AP hears the beacon frame.  When an AP has multiple SSIDs (on the same and/or across multiple radios), it sends out a separate beacon for each SSID on each radio.  Each SSID in a particular band must have a unique MAC address, so typically one of the hexadecimal digit (usually the last, but some vendors increment the first) is incremented so that each SSID has a unique MAC address.   

If you opt to “hide” the SSID, then the SSID name is blank, but the rest of the beacon is still sent out normally.  When the client decides to associate with an SSID, it has to specify the SSID name in the (re)association frame it sends to the AP.  This is why hiding an SSID is ineffective as a security measure and thus generally advise network admins not to bother:  anyone capturing association / reassociation request frames with a Wi-Fi packet analyzer will capture the name of the SSID in clear text.

Considerations for in-band (2.4. GHz OR 5 GHz) beacon frames

In the case where there are multiple SSIDs within the same band, all of the parameters could be set independently.  Obviously the SSID name, BSSID, and the security features are going to be unique, and the channel setting, channel width, and country will be identical.  But what about the other parameters?   

• Beacon interval:  Usually consistent across all SSIDs within a band.  To my knowledge, there isn’t anything to be gained if some of your SSIDs beacon more frequently than others.  A typical beacon interval is 100 time units (a time unit is 1.024 ms, so every 102.4 ms).  One would use a longer beacon interval (e.g. 300 time units or 307.2 ms) to reduce overhead in the channel, since beacons are transmitted at the lowest speeds and each SSID requires its own beacon).  Since a client device uses the beacon frames from the BSSID to which it is connected to confirm the AP is still there (i.e. in range and active), making the beacon interval too long might cause some clients to time out and instigate roaming to another AP when they should not be doing so.
  
  
• TIM / DTIM:  Usually consistent across all SSIDs within a band.  To my knowledge, there isn’t anything to be gained if some of your SSIDs require more frequent check-ins from sleeping client devices vs. others.  A typical DTIM will require that a sleeping client (e.g. VoIP phone, smartphone, tablet) be awake for every 3-5 beacon frames to check to see if any frames have been queued for it in the interim.  If you are using a slower beacon interval, then it is common to adjust the interval here in order that a sleeping client checks in regularly.  As an illustrative example, if one normally told the client to be awake every third beacon for 100 TU beacon interval, you'd probably want the client to be awake every beacon for 300 TU beacon interval.
  
  
• Connection Speeds:  Usually consistent across all SSIDs within a band.  To my knowledge, there isn’t anything to be gained by allowing particular connection speeds on some SSIDs and not others.  Changing lowest basic rates will change the speed at which particular beacons are transmitted, but again there is no advantage to having some beacons go out at faster speeds than others.

I suppose there are some rare use cases where one might want particular SSIDs to act differently.  One potential scenario is a guest network, where I want to maximize compatibility with all possible devices that could connect vs. a staff network, where the admin has strict control over the devices and their locations on their network and wants to “optimize” their performance.  To me, this seems to introduce a fair amount of complexity for dubious practical gains, which is a situation I generally try to avoid.

Cross-band (2.4 GHz AND 5 GHz) beacon frames

In the case where we have the same SSID on both the 2.4 GHz and 5 GHz bands, we generally want to take advantage of a feature called band steering to force dual-band clients to use the 5 GHz band.  The 5 GHz band generally has wider channels and fewer sources of external interference, making for a faster user experience.  In this case, the SSID name and all security features (along with VLAN settings, which are set on the AP but are not part of the beacon) should be identical.  The channel and channel width will be different (by definition).   The connection speeds will be somewhat different based on the differences between 802.11b/g/n on the 2.4 GHz band and 802.11a/n/ac on the 5 GHz band.   There is no need to support 802.11b speeds on the 5 GHz band, though the 802.11a and 802.11g speeds are identical, and the 802.11n speeds are also identical (if the streams are identical). As for beacon interval, these are usually identical but there is no requirement to do so.  Based on the usage characteristics per band (i.e. how many clients per band, what connection speeds being used, etc.), it could be advantageous to tweak this setting per band to optimize overhead performance.

Across the 2.4 GHz and 5 GHz bands, since the radios are independent on both the AP and client device, some vendors increment the BSSID to identify the particular SSID and some vendors don’t. (This is sometimes referred to a virtual BSSID.)  In this case, it doesn’t matter if the BSSID is reused since 2.4 GHz and 5 GHz transmissions cannot hear each other, and the Layer 1 (physical) and Layer 2 (MAC, think Wi-Fi chipset) levels are physically separate from each other.

The most common network scenario in practice is the need to support 802.11b devices (either legacy or new low-power IoT) and/or 802.11g devices (legacy).   Both of these are on the 2.4 GHz band.  There were virtually no independent 802.11a client devices, as this standard was primarily used for dedicated point-to-(multi)point wireless links.  Hence, if a network needs to support slower 2.4 GHz devices, one probably wants to leave the network configured with a standard beacon interval of 100 time units and support for all 802.11 b/g rates.  On the 5 GHz network, we almost always want to maximize performance, so on this band it would make sense to make tweaks, such as using longer beacon intervals (e.g. 300 time units) and drop support for some of the slower 802.11a connection speeds, such as 6 Mbps and 9 Mbps.

The Wi-Fi Range Sucks! Or Does It?

As a Wi-Fi engineer, I get the following type of question an awful lot from people who are not immersed in Wi-Fi technology and not technology experts:

Why is the range of the Wi-Fi so poor?  Why can my device connect to my old cheap consumer WAP and not to your fancy and expensive enterprise access point?

This is a hard to answer this question in a manner that is both simple to understand / not very technical while also being accurate and comprehensive.  But here goes...

It is very common for consumer-grade access points to advertise and tout their range (i.e. area of coverage).  They do this by cranking up their transmit power to FCC maximums (around 30 dBm = 1 Watt).  

To first order, the speeds achievable over Wi-Fi are a function of the distance between the transmitter and receiver, as shown below.   Intervening objects, like walls, furniture, etc. will also attenuate the signal in a non-symmetric way, so in reality the signal is never symmetric, so consider this a vastly simplified illustration only.

The problem is that Wi-Fi communication is asymmetric, and the transmit power of your smartphone or tablet is about 100 times less than that of the AP (around 10 dBm = 0.01 Watt).  The device manufacturers do this purposely to maximize battery life.   Hence, comparatively, the consumer-grade access point is screaming whereas the client device is whispering.  Accordingly, a client device can hear the access point fairly well at reasonable connection speeds, but it is very hard for the access point to resolve upstream messages from the client device, even at very low connection speeds. 

This asymmetric mode of operation was still “ok” in the days when Internet traffic was primarily downstream to a device.  For example, you’d type in a URL in your browser, or click on a link, send a small amount of information upstream to the Internet, then download a whole lot of data and content to your device.

Alas, modern Wi-Fi usage no longer works this way.  People expect to take pictures and videos and either email them to friends and/or post them to social media. Wi-Fi appliances, sensors, and cameras are constantly streaming data to the network.  Accordingly, there is quite a lot more upstream traffic from the wireless devices to the access point and the Internet.  Very slow upstream speeds resulting from a weak transmitter only serve to make the Wi-Fi seem “slow”.

Proper modern Wi-Fi design, therefore, attempts to balance the power levels between the client device and the access point by lowering the output transmit power of the access point.  Hence, the access point isn’t screaming quite as loud, and the client will therefore need to be closer to the access point to maintain connectivity, which improves signal quality and ultimately signal speed.   This approach does ultimately require more access points to be deployed in an environment.  However, there are other industry trends that simultaneously drive the need for more access points:

1. 802.11n and 802.11ac take advantage of the 5 GHz band, which has less sources of external interference and uses wider channels.  Thus, 5 GHz tends to have more data capacity, and thus higher throughput, as compared to the 2.4 GHz band used by older generations of Wi-Fi like 802.11b and 802.11g.  802.11n works on both the 2.4 GHz and 5 GHz bands, whereas 802.11ac only works on the 5 GHz band. (Any dual band 802.11ac access point from any vendor is actually using 802.11n on the 2.4 GHz band).   While 5 GHz has more capacity, it has less range, and attenuates more quickly when passing through walls, furniture, appliances, mirrors, people, etc.  To achieve a roughly equivalent area of coverage, one usually needs the 2.4 GHz radio to be set 6 dB lower (i.e. ¼ of the power) than the 5 GHz radio.  I usually recommend 14 dBm on the 2.4 GHz band and 20 dBm on the 5 GHz band, but this is very much dependent upon the specifics of your deployment environment and the types of devices being used on the network.
   
2. The faster speeds advertised by 802.11n/ac (as compared to their 802.11a/b/g forebears) come at a price: effective range.  The higher speeds of modern Wi-Fi are achieved by increasing complexity:  modern Wi-Fi uses numerous mathematical techniques to stuff more data into the same unit of time.  The more sophisticated the math, the more data can be stuffed, and the faster the effective throughput.  However, with complexity comes fragility.  Remember the old line from Star Trek V when Scotty says “The more complicated they make the plumbing, the easier it is to plug up the drain.”  This adage holds very true in Wi-Fi.  By making the modulation and coding more complex at the transmitter, the stronger the signal needs to be at the receiver in order to properly resolve it and reconstruct the message. 
   
3. People are continuously using more wireless devices simultaneously on their networks and consuming more data, both upstream and downstream.  This trend shall continue to grow rapidly over the next several years with the introduction of Wi-Fi enabled appliances and sensors with the Internet of Things (IoT).  Hence, Wi-Fi design is not only about “coverage” but about “capacity”.  More devices streaming more data back and forth to the wired network and the Internet require more APs in the environment to balance the load.

We’ve been conditioned by the manufacturers of consumer Wi-Fi equipment to think of Wi-Fi like a can of paint:  “e.g. one access point covers 2500 sq. feet”.  The reality is much more complicated and nuanced – it depends on what is in your environment (e.g. drywall vs. stucco vs. metal walls, furniture, appliances, etc.), the number and types of devices you have on your network, what kind of traffic is being passed, both upstream and downstream, and how fast you want your wireless devices to access the Internet.