Buckle down. Learn Wi-Fi. Get paid.

A young kid (ok, 22) came out to my place the other day to hook me up to DirecTV. I got to talking to him about his career and future plans. He presented himself very well; smart, courteous and knew that he didn’t know everything but was willing to learn. I thought to myself… give me six months with this guy and I could triple (maybe quadruple) his salary.

Why? Because Wi-Fi is one of the hottest technologies out there and we are lean for great people. Marcus Burton and I frequently discuss the need for more solid Wi-Fi people and the conversation usually ends in frustration because we need the help but can’t find the pool of talent.

There is a need and any strong vendor will pay for talent. A lot. Most of you reading this are most likely in the field already but for those of you that aren’t… A Wi-Fi SE starts at $120k and I know of some making $200k+ with commissions. No degree required but bet your ass there is plenty of study.

None of use out there started out as Wi-Fi experts. I used to deal poker and Wi-Fi friends of mine used to be TSA agents, car salesman and many are prior enlisted military. Nothing against those professions but they seldom offer $120k+ salaries, stock options and benefits. Wi-Fi does.

What does it take? First off, you do need a certain aptitude for technology. I find that most people can actually fit that role if they are properly introduced to the fundamentals. Second, you need to be able to lock yourself in a room and learn. Read, watch videos, play with the equipment, configure, capture, analyze, rinse, repeat.

It also will really fast track your Wi-Fi career if you get certified. Come to any of us in the industry with your CWNA, CWAP and CWDP and if you don’t get a job it’s because you cheated on the exams or reek of roasted garlic and rotten milk. Customers have to like to be around you after all.

If you or someone you know is looking for a career change, look no further. It could be the best move you’ve ever made.

 

GT

 

 

Speaking of Aerohive…

I’m in the middle of the North American RuckU roadshow and one particularly intense segment is competitive. Of course Aerohive comes up in conversation given the great job they’ve done in penetrating the market.

You’d think a competitive session would focus on the negatives of a product however, with one exception, I really address their story more than the products.

Aerohive’s story surrounds it’s controllerless architecture. It has two distinct chapters:

1. No central bottleneck. Back in 2007 Aerohive saw the upcoming problem with 802.11n (and now 802.11ac) standard being so fast that centralizing all of that data to one point could be problematic. Does Aerohive have the best solution to this problem? Well, I think it’s fine but it is far from end-all. Here are two points of interest:

  • One misconception that accidentally gets perpetrated is that all controller-based solutions centralize the data. False. Ruckus has controllers but doesn’t centralize the data unless you want to. Would a customer ever want to centralize (tunnel) all of the data to the controller? Sure. We have many customers that require the ability to centralize the data. I’m not talking about small customers here. I’m talking 500+ AP systems and major carriers.  Aerohive doesn’t have a controller and therefore can’t do this.
  • You could buy more controllers. Sure, this sounds crazy but if you are talking to a company that mostly centralizes it’s data (like Aruba and Cisco) then just buy more controllers. If you really like their solution then it’s the cost of doing business with them. Is it worth the cost? Just depends on what you want out of your Wi-Fi system.

2. No central point of failure. Of all Wi-Fi solutions out there their’s is the most resilient because it doesn’t have controllers. Just for fun I ask my audiences how many of them have a wired network with no central point of failure and doesn’t include redundant components. I have yet to have someone raise their hand. Your network either has single components that can fail or you have redundancy built in. If you have two controllers, each with 99.99% survivability, what are the chances that they both fail? Seriously, I’m asking. I don’t know the math but I suspect it’s a really, really slim chance. Your wired network has, at best, the same redundancy as your controller-based Wi-Fi system.

No matter what architecture your chosen system has it can NEVER increase the performance of your WLAN. The best a controller / controllerless architecture can achieve is “do no harm”. If you want to achieve phenomenal Wi-Fi performance you must start with the communication at Layer 1. Until your chosen system gets that right, nothing else matters.

Let the flogging begin. :)

GT

P.S. Want a crazy prediction? Aerohive begins selling a controller.

The Balanced Link Fallacy

Having a set of walkie talkie radios as a kid was the ultimate in cool toys. Well, except for my TI-99/4A. Anyway, just like every new plaything, we found the limit of our new form of communication very quickly. Once we reached a three or four hundred yards away from each other we weren’t able to understand each other any longer.  Bummer.

Those walkie-talkies are a great example of a nicely balanced link. They were identical; both had the same transmit power, antenna and receive sensitivity.

Transmit Power

Transmit power is the amount of power that the radio chip actually produces. Power output from a Wi-Fi device is typically measured in milliwatts (mW) or dBm. A 200 mW (23dBm) transmitter is pretty decent in a Wi-Fi access point.

Antenna

The antenna is responsible for taking the power from the chip and sending it out on to the air. Antennas typically provide gain is signal strength although they don’t have to. In the world of Wi-Fi, antennas are typically measured in dBi. Those nice rubber duck antennas that you see give about 3dBi of signal gain.

Receive Sensitivity

This is lesser known of the three factors in our link. Receive sensitivity is how well a device can hear. My wife repeatedly tells me that I’m a good listener. (“Sorry babe, what did you say?”) That means I must have good receive sensitivity.  Receiver sensitivity is typically shown in an RSSI (Received Signal Strength Indicator) chart. This chart states at what signal level a certain data rate can be achieved. Here is a made up truncated chart:

Device #1

-87dBm = 6Mbps

-84dBm = 18Mbps

-73dBm = 300Mbps

Device #2

-85dBm = 6Mbps

-83dBm = 18Mbps

-70dBm – 300Mbps

Device #1 has better receive sensitivity because it requires less signal to achieve the same data rates as device #2. (keep in mind that these numbers are negative so the closer to zero is higher.)

Defining Balance

An imbalanced link is when one device can hear better or transmit higher signal than the other. For example, let’s say that my set of walkie talkies had a “signal gain” dial on it. My brother sets his to 5 and I turn mine up to 11. Now I’m transmitting more power than him and we have an imbalanced link.

Is this link imbalance a problem? Before we answer that, let’s look at the link itself. What defines a good link with our walkie talkies? That’s pretty simple. If each party can understand the other, we have a good link. Oddly enough, this analog link is quite binary in nature. Either you can understand each other or you can’t.

When do you consider that the link failed? The link has failed when there is no longer bi-directional communication. The purpose of walkie talkies is to communicate with each other (two way) not like a radio station (one way). So, for the link to be considered broken, only ONE side of the link has to fail.

Back to the question. Is the link imbalance between our walkie talkies a problem? No, it actually isn’t. All it means is that at a certain distance, bi-directional communication will fail. The fact that one transmitter is higher than the other doesn’t actually matter. This is exactly what happens in a Wi-Fi network.

Have you ever stopped to think about what actually transpires in a Wi-Fi network when a client device can no longer communicate with an AP? I guarantee you, 99.999% of the time it’s ONE side of the link that fails first. If a device transmits and never receives an ACK, the link has failed.

Many a tech document has stated that if you want Wi-Fi to work right, you should lower the transmit power of the AP to the match that of the client. That is a terrible idea. Stream of consciousness as to why:

- The AP has much better receive sensitivity than your client. If you set the Tx power on the AP to 30mW equaling that of the client BUT the AP can hear 6dB better, you still have a seriously imbalanced link.

- Ah… now you are thinking this: If I set my Tx power of my AP to compensate for the client hearing better, now I have a balanced link. What that means is, you set the AP Tx power to 6dB higher than the Tx power of the client. Now, your AP would be transmitting at 120mW (6dB higher) and your client at 30mW. Now you have a balanced link! Perfect! Well, not really.

Bring on the meat!

Some vendors like to use dynamic (non static) antenna gain and / or transmit beam forming (TxBF) to get more signal to the client. But, if the client can’t talk any louder, does that actually improve anything? Read on!

Walkie talkie communication was quite simple. Again, we could either understand each other or we couldn’t. But, Wi-Fi brings in another factor that doesn’t exist in analog communication. Data rates.

Wi-Fi automatically adjusts data rate to accommodate the communication channel. If signals are high and everything is good, it transmits at high data rate. If there is noise and signals are weak, it will transmit at a low data rate. (There are a bunch or rates in between too) With Wi-Fi, signal equals speed and reliability. Unless you are at your maximum MCS (data rate) extra signal will improve your link speed and that equates to improved capacity and throughput.

So what happens if you have that evil unbalanced link and your AP sends higher signals than your client?  Great! I’m digging that because it gives me increased data rates on ALL downlink data. Given that many networks have 80%+ of their data going to the clients from the AP, who wouldn’t want more signal, speed, capacity and throughput?

Looking Beyond the Room

For those of you that don’t follow Devin AkinJared Griffith or Jeanette Lee on Twitter… let me give you an update. 

Effectively it is being argued that Ruckus technology (adaptive antennas, ChannelFly etc) has no effect on performance in a classroom environment because all of the 30+ iPad devices in the classroom are limited by their downstream throughput which is about 25Mbps. In Aerohive’s “Need for Speed” blog they state that these iPad consume about 80% of the airtime even though they are moving at relatively slow speeds by today’s standards. I haven’t personally tested this but I believe these numbers. 

Now, my response.

First off, I work for Ruckus and this blog is Ruckus centric. I’ll try to not make a habit of it. Promise.  

One of the things that I have stressed with all of my Wi-Fi students over the years is to look at a Wi-Fi network as a whole organic structure. Understanding the protocols and RF between an AP and a client are essential but the next step is to understand how each Wi-Fi device (STA or AP) effects each other. We don’t live in a world with one AP. 

High Density Myth #1: Adaptive Antennas (BeamFlex) doesn’t help the throughput of an iPad. 

True (yes, you read it right). If you test one iPad with one AP within 10 feet of each other in a clean environment, you’ll probably get similar results from most vendors including Linksys and Netgear. Unfortunately for those vendors, that situation only exists in poorly thought out tests.

BeamFlex is an adaptive antenna technology that customizes signals in both direction and polarity to optimize the signal for the client device. That is what BeamFlex is most known for anyway. However, one of the significant but unsung benefits of adaptive antennas is the reduction of co-channel (AP to AP) interference.

Imagine that you install one AP per classroom like is recommended by most vendors. Now you have a multitude of APs within close proximity of each other. If they follow their standard channel plan of 1,6,11 then you will have significant co-channel interference because you bought too many APs. And, don’t give me that crap about reducing transmit power for “smaller cells”. That only works so so and if you reduce the transmit power enough to make a real difference then you reduce the data rate to the client devices creating a new host of problems. 

Signal control while maintaining appropriate transmit power reduces co-channel interference while keeping data rates high. 

High Density Myth #2: Channel selection is simple

The “standard” channel plan is to use 1,6 and 11 and change channels when some arbitrary measurements hit a pre-determined threshold. Ruckus invented a technology called ChannelFly that works off of a very simple measurement. Capacity. Each AP selects the channel that gives it the best possible throughput and network capacity. It’s secret sauce how this happens but it really makes a difference. Don’t trust me, try it in real life (I hate lab environments). 

High Density Myth #3: More clients equals more APs

One of the most common and significant mistakes in Wi-Fi network design is installing too many APs. Ask any independent Wi-Fi consultant and they’ll tell you that they have, at some point in their career, turned APs off in order to improve the network. Is one AP per classroom appropriate? Only in limited cases. Many factors must be present before I recommend one AP per classroom. Many vendors arbitrarily and consistently recommend this and I do not agree with this practice. 

My Invitation

More than likely you will test each vendor’s Wi-Fi gear before you buy. I highly encourage it. However, here is what I ask of you. If you want to test one AP in a classroom that is fine but if you want to see real results, test in as real of an environment as you can. Install 6+ APs, stress them all and observe the overall network performance. 

Each vendor puts focus on solving a different problem. Some problems are real and some aren’t. Ruckus is the Ferrari/Lamborghini/McLaren F1/Bugatti/Ducati of the Wi-Fi world because that is where we put our focus. Ruckus has more Wi-Fi engineers than Aerohive, Xirrus, Meru and Meraki combined. Ok, I made that up (blogs do that) but I bet I’m not far off. :)

GT

Happy Birthday Paradox!

Disclaimer

I’ve read over my own words here and I thought that it would be good to insert a disclaimer. It isn’t normal for me to talk about a complex topic without some context but unfortunately I need to here because this is a blog and not a book. However, here are a few links that should provide some context if the subject of contention is new or a bit rusty. The first is a paper written by Marcus Burton. The second is the full meal deal, the CWAP book. Enjoy!

Now for the Beginning

The birthday paradox, also known as the birthday principle is a math equation that calculates probability of two people in a group having the same birthday (day/month). As an example, to guarantee that two people in a group have the same birthday you’d need 367 people because there are 366 possible birthdays.

Here is where I’ve earned myself some extra cash on the side and dazzled many an intoxicated onlooker. Let’s say there are 30 people in the room. I put $100 on the table and tell you that I’ll bet that two people in this room have the same birthday. Your gut tells you that you should take that bet but you are hesitant because I sound so confident. Keep your money in your pocket because I would have a 70% chance of winning. Yes, with only 30 people in the room there is a 70% chance of a duplicate birthday. This isn’t because people don’t want to go outside in the winter either. It’s all about the math. In fact, with only 23 people there is a 50.7% chance of duplicate birthdays. Why? Well, I’ll let you click the links above because I want to get somewhere Wi-Fi-ish with this blog and lots of math is a surefire way to get people to stop reading. :)

If we can assume for a minute that birthdays are randomly distributed then that makes for a great analogy to Wi-Fi. Wi-Fi uses a randomly generated number system called a random backoff timer to help avoid collisions . This is the basis for a system called contention. Two or more devices “contend” for access to the medium.

The Wi-Fi Paradox

The question is, what are the chances that a collision will occur? First, we need to know the number of possible “birthdays”. Before a device transmits regular data (not voice or video) it will randomize between 0 and 15. That give us 16 different possible choices. With that known, what are the chances of collision with x number of devices?

2 – 6%
3 – 18%
4 – 33%
5 – 50%

What that means is that if there are 4 devices contending for the medium there is a 33% chance of collision. Better stated, if you had that as a persistant situation, your network would have a 33% collision rate. That is of course unacceptable and would make for a poor Wi-Fi network.

For the life of me I can’t figure out where to conclude this thing. This is one of those discussions that will have a lot of rabbit holes and I can’t figure out when I’ve said enough. Good thing I love to talk because my writing is horrible.

Anyway, I think this deserves a follow up at some point. For now I want to leave you with a few questions to ponder on:

- Is it actually feasible and common that 4 or 5 devices would be contending with each other simultaneously (in the same contention windows)?
- Our example used the number 16 but what would happen if the randomization is with fewer numbers such 8 or 4?
- Will varying frame sizes make a difference in the collision rate?

GT

Talk faster and not so loud…

… I’m in a hurry and my head is pounding.

Ever read something a dozen times only to notice something completely new the 13th time around? Not too long ago I was perusing some boring vendor specs (chances are it was ours) and noticed something on the transmit power specs:

- 6 Mbps | 23 dBm
- 9 Mbps | 23 dBm
- 12 Mbps | 23 dBm
- 18 Mbps | 23 dBm
- 24 Mbps | 23 dBm
- 36 Mbps | 22 dBm
- 48 Mbps | 20 dBm
- 54 Mbps | 19 dBm 

As the data rate increases, the maximum transmit power decreases. I’ve actually observed this before but I never stopped to think of why. Why does the transmit power decrease? 

I’m quite fortunate that I work for a company like Ruckus. I can walk into Bill Kish’s office (uber genius CTO) and ask him this very question. Instead of trying to put things in my own words and looking like I’m some smart guy, I’m going to start by quoting Bill: 

OFDM backoff due to high peak to average power ratios of higher OFDM modulations.

OFDM signals are more challenging to amplify since with all the subcarriers you sometimes get ‘unlucky’ combinations of the values on the different subcarriers which results in high peak signal strength.  These high peaks would cause the amplifier to go non-linear, distorting the signals.  Sorta like ‘clipping’ in an audio amplifier.

This effect gets worse with higher order modulations.  So two things: for OFDM you need to turn down power compared to e.g. CCK and furthermore you need to turn down power even more for each higher order modulation.   Good radio design and good PAs (power amplifiers) can reduce this effect but not really eliminate it.”

I ran this through the GT translator and this is what popped out:

Let’s imagine that you have an audio source (e.g. your phone) connected to an amplifier and speakers. During slow, soft music (e.g. 1 Mbps CCK) everything is fine. However, when you start playing faster music like techno and house mixed together (OFDM) the chances of “too much music” coming out of your source and overpowering your amplifier increases. As the music gets faster and chances of a peak increase, the input volume to the amp needs to be reduced to avoid clipping. This is the very reason why AP manufactures sets decreasing transmit powers for higher OFDM modulation rates.

When any manufacturer tells you their maximum Tx power and EIRP that is almost always for the lowest data rates. Sure, that helps you just fine if you are trying to gain more coverage but coverage isn’t the main concern for most enterprise installations. Throughput and capacity are paramount. 

What’s the best way to compensate for this Tx power loss at higher speeds? Antennas.

Resisting… sales…. pitch…. 

:)

GT

RTS/CTS. Request to Send / Clear to Send. But, don’t remember what it stands for because it’s lying to you.

RTS/CTS is one of those protocols that is widely misunderstood. At face value it appears that it’s job is some sort of “negotiation” to determine if it’s ok to talk. It reminds me a bit of my kids. “Dad, can I ask you a question?” Well, you just did dear. :)

“Requesting” to send is a bit of the same thing. A Wi-Fi device has to send send a frame to… request to send? No, it doesn’t do that. I truly don’t want people to know or remember what RTS/CTS stands for because it is misleading.

RTS/CTS has nothing to do with requesting access or clearing the way. If you don’t believe me, well, there is nothing I can do to help that.

Ok, you’re a believer. Read on.

RTS/CTS has the same function as toast. Yeah, like hot browned bread just out of the toaster. No one (except the English I think) eat toast plain. Americans eat toast with butter and preferably with butterand jelly. So, what is the toast good for? To carry your butter and jelly. Now, if truth be told, many of us would rather just eat the butter and the jelly out of the jar but civilized people don’t do that so we drowned some brown bread in loveliness and call ourselves sophisticated.

The purpose of toast is merely a carrier for butter and jelly. RTS/CTS is just a carrier as well. It carries something called a duration value. A duration is quite simple. It’s an amount of time that we want everyone in receiving range to stay quiet. Why do we want them to stay quiet? Because Wi-Fi is anarchy and anything that can be done to fix that can be helpful. Ok, that wasn’t as in-depth as you may have liked. Go here to see one problem it can solve: http://en.wikipedia.org/wiki/Hidden_node_problem.

When a device receives any frame (including RTS/CTS) with a duration value >0 (duration values are in microseconds) it will set something called a NAV timer. If you’ve never heard of this don’t fret. It’s just a fancy way of saying “countdown timer”.

Simply put, if any device hears a duration value, it sets it’s NAV and stays quiet at least that amount of time. Wish I could do that during family outings.

What’s the difference between an RTS and a CTS? Have you ever played Marco Polo as a kid? Someone says Marco and what do you do? You say Polo. If an RTS frame is sent to you (RTS’s are always unicast) the you MUST respond with a CTS frame. RTS frames have space for two addresses and CTS frames have space for one.

RTS and CTS frames are used quite often in Wi-Fi so when you are sniffing a network (www.sniffwifi.com) and you see them just remember that they are there to help your network. Or a denial of service attack. Ah, I love Wi-Fi. :)

GT

Follow

Get every new post delivered to your Inbox.