Should you ever deploy 802.11ac wave 2 for an SMB Wi-Fi network?

This has been a controversial question amongst AP manufacturers and Wi-Fi engineers.   The AP manufacturers are busy pushing out 802.11ac wave 2 access points, while us Wi-Fi engineers cannot resist playing with the “latest and greatest” Wi-Fi technology.

That said, as always, the answer to the appropriateness of deploying 802.11ac wave 2 is “it depends on your requirements.”  In the SMB market, where I specialize, the answer is almost always going to be “no”. 

(If you are interested in more detailed technical aspects, I refer you to my previous blog post, which goes into technical detail as to how MIMO and MU-MIMO work.   While 802.11ac is a single standard, it has been implemented by the Wi-Fi industry in two different phases, known as “waves” in the market.  Thus, it is convenient and practical to present “802.11ac wave 1” and “802.11ac wave 2” as two different and successive generations of the Wi-Fi standard, even though this is incorrect by strict definition.)

802.11ac wave 1 was introduced in 2014 and provided two major improvements over 802.11n:

• 80 MHz channels at 5 GHz.   This more than doubles the throughput of a 40 MHz channel at 5 GHz with 802.11n, though the number of independent non-overlapping channels is now only 5-6 at 80 MHz, vs 12 at 40 MHz.   If the DFS (i.e. radar) portions of the band need to be omitted, generally due to close proximity to airports, military installations, or weather stations, this reduces to only 2 independent channels at 80 MHz vs. 4 independent channels at 40 MHz.  Fortunately, most SMB applications are not high density and generally not in close proximity to locations where DFS is an issue, so using 80 MHz channels is perfectly appropriate.
• 256 QAM at 5 GHz:  This is a more complex modulation scheme that, at its maximum, squeezes an additional 33% throughput improvement above the maximum 64 QAM MCS rate used in 802.11n.  The major limitation of 256 QAM is that the signal to noise ratio (SNR) needs to be > 29 dB in order to successfully resolve this encoded modulation at the receiver.  In practical terms, this typically translates into the client device needing to be within 10 – 15 feet of the access point with no major obstructions (e.g. walls) or significant co-channel interference.   Clients with lower SNR (either due to distance and/or interference) will still connect at the same MCS rates available in 802.11n.

Thus, while 802.11ac wave 1 could be argued to be a “minor” improvement over 802.11n @ 5 GHz, the throughput gains from using 80 MHz channels can generally be realized, making it a sound technology investment for any new SMB Wi-Fi network.   

802.11ac wave 2 brings three additional “improvements” over 802.11ac wave 1, though the practical gains from these for the SMB market are non-existent. 

“Improvement” 1: 160 MHz Channels

These can either be a contiguous 160 MHz or two non-contiguous 80 MHz channels on the 5 GHz band.  Currently, either configuration only supports two independent 5 GHz channels, given the allowable frequencies by the FCC.   Any practical multi-AP deployment needs an absolute minimum of three independent channels to keep co-channel interference effects manageable.  More independent channels are always better, which is why higher density deployments tend to avoid even 80 MHz channels (5-6 independent channels).   Hence, unless significantly more 5 GHz frequency space is opened up for Wi-Fi use (which is being considered by both Congress and the FCC), it is unlikely that 160 MHz channels will be practical for any type of multi-AP deployment.

Where 802.11ac using 160 MHz channels will be useful is for short-distance and very high capacity 802.11ac point-to-point wireless backhaul links.  Conceivably, practical throughput speeds above 250 Mbps should be achievable.  This will require the use of highly directional antennas and a distance limitation of a few hundred feet, in order to minimize the effects of surrounding Wi-Fi systems on overlapping channels and to maintain a SNR above 29 dB, to maintain MCS rates utilizing 256 QAM.   There are a lot of applications where such links are useful, especially when doing multi-building IP camera surveillance.

“Improvement” 2:  8 Stream Multi-In Multi-Out (MIMO)

Both 802.11n and 802.11ac wave 1 had a maximum of 4 spatial streams per band.  When the spatial streams are used to pass different data sets between an AP and a client device, a technique known as spatial multiplexing, the throughput is effectively doubled, tripled, or quadrupled compared to a single stream.   Because of the way spatial multiplexing works, the number of achievable streams have to match on both the AP and the client; whichever device has the lower number of spatial streams drives the number of spatial streams that are used.  Because of power and size constraints, most smartphones only have one spatial stream, and most tablets only have one or two spatial streams.  Some higher-end laptops will have three spatial streams, but 3x3:3 is a practical maximum for client devices.  Accordingly, no enterprise AP manufacturer ever commercially offered a 4x4:4 stream access point for 802.11n or 802.11ac wave 1, even though the 802.11 specs allowed for it.   Hence, increasing the number of spatial streams is of no benefit to spatial multiplexing operation with single user MIMO (SU-MIMO).  Emergent 802.11ac wave 2 APs are 4x4:4 stream, but the motivation for additional streams is MU-MIMO. 

“Improvement” 3:  Multi-User Multi-In Multi-Out (MU-MIMO)

MU-MIMO is intended to talk to multiple client devices simultaneously.   While this technique looks impressive on paper, it is still a dubious prospect as to whether MU-MIMO can be made to work in actual practice, despite most AP vendors racing to produce MU-MIMO AP models.  Even if MU-MIMO can be made to work in real-world environments, its application is fundamentally limited.

MU-MIMO requires position feedback from all client devices engaged in a simultaneous communication session, which requires the chipsets and drivers in the client devices to support calculating and providing such feedback.    Furthermore, the client devices sharing a simultaneous communication session need to be geographically separated (with respect to the AP location) while connected at the same MCS rates, so that the communication to each client takes the same amount of time.  Unlike past Wi-Fi performance improvements, which have generally been focused on establishing and maintaining faster and faster connections between APs and clients, MU-MIMO does not increase connection speed but increases airtime efficiency.  The logic is as follows: if an AP can talk to 2-3 clients at once, it can support more clients at the same connection speeds, or (this is where we collectively “cross our fingers”) support more data throughput to the same number of clients.

Hence, MU-MIMO will only be of any practical benefit in very high density deployments, such as stadiums and conference centers.  It isn’t particularly clear whether K-12 and higher education environments are dense enough to really benefit from MU-MIMO, even though that is clearly the largest target market for MU-MIMO technology. 

For the SMB space, the growth of devices on Wi-Fi networks is coming in the Internet of Things (IoT), which, according to the hype, consists of an ever-growing array of wearable sensors and Wi-Fi appliances to monitor our health, our environment, our security, and our activities.  Some of these devices, like Google Glass and Apple Watch, are already on the market and have a decent adoption rate.  That said, the IoT in the short and medium term have characteristics which make them incompatible with 5 GHz 802.11ac with MU-MIMO. Most importantly, most IoT devices that are Wi-Fi compatible only operate at 2.4 GHz, and are likely to stay that way for the foreseeable future.  Google Glass contains a 2.4 GHz 802.11g chip (2003 technology), and the just debuted Apple Watch contains a 2.4 GHz 802.11n 1x1:1 stream (2009 technology).  Why?  Older generation NICs are cheap, and most IoT devices require minimal bandwidth.  Monitoring someone’s health vitals requires << 1% of the throughput of a streaming 4K video.  These devices are also designed with consumers in mind, so making them sleek and sexy, as well as functional, is way more important than maintaining optimal performance of a third party Wi-Fi network.  Even if the IoT manufacturers eventually succumb to pressure to include 5 GHz Wi-Fi, it is unlikely that they’ll install anything better than 5 GHz 802.11n 1x1:1 stream, because the data requirements simply aren’t there.

So what’s the recommended technology to invest in for an SMB Wi-Fi network?

Most new or renovated Wi-Fi network deployments in the SMB market should be installing 802.11ac wave 1.   Any system being installed today has a life expectancy of, at least, 5 years, so for that reason alone, the latest and greatest technology should be used, as it will be “less antiquated” in that 5 year period.   We don’t really know how a network deployed today will be used over the next several years, but it is reasonable to expect to see even more devices consuming even more data.   

I would only recommend 802.11n dual-band deployments on an exception basis, in cases where project budgets are really squeezed (though 802.11ac APs are not substantively more expensive than dual band 802.11n APs), or in specific cases where density and/or DFS constraints make it impractical to use 80 MHz channels.   As for those of you still deploying 2.4 GHz only, please stop!  Unless you’re deploying in a mine shaft, where 5 GHz simply doesn’t propagate, a properly designed and implemented network will always provide better Wi-Fi performance on the 5 GHz band.

VLANs: Why You Always Want to Use Them, and How They Work

VLANs, or Virtual Local Area Networks, are one of the most powerful, and one of the most misunderstood and underutilized, tools for Wi-Fi networks in the private home and small-to-medium-business space.  This post provides a pragmatic guide as to why and how you should use VLANs.

What are VLANs?

At its simplest, VLANs enable you to transform one physical Local Area Network into multiple, isolated, logical Local Area Networks.  Thus, you literally have multiple LANs with different purposes and intents that are co-located physically, without the expense of multiple sets of hardware and multiple sets of cabling.

This is extremely useful for even small network applications, especially with the growth of IoT and the proliferation of network appliances measuring and controlling our environment.

Take the "simplest" case of a private home.  Even when you only need a single AP to provide Wi-Fi coverage, there are, at least, two distinct and isolated networks needed.  First and foremost, a network is needed for the residents of the home, allowing access to all PCs, network printers, multimedia devices such as AppleTV or SONOS, IP cameras, NEST thermostats, and the like.   However, a separate network is needed by guests, as the homeowner undoubtedly doesn't want the teenage daughter's 20 closest friends staying over for a slumber party to hack any of the computers or network appliances  in the home.  In slightly more complex SMB applications, such as coffee shops, restaurants, doctor's offices, and multi-dwelling units such as an apartment building, dormitory, or hotels, there are also usually at least two distinct and isolated networks needed.   There is the network needed by the business staff for operations, such as point-of-sale, IP surveillance, access control, HVAC control, multimedia, etc.  There is also the need for the businesses' customers to be able to simply and easily access the Internet, but not have any access to any network devices used for operations.  

Generically, virtually Wi-Fi network networks need to be segmented, at least, into an operations network and a visitor network.   The requirements for who is allowed access to these networks and how they get used are quite different. 

• Operations:  Typically, access to this network needs to be restricted to authorized personnel, as it contains data that is confidential to the business and critical to day-to-day operations, especially financial and security data.  For a small network, typically a WPA2-AES Pre-Shared Key is sufficient security: the code must be known in order for the wireless client to connect to this network.  In larger setups, using 802.1x with RADIUS may be appropriate.  Once connected to the network, the client device likely needs access to other wireless devices and appliances on the network, so client devices need the ability to intercommunicate with each other.   In some environments, breaking up the operations network into multiple separate VLANs by function is appropriate, especially to separate out applications like security (i.e. cameras and access control), facilities (HVAC, lighting control), and voice over IP / voice over Wi-Fi.

• Visitors:  Also commonly referred to as a "hotspot" (i.e. independent of actual size of coverage area / number of APs), access to this network needs to be unrestricted, as the facility has no control over what devices their customers are bringing in and using.  Thus, typically no encryption is used to facilitate access, though a captive portal may or may not be appropriate to capture email / social media information, publish terms and conditions for use, and/or restrict maximum bandwidth per device.   Once connected, visitors should only have access to the Internet, and have no access to any network devices on the operations network, nor access to any other client devices on the visitor network.   You don't want a hotel guest hacking into the device in a different room.

A note on security for visitor / hotspot networks:   I keep encountering "visitor" networks that require a WPA2-AES pre-shared key.   This is actually quite pointless, and creates a false sense of security!   The logic of using a pre-shared key is that a hacker sniffing unencrypted radio frequency transmissions can intercept data traffic.   That is true.  Unfortunately, using pre-shared key encryption doesn't actually solve the problem.  A hacker that has the pre-shared key and who captures the association exchange (which is unencrypted) between a client device and an access point when it connects to the network, can use the collective information to decrypt the client device traffic.   Furthermore, most security issues on visitor / hotspot networks actually do not require sniffing the radio frequency, but rather come from the "wired side" of the network; all Wi-Fi encryption only occurs between the client device and the access point, as the access point decrypts all data traffic before passing it on to the wired network infrastructure.   If client isolation on the network is not set up properly (an all-too-common problem), a wireless hacker can simply connect to another wireless client device through the wired network.  Accordingly, the only thing that WPA2-AES pre-shared key adds to your network does is increased overhead on the staff, who have to give out the passphrase to all of the visitors.  If you want to remain secure when using a hotspot / visitor network,  make sure you are using application level security, such as https for web surfing and SSL for your email service. Personal or corporate VPNs are also eminently appropriate and effective. 

Many consumer wireless router appliances, such as the EnGenius ESR series, and enterprise wireless access points, such as most EnGenius APs in the EAP / ECB / ENS / ENH / EWS series, come with the ability to set up a "guest network" with a separate subnet and DHCP range.  The access point therefore creates a Layer 3 (IP) barrier between the guest network and the operations network to isolate them from each other.   Using this feature, however, is only appropriate for single AP networks.  On networks consisting of multiple APs, this configuration prevents roaming between APs since each AP is creating a separate standalone guest network.  Any client attempting to roam on the “guest network” will have to re-establish a Layer 3 connection, thus interrupting any streaming applications.  Thus, on multi-AP networks, VLANs should always be used to provide visitor / guest networking.

How do VLANs work?

Client devices don't know, and generally shouldn't know, anything about the VLAN configuration of a network.   Accordingly, all VLAN configuration is done on the network router, switch(es), and access point(s).  When a client device sends data, each packet is "tagged" as it enters the network so it can be routed to the correct destination, similar to the way your luggage is tagged when you check it at the airport, to make sure it is loaded on to the correct plane(s) to travel with you and is retrieved at your destination.   When the data reaches its intended destination, the tag is removed, which is commonly referred to as either "untagging" or "stripping the tag".   

In networking, the VLAN tag is a 4 byte element inserted into the MAC header of the packet.  This element contains a 12 bit number indicating the VLAN ID (or VID), meaning that, in theory, a network can have 2^12 or 4096 tags.  The all zero and all one tag (i.e. VLAN 0 and VLAN 4095) are not used per the 802.1q specification.  Furthermore, VLAN 1 is reserved for "untagged traffic", meaning that any data traffic in a network that does not have a VLAN tag is considered to be on VLAN 1.  This is also why all switch and access point VLANs are defaulted to VLAN 1.

By default, each port on a switch will drop VLAN traffic, so any VLAN traffic that is allowed through a switch port must be explicitly defined in the configuration.  Trunk ports are used to interconnect switches (and access points), where each VLAN in use on the network is explicitly defined as a tagged VLAN, meaning that the switch will pass traffic on that VLAN without touching the VLAN tag.

The tagging / untagging mechanism in switches and access points are a bit different between a wired client and a wireless client, but functionally they are identical:

• Wireless:  A wireless client associates to a particular SSID, and in the configuration of the access point, the SSID is associated with a particular VLAN.   All traffic coming from a wireless client is tagged with the VLAN ID associated with the SSID.  Similarly, the access point strips the tag associated with the SSID for all data traffic being transmitted to a wireless client.  Thus, from the perspective of the switch, all traffic coming from or going to an access point is tagged.
  
• Wired:  A wired client is connected to a particular port on a particular switch.   This port has two settings associated with it, which unfortunately are commonly put on different screens.  The first is the PVID.  This setting indicates the VLAN ID that should be tagged onto all traffic coming into the port (i.e. from the wired client).    Since each port has all allowed VLANs explicitly defined on it, an untagged VLAN can be defined, such that any traffic on that particular VLAN gets its tagged stripped before the traffic leaves the port.   By definition, a wired port connected to a client can have only one PVID and should have only one untagged VLAN, and these two should match in order for the connected wired client to communicate in both directions on that VLAN.

The router configuration similarly becomes a bit more complex.  Each VLAN on the network is considered to be a sub-interface of the LAN interface (since multiple VLANs exist on the same physical wire / NIC).   Thus, instead of defining an IP address, subnet, and DHCP range for a single LAN, each VLAN is treated as a separate LAN, and requires an independent subnet, IP address, and DHCP range.   By convention, some people like matching the second or third octet of the subnet to the VLAN ID.  For example, VLAN 8 could be given the subnet 10.8.0.0/16 or 192.168.8.0/24, VLAN 16 could be given the subnet 10.16.0.0/16 or 192.168.16.0/24, etc.   These settings are independent, so no correlation between the VLAN ID and the subnet is required, but it is often convenient. 

Typically, VLANs are used to keep the various LAN subnets isolated, so the router is generally just doing WAN to VLAN routing.   Cross-VLAN routing can be done in specific instances, and usually requires explicit rules to be set up to allow particular exceptions.   One common example would be a hotel with a printer in the lobby that they want both staff and guests to be able to use.   This printer could be placed on the visitor VLAN, and router rules can be defined to route traffic from the operations VLAN to the printer on the visitor VLAN.  In such a case, however, it is often simpler and cheaper to just buy two printers.

What's a Management VLAN, and should I use it?

Just as your operations and your visitors are put on two (or more) VLANs to separate the network traffic, it is best practice to use a separate VLAN for the web and CLI interfaces for your network router, switch(es), and access point(s).   This way, no users on any user VLAN can access (and therefore hack) your network equipment.   The management VLAN, therefore, is the VLAN for your network equipment.   

By default, all network equipment comes with the management VLAN set to 1, and all managed and smart switches are configured such that every port is PVID 1 / untagged VLAN 1.    Strictly speaking, if your operations users and visitor users are on their own VLANs, then the LAN is isolated from the VLAN users and acts as a separate VLAN (i.e. VLAN 1).   However, any user connecting to a misconfigured access point or a non-configured switch port can access your network equipment.  Therefore, it is best practice to explicitly define a VLAN for management and configure all of the network equipment to require traffic to be on the management VLAN in order to access its configuration. 

Can I get myself into trouble using VLANs?

Absolutely.   VLANs are a powerful tool, and are quite easy to misconfigure.   The usual problems encountered with VLANs are the following, along with some guidelines for avoiding and/or troubleshooting:

• Device is on the wrong VLAN:   This is usually due to traffic being put on to the wrong VLAN as it enters the network.  Make sure your SSID settings and PVID / untagged VLAN switch settings are correct.  Fortunately, this is usually fairly easy to catch, especially if your client device is configured for DHCP.   One look at the IP address on the client device will indicate if it is not getting a DHCP address, or is getting a DHCP address on the wrong subnet.  For static clients, an arping or nmap on the wrong VLAN will reveal the presence of the client.

• Data traffic doesn't flow:   This is usually due to either traffic being put onto the wrong VLAN as it enters the network, or switch ports not being properly and explicitly configured to pass traffic on that VLAN.  Remember that all network equipment ports on a switch, defined here as ports connected to either the router, backhaul to other switches, or access points, should be trunk ports and be configured for tagged VLANs for all VLANs used in the network, including management VLANs.  All ports connected to client devices and/or network appliances should only be configured for the PVID / untagged VLAN that the client should be connecting to. 

• Lose access to network configuration:  This is virtually always a VLAN mismatch between the PC being used to configure the network devices and the management VLAN set up on the device.   Management VLANs should generally be configured last; once you configure a network device to use a particular VLAN, you will typically lose access to that device until changing the port of your PC to be on the same VLAN as the management VLAN.  If you have a switch configured to be on management VLAN 4000, but none of the switch ports are configured for tagged or untagged access on VLAN 4000, you are cut off from the switch and have no way to access the configuration, short of a serial interface or a hard reset.   I always advise that each network switch have one port designated as a management port, and that it be configured to be PVID / untagged VLAN on the management VLAN.  

VLANs are a powerful tool, and should be an integral part of all of your Wi-Fi network designs.