The case "against" 802.11ac

Still a hot topic for debate:  Do you invest in more expensive 802.11ac access points or do you deploy cheaper 802.11n, given that 802.11n is likely more than adequate for today's needs in the small to medium enterprise environment.

The answer:  As always, it depends.  :)

There are only two main improvements in 802.11ac wave 1:

• 80 MHz channels:  Gives you 2x improvement in speed, but higher noise floor and more subject to external interference
• 256 QAM:   33% improvement in speed, but you need a > 29 dBm SNR to take advantage of it, meaning that in practical terms you must be within 10’ – 15’ of the AP in open air to get MCS 8 or 9.

Additionally, newer chipsets and APs generally have better performance, though impact is probably at most in the 10% - 15% range.   Given the same environment and the same 2x2:2 5 GHz 802.11n client device, an 802.11ac is likely to perform somewhat better than its 802.11n counterpart.

802.11ac wave 2 will have two other “improvements”:

• 160 MHz channels:   Gives another 2x improvement in speed, but even higher noise floor and, at least with current FCC allocated spectrum, only two usable channels, making it impractical for multi-AP deployments.
• MU-MIMO:   I finally understand how this is supposed to work (from WLPC 2015), and will have to go into it in a separate blog post.  Suffice it to say that it will likely only be useful in high density environments, and it requires transmit beamforming feedback from the client devices, meaning that the devices will likely need to be 802.11ac wave 2 compatible.  The feedback mechanism is actually part of 802.11n spec, but most client device vendors didn’t implement it.  It is not clear whether the functionality even was built into the chipsets of most 802.11n or existing 802.11ac wave 1 devices, or even if it was, whether firmware upgrades will ever be made available on current generation devices to make it useful.   Note that the feedback mechanism will also serve improve range, even if the "multi-user" part is not applied.

Add to this the bifurcation of client devices we are likely to see on the networks evolving in the next few years, which will ultimately lead to different classes of service based on FREQUENCY BAND:

• Smartphone / Tablet Devices (i.e. the iPhone 10):   Don’t know their capabilities, but their being more of them, sucking down more bandwidth more frequently is a pretty safe assumption.   Will use the latest and greatest Wi-Fi chipsets for 5 GHz / dual band.  They will still only be 1x1:1 or 2x2:2 devices because of the need to keep both size and power consumption down.   Even now there are very few high end laptops with 3x3:3 802.11n or 802.11ac capability, and that is unlikely to change going forward.  Hence the desire for MU-MIMO.
• Internet of Things:  Lots of devices that need to be connected all the time but each one passing very little data.  Consumer / price driven, so likely to have the cheapest Wi-Fi chipsets and antennas that can be found.  Hence, most of these devices will likely be 2.4 GHz only and maybe still 802.11b or 802.11g (i.e. not even 802.11n).

It is true that the bottleneck of the network is the internet bandwidth connection from the carrier.  That is where you want the bottleneck to be.   You never want the internal network (APs, switches, wireless bridges, or routers) to be the bottleneck.

So, still begs the question – do you deploy 802.11n or 802.11ac?   I still think the answer ultimately comes down to the expected lifetime of the network.  Most small / medium enterprise customers are not going to want to upgrade anytime soon.  The minimum lifespan of a network deployed today is at least 5 years, with 7-8 years being more likely.   Hence, do you deploy for today, or do you deploy for tomorrow?   The expectations of performance out of a network deployed today will only increase over time, both in terms of number of devices and in total bandwidth consumption.  I therefore believe today’s networks should have the latest and greatest technology deployed, if only to be 2-3 generations behind in 5 years vs. 4-5 generations behind.

LAA-LTE and the Threat to Wi-Fi

There is a big raging debate in the Wi-Fi industry right now about LAA-LTE.   This is a proposal by cellular carriers to use the 5 GHz unlicensed band to perform data offload, but using a LTE protocol and not Wi-Fi.   Of course the mobile carriers are going to proclaim how wonderful LAA-LTE is for their network operations and sugar-coat the whole Wi-Fi co-existence problem.

LTE, as a protocol, is designed to work on a licensed spectrum where you do not have to compete with, or even share, the resources with another network.  The "LAA" here stands for "licensed assisted access", which is a wonderful Orwellian term that sounds really good but actually means the complete opposite of what it sounds like.   In this context, "licensed assisted access" means that your traffic is traveling over unlicensed spectrum.

Whether licensed or not, wireless radio technology, being half duplex, is all about collision avoidance.  LTE uses time division multiplexing, generically known as TDMA.  TDMA, and all of its variations, are designed to work under the central premise that the network coordinates the usage of the spectrum, in order to prevent collisions from occurring between two or more radio transmissions on the same frequency.  Wi-Fi, by contrast, works by clients "contending" for the space and the right to transmit.  Most people don't understand that when you have a network with an AP and 20 client devices, the AP has to compete for the next transmission slot along with all of the clients, and while QoS modifies the contention rules, it is only a statistical advantage, not a guarantee. 

Wi-Fi and LTE are fundamentally conflicting and mutually exclusive architectures. Even if LAA-LTE allocated a large portion of the spectrum time to "external Wi-Fi", early studies (see http://www.cablelabs.com/wi-fi-vs-duty-cycled-lte/) have already shown that latency in Wi-Fi increases astronomically when an LAA-LTE network is present, even under light duty cycles. There are also no guarantees or requirements that LAA-LTE has to be configured to "play nicely" in the 5 GHz sandbox.

It is ironic that 2.4 GHz and 5 GHz used to be considered "garbage bands" that nobody in the cellular space wanted to get close to, until other companies figured out how to use the bands effectively (and make money from it). Now, these same carriers want to save money on licensed bands by seizing control over "free" unlicensed bands with LAA-LTE.

At the same time, the way the FCC rules are currently structured, the bands are unlicensed and thus there really isn't anything that the industry can do to stop it. If the 800 lb gorillas in the room want to bully their way into taking over the spectrum, they have the ability to make a real go of it.

One idea I've had on this subject is to take the proposed 5.9 GHz band that Congress wants to open up and dedicate those channels to applications like LAA-LTE, to keep it unlicensed yet, by mutual agreement, separated from Wi-Fi. Such an approach is unfortunately way too logical and reasonable to likely gain any traction.

Deploying in Hallways vs. Deploying in Rooms

Having done a lot of Wi-Fi in the Multi-Dwelling Unit (MDU) space, I'm often asked by installers for Wi-Fi in apartment buildings and hotels as to why I always recommend putting access points in the apartments / guest rooms instead of in the hallway.

It is generally true that installing APs in hallways is generally far easier than installing APs in units.  After all, many hallways have drop ceilings making cabling and installation a snap.    Even when there are hard ceilings present, cabling soffits or access panels are often already in place or are fairly easy to install, making cabling possible.   If there isn't already low-voltage infrastructure (i.e. a spare CAT5e / CAT6a cable) available in each unit, getting cabling into the units can be impractical or cost-ineffective.  

However, from a performance standpoint, putting APs in line of sight of each other down a hallway is the worst thing you can do for the following reasons:

1. Talkback:  Client devices like smartphones and tablets have weak transmitters in order to maximize battery life.  Accordingly, while the AP may be strong enough to be heard by the client, the client often is not strong enough to be heard by the AP.  Hence, you want to put the APs as close to the clients as possible to best facilitate the client's ability to "talk back" to the AP. 
2. Attenuation:  The inside wall adjacent to the hallway tends to have high attenuation.  Why?  Everyone likes having the biggest windows looking out as possible.  Hence, the inside wall tends to have all of the metal appliances (refrigerators, dishwashers, ovens, etc.), mirrors, plumbing, steel fire doors, etc.    This serves to attenuate the signal from the hallways.  It is not uncommon to see signal penetration through the floor / ceiling be much better than signal penetration from the hallway into the unit.
3. Self-interference:   A long, thin hallway acts as a tunnel for Wi-Fi signals, focusing the signal and making it extend much further than it will laterally into the units.    Furthermore, even with the APs on different channels, there is always some level of adjacent channel interference.   When all of the APs are in line with each other, they will cause interference with each other.  The heavier the traffic load, the more interference there will be.

If you don't have the benefit of existing low-voltage cabling infrastructure, one trick often used is to run the cables down the corridor, penetrate above the doorway to the apartment / guest room, and mount the AP above the door.   While the AP may still not be ideally located within the center of the unit, having to penetrate the inside wall with signal is eliminated, placing the AP closer to the client devices and taking advantage of the building structure itself to further attenuate signals between the APs.  

The Challenges of the Low-End Enterprise for Wi-Fi

The video of my 12 minute "Ten Talk" from the 2015 Wireless LAN Professional's Conference on the Challenges of the Low-End Enterprise for Wi-Fi is available online:

http://www.wlanpros.com/videos/jason-hintersteiner-challenges-of-low-end-enterprise-market/

The key messages from this talk are as follows:

• Most non-residential networks are in the low-end enterprise market (small and medium businesses) - this is a segment that is growing tremendously but is largely ignored by WLAN professionals
• Most enterprise solutions are not geared towards this segment - both too expensive and too complex
• Many of the challenges in the low-end enterprise market are similar to larger enterprises
• The tools used to deploy Wi-Fi in the low-end enterprise are more limited:
• Generally no site surveys except sometimes for predictive models
• Site walk-throughs are generally only concerned with where you can run cables
• Packet analysis never happens
• Most Wi-Fi problems come down to the four degrees of freedom
• Number and placement of APs
• Antenna
• Channel 
• Power
• You are designing for tomorrow, not today:  the infrastructure stays static while the expectation for the number of devices and the amount of data per device is increasing exponentially
• BYOD and IoT:  2.4 GHz will unfortunately be with us for a long time
• Cabling infrastructure is key 

I've been invited to give an hour long version of this talk at the CWNP conference in San Francisco in September 2015, so I'll be expanding on all of these topics.  

Daft WISP's Get Wi-Fi

Daft WISP's Get Wi-Fi
A parody of Daft Punk's "Get Lucky"
Written by Jason D. Hintersteiner
Copyright 2015


VERSE 1:
All the hope of good deployments
Depends on execution.
What keeps the data streaming
Is successful integration.

CHORUS:
We've come to far to leave nodes on 2.4
So let's run a scan.  We need a channel plan!

She's deploying AC wave 1,
I'm not getting cabling done.
She's got firmware updates to run.
I'm up all night to get Wi-Fi

We're deploying AC wave 1,
The cabling's not getting done.
The firmware updates won't run.
We're up all night to get Wi-Fi.

POST CHORUS:
We're up all night to get Wi-Fi.
We're up all night to get Wi-Fi.
We're up all night to get Wi-Fi.
We're up all night to get Wi-Fi.

VERSE 2:
The customer's mood is sour
My laptop's got no power
What is this I'm surveying?
The signal ain't penetrating.

CHORUS (repeat)
POST CHORUS (repeat)

Wi-Fi Bridge:
We're up all night to get...
We're up all night to get...
We're up all night to get...
We're up all night to get...

We're up all night (to get back strong sigal)
We're up all night (let's get back strong signal).
We're up all night to get online
We're up all night to get Wi-Fi.

POST CHORUS (repeat 2x)
CHORUS (repeat)
POST CHORUS (repeat 2x)

The 2.4 GHz Wi-Fi Wasteland

The 2.4 GHz band is ludicrously over-saturated with both neighboring Wi-Fi networks and non-Wi-Fi devices (e.g. Bluetooth, microwaves, etc.).  Walk into any mid-rise or high-rise apartment building in America and look at the list of SSIDs -- if the list is shorter than 50 SSIDs, the environment is relatively RF clean.  Same is true for storefront shops and restaurants and office parks.  Pretty much every urban and suburban area in America will have some level of external Wi-Fi interference on the 2.4 GHz band.

In most practical environments, any new Wi-Fi deployment on 2.4 GHz (with any vendor) is likely going to suck.   There is only so much  you can do with three non-overlapping channels when all 11 channels are already noisy.  Usually, the “only so much you can do” involves cranking the power up to out-shout everything else, which only serves to pollute the airwaves further and tends to lead to a lot of needless self-interference as well. 

Some have claimed that 2.4 GHz is dead, on life support, undead, or the like.   Perhaps the best analogy is one of a post-apocalyptic wasteland, where all the access points are screaming and all the clients are fighting like dogs over scraps of bandwidth.   Unfortunately, the abundance of old client devices, current and new network appliances for both the consumer and enterprise markets, along with the expected onslaught of IoT devices about to emerge means this Wi-Fi wasteland isn't getting cleared out anytime soon.

Even more depressingly, 5 GHz is rapidly going to become the same type of wasteland in the not two distant future.   Two unlicensed bands enter, one unlicensed band leaves!

All About That [802.11]n

On the lighter side:  For a snowy Monday after WLPC 2015, I present a theme song for the Wi-Fi engineer.

All About That [802.11]n


A parody of "All About That Bass" by Meghan Trainor
Written by Jason D. Hintersteiner (@EmperorWiFi)
Copyright 2015

 CHORUS:
Because you know I'm all about that n, 'bout that n (no b/g)
I'm all about that n, 'bout that n (no b/g)
I'm all about that n, 'bout that n (no b/g)
I'm all about that n, 'bout that n <eight oh two eleven n>

VERSE I:
Yeah it's pretty clear, I ain't ac wave two
But I can stream it, stream it.. like I'm supposed to do
'Cause I got that MIMO MIMO that all devices chase
All the right signal in all the right places!

I see the heat maps
Drawn out in Photoshop
We know that shit ain't real
Come on now, make it stop!
If you got surveys, surveys, just raise 'em up
Cause every inch of you needs coverage,
From the bottom to the top!

CHORUS INTRO:
Yeah my client he told me "Don't worry 'bout budget size,
'Cause I need one million iPads connected before it dies!
Give me unlimited bandwidth and signal had best be strong,
And if you serve captive portals, then go 'head and move along."

CHORUS {repeat}

VERSE II:
I'm bringing dual band back
And an IPv4/v6 dual stack
Serving devices 'cross my coverage map.
<but I'm here to tell ya>
If you're only running 2.4 then your Wi-Fi will be crap!

CHORUS INTRO {repeat}
CHORUS {repeat 3x)

How many IP cameras can I put on a point-to-(multi)point link?

In many deployments, it is convenient to use point-to-(multi)point wireless links to stream IP cameras from remote locations back to a central network video recorder (NVR).   Sizing these wireless links is critical to the performance of the camera recordings.  The number of cameras per link depend on several factors, but at its simplest, it is the ratio of the average bandwidth available on the wireless link over the average bandwidth consumed by each camera.    

Specifying an appropriate wireless link:   

The available bandwidth of the link depends on numerous factors, including the technology being used (i.e. 802.11n, 802.11ac, proprietary), the frequency and channel size, and the distance.   For most video surveillance applications, the link distances are very short (<< 1000 feet), so it is generally convenient and economical to use WDS links in the unlicensed 5 GHz spectrum for such applications.

There are, of course, numerous vendors in this space offering a wide range of products at a wide range of prices.   One product that I have successfully deployed on several video surveillance applications is the EnGenius EnStation5 (MSRP of $240 per pair), which is a point-to-(multi)point radio based on 802.11n 5 GHz with 2x2:2 MIMO streams.  It is quite reliable, very easy to configure, very easy to mount, and has a measured sustainable throughput of just over 80 Mbps (1000' shot, 40 MHz channel, no interference).  

Whatever brand, frequency, and capacity of wireless link you choose, it should always be measured for the actual average throughput under sustained load once the links are mounted and online.  I generally recommend designing to use only a 50% average load across each wireless link.   This is to leave margin for several sources of variation, including:

• Instantaneous camera bandwidth consumed due to image compression ratio variations
• Instantaneous link bandwidth available due to external interference
• Accommodation of those “last minute additions” of a few cameras to the link, which always seems to happen on camera projects

It is also not uncommon for large and complicated properties to have multiple links in parallel as well as multiple links in series.   Thus, when creating a network of point-to-point and point-to-multipoint links, the load across the entire path between the demarc (where the NVR server is located) and the cameras must be taken into account.

Specifying the average load per camera:   

The amount of data streaming from each IP camera depends on several factors, including:

• Image size
  (i.e. number of pixels per frame)
• Color depth
  (i.e. the number of bits per pixel)
• Frame rate
  (i.e. number of images per second)
• Video Compression Ratio
  (i.e. dependent upon technology such as H.264, MPEG-4, or MJPEG and the image itself)
• Duty cycle
  (i.e. for cameras that only stream data when motion occurs)

Obviously, the lower the image quality (fewer pixels, lower duty cycle, lower frame rate, lower color depth), the less bandwidth required per camera, but the worse the quality of the image.   Make the image quality too low, and the recorded video will not be useful for the desired application.  Make the image quality too high, and you are consuming a lot of bandwidth that is not necessary. 

For a typical video surveillance application, I use H.264 compression with an average compression ratio of 100:1, 10 frames per second, assume a full duty cycle (though generally use the motion detection capabilities of the camera), and high color depth.  With these parameters, the average data per camera and number of cameras per 802.11n 2x2:2 40 GHz channel link are as follows:

-        1.0 MPixel / 720P HD:  1.92 Mbps (up to 21 cameras per link)

-        2.0 MPixel / 1080P HD:  3.84 Mbps (up to 10 cameras per link)

-        3.0 MPixel:  5.2 Mbps (up to 8 cameras per link)

-        5.0 MPixel:  6.4 Mbps (up to 6 cameras per link)

-        10.0 MPixel:  14.4 Mbps (up to 3 cameras per link)

These numbers need to be scaled upwards and downwards appropriately based on the parameters you are using for number of frames per second, duty cycle, and image quality.

Why not just deploy the cameras wirelessly?

I'm often asked about deploying remote IP cameras wirelessly by deploying access points and using the camera's built-in Wi-Fi capabilities.  I am usually very resistant to such plans.   First and foremost, you still need to get power to the camera, so a wire (typically a CAT5e cable with a PoE injector) always needs to be run to the camera. More importantly, even for high-end and expensive IP cameras, the vendors usually incorporate the cheapest 2.4 GHz only chipsets they can find.  Thus, in addition to being very poor Wi-Fi clients, the 2.4 GHz band is generally extremely crowded with a lot of external interference, making it quite unsuitable for any real-time streaming video applications.

Hence, for remote camera applications, always deploy point-to-(multi)point links and use the wired Ethernet link on the camera to provide both power and data.  When the remote location has two or more cameras,  deploy a PoE switch to power both the cameras and the remote end of the point-to-(multi)point link, so as to get full data communication and only use one electrical outlet.  For a location with only one camera, cross-connecting PoE injectors is generally more efficient and economical, even though two electrical outlets are required.

Should you select 802.11n or 802.11ac access points for your project?

The answer, as always, is that it depends on your project’s requirements and constraints.  

802.11ac is only available on the 5 GHz band – for 2.4 GHz, both 802.11n and 802.11ac access points will only provide 802.11n service on the 2.4 GHz band.    The 802.11ac standard is being introduced in multiple phases, called “waves” by the industry.    802.11ac wave 1, which is what all AP manufacturers currently have on the market, is very similar to 802.11n at 5 GHz. 

The two main (and cumulative) improvements in 802.11ac wave 1 are as follows:

• 802.11ac wave 1 allows for the use of 80 MHz channel sizes, as opposed to 20 MHz or 40 MHz channel sizes with 802.11n.   This provides over double the effective throughput as compared to 802.11n using 40 MHz channel sizes.

• 802.11ac wave 1 introduces the “256-QAM” modulation scheme, which allows for a 33% improvement in throughput compared to 802.11n by using a more complex encoding scheme to stuff more data into the same period of time.

As with all technology improvements, there are limitations:

• Since the portion of the 5 GHz spectrum available for Wi-Fi is fixed by the FCC, as the channel sizes increase, the total  number of independent channels decrease.   Accordingly, you need to ensure that you either have only a few access points, or an appropriate channel reuse pattern, when using larger channel sizes.   When using the UNII-2 and UNII-2e bands (typical for enterprise-grade access points), there are 25 independent channels @ 20 MHz channel size, 10 independent channels @ 40 MHz channel size, and 5 independent channels @ 80 MHz channel size.   When using consumer access points (e..g consumer routers/access points), the  UNII-2 and UNII-2e bands are not supported due to DFS (subject of a future blog), there are 9 independent channels @ 20 MHz channel size,  4 independent channels @ 40 MHz channel size, and only 2 independent channels @ 80 MHz channel size.    By comparison, the 2.4 GHz band only has 3 independent channels @ 20 MHz channel size.

• 256-QAM modulation requires that the signal strength between the access point and the client device must be very high (i.e. a signal-to-noise ratio of >29 dB), which is only achievable in practice when the client device is less than 10 – 15 feet away from the access point without any obstructions (e.g. walls) or external sources of radio frequency interference.

If you have the available Internet bandwidth, a reasonably clean radio frequency environment at 5 GHz,  and you want your network to have a 3 - 5 year lifespan while supporting all of the new Wi-Fi client devices that will emerge during this time frame, you should invest in 802.11ac wave 1 now for your deployments.   Otherwise, you should continue to deploy 802.11n, but expect to upgrade that network in 18 – 36 months to take advantage of the more radical improvements expected with 802.11ac wave 2.